As Simple As Possible Why less is more...stable...functional...compatible... By Terry Sullivan One of the key lessons I've learned in 15 years of designing production software systems and user interfaces is this: Simple is good; simpler is often better. Those of us who praise the virtues of simplicity certainly find ourselves in good company; one of Albert Einstein's more memorable quotes is, "Things should be made as simple as possible -- but no simpler." Inevitably, when the topic turns to simplicity in Web design, some will dismiss the discussion as Luddite nonsense. Yet the most vocal advocates of simpler designs are often seasoned systems professionals, who've learned (usually the hard way) that simplicity is a key element in ensuring the stability and longevity of any software product (including Web pages). Indeed, many of the things that work well in simpler software systems are also applicable to Web pages and site designs, for these reasons: Simpler is more stable and less prone to error. Simpler is more compatible. Simpler is easier to maintain. Simpler is easier to use. More Stable One way to think of the functionality of any software system (including Web designs) is to examine it for "points of failure." Basically, anything that can break is a potential point of failure. A key element in building stable, robust systems is to minimize those points of failure. One of the great challenges of Web design is that, for each and every page we create, client-side incompatibilities represent additional points of failure for our work -- points of failure that we do not and cannot control. As conscientious Web designers can attest, Web browsers are the ultimate proof of Lubarsky's Law: There is always one more bug. And the more elaborate a page design is, the more likely it is to interact unpredictably with one or more browsers and trigger a client-side error, ranging from a browser crash to a complete system lockup. Such experiences can't help but frustrate even the most patient of users, and visitors will soon move on to simpler, less gear-driven Web sites. It's important to realize that in a narrowcast medium like the Web, losing a visitor often means losing them for life. The Web offers only one or two opportunities to "snag" a user. So, simpler designs are ultimately a matter of enlightened self-interest for site designers. More Compatible It's not surprising that even relatively simple Web designs can prove incompatible with various browsers. It's surprisingly easy, for example, to create a syntactically valid page whose content is totally invisible in early versions of Mosaic, simply by using nested tables. Other browsers in the Mosaic "family" (and that's a big family!) are often subject to variations on this bug. Combining nested tables with admittedly odd ALIGN attributes can trigger the bug in both Netscape Navigator 2.x and 3.x, for instance. Browsers already number in the hundreds, if not thousands. (There were 704 unique browsers available at the end of last year, as noted by All Things Web, a Web-site builder's resource; see " Online.") As browser versions continue to multiply, it's becoming increasingly difficult for conscientious designers to work around all the various and sundry browser bugs. The day is probably not far off when sidestepping a bug in one browser will actually end up triggering a bug in another. Thus, Web designers who are concerned with the accessibility of their content will naturally gravitate to simpler, more broadly compatible designs, simply to ensure the largest possible readership. Of course, the inevitable question arises: "compatible with what?" In the Dark Years of the Web (circa 1995), countless Web developers made a Really Bad Design Decision. They allowed the feature sets of the latest release of the most popular Web browser to drive their designs. Today's Web is a ringing commentary on just how shortsighted that design strategy really was. When the W3C created HTML 3.2 in 1996, its goal was to capture "current practices," to define a tag set that was widely supported by most Web clients. Indeed, many decisions regarding tag inclusion in HTML 3.2 were based less on good, solid design principles, and more on the breadth of client-side support. Despite HTML 4.0's recent one-year "anniversary" as the most current Consortium Recommendation, client-side support for 4.0 tags is at best spotty (and at worst, nonexistent). Thus, compatibility with HTML 3.2 remains the surest guide to reaching the broadest audience. Easier to Maintain A recent foray onto the Web yielded a site that bragged: "This site has been optimized for 10 different browsers, and has been rebuilt from scratch four times in the last six months." An astute reader might just be tempted to think that these two items are related to each other! A simpler, more broadly compatible approach that avoided a dozen different "optimizations" would allow the site designers to devote their time to creating new content, instead of rebuilding their site every time a new browser beta is released. One of the key lessons of the last three years is that browser-bound designs are necessarily high-cost, high-maintenance designs. If your pixel-driven pages were broken by WebTV, then you can bet that they will break again, as high-resolution display technologies evolve. Then too, as audio browser technologies mature, a sizeable portion of your "readers" may actually be listeners, and you'll scramble to discover "how your pages sound" in the latest version of pwWebSpeak. Easier to Use It's intuitively obvious that simpler tasks are easier to master–that is, after all, what makes them simpler! By implication, simpler Web designs are easier to master, too, especially for Net newcomers. Designing with novice users in mind is a great way to build a robust, inviting Web space. It's also a key element in building a loyal traffic base for your Web site, because it's likely (or even certain) that relatively inexperienced users represent a sizeable portion of any Web site's visitors. Indeed, the sustained growth of the Web implies that there is always a constant influx of new users (some 38,000 new users every day during 1997 in the U.S. alone, according to the Cyber Dialogue surveys presented in Peter Clemente's book, The State of the Net: The New Frontier, from McGraw-Hill). If it's true that the Net roughly doubles in size every year, then that implies that roughly one in every 15 or so of any site's visitors has been browsing the Web for less than a month. By implication, many users are still in the process of learning to master their browser software. Intricate, complex page designs and elaborate navigational hierarchies are likely to overwhelm these less experienced users, inviting them to browse elsewhere. Then too, even seasoned Webheads are "new" to a site on their fist visit (or even several visits), in the sense that they are unfamiliar with the site's content, organization, and structure. By inference, simpler interfaces make for a more inviting Web space, regardless of how long a given reader has been browsing the Web. Treating the Web Like Software The notion of treating Web systems like software strikes some as a profound insight. Yet Web sites behave like software, they're created like software, they can be managed like software, and their cost is like that of software, too, in that they frequently cost more (often lots more) to maintain than they did to develop in the first place. So it's reasonable to expect that we can harvest fundamental insights from the traditional software design process and apply them to Web design. For further discussion of the parallels between Web-site design and software development, visit All Things Web. Of course, the foundation for every software application is some sort of definition (no matter how incomplete) of the functional requirements that the system must meet. So, it's especially ironic that many Web designs are based on a set of visual rather than functional requirements. It's increasingly easy to spot those sites on which the designers spent way too much time thinking about how the site should look and way too little time thinking about how it should work. But how can Web designers possibly define a stable set of user requirements when their audience changes by the day, the week, the month? Thankfully, the GVU Web surveys from the Georgia Institute of Technology (see " Online") provide information about what brings most users to most Web sites. The typical user has a goal in mind–and that goal is to discover and acquire information, for either personal or business use. Thus, the core functional requirement for most Web designs should be to make that process of information discovery and acquisition as simple as possible for most users. (See the box titled " Design Constraints for Simplicity and Compatibility".) The design implications are both obvious and overwhelming. Shallow/broad navigational hierarchies, ubiquitous orientation aids, multimode navigational support, and effective search capabilities are all hallmarks of simple, high-functionality Web designs. Logical organization of information and ease of discovery represent the single best way to add value to information on a Web site, and to enhance simultaneously both the users' experience and the providers' prestige. And then, of course, there's speed. It's inevitable that some visitors' information needs are time-sensitive, even time-critical. And we know, again thanks to the GVU surveys, that users will abandon a site simply because it takes too long to load. It's certainly much more likely for a time-crunched user to leave a slow-loading, graphically overburdened site than it is for a casual "surfer" to be unhappy because a page loads too quickly. Of course, many industry pundits have declared that 1999 is the Year of High Bandwidth. (Didn't they say the same thing about 1998?) But Web designers who think in global terms know differently. It's a mathematical inevitability that, on a worldwide scale, bandwidth will decrease in absolute terms, not only this year, but next year, and even the year after that. High-bandwidth Web sites can't help but find themselves at a profound competitive disadvantage in a truly global marketplace. When the Tool Is the Task In traditional software development, it's possible to draw some artificial distinctions between an application's functionality and its usability. But in Web design, the tool and the task are fundamentally one and the same. It's utterly impossible to separate a site's functionality from its usability. The already central role of usability considerations will become a make-or-break issue for a lot of Web sites. The Law of Large Numbers dictates that as your site's audience grows, it necessarily becomes less technically minded and therefore less tolerant of elaborate, error-prone, overburdened designs. So it's a fair question to ask: What exactly is the perceived value in complex, elaborate site designs? Indeed, even the word elaborate comes from a Latin verb that means "to acquire through labor." In other words, an elaborate design implies that readers have to work at finding and gathering the information they need. It is probably impossible for designers to underestimate users' increasing intolerance. Simpler, faster, easier designs cannot help but appeal to a much broader constituency. --------------------------------------------------------------------------------- Terry is a systems professional with 15 years' experience in software design and usability engineering. He is a doctoral candidate in the interdisciplinary information science program at the University of North Texas, where he teaches graduate-level courses in Web design. Design Constraints for Simplicity and Compatibility --------------------------------------------------------------------------------- As with all design and engineering projects, Web design requires balancing different -- and sometimes competing -- requirements and constraints. Among the most important are the capabilities of your site's audience. At 2-Lane Media we rely on demographic information, a solid understanding of many of the Web standards, and the context of the project itself. Detailed demographic information about potential visitors is tough to find. If your site is already online, the best source is your own server logs. Otherwise, you can gather data from the various sites that survey the Web-using public (including www.gvu.gatech.edu/user_surveys/ and www.statmarket.com/) as well as occasional reports from industry analysts. Unfortunately, all of these surveys are skewed in various ways, depending on how the data was collected. But by averaging out the figures we can glean the following information: Many users still have 28.8-kbps modems. Try keeping pages under 50KB (for both HTML and graphics) and definitely under 100KB, unless there's specific content you know visitors will wait for. For practical purposes, the general public is split roughly evenly between Microsoft's Internet Explorer and Netscape's Navigator. At least half are using version 4.x of these browsers and the rest are on version 3.x. But some sites with particular audiences may need to support specialty browsers, including those that are text-only, TV-based, or PDA-based. All the major browsers support all but a few obscure features of the HTML 3.2 standard -- but don't fully support HTML 4.0. Unfortunately, HTML focuses on the structure of the content on your Web page (for example,and
indicate different levels of subheads) rather than the display of the content. Consequently, precise control over a page's appearance isn't possible without a fair number of workarounds. The Cascading Style Sheets, Level 1 (CSS1) standard, which does provide precise control over typography and layout, isn't supported by the 3.x browsers. However, in the 4.x browsers, it's possible to use CSS1 for typography (with semigraceful backwards-compatibility for older browsers). But for layout you'll still need to use tables, due to the partial and often buggy implementations of CSS positioning features. JavaScript 1.2 provides the most common set of features among the major 3.x/4.x browsers, but its support remains uneven, so use it with caution -- and lots of testing. Sad to say, Java 1.0 still remains the safest baseline, despite the numerous limitations that imposes. About half the users have 800x600 monitors -- but another third still have 640x480. "Flexible" design (for example, using tables with percentage widths for layouts) can satisfy both groups. But if you have to optimize for one size, make it work on the smaller monitor. Most users have monitors capable of displaying thousands of colors. However, it's still a good idea to stick to the browser-safe Web 216 color palette where dithering caused by a 256-color monitor would hurt a flat-color image (such as your corporate logo). Many users lack plug-ins, although the RealPlayer and Macromedia Flash plug-ins are becoming somewhat widespread. If you're going to use plug-ins, ask yourself whether your audience will be interested enough in the content to go through the effort of getting the plug-in. In most cases, you should also provide a non-plug-in version (for example, substituting a static graphic for a Flash animation). XML, a sort of "super-markup" language used to exchange data, will be supported in the upcoming 5.0 browsers, but the extent of that support remains to be seen. Good sources of information about specific browser capabilities and incompatibilities include The Web Standards Projects (www.webstandards.org/resources.html) and Project Cool's DevSearch (www.devsearch.com), a specialized search engine for Web developers. -- George Olsen, design director at 2-Laane Media (www.2lm.com), an interactive agency