The Web Beyond the Desktop

In: Articles

By Dave Shea

Published on April 1, 2008

Digital video recorders such as Tivo are popular, in part, because they introduced an idea to TV viewing called time shifting. You no longer need to rush home from an evening out to catch the newest episode of Lost at 9pm—instead, just instruct your DVR to record it while you’re gone, and enjoy it later at your leisure.

For the viewer, time shifting has been a dramatic improvement over the traditional experience of watching TV. The web is about to experience as dramatic a shift in place for the user of a website, which will inevitably affect the way we design and develop web sites and applications in the future.

Fragmented Environment

For all the multiple environments, cross-platform concerns, and varied use-case scenarios we take for granted when building on the web today, the fact is we still make some fundamental assumptions about how the users of a site or application are interacting with our work.

In our mind’s eye, we picture a place and a device. The place: users are sitting at a desk, or a table, or some other hard surface where their bum is firmly in a chair and their hands are at a comfortable 90-degree angle to their work surface. The device: maybe they’re using a desktop PC, or a Mac, or a laptop computer running Linux.

Building on these two assumptions, there are things we take for granted: they must be running one of a few browsers; they enjoy (increasingly larger) full colour displays; and they interact with their computer using a keyboard and a mouse—except, of course, for those using voice recognition and screen reading software.

And developing for this environment has become reasonably comfortable; we’ve figured out the big issues, we know a lot of what works and what doesn’t. Common practices and industry conventions have taken much of the guesswork out of building for today’s web.

But this monolithic environment under which most users operate is beginning to fragment, and our safe assumptions are beginning to look like less of a sure bet. If you know where to look, you can already see this happening.

Rise of the Devices

Let’s start with the recent news of mobile Safari’s market share. According to StatCounter, it accounts for 0.23% of web traffic (as of March 2008). A fairly small percentage, to be sure, but this is in relation to all browsers and not simply a subset of mobile browsers. When you consider the hundreds of millions of people using the web daily, that number translates to a lot of individuals, and we’re still only at the start of a very large adoption curve.

Mobile phones have traditionally been a poor environment for web browsing, which has meant few users bother to do so. The iPhone and iPod Touch version of Safari is a mobile browser capable of rendering web sites as faithfully as any desktop browser, however. It’s a first-class web browsing experience, not a tacked-on checkmark in the device’s feature matrix—and the numbers prove that those who own these devices actually are using them to browse the web. Given Apple’s success, you can be assured that we will start seeing similar momentum from other devices as their browsers catch up.

But it doesn’t end with phones. Did you buy a gaming console from Nintendo or Sony in the past year? You probably have a browser on it. How about a device like Amazon’s Kindle or Nokia’s N800 tablet? Other devices with screens are getting smarter and smarter all the time; the Chumby is a web-connected widget display screen and browser; recent thermostats can provide weather forecasts; some watches and digital cameras come with data services; and LG even has a line of household appliances with web access in the works.

If a device has a screen and the ability to connect to the internet somehow, it will very soon come equipped with a web browser—or some ability to render web content like widgets—if it doesn’t already. The iPhone example shows that if the user experience is good enough, people will use them, and they will do so to the point of shifting a large percentage of their desktop web use to other devices, in places and situations far removed from the assumed computer-on-desk context we take for granted today.

Place Shifting

But, as the place and time of web usage changes, so too do conditions and constraints. Interacting with a smaller device may not be as easy as interacting with a desktop. Lighting and viewing conditions are not equal between indoor and outdoor environments. And a desktop assumes the user’s attention, but other contexts may critically divide attention.

Device viewing scenarios

	In the Street	In Restaurants / Cafés	In Transit	In the Living Room	In a Car	In Bed
Attention Level	Distracted	Intermittent	Focused	Focused	Intermittent, Dangerous to Focus	Focused
Viewing Conditions	Variable, Poor	Good	Good	Variable	Poor	Good
Motor Skills & Input Ability	Variable	Good	Good	Variable	Poor to Non-Existent	Good
Information Needs	Immediate: directions, maps, alerts & lists	Basic to Full: headlines & summaries, quick lookups	Full: more available time to process longer articles	Full: entertainment- oriented content	Immediate: directions, maps, alerts & lists	Full: more available time to process longer articles
Viewing Privacy	Little to none	Some	Little to none	Complete, but potential for shared experiences	Complete, but potential for shared experiences	Complete, but potential for shared experiences

