Developer

Running Water Web Design

I think that it is time to fully explain my philosophy of Web site design and development. I call this theory "running water Web design," because it follows the idea of running water: smooth flowing, taking the path of least resistance, and simplicity. This philosophy does not force anything upon the user, adapts to their needs and environment, and degrades gracefully. It makes Web sites that endure the inevitable change, while delivering your content to the end user in a manner that makes it as easy as possible for the end user to consume it, with an emphasis on usability.

To distill the running water Web design philosophy into one simple sentence: make no assumptions about your user, their technical savvy, or their technical capabilities, while at the same time never forcing them to do things your way instead of their way.

The first step in adopting this philosophy is to simply give up on the idea of being able to precisely control the way your Web site appears to the end users. Once you surrender to the reality that users have a wide variety of screen resolutions, operating systems, color depths, and needs, you give yourself the freedom to design great looking, highly usable Web sites.

Use CSS as much as possible, but only use CSS that all browsers will accept and only use CSS that the site will properly work without. CSS is great because it allows you to separate your presentation as much as possible. This also translates to cleaner server side code, because design changes require minimal editing of templates or of code that generates HTML. But CSS has a dangerous side as well, which is that despite the perpetual call for HTML standard compliance, different browsers interpret much of it differently, or have their own specific extensions to it. This means that you should be very careful with your CSS. Unless you are designing an intranet, where you are guaranteed that users have a particular browser with particular settings, you cannot count on your CSS working right if you rely upon a particular browser's interpretation of it. Some users will disable CSS entirely, or have their own browser settings establish that override or ignore your CSS, so make sure that your site is still usable without the CSS as well.

All font sizing should be proportional; any non-standard sizes (such as "smaller") should be percentages of the base size, and the base size should be set in ems, not pixels or points, in order to ensure correct cross platform sizing. Different platforms interpret "pixel" differently, in terms of onscreen DPI. The end result is that a font defined as "14 px" will appear differently on different screens (Mac OSX is one example of an OS that does not follow the norm). Font points are also slightly different from OS to OS, and should be avoided as well. Ems are the only unit of measurement that you can count on being the same on every user's system. Never forget: anything less than the equivalent of 10 point font is going to be unreadable to a substantial portion of users. If you find yourself tempted to use a small font for whatever reason, take a moment to consider if losing the page views of people with less than perfect vision is worth preserving your design.

Using fixed width table or page sizing is acceptable, as long as at least one portion is set to a width of 100% in order to consume the user's window, as well as to scale down properly if their window shrinks. One of the biggest frustrations I have with Web sites is seeing a site where the designer made sure that it worked great at 800 x 600 resolution without allowing it to easily scale upwards for users with higher resolutions. The end result is a design where users at higher resolutions see content floating in a sea of background color or tiled images, causing unnecessary vertical scrolling. Even worse, to compensate for these horrible fixed width designs, the designer often forces a font size that is nearly unreadable to those with less than perfect vision. Your user picked a specific size for their browser window on purpose. They have a particular display resolution for a reason. Forcing the user to scroll unnecessarily will lead them to subconsciously hate your site.

Any design element must be wholly optionally or changeable according to the users' web browser settings without breaking the site or rendering it useless. A great example of this is link color. Over the years, the user has become accustomed to the default link colors of their browser. Trying to change this or using non-default link colors will cause the user to have a more difficult time finding the links. Even worse, if your background is similar or the same as the user's standard link colors and the user has forced their browser to use the default link colors no matter what, the user will not see your links at all. Font size is also in this category. Modern Web browsers all the user to force their own font sizes onto any site. If this completely breaks your design, your design needs to change.

Eliminate the use of any non-HTML compliant tags or code. Do not use HTML compliant tags that major browsers interpret in a radically different way that will break your site design. Again, our goal is to sure that anyone interested in your content is able to consume your content. Any design element which does not accomplish this goal is a waste of time and makes QA a nightmare.

Do not use fancy code that will not work well for users with screen readers as well as content or navigation that requires user input (including mouse gestures) to be visible. Not only is writing this kind of code a lot of additional work, QA testing on it is a royal pain in the neck. Why make your life hard, as well as turning users off to your site for some drop down menu or flying widget? Many users (if not most users) instinctively position their mouse on the vertical scrollbar while reading your site. If the content or navigation requires any kind of input to be visible, many or most users will not see it. This especially applies to links; if the link is not noticeable without a gesture or input from the user, you can bet that you are going to lose a ton of page views.

If user input other than a single left click is required to view or activate content, assume that the user and search engines will not see it or be able to access it. Any content displayed in such a way must not be critical or important information. Ant interface behavior that operates in a desktop application manner as opposed to a Web browser manner is not good either. I know, I have been hammering this point quite hard lately. There is an excellent reason for this. Any user activity other than a single mouse click, or typing into clearly defined text boxes is a total failure of "the Mom test." Users do not do experiment with interfaces, users do not instinctively know that things can be dragged/dropped or right clicked or whatever. To have your design require this type of input (even if there are clear directions) renders your site useless to many users. For example, if clicking on a column header sorts the contents, also provide a drop down list for sorting. Yes, some users know that when the column header is linked that it typically means that clicking it will sort the table on the column. But a huge portion of users don't know this. When your user opens a Web browser, they expect anything within it to act like a Web site, not Excel or Outlook or whatever application you think you are replicating, regardless of how similar to the original it looks like.

Any client side scripting (including, and most importantly input validation) must be replicated server side as well, in order to allow "tightened down" browser installations, downscale installations, and automated site usage (search engines, screen scrapers, etc.) to properly use the site. Malicious users should not be able to circumvent your security by disabling client side scripting. This is an easy trap to fall into; client side scripting, especially input validation is friendlier to the user. Why have a round trip to the server just to tell them, "Sorry, your chosen password does not meet or strength requirements?" On the other hand, the moment you assume that the user has client side scripting enabled or that your client side scripting worked properly on their browser, you are in deep trouble. Many users disable client side scripting, or restrict its use to pre-approved Web sites. Other users may have a browser with a different implementation or interpretation of your client side scripting. And one of the first thing a malicious user will do is try your website without client side scripting, to see if they will be able to pass bad or dangerous values to your backend server. The last thing you need is to have assumed that everything was handled client side, and not re-validate and error trap on the server side.

All images must have ALT text as well as sizing information to ensure proper display. Never assume that the user is able to view the images. You want your users to be able to start consuming your content immediately, not to have to wait for images to download. Users on slow connections may even be done with that particular page view before the images finish downloading. Proper usage of image sizes help the browser properly render the page before the images download and help the browser render them properly (IE, for example, has a bad habit of resizing images as it sees fit). ALT tags make the images useful to the user before they download, as well as provide context to a search engine indexing the site. There is no reason to leave out these critical, but simple elements of HTML design.

Whenever possible, allow the user's browser setting to override your own settings without breaking the site. I have already mentioned this numerous times. Whenever you assume that whatever you have specified the site to look like will be what the user sees, you are going to be in trouble. There will always be users out there who override your link colors, font sizes, window sizes, and so on with their own settings. If your site breaks under these conditions, you will be in trouble. If your navigation consists of transparent images with white text, and you set a dark image to be the background, and the user disables background images, they will not see your navigation. If you use the default link colors for a background, and specify your own link colors, and the user forces the default link colors, your site will not be usable by those users. If your site relies on a particular font size to not overflow itself, and the user forces a particular font size for readability, you are going to be in trouble. Making no assumptions about the user or their browser settings will help you have a grateful audience that is delighted to use your site.

Aim your code towards the current least common denominators: screen resolutions, color depths, HTML levels, plug-ins, etc. If your site requires 1024 x 768 resolution as a minimum or 16 bit color or a plug-in or a JVM or something else that may not be installed, turned on, available, or set, you are limiting who can view your site. Why turn away visitors just because their setup or computer does not meet your definition of how a computer should be set up?

