Making a site mobile by resizing -how does it work?

Off Topic:

Remember to keep to the topic guys. No need to get personal. These are really interesting topics, so just argue your case as honestly as you can. That makes for much better reading. :slight_smile:

Not that I have any experience in making mobile web design… but if it were up to me then I make a completely separate view code. Meaning separate CSS/HTML/possibly even javascript libraries. The reason is that UI for mobile and desktop UI are completely different. For example, goto youtube.com using your smartphone. It looks nothing like desktop youtube.com. I’m sure they don’t reuse css/html/etc… Personally, I hate browsing desktop UI on my phone… so much dragging/resizing/etc… To me, I focus more on reuse of the business logic then presentation logic.

Let the user worry about data plans.

I agree w/ this statement…if you’re worried about data usage for downloading CSS then you are clearly missing the big picture. CSS also gets cached after being downloaded as well. I have bigger fish to fry then slimming CSS.

Responsive design is a direct response for the said problem. It uses media queries to improve exactly this: UX.

One must understand this about MQs, that they’re not CCs for controlling resource download.

<hr>

It’s what I’ve already said a couple of times: http://m.youtube.com

As a side note, youtube has an unfair advantage. It knows its users will have javascript enabled due to the nature of its content.

<hr>

Try that. You’ll soon change your mind. Very soon. Completely separate it’s not viable. Somewhat different, on the other hand, it is.

<hr>

They’re somewhat different. Completely different they’re not.

For example, take a look at Surface: www.microsoft.com/surface/

It’s desktop OS but it’s not classic desktop, it’s closer to mobile touch screen.

I still don’t get it… so you use this “media queries” that defines CSS definition using the same HTML content. While this sounds very good but 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.

What I’m saying is that… I don’t believe same HTML content should be delivered to desktop ui and mobile ui. 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>

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.

[QUOTE=itmitică;5111355]Simple.

You CSS build 4 tabs/pages in your media queries.[/QUOTE]

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.

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”


<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:


<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:


<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:


* {
  -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.

Nice post, Jason. On the ewi site you use this:

<meta
	name="viewport"
	content="width=device-width; initial-scale=1.0;"
/>

while on the deathshadow site it’s


<meta
	name="viewport"
	content="width=device-width; initial-scale=1.0; [COLOR="#0000CD"]maximum-scale=1.0;[/COLOR]"
>

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.

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.

O, right. You can use this for that problem:

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

Actually, I had that in my reset. Moving it into a universal selector seems to work better… as I said above:

* {
  -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.

Duh, sorry. I missed that somehow.

Off Topic:

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. :smiley:

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.

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.

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!

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.