Mobile website design

Is it worth changing markup language for a mobile version?

[lzr0]

Hi,
Since nowadays most smart phones can display regular html pages (and regular AdSense), is it worth designing mobile version of a website with xhtml or other special markups?

Besides optimizing the layout, images and font sizes, what else makes sense to do for a mobile version?

[tedster]

If you feel you have a potentially significant mobile audience, I'd say it does make sense. There's a lot of guidance available from the search engines on the kind of thing that makes for a good mobile page - starting with a mobile doctype. Here's a good place to start: [support.google.com...]

There are still a lot of feature phones out there (as opposed to true smart phones) and getting your site to show up for these phones when they use mobile search most definitely requires strict development principles, especially with regard to file size. If the page is too fat, then it won't show in mobile search for feature phones.

What you actually need to throw resources into in any particular case all depends on the site's audience.

[pageoneresults]

is it worth designing mobile version of a website with xhtml or other special markups?

For us, it's worth it. But, we're not doing a special mobile version. We'll be using Media Queries and producing a Responsive Design, one which dynamically adjusts to the users device settings. It's really cool how it all works.

Media Queries
[MediaQueri.es...]

Take a close look at the above examples. Resize them in your browser. View them on your mobile device or tablet. That's the future of websites. You'll be able to view them on any device, no matter what size the viewport is.

Remember our old <table> designs that would resize based on the users viewport dimensions? We called it fluid design back then. ;)

Note: It's not only a mobile audience, it's a tablet audience too. And then you still have us PC users with large displays. Imagine being able to serve a user friendly version for every possible display size?

Is it worth changing markup language for a mobile version?

It's not just a markup change. It's a change in thinking from a design perspective.

[Hoople]

It's not just a markup change. It's a change in thinking from a design perspective.

Very true. Two years ago my server logs showed a slow upward trend to larger screen sizes. I was getting to the point of abandoning all testing at 800x600 and below.

The first clue I had to mobile taking a design priority was 320x480 overtaking 768x1024 as the top screen size (by visitor count). Since that time that site has a myriad of new resolutions showing up like: 480x360, 320x488, 320x240, 800x1183, 320x452, 800x1220 and 320x508. Not seen in the top 10 - 1280x1024 the 'displaced' top screen size.

As a quick fix I did a minimalistic implementation of <meta name="viewport" content="width=device-width, initial-scale=1.0"> and CSS max-width:1024 on the only page served (to all - no mobile specific page made). Then I did a lot of testing with mobile browser emulators and real devices. More on meta="viewport" [developer.mozilla.org...]

Where I saw some wonky screen reflow behavior I made some minor tweaks to the markup. These changes didn't greatly change the larger views but helped the mobile view look more 'polished' in nature. Several of my human testers remarked that they liked it being viewable right off in that they didn't have to pinch re-scale the page to begin to read it.

[lucy24]

There's also the w3c "mobile OK" validator:

[validator.w3.org...]

Depending on your audience, some things can be ignored. Notably, the iPad can take anything you throw at it, so long as the picture doesn't get too small for human eyeballs. But it gives you things to think about.

But you're not designing for a continuum of screen sizes. It's either a monitor (say 800-and-up) or a mobile (say 500-and-under).

[pageoneresults]

But you're not designing for a continuum of screen sizes. It's either a monitor (say 800-and-up) or a mobile (say 500-and-under).

Ah-ha, it's not the screen size one needs to be concerned about, it's the viewport dimensions. I'm tracking those via GA and they are all over the place. For one site, this month, there are 700+ viewport dimensions being reported. I think we are designing for a continuum of viewport dimensions. :)

How do we track viewport dimensions in GA?

 _gaq.push(['_trackEvent', 'Viewport', 'load', $(window).width() + 'x' + $(window).height(), $(window).width()]);

^ Shows up in GA > Audience > Technology > Browser & OS > Screen Resolution

The smallest I see is 122x146 and the largest is 3840x1024 and then there is "everything" inbetween.

[lzr0]

Thanks all for your input.

As a quick fix I did a minimalistic implementation of <meta name="viewport" content="width=device-width, initial-scale=1.0"> and CSS max-width:1024 on the only page served (to all - no mobile specific page made).

Yes, I've tried this too on regular html pages. Just don't know what to do with a banner and wide images.

[pageoneresults]

Just don't know what to do with a banner and wide images.

You can set image widths in percentages which allows them to scale with the viewport. There some calculations involved but once you get the hang of it, it's pretty cool.

[lzr0]

You can set image widths in percentages which allows them to scale with the viewport. There some calculations involved but once you get the hang of it, it's pretty cool.

I have an image inside a <div> container, and I set image max-width:100%, so the image scales down with viewport. However, i understand that both no definiting image width and forcing the browser to scale the image slows down the page loading. Unless there is a better way to get around it, I am thinking of not displaying the image in mobile browser at all, if I can found out how to do it with a javascript.

[pageoneresults]

I have an image inside a <div> container, and I set image max-width:100%, so the image scales down with viewport. However, i understand that both no definiting image width and forcing the browser to scale the image slows down the page loading.

The sites that I've been using as a model for Responsive Design are not defining image widths (see [BostonGlobe.com...] They're using one large image and scaling down to fit which is what my example does. What I've done is define my max-width based on the original image size e.g.

<img style="width:100%;max-width:1200px;" src="" alt="">

And then I've optimized the original 1200x900 using a Fireworks compression routine which allows you to make BIG images small in byte size while maintaining quality. Yes, I realize that this may not be the optimal way to serve the images but it appears to be the trend. I figure if I optimize the original to be as small as it can be byte wise, I've done my best to keep things optimized for the mobile visitor.

I would guess that you could serve multiple images via Media Queries and JavaScript. You'd end up with 2, 3, 4 or maybe even 5 image sizes based on your targeted viewports. As the viewport changed in dimensions, the image reference would also change to use whatever image size is closest to the target viewport.

I've still got much to learn. This is really the first time I've worked with images in this manner. Up until now, we've usually served 3 different images; Small, Medium, Large all with fixed dimensions. I think using one highly optimized image is the way the go if you're working with image sizes of 1200px or less. Most folks are going to be working with images half that size or less.

[tedster]

I'm thinking that the image scaling features of the mod_pagespeed Apache module [code.google.com] might be a very efficient approach for serving images variations for different devices. Essentially, the server only sends the number of pixels that the device needs for jpg and png formats.

[justa]

There a w3c group looking at serving adaptive/responsive images.

Most solutions currently involve loading a smaller image first (mobile first approach) and following up with a hi-res version from the data-src attribute.