My Web Design and Development Philosophy

I’ve been using the World Wide Web for over ten years now, and writing web pages for over eight of those years. In that time, I’ve seen anyone’s fair share of painful blunders, usability mistakes, and outright horrors — and I’ve also seen a lot of well designed pages and sites, and smoothly-functioning scripts. These are my own observations on what works and what doesn’t; what annoys me as a web user and what makes me happy and gets me to come back to a site a second (or two hundredth) time.

Serve Your Users, Don’t Try to Rule Them

Your web site is there for your users, not for your company. It’s to give them information. Don’t try to force the users into a set path, jumping through the particular hoops you think will be most interesting — or most likely to get them to buy something from you. No matter how much you might try to restrict their choices while they’re on your web site, they always retain at least one choice: the option to leave. Your biggest competitor is just one click away from a Google search on “[your-business-name] competitor”.

Make your site easy and fun to use, and users won’t want to leave. Let them be in control, and they’ll be happy. Even if you’re not selling anything, you’ve presumably put up your site so that people will come to visit it; there’s no sense in driving them away once they arrive. Practically everything else in this essay proceeds from the basic notion that your site should serve your users, rather than trying to subjugate or otherwise annoy them.

No-Brainers

Most of these are things I consider so obvious, I shouldn’t even have to put them in here. But since people are still routinely violating them, even in the fall of 2005, apparently they still bear repeating.

Never Use Auto-Playing Music

This is a perfect way to make 90 percent of your readers leave your page immediately, and never come back. Some of them are browsing your site from work, and don’t want the person in the next cubicle to think they’re goofing off. Even if they’re visiting your site for valid business reasons, it will still sound like they’re not working, and it will be remembered at their next performance review. If they’re not in some environment where their computers need to be quiet, then they’re probably already playing music of their own. The chance that your music will mix well with it is essentially zero.

Even if you are a musical artist of some sort, and your web site’s sole purpose in life is to promote your music, give the user the option to play it at a time of their choosing. If you inflict it on them the moment your page loads, they’ll just make sure to unload your page as fast as they can. U2 doesn’t auto-play music at their visitors; neither do the London Symphony Orchestra, Eminem, Kelly Clarkson, the Boston Pops, Bonnie Raitt, Coldplay, or the Rolling Stones. If big-name artists like that don’t need to do it, neither do you.

Backgrounds Should be Boring

They’re backgrounds, not foregrounds. This is a problem that really only shows up on very amateurish sites; I’ve never seen a professional site make this mistake. Any background you put on a page should be blurry, low-contrast, and it shouldn’t interfere with reading the page’s text in any way.

Know the Difference Between ALT and TITLE

Browser manufacturers’ decisions to start displaying images’ ALT attributes as tooltips — even when the image in question was already loaded and displayed — has always been wrong. (Not only did the HTML 3.2 spec state that the ALT attribute was “for display in place of image”, even the HTML 2.0 spec described ALT as “text to use in place of the referenced image resource [emphasis added]”.) But wrong or not, web page authors everywhere immediately picked up the new behavior, and misused it with ALT attributes that made no sense unless you could already see the image.

Then the HTML 4.0 spec not only included an expanded description of what ALT is (and is not), but also made the TITLE attribute applicable to any element, and explicitly mentioned that it could be rendered as a tooltip. But somehow, the same authors who were so eager to exploit the misbehavior of ALT on non-conforming browsers have not bothered (over the past seven years) to try to write new pages that do conform to the standard, and that take proper advantage of the two different (and useful) options. Indeed, in some cases, they even seem to go out of their way to misunderstand, carping about having to use the same text in both attributes.

It’s really very simple: if you want a tooltip on something — anything — use TITLE. For substitute text for when the image doesn’t load, use ALT. It’s long past time people started using these things correctly.

Make Your Layouts Flexible

You don’t know what size screen your user has. You don’t know if the user has their browser maximized or not, either. And even if you did know all those things (maybe by using JavaScript to return window.innerWidth or document. documentElement. clientWidth values), you still don’t know what font size the user has their browser set for. (Sure, you could get that from the DOM on page load, too, but what if the user says “Hey, that’s too small for me to read!” and knocks it up another 25 percent two seconds after your page-load function has fired?)

The painful, ugly truth for web designers and developers is that we do not control the final presentation of our designs. We need to deal with that fact. I’m not trying to say that all designs have to be liquid layouts, but they need to at least have some recognition of the fact that the user has a lot of input into the final display, and that they’re going to be viewed under conditions that are charitably described as “unpredictable”.

Not Everyone Has Broadband

According to recent statistics from the Pew Internet and American Life Project, just over a third of US households have broadband. (That’s a mere 53% of the 67% of households that have Internet access at all.) The folks without broadband aren’t all Luddites, either; people in rural areas may have no options for getting high-speed connections. But their money is the same color as anyone else’s. Remember them when you think about putting some huge image or Flash object on your main page.

Make Sure Your Text Has Margins

Whether it’s done with <body topmargin="0" leftmargin="0"> or with CSS BODY { margin: 0px; padding: 0px; }, there are too many pages that result in text flush-left against the edge of the browser window. It’s viscerally ugly, and almost physically painful to read. Hurting your readers’ eyes will make sure they look at your site for as little time as possible.

Yes, sometimes you want to make sure an image is flush-left against the edge of the screen. But do it in a way that doesn’t also affect all the text on your page. CSS makes it easy to do these days, and even one em of margin is enough to make readability a dozen times easier.

All Scripts Need Security

Every form on your site, every dynamic page that accepts some kind of user input, is exposed to all the hostility that an entire Internet-full of miscreants can muster. I’ve already talked about the security of CGI scripts elsewhere, so I won’t belabor the point. Just remember that the same comments apply to anything on your site that takes input of any kind.

Code to Standards, Even Internally

The usual lecture about coding to the W3C spec, and testing in a variety of browsers for cross-platform compatibility, has been delivered so often that there’s not much I can add to it. My only real contribution is to point out that even when you’re 100% sure that this particular web app will only ever need to target one specific platform, you don’t know how it will be repurposed tomorrow.

That’s exactly what happened to FEMA right after Hurricane Katrina, and gave them such a black eye in the tech news for their IE-only disaster aid application form. As Ars Technica reported, FEMA had originally planned the form as an in-house tool only. They’d even planned to make it accessible to any browser, but hadn’t quite gotten around to it before Katrina hit.

Remember: nobody ever got fired for making their site accessible to everyone.

Pet Peeves

These aren’t quite in the category of “no-brainers” — the above are things that nobody has any excuse to be getting wrong in this day and age. These pet peeves, on the other hand, are things that haven’t gotten nearly as much widespread attention, but that I find annoying anyway. And curiously, so do a lot of other web users that I’ve mentioned these issues to, from the “I just got online with AOL three months ago” crowd all the way up to fellow web developers and Linux gurus. If that kind of cross-section of the web finds these things annoying, your clientele probably does, too.

Phone Number Inputs Broken Into Three Fields

How often have you been asked to enter your phone number in a series of three different text boxes, like this:

Enter Your Phone Number:
- -

Leaving aside the question of what someone outside the US is supposed to do with this, there’s still the question of whose life this artificial separation is supposed to improve. I expect the excuse is, “We want to make sure it’s entered in the right format, and we want to maintain the area code in a separate field of our database.”

Which are both laudable goals, but why should I have to hit the Tab key a couple of extra times just to help some server-side software be lazy about parsing something that’s nearly trivial to begin with? (Somehow, I suspect it’s not the software that’s lazy. It’s the developer.)

This should be a single field, wide enough to take at least 14 characters, so people who are used to typing “(123) 456-7890” can do so. (Allowing one or two extras wouldn’t hurt, either.) And people who prefer the “123-456-7890” format can use that, and people who like “123.456.7890” instead can enter that.

Then, at the beginning of your server-side processing, just strip out everything that’s not a digit. Really, how hard is it to put the entire phone number through a Perl statement like $phone_num =~ s/\D//g; or a PHP equivalent using preg_replace()? After that, just check the length to make sure you’ve got 10 digits (flagging other lengths as probable international numbers and returning an error message), then break off the first three and store those in your $area_code variable.

I’ve even seen some sites that try to make up for the inconvenience of incurring the extra Tab keystrokes by automatically shifting the focus to the next field as soon as enough characters are entered. While it’s well intentioned, it invariably makes the user swear as they realize that the behavior they were expecting isn’t what they got. (This particularly annoys those who look at the keyboard as they type — not many people are touch-typists.)

Making Users Enter Their Email Addresses Twice

I’m honestly not sure why this has become such a regular occurrence; if there’s been a plague of people mistyping their email addresses on web forms, I’ve missed it. Instead, it simply looks like another hoop to jump through. (Personally, I routinely type my address the first time, then hit Shift-Home to highlight the entire thing, Ctrl-C, Tab, and then Ctrl-V. That cuts it down to only an extra four keystroke combinations, but I’m still irked by the extra four.)

Of course, having users double-type their passwords has been standard for decades now — whether on web forms or VT100s or anything in between. But there’s a crucial difference between entering a password and entering an email address: the password is usually masked somehow (generally with asterisks, occasionally by not echoing anything at all), while email addresses aren’t. (This is, of course, assuming you haven’t made a completely elementary blunder in your UI.)

We have users verify their passwords because they can’t see what they’re entering. With an email address, which they can see, isn’t it sufficient to simply tell them something like “Please make sure your email address is correct before submitting the form”? Or, even better, isn’t it reasonable to assume that they can type their email address just as well as they can type their name, address, and city? I’ve never seen any of those fields doubled, and I doubt I ever will. What’s so special about an email address?

CAPTCHAs on Separate Pages

This issue is becoming less of a problem, as CAPTCHAs are starting to fade from use. And many sites that use them at least have the sense to put the CAPTCHA image on the same form with the rest of their sign-up questions.

However, at least one domain registrar using a CAPTCHA on their WHOIS lookup form has you enter the domain you’re looking for... and then, after you click the button labeled “Go!”, it presents you with the CAPTCHA. It’s just another example of the kind of “why make the user jump through only one hoop, when we could have them jump through two or more instead?” interface design that causes unnecessary frustration.

It’s possible that this was intended to try to prevent automated runs against the Register.com database by CAPTCHA farmers (a possibility that’s bolstered by the fact that the WHOIS results are returned as a JPEG image, not as text). But presenting the CAPTCHA after the initial form submission wouldn’t actually stop farmed attacks; it just means the farming software doesn’t bother to send its first request until it already has a user on the other end, ready to decode the image. Basically, it boils down to about an extra half-hour of coding and debugging work for the farming-software writer.

Oh, and an extra delay, and and extra helping of annoyance, for everyone else who wants to look up a Register.com domain. Tell me again how this is a win for anyone?

Excessive Page and Column Widths

For centuries, print designers have known that a line of text shouldn’t be too long. (They’ve generally considered anywhere from 40 to 70 characters to be ideal, depending on whether the layout is multi-column or not.) I’m not sure whether they simply forgot that rule when they started designing for the web, or if print designers never actually moved into web design at all. Either way, there are far too many sites out there with text formatted into columns of 100 characters or more.

There are also a shocking number of sites designed with fixed layouts at bizarre widths. It’s almost as if they were made specifically to cause side-scrolling at 800 pixels wide, while leaving excessive blank space at 1024 pixels. Others simply seem to assume that everyone must have 1024x768-pixel screens by now, disregarding the evidence (admittedly somewhat shaky) that at least 25% of users have smaller screens. Finally, there are the sites that were apparently attempting to design for a 1024-pixel-wide screen, but who seem to have forgotten to leave room for a vertical scroll bar. This doesn’t force any side-scrolling at 1024x768 pixels, but it does make the designer look pretty absent-minded (at best). And the articles on that site do require side-scrolling at 800 pixels wide.

When choosing a size for your fixed layout (if, indeed, you must use one), consider the following questions: Would you turn away one out of every four visitors to your brick-and-mortar store? Or even just have one of your sales people follow them around, constantly annoying them? Then why do the same to your online users? If you’re targeting 1024x768 screens, don’t make your fixed layouts any wider than 975 pixels; if you want to welcome the other 25% of users with 800x600 screens, keep your layout within 750 pixels.

And if you have any content that you want people to actually read, make sure your lines aren’t dizzyingly long. (At the time I wrote this essay, the lead article on the InfoWorld site had lines spanning anywhere from 140 to 150 characters!) Consider using CSS to specify your column widths in ems instead of pixels, and remember that people with poor eyesight may well try to increase the font size.