Tailoring our web sites and applications to these contexts may prove difficult or even impossible in a general sense. For example, if we were to build a single mobile site that serves more immediate information-gathering needs while assuming very little focus on the user’s part, it may cover some needs, but would ultimately frustrate users wishing to dig deeper into the content.

But this may be out of the designer’s hands entirely; the devices themselves might be a better place to respond to these scenarios, with software serving as an interpreter between the user and the site or application:

• Car audio systems that speak aloud the menu items from the restaurant to where the user is driving instead of showing it on a display, to keep visual attention focused where it matters.
• Auto form-completion utilities that store a user’s contact information and will selectively fill out standard form elements, to save the frustration of entering the same text on a small keyboard over and over again.
• Camera-equipped devices that recognize QR codes, to make entering URLs far easier.
• Lightweight, microformat-savvy web search applications that only return vEvent or hCard results, when the user simply needs a place or an email address on the go.

Software interpreting web pages for the user? Hey, that sounds familiar. The knowledge we already possess of interpretive devices and software that aids accessibility will equally apply to the non-desktop web. Building accessible web sites and applications already improves usability for all users; given the constraints of viewing and input limitations imposed by mobile devices, accessibility improvements will benefit these devices as well. Practices like increasing link target areas for those with mobility impairments, or facilitating font size adjustment for those with vision impairments, also provide obvious benefits to those using mobile devices.

Browser Landscape

On the desktop web we have four significant browsers to account for these days—maybe a couple more or less depending on your target audience—but for the past decade, there has been very little consistency between browsers and operating environments on mobile phones, with hundreds of devices and perhaps dozens of proprietary browsers. However, if we look a little further and include non-phone devices in our criteria, some trends emerge.

There are currently three major browsers with strong support for modern web standards and technologies that are available on a wide enough array of devices and phones to be statistically significant:

On-device browsers

Browser	Description	Devices
Opera	For years, Opera has been making browsers for devices. Opera Mini is available for almost any mobile phone that runs Java.	Nintendo Wii and DS, Nokia N800, many mobile phones
WebKit	WebKit is the open source rendering engine powering desktop Safari and Apple’s touch products. Nokia is releasing phones with WebKit, and Google chose this engine for their upcoming Android platform.	iPod Touch, iPhone, Nokia, Android phones (future)
Netfront	Did your mobile phone come with a browser? Chances are that browser is NetFront, produced by a Japanese company called Access. Starting life as an extremely simple HTML rendering engine for underpowered mobile phones, recent versions have evolved into a fairly capable browser that can faithfully render many modern web sites.	Countless mobile phones, Amazon Kindle, Sony Playstation 3 and Playstation Portable

Designing for the Device

Unfortunately we don’t have a bag of quick fixes at our disposal that will make everything magically work on any device; this is relatively new territory even for those of us who have been building web sites for the past decade or more. But we can start looking at some of the most obvious issues we’ll be facing on the device-based web, and how we might potentially design with these in mind.

Screen resolution

Layout on differing screen sizes is an obvious place to start thinking about design concerns. What happens when you throw a web site built with desktops in mind at a mobile device? Designers have spent the last couple of years pushing beyond the old “limit” of 800×600 and building much wider designs, but traditional screen sizes are becoming less relevant given what’s around the corner:

An obvious solution is to simply allow our designs to expand and contract between all possible ranges, but it doesn’t take a lot of thought to realize that designs perfectly suited for small screens don’t scale well to larger screens, and vice-versa. A site optimized for a 160×240 phone display simply doesn’t work on a 1920×1080 HDTV display. Take Facebook’s mobile sites for example; they’ve built a generic mobile site, and a second optimized to display on Apple touch devices:

Both work well on their respective devices, but try viewing either in a browser on a wide-screen display, and the waste of space is problematic:

It’s pretty clear that we need the ability to modify our sites and applications to look and function differently between these environments. Luckily, CSS has had this ability all along, in the form of media types. Unfortunately, not all devices support them as you might expect: the mobile version of Safari doesn’t render the handheld media type for example, opting for screen instead; Opera Mobile has followed suit by doing the same. Without that fundamental browser support, what use are media types? Not so much.

