The landmines of Web 2.0
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.
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.
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.
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
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.
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
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.