Never, ever use JavaScript to activate a page view, unless yourAJAX (or similarly coded) application requires it. This completely breaks the user's ability to use their browser's tabbed browsing or opening a link into a new window. It also makes the link invisible to a search engine. If you need to open a link in a new window, use "target="_blank"" not JavaScript. If you want to try to force that window to be a certain way (no scrollbars, a certain size, etc.) use JavaScript on that new page to do this, do not try to do it within the page link.

Stick to major navigation being placed on the top or left as much as possible. The top and the left (particularly the top left corner of the page) portions of the page are what the users' eyes are drawn to upon the initial page view, and the user spends more time looking there than anywhere else on the screen. If you put your navigation there, the users will be able to quickly and easily navigate your site. Another fact to consider, is that these locations are where users are accustomed to looking for navigation elements, since most Web sites put the navigation there. If you put expected design elements (navigation, site search, "email the Webmaster" link, etc.) where the user is used to seeing them, your users will be able to use your site from the get go. No one likes having to learn to use a site, and that significantly damages usability. You want your users to remember your site as "the one with good prices that I had no problems with," not "the one with great prices, but I could not figure out how to add items to my cart."

Remember that the top left corner is the most important place on the screen; the bottom right corner is the least important. This means that whatever you feel is the most important part of your site design, whether it be the logo for branding, a site search, navigation, or something else, needs to go here. There is no way to change this fact. If you put the site search at the bottom right corner, no one will use it.

All links must obviously be links. This is something else that has been changing since the introduction of CSS. For whatever reason, many Web designers feel that making links look less "ugly" by removing the underlines and/or making them look like the rest of the text is a Good Thing. I suppose on an aesthetic level, they are correct on occasion. In terms of usability, they are dead wrong. If you want to drive users away ASAP, make it impossible for them to find the links they want to follow by making them blend into the rest of the

Offer a "printer friendly" link on every page. This is optional, but as highly recommended as can be. When a Web page is printed, none of the design elements are useful to the person reading the hard copy. They cannot click the links, the styles are useless, frequently it is being printed on a black and white printer (or in black and white mode) and so on. All the user wants is the content. Give the user what they want, and provide a "printer friendly" link that provides the content, plain and simple, in a format and font suitable for printing as opposed to viewing on a screen. If the content is split over multiple page views, the printer friendly version should provide all of the pages as one

URLs should be browser bookmark, email, and search engine friendly. If they are not, the server should be able to determine the correct content to display to the user. If you are passing really long URLs around that may break in email clients, or may get mangled if someone tries to post them to a newsgroup or Web forum, you are missing out on potential page views. If your URLs contain a session ID, you are giving your users a lousy experience, especially if they send "?product_id=50&session_id=541039ASD" to a friend in an URL, and the friend gets a giant warning message about an expired session. Do you really think that the average user is able to correct the URL to see the product? Of course, you also want search engines to spider our site nicely, and present clean URLs to the user. Ugly, long, session specific URLs may make life a touch easier on the backend, but they are going to kill you on the front end. And accepting the session ID from the URL is a dangerous habit, as it allows a malicious user to participate in other user's session with enough automated guessing or reverse engineering of the ID creation system.

Avoid splitting content over multiple pages. Each page should be a discrete item, and not require additional page views to finish reading. If multiple page views are needed for whatever reason, usually due to an ad-driven business model where page views drive revenue, a "print friendly" link must display all pages as one. This serves many purposes. First of all, when someone finds the page through a search engine, and they land on page three out of seven, they may be rather confused, and they may not be able to find their way back to Page 1. Users really do not like having to go through multiple pages. In addition, compressing the content into one page increases its visibility to search engines. And search engines like to only display one or two pages for a site; would you prefer that the users see three separate pieces of content that might help them, or just three portions of the same piece of content? Remember, each time you require your users to use the navigation system, regardless of how well designed it is, you are introducing a potential difficulty or interface failure. Keeping your content on one page minimizes the points of potential failure for your users.

