Mobile Web Design: Methods to the Madness
~ 12 August 2005 ~
“Mobile Web Design”
Let’s cut to the chase: You’re considering retrofitting an existing website/web app to be more accessible to mobile users, or you’re planning a new website/web app and want to include mobile in the mix. What are your options?
The way we see it, your options boil down to four choices:
- Do nothing.
- Kill all styling and allow raw HTML to be rendered.
- Use
media="handheld"stylesheets. - Repurpose content, code, and images specifically for mobile users.
Following is an explanation of each method, including an unbiased look at the advantages and disadvantages of each.
Method #1 - Do Nothing
Here’s where we summon the WAP gods and pray the site renders well. Or we wait for mobile browsers to latch on to standards, while cursing the software developers in the meantime. Neither praying nor cursing is likely to do a mobile site any good, especially if done in tandem.
Jests aside, the Do Nothing method is not all that heinous, surprisingly. Two reasons fuel the surprise. First, Opera’s Small Screen Rendering (SSR) — an on-the-fly, micro-reformatting of sorts — is fairly adept at repurposing sites to fit the smaller widths of mobile screens. A website isn’t merely reduced in size, but rather reorganized and stripped down to present relevant content more efficiently. Sample screen grabs, courtesy of Opera: Nokia.com, News.com, and The Register.
Second, this approach adheres to W3C’s Device Independence principles, albeit loosely. Simply stated, the mantra of this effort is to promote “access to a unified Web from any device in any context by anyone.” Ultimately, Device Independence would include everything from desktop machines and smartphones, to screen readers, TVs, cars, watches, vending machines, and so on.
However, given the current state of the mobile web, is the cart before the horse? Sure, “anytime anywhere” is a sensible goal for the future. But what to do until then?
Jason Fried, 37signals founder, doesn’t mince words when confronting the practical issues of Device Independence. “We think the idea of write-once-run-anywhere is a pipe dream,” Jason opines. “Sure, your H1s and H2s and LIs will degrade gracefully, but it’s not just about how something looks, it’s about how something works. What’s important are people’s priorities on different platforms. People on a phone and people on a computer shouldn’t necessarily see the same thing with different paint, they should see an entirely different picture. Different form, different function, and different priority.”
Advantages of this method:
- Consistent with Device Independence principles.
- No additional effort required on the part of the development team.
- Users browse the exact same site they visit on the desktop.
Disadvantages of this method:
- Does virtually nothing to address the content-, context-, and feature-specific needs of mobile users.
- Opera and other SSR browsers function only on Smartphones and PDAs and not on the market majority “feature phones.” (Note: Opera Mini, just announced, aims to provide a browser-independent solution with similar SSR rendering.)
- Not a very compelling experience for the present-day mobile user.
Method #2 - Raw HTML, No Styling
Recognizing WAP 2.0 devices (practically all devices sold today) support XHTML in addition to WML, method #2 relies on the strength of markup sans styling to deliver a navigable, content-rich experience. The important element — or better yet, the lack thereof — is the removal of styling and images, leaving the raw, no-flavor markup. Visually akin to the Wayback machine set to 1996.
Several resources already exist that allow both the user and the developer to perform this raw rendering with minimal effort. Skweezer.net, a mobile web pioneer developed by Greenlight Wireless Corporation, has been in use since 2001. Skweezer’s freeware web portal serves its users with sites that have been reformatted and compressed dynamically. Likewise, WebJillion’s IYHY.com offers similar lean formatting. Over in the developer’s chair, Mike Davidson’s “two-minute” mobile mod allows site owners to repurpose an existing site with a domain mirror and global_prepend / global_append PHP files.
Advantages of this method:
- Properly coded sites — separate content markup and presentation styling, few inline images — tend to render well in HTML-only environments. Consider Dave Shea’s Mezzoblue, whose markup-only counterpart doesn’t look too shabby.
- Current mobile browsers override a fair share of styling anyway, begging the question, “Then why bother with it?”
- Readily viewable by a variety of user devices, and (generally) a faster download
Disadvantages of this method:
- File size may still be excessive. Markup code and text-only content can still be a heavyweight in its own right. (Raise your hand if you’re paying per KB for mobile web access.)
- Related, dreaded scrolling due to bulky content. (Raise your hand if it’s painful to scroll on your mobile device.)
- And perhaps most importantly, this method possibly ignores the content-, context-, and feature-specific needs of mobile users.
Method #3 - Handheld Stylesheets
By far, handheld stylesheets are regarded by many standards aficionados as the poster child of a more mobile-friendly web. This third method is in line with Device Independence principles, and implementation is often as easy as adding as little as one additional stylesheet to a properly coded site.
There’s certainly no shortage of resources for handheld stylesheet development, and those familiar with XHTML and CSS revel in the flexibility and control of these sister stylesheets. However, things aren’t as rosy as they seem. Handheld stylesheet support on mobile devices is currently hit or miss, more often miss than hit. More importantly, handheld stylesheets deal primarily with aesthetics, rather than content and context.
Advantages of this method:
- Developers maintain as little as one additional stylesheet.
- Aids users with a single, unified web address. No need to resort to mobile-specific URIs, such as sitename.com/mobile or mobile.sitename.com.
- Consistent with Device Independence principles.
Disadvantages of this method:
media="handheld"support is currently inconsistent.- CSS support is also highly inconsistent.
- User bandwidth costs may be excessive, as hidden content (e.g
display:none) won’t display on screen but may still be downloaded by the device. - Yet again, this approach possibly ignores the content-, context-, and feature-specific needs of mobile users. Handheld stylesheets deal primarily with how the content looks, often giving little attention to whether the content is even relevant to mobile browsing.
Method #4 - Mobile-Specific Site
Even if it goes without saying, we’ll say it again: Methods that rework only the aesthetics of a site merely to fit it on a small screen likely fail to address the content-, context-, and feature-specific needs of mobile users.
Little Springs Design refers to this issue as miniaturizing vs. mobilizing. Miniaturizing “treats the mobile environment and technology as a subset of the desktop environment.” It fails to consider the strengths and weaknesses of mobile devices. Mobilizing, on the other hand, “precisely targets mobile user needs, making [the] best possible use of technology.” Contextual user tasks — not the existing website — determine the architecture of the mobilized site.
Yet even this method has its issues. The biggest of these include added development time and file duplication. So-called walled garden sites — content repurposed specifically for a carrier or device — aren’t necessarily a long-term, ideal solution.
Advantages of this method:
- Addresses first how content is accessed, second what it looks like.
- Leaner files. Users are spared excessive bandwidth costs and generally enjoy a faster browsing experience.
- Sets the stage for the recently approved .mobi top level domain.
- Small-screen adaptation may be necessary into the foreseeable future anyhow. From A List Apart’s “Pocket-Sized Design”: “Even if the screen resolution of devices increases with time, the physical width will not be much wider than your pocket.”
Disadvantages of this method:
- Developers must maintain at least two sets of files (desktop, mobile).
- Mobile-specific sites are audience- and device-centric, which is inconsistent with Device Independence. Further, what happens when mobile devices are as powerful as desktop machines?
- Alternate web addresses are often required. This puts a strain on user recollection and resource sharing (think bookmarks, advertising).
- W3C: Say no to .mobi.
Which Method Do I Choose?
So, which of these methods is best for your particular project? If only there were a clear winner among the four methods presented here! Alas, the “It Depends” maxim rears its ugly head, and your strategy likely depends on the following:
- User goals
- Business goals
- Development resources
- Size of website/web app
- Short-term vs. long-term objectives
Consider the following diagram:
It quickly becomes apparent that there’s a relationship between speed, complexity, and value among the four methods. Method #1 is shamelessly easy to “implement” (do nothing, that is), but it’s the slowest of the four methods in terms of overall browsing experience, and it offers little value to a mobile user in terms of delivering context-sensitive content. In contrast, method #4 requires the most complex development process, but the ROI for user value and browsing speed is unmatched by the other three.
We’d be remiss if this series didn’t provide at least a nudge in the right direction when considering one of
the methods outlined here. Thus, we’ll offer advice for producing handheld stylesheets and mobile-specific sites
in Part Three: Tips & Techniques.
About the Authors
Cameron Moll is a freelance new media designer, with a passion for functional web design, clean markup, and savvy print design. Some say this one-page PDF sums things up quite nicely. Others say his website does the trick.Brian Fling has been entrenched in mobile design for nearly five years. His love for the Mobile Web is matched only by his contempt for its current limitations. He publishes thoughts and portfolio work at FlingMedia.com and MobileDesign.org.
29 Comments
Veer: Visual Elements for Creatives.Stock photography, type, and killer tees. Genuinely recommended by Authentic Boredom.
It depends on the country. The US is obviously latecomer to the game, but the numbers have steadily been increasing as consumer replace older devices with newer “feature phones.”
M:Metrics says between 12-15% of mobile subscribers.
<disclaimer>
I know absolutely nothing about the mobile web.
</disclaimer>
It seems that it would be more powerful to use server-side XML/XSLT tools to render different views of the site from the same URL, depending on the HTTP request header, than to break your content out over multiple domains. Looking at the disadvantages of #4, “Mobile Specific Site”:
*1. Two sets of files must be maintained.* Well, here again, two sets of XSLT stylesheets, which is really no different than having an additional ‘media=”handheld’ set of CSS stylesheets. Except that you have to learn XSLT. But you get the added bonus of truly semantic content structure (XML). Also, XSLT rocks. And it can easily be used in conjunction with CSS.
2. Not consistent with some abstract, academic concept of How Things Should Work. I think I can live with that.
3. No need for multiple web addresses, just parse the user agent on the server.
4. No need for .mobi
I guess the disadvantage is that you need to have some sort of backend structure and server-side scripting going on, whether it’s semantic XML files (for blogs, RSS feeds would do nicely) parsed by XSLT, or databases parsed by a server-side scripting language.
At the very worst, you can just set up your webserver to point to a different docroot for mobile user agents - this would work even if you maintained a full set of handcoded HTML for different mediums. I don’t see when the need for different URLs would arise at all, let alone a seperate top-level domain.
I know user-agent “sniffing” isn’t a great practice when it comes to coding javascript, but in this case it seems that it would work pretty well - I don’t see too many mobile phones which enable user-agent spoofing, although if Opera’s involved, who knows?
david gee: I agee with you (see what I did there?) Only thing that might be tricky is parsing the UA. hmm …
I say do nothing unless it’s some sort of news syndicated site that is averaging thousand upon thousands of hits per day. I personal have owned a treo 600 now for two years and find myself either going to espn.com for sports, cnn and yahoo for news, weather etc. Any other site, I wait til I touch down at the office.
David,
You bring up a good point. Using XSLT to do the transformation to WML, XHTML-MP and the Web is a common practice for mobile publishing companies. This approach requires using device detection based on User Agents Profiles (UAProfs) to route to the appropriate content.
Though this approach is out of reach for most web publishers anyone serious about creating mobile content should look in to it.
Brain: Why is David’s solution out of reach for most web publishers? I guess what I’m saying is it would be nice to hear the experts give a bit of a “how to” on implementing that idea.
I think there is another method that it’s not mentioned here.
I’m talking about device detection based on obtain device capacities using it’s UAprof as an identifier and comparing it in a repository of device capacities (like wurlf or similar).
Knowing the device capacities you can send an appropriate version of the site to each device (one in wml, other in xhtml-mp, other in chtml, other with handheld css, javascript, different content, etc.)
This approach doesn’t need to use different url for mobile version, and doesn’t force developers to maintain more than one set of files.
Great article. #2 and #3 need to be swapped in your chart though. Simply using a handheld stylesheet is slower, not faster, than raw, compressed, simplified HTML (and it’s slower to develop too).
With CSS, you have the additional bandwidth overhead of the CSS file itself, as well as a larger HTML file, as well as any images you may decide to load. The only argument one could make that says the CSS route is faster is if you hide a ton of elements on the page, thus decreasing scrolling… but even so, you’re still loading the HTML for those elements. I don’t think scrolling really slows you down either… it’s certainly better than pagination where I have to keep hitting “next page” every 10 seconds and hitting the server again.
you could say I am living under a rock. in any african country the normal response to mobile media development is normally: “HUH?”
I could start learning this in 5 years time and still make a packet in the future.
Bah… nevermind my last comment. It would mess up the nice pyramid shape. 2 and 3 are in their correct places on the “complex/simple” continuum at least, so let’s leave them there unless you want to do some crazy geeky 3-dimensional chart that totally complicates the point.
Shutting up now…
Hey cam,
Tell us about the calendar on the Hiram site. Is that your work? How about a tut?
Wait to hear back.
cmp
Mike D - Yeah, it isn’t a perfect diagram, but still holds up for all three (speed, complexity, value).
Mel - A bit off topic, no?
Awesome entry…I’ve always wanted to learn more about designing for mobile web. I’m actually working right now as a tester for Verizon, and I work with a lot of WAP 1.x and WAP 2.0 testing on handhelds. It’s kinda disappointing to see so many beautiful CSS/Web Standards sites broken up and unusable from a handheld pespective.
I think probably the best site i’ve seen so far on a handheld browser is ESPN.com, and they work with developing a mobile web specific site. Well, I can’t wait till you’re next entry. Keep up the good work.
You’re considering retrofitting an existing website/web app to be more accessible to mobile users
That’s the first mistake and it’s a big one. There’s really very little reason to retrofit an existing website to mobile. Mobile should have its own apps tailored for whatever makes mobile compelling.
pwb - Sounds as though you may have read that first line only and then jumped straight to the comments, perhaps skipping the discussion that covers the points you suggest?
Awesome article. I love the method comparison diagram. Interesting, that prior to mobile I was very against separate versions. But I’ll admit that mobile is so different that separate versions really do appeal to me (despite the higher cost).
We are working on a “walled garden” for out university community. You can take a sneak peek at the TEST version of UT Mobile
I’m most excited about the Campus Maps that my buddy Lewis Phillips is developing. We’ve got a HUGE campus, and being able to access a map designed for my mobile phone while I’m feverently looking for a building is sweet beyond sweet! Way to go Lewis! Who ever thought I’d want map pictures on my phone???
Campus maps?! Now there’s a wise use of mobile content. I would have killed for campus maps on my cell back in the day…
Wow — you’ve really thought this one out. For me, regardless of the complexity issue, option four is the only way — designing for the way the site will be accessed. Or maybe do nothing.
I wrote about this a while ago, since I noticed one day that sites using an XHTML DOCTYPE render rather poor on older phones (in my case a Sony Ericsson T630).
very well said David
I may be young, but I do not know one soul who surfs the web using a handheld. I know most of my stepfather’s friends, and he’s a computer geek, and I still have not met or know of a person that uses handhelds for surfing the web. Right now, I would do nothing because redesigning a website so people with handhelds can see a website that is meant for at least a 15” screen seems proposterous. Everyone wants the most traffic possible, but right now it seems that handheld web traffic doesn’t make up very much of the overall traffic.
I’ve done a PDA view of my web site, no style sheets. Just html. It makes my blog look more like a default blog out of the box. It’s all one column and I include the comments. I leave out most of the extra fun stuff from the sidebars.
I’m sure the extra stripped version of this is perfect for the visual impaired, not a lot of extra junk, and something easy for the synthesizers to read.
http://garysaid.com/pda/
I make one big assumption, I assume if they don’t want graphics, they’ve got them turned off or bit depth lowered, because I’m not the only one feeding them graphics.
As I said I also include the comments, assuming once they’ve loaded the page they’d rather scroll past them then do the click/back thing, especially if they’re on a slow connection.
If you leave the page you get pages that while not formatted for the PDA do load pretty nicely. I felt it was important to include the links in case someone really want to see other posts in that category or make a comment of their own.
I also include a link (http://garysaid.com/pda/synctop.php) so if they sync with their PDA with something like AvantGo, it gives them a little more since if you grab everything from a link down you’re all set.
It’s worked well for me so far, so I thought I’d share.
Gary
http://garysaid.com/
For a fairly advanced example of the use of media=”handheld”, check out www.opera.com and my.opera.com.
Browse those sites with Opera 7 or newer on a PC. Then hit SHIFT-F11. This will tell Opera to go into what we call “handheld mode”, rendering the site with the handheld stylesheet. If no such stylesheet exists, Opera will instead reformat the site with the Small-Screen Rendering technology so it fits within the width of the screen or window.
Opera on mobile devices defaults to “handheld mode”. (SHIFT-F11 on the desktop version is basically emulating the mobile versions of Opera.)
Note that Opera for Mobile will disable SSR for sites written in WML, XHTML MP and CHTML (declared in DTD). The assumption is that when an author has used one of those mark-ups, he has also designed specifically for the mobile form factor. Not perfect, but the best compromise we could come up with. Otherwise, sites which are mobile but do not have media=”handheld” would have been reformatted needlessly.
To summarize, here’s the default rendering Opera on a small screen device:
1. Site written in XHTML MP, WML, CHTML —> rendered as designed
2. Site includes media=”handheld” —> rendered using handheld css, display:none elements are not downloaded
3. All other sites —> reformatted to fit screen width with SSR. Can be disabled by user.
I enjoyed your site so much so i have to say it to you. Soft voice over the net: http://interactive.usc.edu/members/students/2005/09/carcassonne.php , Naked truth
Very original content. I really like your site. Fantastic blog: http://www.yioni.com/2005/10/what-to-do-with-this-site.html , Soft voice over the net
Excellent series (and site). Do you have an ETA on the third and fourth articles?
Hava - hoping any day now. Part 3 is finished and currently under final editorial review.
good stuff…
Authentic Boredom is the platitudinous web home of Cameron Moll, freelance new media designer, author, and speaker. More…
Full-time and freelance job opportunities. Post a job...
A selection of fine reading, available for a limited time only:
- Jobs home page reorg
- Coming soon: Mobile Web Design, the book
- Dyson ad: Text as more than just words
- Setting sail for Europe
- Review: Sumo Omni bean bag chair
- Dashboard widget for Authentic Jobs
- Limited-time offer: $99 listings
- Nine skills that separate good and great designers
- Fire sale
- Introducing AuthenticJobs.com
CSS Mastery: Advanced Web Standard Solutions A solid round-up of indispensable CSS design techniques by Andy Budd, Simon Collison, and Cameron Moll.
Mobile Web Design A guide to publishing web content beyond the desktop. Tips, methodology, and resources. Now available.
Letterpress Posters The unassuming beauty of a freshly letterpressed print.
That Wicked Worn Look. Techniques for that worn, aged, distressed look.
Mister Retro Machine Wash Filters Turn the dial to “Instaworn” with these filters.
Blinksale Dive in and enjoy shamelessly easy invoicing from Firewheel Design.
Basecamp My preferred web app for internal and client project collaboration.
HOW Conference Austin, June 24–27. Pentagram, Adobe, P&G, et al.
Web Design World Seattle, July 20–22. Practical sessions on web design.
Stimulate Salt Lake City, September 2009. Entrepreneurship and design conference.
Linkage:
Follow me: 
1 Miko ~ 12 August 2005 at 03:47 PM
Do we know the stats of users browsing on mobile devices? Of course, it’s on the rise - but is it currently in a low percentage?