Locative Lab

researching locative media

Mobile Web Design ~ The Series


Part One: State of the Mobile Web

http://www.cameronmoll.com/archives/000398.html

~ 02 August 2005 ~
This is the first article in the four-part series,
“Mobile Web Design”
With great pleasure I announce an unexpected but welcome adjustment to the  Mobile Web Design series: Brian Fling has assumed the role of technical editor for the four articles to be published in the series. He’s been entrenched in mobile design for nearly five years, and his love for the Mobile Web is matched only by his contempt for its current limitations.
Brian publishes thoughts and portfolio work at FlingMedia.com, and expect his recent launch of MobileDesign.org to quickly rise to the top of Mobiles’ visit lists.
Now on with the series.
A couple months prior to WebVisions 2005, I posed a series of questions to Josh Williams of  Firewheel Design. Apart from royalty-free stock icons at IconBuffet and the newly launched Blinksale invoicing app, Josh and his crew design the front-end UI for a plethora of Java apps available on Sprint and Verizon phones. So the mobile web — at least the U.S.-based one — is nothing new to Firewheel Design.
“Yo Josh,” I said, or something equivalent in friendly vernacular. “Tell me your thoughts regarding XHTML and CSS for mobile devices.”

Josh began his answer with eloquent bluntness: “Sadly, the current state of mobile browser support for XHTML/CSS makes the web standards battle that raged fiercely a couple years ago look like a cakewalk.” He continued in detail, and eventually wrapped up his answer with a blend of language half Napoleon Dynamite, half Forrest Gump: “The mobile web is pretty much like a box of chocolates.”
“Sadly, the current state of mobile browser support for XHTML/CSS makes the web standards battle that raged fiercely a couple years ago look like a cakewalk.”   –Josh Williams
Mike Davidson, who recently made the jump from Disney Internet Group to entrepreneurship, views the current mobile web in much the same vein as Josh. “Designing for handhelds, set-top boxes, and any other resolution markedly less than 800×600 is just not a very ‘fun’ designer-like undertaking at this point,” Mike observes. “It may never be.”
Or will it? After all, it’s not like the mobile web is ill-frequented. In the UK, users downloaded 8 billion pages to their web-enabled phones during the course of 2003 (source). Here in the U.S., the numbers also seem hefty, with 21.6 million people accessing the mobile web in May 2005 (source).
But what Mike Davidson and Josh Williams point to are concerns not necessarily about accessing the mobile web, but instead developing for it. And that’s where the frustration begins. The variety of screen sizes, devices, user agents, and operating platforms is astounding. XHTML and CSS support is all over the map. “Standards” are virtually non-existent.
By now, those of you in Europe and other parts of the world are wondering where all this U.S.-centric banter is headed. Take comfort knowing we, the article’s authors, fully realize we Yankees are mobile laggards compared to our Brit and Japanese counter-parts. We’re a good 12 to 24 months behind the adoption and usage rates of some of the more affluent areas of the world, and we don’t hide behind the facts.
By now, those of you in Europe and other parts of the world are wondering where all this U.S.-centric banter is headed.
However, we’re looking to the future of the Mobile Web, where’s it’s headed, or better yet, where it’s supposed to be headed, regardless of geographic differences. If by authoring this series we have any influence on the direction of that path, we’ll sleep well at night knowing we’ve completed the task we set out to accomplish.
And we’re not alone. In May 2005, the W3C, the leading consortium for the World Wide Web, announced the launch of the Mobile Web Initiative (MWI). In the official press release, W3C Director Tim Berners-Lee recognized that “mobile access to the Web has been a second class experience for far too long.” He continues, “MWI recognizes the mobile device as a first class participant, and will produce materials to help developers make the mobile Web experience worthwhile.” It may be too early to tell, but with sponsoring organizations such as Nokia, Ericsson, France Telecom, Vodafone, and NTT DoCoMo on board, there’s hope the initiative toward a more worthwhile mobile web will be a unified one.
Yet unity could inevitably come at the expense of carriers and device manufacturers, who ultimately control the mobile web user experience. If unity, even “standards”, negatively impact the bottom line, we expect W3C’s MWI will be virtually powerless against those who really write the rules — the carriers and manufacturers.
If unity, even “standards”, negatively impact the bottom line, we expect W3C’s MWI will be virtually powerless  against those who really write the rules — the carriers and manufacturers.
Further, as of this writing, OpenWave — a dominant browser developer with the second largest mobile install base and the brains behind XHTML Mobile Profile (covered later in this series) — has yet to join the party. Without OpenWave, MWI could potentially do very little. Update: OpenWave are part of MWI. See comment from W3C’s Dean Jackson.
However, if we learned only one thing from the “desktop web” standards movement in recent years, it’s that even the most behemoth organizations listen if the wheel squeaks loudly enough. And where listening ears are found, there lies also the potential for change.
However, if we learned only one thing from the “desktop web” standards movement in recent years, it’s that even the most behemoth organizations listen if the wheel squeaks loudly enough.
On that note, consider some of the more encouraging signs of mobile design and development:
•     There are three times as many mobile phones as PCs worldwide, and that gap doesn’t show any signs of decreasing
•     Virtually all phones on the market today are web-enabled
•     Google maintains a separate index for “true” mobile-friendly sites, Google Mobile
•     Mobile startups are currently experiencing large amounts of investment dollars
•     Location-based services, such as GPS and RFID technologies, are right around the corner, providing local context to web content
Need more to substantiate the jump to mobile? Try  10 Reasons to Publish to Mobile, hot off the presses and authored by Brian Fling.
So in short, we know mobile users are already accessing the web on their devices, and we can safely bet they’ll continue to do so. The question then becomes, How do we design for the mobile web? A superb question, indeed, and one that will have to be answered in Part Two: Methods to the Madness.

Part Two: Methods to the Madness

~ 12 August 2005 ~
This is the second article in the four-part series,
“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:
1     Do nothing.
2     Kill all styling and allow raw HTML to be rendered.
3      Use media=”handheld” stylesheets.
4     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.
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.”
“We think the idea of write-once-run-anywhere is a pipe dream.”  –Jason Fried
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.
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.
Regarded by many standards aficionados as the poster child of a more mobile-friendly web, handheld stylesheets aren’t as rosy as they seem.
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.
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.

Advertisements

Filed under: Uncategorized

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About

Cityscape LocativeLab.org is Ronald Lenz's research website on locative & mobile media. This is mostly an archive of blogposts I find inspiring and interesting and an overview of my work. I'm a strategist, technologist and researcher in the field of Location-Based Mobile Services and work at Waag Society, a medialab in Amsterdam, The Netherlands where I head the Locative Media research program and at 7scenes, a platform for GPS games and tours as creative director. Picture 4 Find me at Twitter, LinkedIn or via ronald [at] waag [dot] org.

RSS Slideshare favorites

%d bloggers like this: