Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Design > Voices That Matter

  • Print
  • + Share This
This chapter is from the book The landmines of Web 2.0

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.

  • + Share This
  • 🔖 Save To Your Account

Peachpit Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Peachpit and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Peachpit products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email ask@peachpit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.peachpit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020