Update: I’ve just noticed (as of 25 November 2005) that ZDNet UK is now breaking up multi-page stories in the middles of paragraphs — even right in the middles of individual sentences! If excessively long lines are bad for readability, how much more of a readability disaster is it to force an entire page load in between words like “Microsoft” and “chief executive Steve Ballmer”? If you need to break up a story, put the break between paragraphs (and preferably right before a new sub-heading).

Accessibility is for Everyone

Usability advocates are constantly talking about making sure to include ALT attributes “for the blind people”, or remembering that “people over 40” may have poor eyesight. While trying to cater to all audiences is laudable in itself, these examples are a very limited view of who’s affected by these issues. Consider:

It’s very tempting to handwave away visibility and accessibility issues by claiming, “That just affects old people and blind people — and the old people don’t use the web anyway.” But it’s the wrong answer; it’s not supported by the facts. Accessibility and visibility issues of one sort or another almost certainly affect a full quarter of your site visitors, even if your target audience is specifically the 18-25 age bracket.

(By the way, I’m sure nobody reading this would respond to the mention of “old or fuzzy monitors” with any statement like “well, then the user should buy a new monitor!” After all, would you rather have the user spend hundreds of dollars on a new monitor, or would you rather they spent it on your products?)

Accessibility issues aren’t just for “some tiny fraction of the population”. They actually affect nearly everyone, at some point or under some conditions. And screen-size issues — yes, the issue most often brushed aside with “Who the heck uses a 640 by 480 screen any more?” — can actually affect some of your favorite users: the ones with lots of money.

Those busy peole on the go, with lots of disposable income, are the ones most likely to try to view your site through their cell-phone while they’re away from the office. If their Blackberry, or Danger Hiptop, or whatever can’t handle your site’s layout... honestly, they’ll probably understand. Those screens aren’t very big. But if your site does display flawlessly in that teensy-tiny screen, those users will love you for it.

Hover Effects and Navigation

Even when they had to be done as JavaScript rollovers, I was in favor of hover effects. They provide some extra feedback to the user about what it is he or she’s about to click on. Now that we can do them more easily, more smoothly, and with less bandwidth overhead by using CSS, I’m still just as enamored of them. Rollovers, background-color changes, foreground text that gets brighter, whatever it takes to let the user know “Yes, this is a hyperlink, and you do have your mouse pointer over it.”

However, by the same rationale, I’m not too happy with pages that remove the underline from hyperlinks until they’re moused over. Yes, it lets the user know that this is the link they’re about to trigger, but it can also keep them from knowing that it’s a link until they find it. (The different color isn’t always enough of a clue, especially with every site having its own color scheme.)

Similarly, I prefer nav bars or other navigational aids that give the user some sense of where they currently are in the site. Breadcrumbs, nav links that highlight the current section of the site, icons or other images that give similar feedback; they all help to keep a user oriented. And a well-oriented user is one who will be more comfortable, and hence more likely to stay on the site for longer.

Needless to say, I’m not too thrilled with the idea of changing the visited-link colors to match that of unvisited links.

Sniff Capabilities, Not Browsers

This concept is slowly but surely working its way through the web development community, and in another year or two, it will go in the “no-brainers” category. (Update, December 2008: Yup, this has defeinitely become a no-brainer by now, helped along by the plethora of JavaScript frameworks that make browser capability differences less of an issue in the first place.) When you’re not sure if a user’s browser can support whatever gee-whiz feature you’re trying to create with JavaScript, don’t waste time parsing their User-Agent string and trying to figure out if version X-point-Y of Browser Z has the specific feature you want. Instead, just ask the browser. You want to use the document.getElementById() DOM feature? Fine, write: 

var foo = false;
if (document.getElementById()) {
    foo = document.getElementById('foo').some.property;
} else if (document.all) {
    foo = document.all['foo'].some.property;
}

(Presumably, this code will go on to report an error condition or give some kind of “I’m sorry, your browser doesn’t support the features needed to use this site” message if foo is still false at the end.)

This method of detecting browser capabilities frees you up from a number of worries and problems. You don’t have to worry about whether the user’s browser is spoofing its User-Agent string in some way; you don’t have to worry about whether your parsing routines are reading the User-Agent string properly, and you don’t have to worry about maintaining some insane lookup table of what capabilities every browser has. Finally, it means that you don’t have to care what the browser is called; instead, you look at what it can do.

Be Polite With Your Cookies

First of all, remember that you can’t rely on users accepting your cookies at all. You also can’t rely on your cookies still being there a month later; recent research indicates that up to 39% of web users now delete their cookies at least once a month (and 10% do it every day!). Apparently, users are so frustrated with cookies that they’ll put up with the inconvenience of having to log back into all their web sites and re-set all their preferences.

If you set your browser to show you incoming cookies, it’s easy to see why: many sites will blithely set a dozen or more cookies on every page load, often with cryptic names like “s_vi_bzbx7Bmfehkf”, “zFD”, or “9725_uu”. (Yes, those names are all real examples, taken directly from my cookie file. And this isn’t even counting the fact that “PHPSESSID” and “UID” may not be all that clear to the average person.)

There’s no way you can guarantee that your users will accept your cookies, or hang onto them for any length of time. But if you want to give it a try — and if you want to avoid looking completely obnoxious to anyone who does have cookie warnings turned on — here are a few ideas:

I know, some readers are now crying, “How am I supposed to store all the information I need to with restrictions like that? If I’ve gotta stick to such a small number of cookies, I need to at least use bit fields!” But if you’re looking at it this way, you’re misusing cookies completely. My answer is simple: If you really need this information, don’t trust it to a client-side cookie! Put it in a database on your own servers, where it belongs. Then just give the user one cookie, with a unique ID that you can tie to the database. If you’re putting the data in a cookie on the user’s machine, you obviously don’t consider it very crucial. (That hard drive could have a hardware failure at any moment, even if the user doesn’t delete your cookie next week.)

Also, when choosing your clear, non-cryptic names for your cookies, consider how they might be misinterpreted. There’s a server-side tracking module out there that sets a cookie whose name starts with “ForeseeLoyalty”. I’m sure it was devised by some marketer who was thinking of “brand loyalty” (which is a fairly condescending term already, from the customer’s point of view), and who never considered how it would look when used on government web sites. Like the Department of Justice, or the IRS. Lots of people found it humorous, annoying, cynical, or even paranoia-inducing. None of those are the effects you’re looking for (I assume).

Personal Information is the New “Hot Commodity”

Web sites these days ask users for a staggering amount of personal information in order to carry out the simplest tasks. And the users don’t like it at all. They’re getting upset, and they’re catching on to the fact that information about them is actually worth something. (Note the bits in paragraph five, right after the block-quoted section.) Users are not going to give you their personal data unless they know they’re getting something back in return. If you require it, and put a little red asterisk next to all your form fields, they’ll just lie.

So don’t even bother asking them for information unless you actually need it — and by that, what I really mean is: Don’t ask your users for information unless they need to give it to you in order to get what they want. Obviously, if they’re buying something from you and having it shipped to them, they need to give you their credit card details and their shipping address. But why do you need their phone number? Or their email address? More to the point, why do they want to give those things to you? (If you want to send the UPS or FedEx tracking number to their email account, tell them so!)

If you don’t have a good reason for wanting the information — one that you can clearly explain to the user, in a way that shows how it benefits them — then you might as well not even bother asking for it. It just leaves all the information in your database suspect, and probably tainted by dozens of people who lied and claimed to live at “123 Main St., Anytown AL 12345” (Alabama being the first state in an alphabetical listing by name. If you list by postal abbreviation instead, you’ll be amazed at how all those Alabamans suddenly moved to Alaska.)

The Web Is More Than a PDF Distribution Medium

Organizations that have a lot of PDF files lying around are distressingly loath to convert them to HTML for posting on the web. That’s somewhat understandable, given the dearth of decent automatic PDF-to-HTML conversion tools available. But that’s poor comfort to someone who comes to your web site and gets a pile of links to PDFs instead.

Users, quite frankly, hate it when they click on a link, expecting to see a web page, and instead get an Adobe splash screen popping up in their face. Then they hate it some more when they have to try to navigate around the PDF document. They complain about it on web forums and in blog postings and online editorials, and they create Firefox extensions to minimize the problems, and even usability gurus write articles about PDFs being “unfit for human consumption”.

There are times when you want, or even need, to make PDFs available. But for goodness’ sake, minimize the frequency with which you do it, and warn people whenever a hyperlink has something other than a normal web page behind it.