Never break the user's "Back" button or other elements of their Web browser's functionality. If you are using something other than standard anchor tags for navigation, you are doing something wrong. By breaking the "Back" button and other basic functions of the user's browser, you are damaging your usability. The user always knows where their browser's "Back" buttons are; they may not always find the "Back" button that you coded onto the site. The same applies to "Close Window" buttons. If you have a procedure which will cause something bad to happen (such as double charging for a checkout) by a page refresh or form re-submission, recode your backend logic. A simple disclaimer of "refreshing this page will cause you to be charged twice" just does not cut it. These are functions that the user has probably spent years learning how to use as they need to. Breaking them is like building a highway that requires drivers to drive on the opposite side of the road, it just does not work and will cause major problems.

Never alter the browser window's appearance (scrollbar color, title bar color, etc.). This has become very, very common. Between CSS to control appearance, and JavaScript to change the browser's window display, Web designers and developers have gone nuts. For some reason, they seem to think that their particular design is more important than the user's settings. I have been to sites where the scrollbar was forced to be nearly all the same shade of black, including the arrows. Needless to say, scrolling to see content would have been nearly impossible without a wheel mouse or knowing that the keyboard also scrolls the page (many users think that the keyboard is solely for entering input!). The user has a particular color scheme and window layout on their computer for a reason. Some users may require a high-contrast color scheme for visibility reasons. Others may have spent money or effort on a GUI skinning system to fit their own aesthetic tastes. There are a million reasons why the user's browser window looks the way it does. So why break it? Doing so does not help the user, it just confuses them. If your Web site changes their browser to no longer look familiar, you have forced the user to relearn how to use their browser, just for your site. Remember, the goal is to work within the user's environment, not to make the user learn your environment!

To summarize the running water Web design philosophy into a simple checklist:

* Use CSS as much as possible, but only use CSS that all browsers will accept and only use CSS that the site will properly work without.
* All font sizing should be proportional; any non-standard sizes (such as "smaller") should be percentages of the base size, and the base size should be set in ems, not pixels or points, in order to ensure correct cross platform sizing.
* Using fixed width table or page sizing is acceptable, as long as at least one portion is set to a width of 100% in order to consume the user's window, as well as to scale down properly if their window shrinks.
* Any design element must be wholly optionally or changeable according to the users' web browser settings without breaking the site or rendering it useless.
* Eliminate the use of any non-HTML compliant tags or code. Do not use HTML compliant tags that major browsers interpret in a radically different way that will break your site design.
* Do not use fancy code that will not work well for users with screen readers as well as content or navigation that requires user input (including mouse gestures) to be visible.
* If user input other than a single left click is required to view or activate content, assume that the user and search engines will not see it or be able to access it. Any content displayed in such a way must not be critical or important information.
* Any client side scripting (including, and most importantly input validation) must be replicated server side as well, in order to allow "tightened down" browser installations, downscale installations, and automated site usage (search engines, screen scrapers, etc.) to properly use the site. Malicious users should not be able to circumvent your security by disabling client side scripting.
* All images must have ALT text as well as sizing information to ensure proper display. Never assume that the user is able to view the images.
* Whenever possible, allow the user's browser setting to override your own settings without breaking the site.
* Aim your code towards the current least common denominators: screen resolutions, color depths, HTML levels, plug-ins, etc.
* Never, ever use JavaScript to activate a page view.
* Stick to major navigation being placed on the top or left as much as possible.
* Remember that the top left corner is the most important place on the screen; the bottom right corner is the least important.
* All links must obviously be links.
* Offer a "printer friendly" link on every page.
* URLs should be browser bookmark, email, and search engine friendly. If they are not, the server should be able to determine the correct content to display to the user.
* Avoid splitting content over multiple pages. Each page should be a discrete item, and not require additional page views to finish reading. If multiple page views are needed for whatever reason, a "print friendly" link must display all pages as one.
* Never break the user's "Back" button or other elements of their Web browser's functionality.
* Never alter the browser window's appearance (scrollbar color, title bar color, etc.).

J.Ja

About Justin James

Justin James is the Lead Architect for Conigent.

Editor's Picks

Free Newsletters, In your Inbox