I recently wrote another article exploring server-side methods of selectively dishing up style and content based on the device with which a user is browsing. While writing, I stumbled across a design principle that throws the fundamental assumption of media types out the window: just because a user has a specific device, that doesn’t always mean they want the version of your site that’s tailored to their device. Sites like mobile Facebook and Twitter provide links in the footer to allow the user to switch back to the regular version. In most cases the mobile version is good enough, but every so often users may need access to something you’ve chosen not to show to mobile devices—or they may just prefer to browse the full version anyway, since the very capable browser on their Wii or iPod Touch can handle it. A simple link back to the regular site takes very little developmental overhead, but can make a big difference to the end user.

It’s also worth keeping in mind that browsers are increasingly incorporating tools that allow users to more easily navigate large web pages. Miniaturized full previews of pages are zoomable by moving a viewing window cursor around and clicking to view the selected area in more detail (see this in action with the Opera Mini demo), or using simple finger gestures to zoom in and out, as on the iPhone. Some users may prefer to browse this way, underscoring the importance of allowing devices equal access to a site’s full version.

User Interface & Interaction

Take one of your most basic user interface elements on the web today: breadcrumbs. Breadcrumbs are navigation elements on a site that create a sense of location. Though a user may choose to actively engage them to navigate through a site’s hierarchy, they work best as a form of persistent awareness. But consider what happens to breadcrumbs when a device’s browser shows the entire page at once. Typically it will be zoomed out to facilitate the full width on a smaller screen, resulting in shrunken and often illegible text. In order to read anything at all, the user must first zoom into the page—only then are they able to read the breadcrumb trail. That zoom requirement is enough to significantly alter the primary utility of breadcrumbs; while they still work as a navigational device, they completely fail as a piece of ambient information in that scenario.

Pagination is a more active interface element; a user is expected to interact with pagination controls to view more information. In that regard, zoom level doesn’t matter nearly as much, but target area does. With Fitts’s Law in mind, consider the scant few pixels of clickable area of an individual pagination item on Google’s search results pages. Now try to place your finger over just one of those items. Even with reasonably slender fingers, it’s obvious that using a touch screen to access those is a much more difficult task than using a precise mouse cursor.

Most pervasive may be the pain involved in entering text in form fields on a device that has a small physical keyboard, or a touch screen or some other form of software keyboard. Typing is typically much slower, and concepts that are second nature on the desktop may not be available. Think of the controversy surrounding the iPhone’s lack of copy and paste, an action so fundamental in our daily interaction with our computers that we never think about it—until it isn’t available.

The above examples offer us a brief glimpse of how the device-based web requires adjustment in our thinking, or perhaps even brand new interface elements entirely. Back in the early days of the GUI, an acronym was coined to describe the various elements that make up the computer interface: WIMP, which stands for Windows, Icons, Menus, and Pointers. We still use all those elements on the web today, but they’re awfully specific to a desktop environment.

Windows work best with ample screen real-estate and easy user manipulation. In small screen environments that afford limited mobility, windows are more of a problem than a solution. Our pointing devices are no longer an easily defined cursor on a screen, and in the case of touch screens we have no visual representation of a pointer at all. Events tied to classical mouse-based systems make little to no sense: onmousedown, hover, and dragging/dropping for example. Even icons are problematic on the device-based web: as purely graphical items on a page, we can’t rely on them being present in all situations. Data rate costs for mobile devices are far more likely to force a user to disable images than on the desktop web.

In the desktop space we’ve had decades of evolving user interface best practices that work reasonably well across platforms and browsers. In the device space, many of those bets are off due to their drastically different nature.

Summary

Thoughtful consideration of the context in which users are accessing your work, the devices they are using, and the limitations that go hand-in-hand will be increasingly important design requirements. Web projects that adapt to meet those needs and work around the limitations are becoming more common, but building them this way doesn’t come without a cost. The increased complexity of developing a site or application that differently targets various media types will require a larger initial time investment and more involved maintenance over the life of the project, inevitably increasing overall development costs.

Sites and applications with dedicated teams and large user bases accessing them on non-desktop devices may find it trivial to justify the the extra investment, but not every site or application will demand that same level of involved attention. For those that don’t, relying on the devices to catch up with current web technologies and solve user interaction problems may indeed be the only, though perhaps not the ideal, strategy.

In either case, an awareness of the increasingly diverse methods and devices that people will be using to interact with the web is a fundamental first step toward building truly universal sites and applications.

This article is adapted from Where’s Your Web At?, a presentation given by Dave Shea and John Allsopp at Web Directions North, January 2008.

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Technology, Planning, Navigation, Interaction Design, HTML, Globalization and Internationalization, Convergence, Content, Browsers, User Experience, Web Design, Web Guru, Web Standards