Navigation Bars at the Bottom of the Page

I’m somewhat conflicted about these. In an ideal world, I think they’re a good idea. Once a user’s finished reading some article or essay on your site, they have no real need or desire to go “back to the top” of the document. The only reason for putting those “back to top” links is so people can get to the navigation elements that are all at the top of the page.

So why not put navigational elements at the bottom? Nav elements at the top are only useful if you don’t expect people to read the content. This makes sense on index and navigation pages, but not on content pages themselves — if you don’t expect anyone to read the content, then why did you put it there in the first place?

So, in theory, I’m strongly in favor of putting a full nav bar at the bottom of any page with more than a screenful of actual content on it. It’s just another form of my usual “make the user jump through as few hoops as possible” courtesy.

In actual practice, however, I get the impression nobody really uses those links. People are too well trained by sites that have no bottom navigation; nowadays, everyone expects to have to go back to the top of the page before they can get anywhere else. Which means that having a nav bar, instead of the expected “back to top” link, is just likely to confuse them more.

I still haven’t decided on a firm solution; at the moment, I tend to put a usable nav bar at the bottom that isn’t so splashy as the one on top. (This site’s a good example of that.)

Overuse of Flash

Before I go off on this point, let me note that the heading here is “overuse of Flash”, not “any use of Flash”. There are some great uses of Flash out there, from the games on NeoPets to rich typography with sIFR. Particularly when it’s used to do things that can’t be done any other way, Flash can be the best, or even the only solution. It can even, it appears, be made standards-compliant, which is another bonus.

But far too often, it’s used to do things that could just as easily be done some other way — and in a more usable fashion, too. For example, using Flash to develop an animation effect on your nav bar. Or to make your site’s logo bounce and wiggle around as the page loads, or to show the user some animated video intro.

All of these things can be done in compliant, cross-browser ways using DHTML, without requiring a plug-in. The response time for a DHTML event is also a lot quicker than many Flash effects, though I’m not sure how many of those are just the designer deciding to be “cool” by making text fade or swoosh into view.

Also, remember that any text in your Flash object can’t be searched, can’t be zoomed to aid a viewer who’s having trouble seeing that 10-pixel high, grey-on-black text, and can’t be indexed by search engines. Finally, note the fact that, for an increasing number of users of the Firefox “FlashBlock” extension, every one of your Flash objects looks like this:

That’s right, a big empty box with a little icon inside that becomes a “play” button when the user mouses over it. More and more users are installing this extension to block annoying Flash ads. In the process, they’re blocking out your gee-whiz nav bar, too. Granted, Firefox market penetration is still not quite up to 10% (and FlashBlock use is at some unknown number, but definitely lower than that). Still, if you were relying on that Flash object — any of your Flash objects — to impress or awe your visitors, you should be aware that somewhere from 2% to 5% of them are laughing or snorting in derision, instead.

Of course, if you’ve given your user an explanation of what the object’s for and why they might want to play it, then odds are that they will. And if it’s a good piece of work, then they will, indeed, be impressed. And that’s the difference between using Flash as actual content, and simply using it as eye-candy, or a shiny gimmick. Nobody wants your shiny gimmick. They want your content.

Content Is Still King

In fact, it always has been. The particular content you provide might be entertaining, informative, provocative, or even some combination of the three. Or something that’s not on that list at all. But if you haven’t got any content, then nobody’s going to come back to your site after their first visit.

Whatever it is you’ve got, that’s what your users are coming to your site for. If there’s something on your site that’s getting in their way, then you need to scrap it. Whether it’s a two-stroke form design that makes the user jump through two hoops where one would do, or a snazzy 45-second-long intro video, or a piece of non-conformant HTML that locks out the 10% of users who aren’t using the most popular browser, if it stops users from getting to your content, then it needs to go.

Conversely, whatever helps them get to your content more easily, and helps them do it by the route that makes sense to them — that’s what you need to keep. That’s what you need more of. Hover effects that make it more obvious what’s what? Keep it! A page-bottom nav-bar that saves the user an extra click? Keep it! Look at your design. See how you can streamline it, how you can make things clearer and easier to use, and then implement that...

...because that gets your users to your content. It’s always been about the content. Content has always been king.