SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 42 of 42
  1. #26
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sg707 View Post
    For example, let say I have wizard based forms. If it's desktop UI then I may display about 20 input fields per page and display the error on the of the form. On mobile, I will limit the fields to be 5 per page to reduce scrolling. So how's media queries going to help in this case?
    Simple.

    You CSS build 4 tabs/pages in a media query targeted at certain device parameters where 20 input fields are too much.

    <hr>

    Quote Originally Posted by sg707 View Post
    [...] this reminds me of false impression of i18n. For example, in united states the name order is

    first_name middle_name last_name

    in other countries it's

    last_name first_name middle_name

    another is that zip code is typically the first field of address instead of street address like u.s. Imagine if they put i18n on a Japanese book that reads right to left... Yeah it's translated to English but reading from right to left will annoy the heck out of you and probably burn the book eventually.

    Trust me.. i18n solution does squat to address this problem.
    There's an answer for that: L12y.

    But both are just concepts. It's a developer' job to make it happen. There's no magic recipe.

  2. #27
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,381
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by itmitică View Post
    Simple.

    You CSS build 4 tabs/pages in your media queries.
    Not simple. Let say I have 2 field error on tab 1 and 3 field error on tab 2. How are you going to display the error? For me, I like to show the error on the same tab where the field has been invalidated. Please don't say "I'll display it on top of the tabs". That's like saying the user "Here's are the errors! you figure out where those fields are.. I won't change my code for my customer"

  3. #28
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sg707 View Post
    Not simple. Let say I have 2 field error on tab 1 and 3 field error on tab 2. How are you going to display the error? For me, I like to show the error on the same tab where the field has been invalidated. Please don't say "I'll display it on top of the tabs". That's like saying the user "Here's are the errors! you figure out where those fields are.. I won't change my code for my customer"
    Forgetting about saying this or saying that, how are you going to display the errors for a 20 input fields where 2 field errors are on screen 1 and 3 field errors are on screen 2 without
    saying [to] the user "Here's are the errors! you figure out where those fields are.. I won't change my code for my customer"
    ?

    You're looking hard for so called one sided problems when, in fact, they're common issues.

    <hr>

    Want some proof?

    Use a mobile browser like Firefox Mobile, with NoScript, on a tablet, and go to youtube.com

    You'll see the same youtube you see on desktop, not the sniffed m.youtube.com you'll see using Android Browser, for example.

    Making a separate m.* site has a bigger potential to fail on more than one level.

  4. #29
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sg707 View Post
    I don't believe same HTML content should be delivered to desktop ui and mobile ui.
    Don't take this the wrong way, but that statement means you have completely failed to grasp the POINT of HTML. HTML exists NOT for your pretty desktop design or even to target specific devices. It exists to deliver content in a device neutral manner. The entire original point of HTML was to allow the user agent (browser) to customize that HTML so as to best show it to the capabilities of the device; be it a 22x20 Commodore VIC=20 display, a 40 column thermal printer, a 132 column DEC line terminal, 320x200 CGA video or a 1120x834 NeXT workstation! (the last of those of course being what TBL was using when he made HTML!). That's why TBL's original browser had what we today would call user stylesheets!

    We got away from that during the browser wars as presentational crap like FONT and BGCOLOR were added, and then CSS came along to get rid of all those and let you target specific devices with the MEDIA attribute; and still many people sleaze out HTML 3.2, then slap a tranny or five doctype on it and never even use the MEDIA attribute because they cannot grasp the very notion of "HTML is for saying what things ARE, CSS is for saying what they look like for that MEDIA" -- when that is the ENTIRE reason for concepts like Semantic markup, separation of presentation from content, and progressive enhancement of content to deliver graceful degradation!

    It's also why I do not advocate the idiotic "draw a goofy picture in Photoshop" first approach to web design as it's flawed thinking right out of the gate. Write your content or at the very least a reasonable facsimile first, write semantic markup for that content, then bend the content to your will making the layout with CSS... only then do you go in and make the graphics to hang on the layout. (though with CSS3 that last step is becoming less and less necessary). This process of site building results in pages that are easy to make dynamic width, easy to customize to each devices capabilities, and on the whole just plain simpler to work with and less code to maintain!

    An example of this that might help the OP is my recent (as of today) reskin of my EWI-USB site.

    The markup is semantic with a few common DIV and sandbags thrown in. I have a outermost wrapper for setting the semi-fluid width, followed by a h1 as the topmost heading so my heading orders actually *SHOCK* make sense. Horiztonal rules are present to separate sections that don't have/warrant headings. There's a jumpto OL with accesskeys that's hidden in our CSS versions of the page -- handy for opera's accesskeys menus, the main menu which has a DIV as a styling hook, a wrapper for the columns, standard DIV for the double-wrap content-first type dynamic columns, subsection DIV... sideBar DIV with more subsections, etc, etc... It's not exactly rocket science markup, but the key is nowhere does any of that actually say what it should look like. What it looks like is NOT HTML's job!!!

    I have a default screen.css for normal desktop type sites is included as just MEDIA="screen"

    Code:
    <link
    	type="text/css"
    	rel="stylesheet"
    	href="/theme/screen.css"
    	media="screen,projection,tv"
    />
    The pageWrapper is set to semi-fluid width with a fixed min-width, an elastic max-width so large font users get a wider page for thier bigger text. It's built mostly with dynamic (%/EM) fonts with few if any fixed heights, so as the fonts grow so do the areas to contain them. I avoid declaring widths on the majority of elements allowing flow, margins and padding to automatically do all my work for me -- in fact the only places I'm really setting widths are the elastic width for the column, the semi-fluid pagewrapper, and a few of the graphical design elements for the logo... and even the logo is 100% fluid width.

    Basically it's already before we even talk media queries what people are now calling "responsive design" -- laughable since that's how I've been building websites for over 6 years.

    Then the real 'responsive' comes into play by adding a simple second css file:
    Code:
    <link
    	type="text/css"
    	rel="stylesheet"
    	href="/theme/smallScreen.css"
    	media="screen and (max-width:751px)"
    />
    Any screen devices smaller than 751px gets both the original screen.css applied, then the smallScreen.css applied on top of it. That file:
    http://www.ewiusb.com/theme/smallScreen.css

    Is just about turning off things. The layout is build with floats, on narrow displays it's better to have a single columns so we just strip all the floats. Strip off paddings and borders too as they consume screen space better used for content, and kill a few of the CSS3 effects since they can make the page render a lot slower, resulting in painful scrolling on devices like the iPhone.

    You also have to add a few bits and bobs to make the iPhone not try to force their way of doing things on you... the key points for that are a viewport meta:

    Code:
    <meta
    	name="viewport"
    	content="width=device-width; initial-scale=1.0;"
    />
    Which tells it not to start out resizing all the text to what they think it should be, and to report the ACTUAL device width instead of the 'pretend' width their auto-zoom wants to use -- both of which are aids for using sites NOT designed for phones. Likewise this bit of CSS:

    Code:
    * {
      -webkit-text-size-adjust:none;
      -ms-text-size-adjust:none;
    }
    Has a similar effect for both iPhone and Windows Phone.

    It's not exactly rocket science. It's actually a clean, fast and easy way to build websites if you are already practicing semantic markup and separation of presentation from content... or if you already bothered learning what the MEDIA attribute is for and have been using it all along.

    Which of course a lot of people have failed to do all along... If you're used to crapping out inaccessible fixed width websites where you shove your 'for screen' CSS at all devices with zero separation of presentation from content, starting out with a goofy picture of a website instead of making the layout with your CSS -- basically ignoring the entire point of HTML and failing to grasp how you're SUPPOSED to have been writing websites all along, then sure -- this is an alien concept.

    For those of us who understood said concepts and have been using them for the six to eight years they've been real world deployable (pretty much since we kicked Nyetscape 4 to the curb), tossing in media queries isn't anything new and certainly doesn't warrant needing a new name like "responsive design". It's just the next logical and natural step.

  5. #30
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    23,598
    Mentioned
    411 Post(s)
    Tagged
    7 Thread(s)
    Nice post, Jason. On the ewi site you use this:

    Code:
    <meta
    	name="viewport"
    	content="width=device-width; initial-scale=1.0;"
    />
    while on the deathshadow site it's

    Code:
    <meta
    	name="viewport"
    	content="width=device-width; initial-scale=1.0; maximum-scale=1.0;"
    >
    That extra bit in blue prevents zooming, which keeps the site nicely in the viewport, but I'm not sure if it's a good idea to use it or not. It certainly wouldn't be if the fonts are too small to read. Your fonts are big enough for me to read on an iPhone, but not necessarily for everyone. Perhaps it's better to provide the option to zoom. I haven't made up my mind yet.

  6. #31
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    I'd really like to kill the maximum scale on that site, but the iPhone insists on resizing content at default making the entire layout look like ass. I HATE the idea of turning off zoom, but given the result with that removed... it's staying until I can take a closer look at why iOS is being such a PITA and enlarging all the fonts 200% for no good reason.

    I was actually a little surprised it wasn't a problem on the new site. It's actually kind of sad -- the technology in terms of coding the site is here; it's the damned browser makers ignoring it or thinking they know better than the specification that's still messing with us.

    But that's Apple from day one, anything they can do to "lock you in" to their way of doing things. Vendor lock in, Apple be thy name.

    Thankfully I've got a good Lion install running under VirtualBox now with the latest xCode and iOS simulator running in it, so I can do REAL accurate testing of that platform.

  7. #32
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    23,598
    Mentioned
    411 Post(s)
    Tagged
    7 Thread(s)
    O, right. You can use this for that problem:

    Code:
    body {
        -webkit-text-size-adjust: none;
    }

  8. #33
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    O, right. You can use this for that problem:
    Actually, I had that in my reset. Moving it into a universal selector seems to work better... as I said above:


    Code:
    * {
      -webkit-text-size-adjust:none;
      -ms-text-size-adjust:none;
    }
    I just updated deathshadow.com to match ewiusb.com -- there's still the issue of it not auto-rescaling properly on rotate, but if you load rotated fresh (refresh doesn't reset zoom) it's ok. Turning it back on allows you to pinch-unzoom anyways, and that seems to be the norm for rotating on the iPhone anyhow.

    That could just be my finding Apple's way of doing... well... anything to be a bit counterintuitive.

  9. #34
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    23,598
    Mentioned
    411 Post(s)
    Tagged
    7 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Actually, I had that in my reset. Moving it into a universal selector seems to work better... as I said above:
    Duh, sorry. I missed that somehow.

  10. #35
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by ralph.m View Post
    Duh, sorry. I missed that somehow.
    I'm long winded, people seem to miss details a lot... I have the opposite problem -- where most people go TLDR or "aah, wall of text" -- I tend to miss details in short posts on the assumption there's nothing in them.

  11. #36
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,381
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Maybe it's just me who's too stuborn to understanding this. By all means, I understand HTML is device neutral mechanism that shows the contents only. However..take this for instance. For news paper, there are a lot of contents because the canvas view is HUGE. Now, do you want to take the same content and shove into 3~4" canvas view? I'd rather show only the topics of each content even w/ new menu system. Am I the only one who thinks that the content should be different for mobile and desktop?

  12. #37
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,048
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by sg707
    Maybe it's just me who's too stuborn to understanding this. By all means, I understand HTML is device neutral mechanism that shows the contents only. However..take this for instance. For news paper, there are a lot of contents because the canvas view is HUGE. Now, do you want to take the same content and shove into 3~4" canvas view? I'd rather show only the topics of each content even w/ new menu system. Am I the only one who thinks that the content should be different for mobile and desktop?
    nope, I agree. Different problems call for different solutions. Simply echoing the responsive mentality without understanding the complete scope is ignorant and uneducated. Newspapers are a great example. Though many of those problems actually span from to much crap on the home page and rails in the first place… its a losing battle though. At least mobile gives use a chance to rethink it if nothing else. In my experience the larger the site the more practical a dedicated mobile experience seems to be. Though I do tend to believe that if your asking this question than your site is most likely not to scale that would require a dedicated mobile experience.
    The only code I hate more than my own is everyone else's.

  13. #38
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    23,598
    Mentioned
    411 Post(s)
    Tagged
    7 Thread(s)
    Quote Originally Posted by oddz View Post
    Though many of those problems actually span from to much crap on the home page and rails in the first place… its a losing battle though. At least mobile gives use a chance to rethink it if nothing else.
    That's one thing that's often overlooked with the whole responsive design topic. It's a great opportunity to ask if all that stuff on the page is really necessary. This has been discussed by quite a few people, and in one talk I watched, the presenter showed a typical desktop news page, where—amid all the clutter on the page—the only real content was a tiny paragraph right in the middle of the home page. The mobile version just had that paragraph on the home page. The question then becomes—is all that other stuff really worth having on any device? I tend to think of it as junk, and would prefer it not be there at all.

  14. #39
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    The mobile version just had that paragraph on the home page. The question then becomes—is all that other stuff really worth having on any device? I tend to think of it as junk, and would prefer it not be there at all.
    Jackpot. Spot on.

    The newspaper analogy is a cute one; I remember back in the 90's having a discussion with a print designer who considered newspapers to be horrifically bad design; one dictated not by aesthetics or even usability, but by the fact that large sheet presses without the need for anything more than one horizontal cut is the cheapest way to print.

    They're too large, bordering on unweidly. They're awkward to use -- we've just adjusted to the notion of holding it with both hands, cradling it a certain way when trying to read it, constantly giving it a sharp rustle every few moments when it flops a way we don't like...

    ... and that's before we talk information overload; there's too much on every page, content is broken across pages willy-nilly so as to fit the size constraints.

    Basically as a medium, it's flawed; NOT something to mimic and why I think most major news sites run by brick and mortar news agencies are, well... even more useless.

    If you have enough content on the page that using the same markup for mobile and desktop is an issue, you probably have too much garbage on the page!

  15. #40
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    [...]Simply echoing the responsive mentality without understanding the complete scope is ignorant and uneducated. [...] In my experience the larger the site the more practical a dedicated mobile experience seems to be.
    I find that many developers are somewhat blurry regarding MQs and they mistake them for CCs. They're not.

    Even if you find your self at a crossroad for content between desktop and mobile, both should be echoing the responsive mentality *first*. A no-brainer, really. I'd say that the responsive mentality is even more true when going for a dedicated mobile experience since mobile devices come with a lot more different display parameters than desktop devices.

  16. #41
    SitePoint Enthusiast
    Join Date
    Mar 2012
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm the OP and took someone's advice to get "Responsive web design" by Ethan Marcotte which I've started reading. The grid system I'm still having problems understanding, but I think I get the idea of using percentage values (%EM) in CSS for flexible page widths, image and font sizes related to the browser width as opposed to fixed pixel values and CSS media query to define which elements of the web page go where and what will be shown depending on the type of media (desktop, iPhone, Android, iPad etc.) in order to make a page adapt for any device.
    Correct me please if I've misunderstood the concept.

    Getting back to the confusion surrounding grid layouts: I feel that what I really need is a visual understanding of how it works before I can dive into the CSS/HTML coding. Skeleton for instance has a visual demo here, which shows numerous boxes (labelled one-eleven-two-ten-three-nine....) which resize/rearrange according to the browser width; no doubt demonstrating its responsive design. But I don't understand why there are so many boxes, what they all do and where the actual contents (text/images) go. I'm guessing they're all separate DIVs....
    It gets even more confusing when people introduce Photoshop in the process with grid template images. What on earth has Photoshop to do with designing web pages (other than editing photos, creating logos, buttons and other graphic elements), and how do those vertical lines/columns relate to the web page content and CSS code? I know that it has something to do with arranging the content side by side in a neat manner like the way a newspaper page is set up, but not much more than that.

    With all of that, what I'm trying say is that I could need a quick and practical explanation of what a web grid is.

  17. #42
    SitePoint Member
    Join Date
    Aug 2013
    Location
    California
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Responsive web design allows the web content to resize according to the device's screen size. It emphasizes more on fitting content to various screen sizes instead of shaping the content to fit the value.

    Responsive web design adjusts the width of the browser and adjusts the content accordingly. Coding lang transforms the site's web presence. To be compatible with a wide range of devices, responsive design depends on CSS media queries. But in reality, majority of the devices are not matched with CSS media queries.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •