circa75 Home | About circa75 | Articles | Links | Contact Us

Posted by gustav at 11:01PM, Monday, December 04th, 2000

Introduction to Good Web Design

or, how little professionals really know about design, usability, and fitness-to-purpose.

I've always been a fan of good design, but felt that it's very difficult to find. In almost any profession, design is driven more by flash and (probably inappropriate) marketing and advertising concerns than by good engineering and usability principles. This is especially common in this country, at least in comparison with Scandinavian practicality and simplicity. Look at a mid-eighties Firebird versus a Saab turbo. The Firebird has a high-volume, inefficient, and underpowered eight-cylinder engine, and a screaming turkey painted on the hood. The Saab has a 30mpg, low-displacement, high-output four-cylinder engine, can carry a full-sized couch in the back, doesn't need to be rust-proofed, and has seat heaters because a Swedish engineer with prostate trouble noticed it was uncomfortable to climb into the car and sit there on frigid winter mornings, and some bright Swede figured an electric heater would solve his problem. American cars to this day continue to be designed on marketing principles and hype, and what sells well instantly, regardless of how its users like it in the long run; the Swedes have, for the most part, stuck to their stolid, practical ways.



The inefficient, inflexible, and practically frustrating if not completely unusable, gas-guzzling, overweight, slow, 1970s American car of today is software design, and often web design. There was a time in the mid-eighties when Apple hardly wrote a line of software code without considering how it would impact the user, and the result was that the Macintosh of the time was a paragon of user-centric design. Apple has started to loose its way as it has competed with the behemoth of software, Microsoft, whose products assume that their customers have limitless amounts of screen-size, computing power, and storage. As desktop-only computing has given way to the Web, American business, following Redmond, hasn't often stopped to think about web users, and the particular demands the medium places on design and engineering.



I think about usability a lot, and tend to notice it as it relates to many of my activities. As a web developer, I notice inept web design particularly. Unfortunately, it's evident almost everywhere. Industry professionals are sadly and evidently lacking any idea of the importance of usability on the web, and stubbornly refuse to listen to reason or look at supporting data when confronted. Part of this is because computer science resolutely ignores any consideration of users whatsoever, pretending that the only people to use computers are engineers, and that it's easier to adapt the engineers to the foibles of computer systems than vice versa. Part of the problem is simply that American business listens to marketing and to other companies more than to its own engineers, and wouldn't change even if those engineers brought up usability issues in design.



This doesn't mean that there's any reason for ignoring usability in creating not-for-profit sites, which, after all, constitute almost all the truly interesting pages on the web. And it doesn't mean that, a martyred cause though it may be, fighting for usability standards in one's work in the industry isn't a noble cause. So, here are some of the most important issues in my experience regarding usability and web design.





  1. Grasp the point of the web.

    The web, as a medium, lets you share information with an inconceivably large number of diverse people from anywhere on the planet, regardless of what sort of device or software they're using to read your pages. Given that, your goal in creating a web site should be to provide the widest audience with that information as easily and quickly as possible. If the information is images, then that places limitations on your audience. If it's textual, though, there's no reason to limit the audience of your content -- it should be accessible by anyone with net access, and this should please you.




  2. The web is not print.

    This seems obvious but it has many implications, one of the most important of which is that it's pointless and often impossible to try to control every pixel on the screen, for a variety of reasons. There are more kinds of web browsers than just visual agents that render html into pixels on a desktop monitor, and always remembering this helps you to build faster, lighter, more flexible pages, which also look just fine on-screen using an average browser. Forgetting it means your pages discriminate against users with visual impairments, motor-control impairments, lower-bandwidth connections, lesser hardware, or simply different browser/operating system combinations than the ones you use. Trying to control every pixel -- the absolute position of every graphic and the size and typeface of every character of text -- is simply an inappropriate goal, unless you know the exact configuration of every client who will be using your page, and all those clients are absolutely identical. Not just similar, but absolutely identical.



    Different visual browsers render things like tables and text-markup tags differently, or not at all. Implementation and conformance of style sheets is different in every browser, and often varies dramatically between the same browser running on different operating systems. Basically, you just can't control every pixel if your audience is using even two slightly different browsers. Trying to do so in the real world, where the audience for real web pages uses at least four totally different browsers on four or so major operating systems, is futile. It makes pages that are bloated, slow, and guaranteed to have errors or rendering issues in at least some visual agent, let alone non-visual ones. You can have a page that looks perfect in IE 5 on Windows, at the default font size, but as soon as someone with bad eyesight or a large monitor, or a Mac running Netscape 4 -- someone who, for whatever reason, has a non-"standard" default type size set -- looks at your page, it will break, if you have designed it for specific pixel-sizes and table-widths. The whole point of the web is to share information with the widest possible audience -- people from all over the world, using all different kinds of clients, hardware, software, visual or non-visual agents, and net connections. If you fail to grasp this, you shouldn't be working on the web at all.





  3. Understand the difference between meaning and presentation

    The < b > tag is for bold. This tag doesn't convey meaning. What does "bold" mean to an audio client? What does it mean to a braille client? Is the actual meaning of text that you enclose in bold tags that it's "bolder" than surrounding text? Boldness is presentational markup, and doesn't really convey meaning, certainly not for anything but print. You probably mean that it should stand out, that it's stronger -- an actual meaning, which can be correctly interpreted by non-visual agents. If that's what you mean, that's the way you should mark up your content -- with the < strong > tag. Similarly, the < em > tag conveys a meaning of emphasis, which can be rendered appropriately by non-visual agents, while < i > only conveys the presentation of italics. Remember that the web is not print -- an audio browser is as much the web as Netscape -- and italics has no meaning. Another example is the < br > tag -- a line break has no meaning outside of a visual rendering of text, so it should not appear in content.



  4. Don't make assumptions about your audience.

    The second point, above, is really an extension of this. If you make inappropriate assumptions about your audience, you fail to understand the nature of the web at all. Every manager I've ever talked to doesn't understand this, but you might say that that's one of the reasons most web startups fail.



    An inappropriate assumption about your audience, in my opinion, is any assumption about your audience, if you're making pages for the web at large, and not for an intranet site or a limited-access, password-protected live site. Even then, it's only appropriate when you know exactly what hardware, software, and connection every one who uses the site will use. If you can't guarantee that, you can't make any assumptions.



    I mentioned some reasons not to make assumptions above. You don't know whether someone who uses your site is looking at it on a desktop PC with a visual browser, or an audio browser, or a slow-speed, text-only WAP, or a text-only terminal, or a "regular" browser with a different point-size default font, or javascript turned off, or no plug-ins, etc. Every time you make an assumption about these things, you loose part of your audience. If you assume everyone will be using IE, then whenever a Netscape or Mozilla or OmniWeb or Opera browser-user looks at your page, all your tables and careful spacing will break. If you assume everyone uses a visual browser, or one that is capable of rendering tables, then whenever someone with an audio browser or Lynx looks at your site, the navigation section that's laid out in a neat little nested table structure will be unusable. If you assume everyone can read 12-point Arial, and set that as your font everywhere on your site, then whenever anyone with Netscape on a Mac views your pages, all text on the site will be illegibly small, and using the "increase font size" menu option won't help; every time someone who doesn't have the Arial font views your site, it will look different than you intended; every person who has a 1600x1200 or greater resolution monitor, and sets their default font size to something larger, because she can't read 12-point text when it's that small on her monitor, will have to squint and hunch up close to the monitor to read your pages. You will alienate, irritate, anger, and otherwise lose parts of your audience for no good reason.



    A lot of people refuse to not make assumptions because doing so means they loose control over every pixel of a page. I repeat, if this is your issue, you don't understand the web and shouldn't be even tangentially linked to the creation of web pages.



    Other people, usually managers, try to make the argument that "well, this site is really just for our corporate partners and potential corporate partners to read about us. We can assume they'll all have Windows and keep their browsers maximized on the screen all the time, so we can design for IE and 800x600 resolution." If this site is also your public face to the world, that's a foolish reason to make assumptions. What if you're desperately seeking an experienced Java engineer, and the ideal applicant, who happens to use Opera on Linux, and always browses through small, non-maximized windows, finds your online job-posting in a search, but sees your site, and how it breaks on Opera, and doesn't resize to a smaller window, and says "Jeez, if this is how clueless management is, I don't want to work under them?" What if a manager at one of your corporate partners (this is a stretch) actually knows something about web design, or uses a Mac, or doesn't have her windows maximized all the time?



    This doesn't mean that you can't set fonts for your pages, or use style-sheets, or tables, or graphics. It just means that you should be aware how all these extra features that only apply to some browsers degrade, when you use an older browser, or a text-only one, or a non-visual one. It means that you shouldn't make tables that require a minimum specific screen size to work, or that have such a complicated nesting structure that you can't make sense of them with Lynx or a non-visual browser. It means that you should always use alt tags for every graphic on your site, particularly those that are part of navigation. It means that you shouldn't put a huge, complex, graphic-oriented "branding" navigation bar on every page, so that users on low-bandwidth connections loose patience and give up.



    Solving these problems isn't that hard. It requires some knowledge of how all these added features degrade, and experience with a lot of different clients (browsers). Mostly, you just need to acknowledge the way the web is, and not try to fight it.




  5. Designing for unlimited resources is bad design.

    As I said, you shouldn't have expectations about your clients, including connection speed and type of browser, but even among traditional, CSS-enabled, table-rendering, graphical visual browsers, it is a mistake to demand too much in the way of bandwidth, rendering ability, and on-screen real estate. If site features that rely on these don't bring anything to the user experience, or you can rework the site to be just as usable without them, get rid of them. Your servers will be happier, your visitors will see more of the site faster, and you'll be more scalable. The Microsoft approach, where you demand at least as much as possible at the time in terms of client hardware, is a cop-out that shows no engineering skill. It's easy to do something with all the hardware in the world, but it's better in every way to do the same thing with less.




  6. Don't confound user expectations.

    This is an important point in software usability as a whole, and is only minor on the web in relation to the other flaws of traditional web sites. If you're building a business site, or anything where you want people to be able to find information quickly, it's good to be predictable in terms of navigation and site layout: make URLs at least somewhat reader-parsable in case page links break, so the user has a chance of figuring out the correct URL; put navigation at the top or down the left side of the page; put the site's homepage address, a link to a sitemap, and a link to privacy information, if applicable, along the bottom. In addition, for any site, don't change the things that users understand for no good reason. If you specify text colors, content should be black on a lighter background; links should be blue, and underlined; visited links should be purple; and active links should be red. If you make content text blue, users will try to click on it. If you make links green or (worse) black, or any other non-standard color, users will be confused, and tire of the site quickly.



    Graphic designers will complain about this. It's just one of the limits you have to work within, if you design for the web. If you let them have their way, you're placing flashiness and superficial eye-candy above usability -- you've painted a screaming turkey on your hood.





Message Preferences: Mod Level:

Messages:

circa75 Home | About circa75 | Articles | Links | Contact Us

All content copyright © 2001-2009 the owners of http://www.circa75.com/