- The ever-widening world of the web
- The landmines of Web 2.0
- Progressive enhancement to the rescue
This chapter is from the book
This chapter is from the book
This chapter is from the book
The landmines of Web 2.0
Many of the more interesting and engaging features in the explosion of Web 2.0 sites and applications developed in the past decade are supported by JavaScript for rich interactivity, Ajax for dynamic data, and advanced CSS.
These advances paralleled the launch of scores of different desktop browser versions over the past decade—and this doesn’t take into account the vast array of web-enabled devices and mobile phones in recent years. While many contemporary browsers embrace web standards, they don’t render the web uniformly, and collectively require a complex system of coding, testing, and occasional hackery to get sites to appear and function in a consistent manner.
There are a number of common web design and development trends that are under-mining the promise of universal access that the web is built on.
Browser tunnel vision
To make development and testing manageable in the real world, all companies and individual developers (ourselves included) focus their coding and testing on a specific set of browsers. This is reasonable from a contractual perspective: clients ask us to commit (in writing) that our code will look and function exactly as designed, and we know that not every browser can handle the styles and scripting that a modern site design requires. So part of our agreement involves testing the code in some agree-upon list of browsers or environments, depending on the project.
But what about all the users who aren’t using a supported browser? Is it acceptable to exclude them from accessing the site and display a message asking them to upgrade their browser? Many people don’t upgrade their browsers—either because they’re not technically savvy enough to upgrade, aren’t allowed to install software on their machines for security reasons (especially true in corporate environments), or are tied to a legacy browser because a crucial-to-them web application works only in that specific browser.
It’s easy to dismiss users in non-supported browsers as unimportant because they represent a marginal percentage of the audience, or because it’s assumed they are generally less savvy or technically adept and, therefore, not a target user. But poor browser capabilities are not limited to outdated devices or to Luddites: Amazon’s Kindle, a device commonly considered to be “cutting edge” and used by very demanding early adopters, has a monochrome display and a text-based browser that offers only limited CSS and JavaScript support as “experimental” features.
Enforcing access to a specific set of target browsers through user agent detection is fundamentally unreliable. For example, many versions of the popular Blackberry smartphone provide a preference that lets users identify their browser as either Blackberry, Firefox, or Internet Explorer, precisely to get past these developer roadblocks.
This leads to situations where developers may take risks with their use of JavaScript and CSS, assuming that they’ve locked out all the “bad” browsers, and will deliver a very broken experience to anyone who switched a preference setting to gain access.
The notion of a list of supported browsers oversimplifies a host of other assumptions: developers commonly assume that supported browsers will have all features enabled—like images, CSS, cookies, JavaScript, and plugins like Flash, Java, or Silverlight—and that all of these enabled features will behave as they expect. What if a user has a supported browser but decides to disable cookies or JavaScript for security or privacy reasons? What if a user has disabled CSS or images in their mobile device to make pages load faster? When developers estimate that a chosen list of supported browsers will cover 95% of the general web population, they overlook situations where users technically have a supported browser but have disabled a feature that is critical for the design to work.
In the real world, code probably fails far more often than developers know (or care to admit) because the majority of testing happens in a relatively safe and controlled environment—a limited set of modern browsers in their default configuration, on a “typical” screen resolution, at default font size. The real world is much more unpredictable and varied. The notion that we need only consider a small set of “target” browsers creates a false sense of security. This “tunnel vision” prevents us from really seeing all the browsers and devices that we need to support and working on ways to make our code more compatible and bulletproof.
“JavaScript required” may leave many users out
Many sites now rely on JavaScript for essential functionality, like populating page content with Ajax or submitting and validating forms—which means that when scripting isn’t available, entire pages or features can break completely.
A search for statistics on the percentage of users who have JavaScript enabled yields numbers from 85–98%; the most quoted source, W3schools’ browser statistics site, estimates that about 5% of Internet users have JavaScript disabled. (At current internet usage rates, this translates to roughly 83 million people!) We work with several clients who use custom enterprise browser configurations with selected JavaScript features modified or disabled for security reasons; these browsers will properly “register” as JavaScript enabled, but not all sites or pages will function.
Many popular JavaScript- and AJAX-powered sites—including Adobe’s e-commerce store, the travel-booking site Kayak, and the project-management tool Basecamp—simply require JavaScript for core functionality, and present an error message when scripting isn’t enabled.
These error messages usually tell the user to turn on scripting and use a supported browser. But what if a person is at the airport and needs to check alternative flights, or see the status of a project, on an older Blackberry or Palm Treo that doesn’t support JavaScript? Downloading a new browser isn’t an option.
A surprising number of large e-commerce sites build essential features that drive revenue in a way that works only when scripting is available. On the Sears.com website, newly relaunched in the fall of 2009, when a customer either searches for a product or navigates to any product listing page (for example, Home > Appliances > Microwaves > Countertop) without JavaScript, the results area that should display products remains blank except for an Ajax “loading” animation.
The page is served with only a placeholder spinner animation, which is clearly intended to be replaced with a list of products by an Ajax request after the page loads; there is no meaningful markup on the page when it loads. The search filters and featured product blocks are also JavaScript-dependent. For users without scripting, the Sears site completely fails in its primary purposes: helping shoppers do research and buy products.
Although it would be nice to assume this is an isolated situation, it’s a widespread problem. On the current Walmart.com site, every Add To Cart button is added to the page with Ajax; without JavaScript, there are no purchase-related buttons. Both the Toys R Us and The North Face sites have an Add To Cart button on their product detail pages, but clicking that button calls a JavaScript function that does nothing at all in a browser with scripting disabled.
All of these are lost revenue opportunities that could have been easily avoided by simply including a functioning Add To Cart button in the page that submits a simple form.
Assuming CSS is another potential a point of failure
Assumptions about CSS support, either alone or combined with JavaScript, introduce another whole range of potential failures.
Many older desktop browsers don’t render CSS according to web standards. On popular smartphones like the Palm Treo and older Blackberry devices, users often disable CSS completely because of the browser’s poor CSS support. We sometimes see complex and advanced CSS applied to the page and served to every device. When rendered incorrectly by browsers with spotty or no CSS support, the page may not look as intended, and it could even cause sections or the entire page to become unusable if elements end up positioned incorrectly or styled illegibly.
Compounding this issue, developers sometimes rely on JavaScript to add or manipulate CSS styles in order to make a page functional. This is a common point of failure: if either CSS or JavaScript isn’t properly supported, the page may be rendered unusable, regardless of how nicely structured the markup may be under the covers.
On the Ford cars home page (http://www.fordvehicles.com), both the global navigation bar and footer links rely on JavaScript to position them correctly on the page. Without scripting, the global navigation is invisible, and the footer navigation links are positioned over the main product image, making much of the page illegible and unusable.
The international landing page for Nike.com has a JavaScript- and Flash-enabled list of countries to route shoppers to a country-specific site. With scripting disabled, a customer sees only a blank, black page that completely prevents them from shopping. Ironically, in the HTML source for the page, there are perfectly usable links for each country, but they’re hidden with hard-coded CSS to make room for the JavaScript enabled experience they assume everyone will see. This simple choice denies untold numbers of potential shoppers every day for Nike.
The black box of plugins
Plugins like Adobe Flash, Microsoft Silverlight, and Sun Java are popular with developers and many users—they can provide powerful capabilities like visualizing interactive charts, maps, and other information; playing media; connecting with a computer’s file system; and more. But because they can require manual installation and updating by users, and are not supported on every platform and browser, they frequently offer the frustrating “update your system” roadblock to users without the most current version installed.
On mobile devices, plugin support is currently piecemeal, as carriers, handset manufacturers, and plugin developers work to balance performance with the less powerful processors found in mobile devices. For example, Apple has steadfastly refused to allow Adobe Flash support in the iPhone’s browser, meaning that the tens of millions of iPhone users cannot currently access any form of Flash content.
In addition to concerns about mobile access, any content delivered with a plugin is stored within the proprietary plugin code structure, so despite the efforts of plugin makers to improve accessibility, the content is not as accessible to screen readers or search engines as it would be if coded with simple, semantic HTML.
Finally, there is small but alarming trend that Adobe Flash and PDF are being targeted as the most popular vectors for malicious tampering, as they have generally broad support on the most popular browsers and platforms. This emerging security risk may have implications for both user adoption and corporate security standards that will influence users’ willingness to access plugin-based content. (Sources: “Adobe Flash’s security woes: How to protect yourself,” Computerworld, 12/14/09, http://www.computerworld.com/s/article/9142223/Adobe_Flash_s_security_woes_How_to_protect_yourself?taxonomyId=63, and “Adobe to patch zero-day Reader, Acrobat hole,” CNET news, 12/16/09, http://news.cnet.com/8301-1009_3-10416816-83.html.)
New devices introduce unanticipated interaction norms
Many popular mobile phones have excellent browsers that rival the latest desktop versions in terms of CSS and JavaScript capabilities, but have introduced radically different ways for users to interact with the page than on standard desktops—which can have significant usability implications.
For example, touchscreens that support multi-touch gestures have emerged as the new standard for interactions in many mobile devices. The combinations of tap and drag gestures on a touchscreen introduce a new set of interaction norms that allows users to zoom, click, and scroll pages. However, there are a few important interactions that an iPhone or Android user cannot duplicate easily in a multi-touch environment:
- On a multi-touch mobile device, the gesture of dragging a finger across the screen is used to pan or scroll the visible area of the web page. Since the drag gesture is already used for panning around the screen, there isn’t any gesture to let users drag and drop items on the screen. If you build an interactive experience where users can add items to their cart only by dragging, this feature won’t work on these advanced mobile devices.
- Some web applications mimic the desktop multi-select capability by clicking items with the mouse while pressing the Control or Shift key on a keyboard. On a touchscreen, any interaction that requires simultaneous keyboard and mouse clicks is not supported without some custom workaround.
- Sites that break pages up into small scrolling panels by setting the CSS overflow or using frames—like an Outlook-style email reader with a list view and reading pane, for example—won’t work on an iPhone, as there are no persistent scrollbars within the web browser. In fact, the iPhone could render the whole interface perfectly, but the internal scrollbars for the message list or detail pane won’t be displayed—the user would need to intuit that they aren’t seeing the full list or message and know to use a two-finger drag gesture to scroll within the sub-pane.
* * *
Many site developers assume that everyone who can render the enhanced experience has all the features and tools to fully support it, and has a desktop browser with a keyboard and mouse for input. But we hope we’ve convinced you that, increasingly, these are dangerous assumptions to make.
As companies and individuals launch new sites, or build new capabilities into their existing systems, they face important decisions about how to design and implement the front-end code. Since the web is inherently an unpredictable environment, assumptions about browsers and plugins deliver a false sense of security. In reality, any technology used in a web page that isn’t simple HTML markup will break somewhere, and could ruin the user experience.
To avoid these pitfalls, any content or transaction that is essential to the core purpose or business of a site should be developed to work on any browser that understands basic HTML—this is the cornerstone of the underlying design of the web, and the key goal of universal access. CSS, JavaScript, cookies, and images can all enhance some browser experiences, but inhibit or break in others; a design approach that makes them secondary and optional is the one that will deliver an optimal experience for the broadest possible spectrum of users.