Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

WebSite Rules

In recent days, I've come across a great number of web sites that had fantastic content, but werecompletely unusable and impenetrable, or simply annoying. As a result, I decided to make a list ofrules that are intended to help people designing web sites avoid the pitfalls I came across. This isnot the be-all-end-all of web design rules. It was collected from personal experience, and thus willmost definitely miss some other important rules that most web pages already obey, or contain rules thatare only appropriate for a particular kind of web site.

Think of First-Time Visitors

Problem:

Frequently, I come across a web site and, after browsing it for acouple of minutes, I notice that I still don't have the foggiest of a clue what it is about. Too often,authors assume that people who enter the URL of a site already have an idea what to expect. However, often visitors just curiously follow a link from another similar page, or were Googling for something and ended up at your page that way.

Solution:

Every web site should have a clearly-labeled section thatindicates what it is about. A good name would be "What is it?" or "Introduction". Ofcourse, you may instead put this information on the home page of the site, and are actually even encouragedto do so.

When writing the text for such a section, keep in mind that it is intended for the first-time visitor.It should be short and to the point, and it should give the user an idea where to continue on your website.

Example:

Take a great fan-fiction web site likeU.S.S. Liberty. It is a page of stories about a spaceship in thesame universe as Star Trek. There are different kinds of stories there, short character pieces,longer short stories, novelettes and finally there are novels. You enter the site,and you pretty quickly get the picture that these are Star Trek fan stories, and if you know a littleabout the matter, you realize you never heard about the "Liberty" - so it's probably a faninvention as well. And then you find yourself staring at a beautifully done menu that looks like theEnterprise's computers, and you have no idea where to start.

The simple solution here, is to add a "What is it?" section. It would contain a shortsummary, like

These are the adventures of the Starship U.S.S. Liberty, as told by Joseph Manno.Set in the world of the U.S.S. Enterprise, these stories will take you on a Star Trekof fantastic proportions.
A short blurb like this is enough. In addition to that, the first page should contain a link"To the Stories", that leads to a list of the stories in the recommended order ofreading (this link may of course also be in the navigation area of the site instead, if it is clearlynamed). Usually, that's the order the stories were written in, simply because most stories growmore and more complex, the longer they are (and a series of stories is in principle one long story).

For reasonably complex universes, stories should be marked up to indicate the ones that containcentral points to the series, and those that are more of a "further reading" nature, orstandalone stories.

This Site:

You will notice that my web site doesn't have a"What is it?" section. Why is that so?

This web site is more of a compound web site of all my interests. As such, it would be prettyuseless to say anything more than what the home page says: It's Uli Kusterer's web site. All mystuff goes here. However, the home pages of the different topic areas of my site still containa quick summary of what they contain. So, strictly spoken, I do have a "What is it?"page for each sub-site of the compound.

Apart from that, my Stargate Fanfiction Archivehas such a blurb.

Think of Repeat Visitors

Problem:

Most web sites are intended to be visited repeatedly.As such, the path to a desired piece of information from the home page of the site should be intuitiveand fast. Everything the user has to click past before they get to the main navigation area after enteringa site's URL thus means it will take repeat visitors additional time to get at the information. Or, to bebrutally honest, it will annoy them.

Flash intros are a case in point. They are cool, they help me remember a particular site, and theyannoy the hell out of me whenever they are on a site that I visit regularly. E.g.there used to be a site called Cobraaa.com. They had monthly new G.I. Joe pictures, which meant I triedto visit the site about once per month. Every time I did that, my DSL connection downloaded half of their Flashintro before I even had time to click "Skip Intro". It was an unnecessary click for me, and itactually cost the cobraaa.com folks money because I downloaded a couple hundred unneeded kilobytes each time Ivisited their site.

A similar problem are Intro pages like that at Videodrom. I get a picture I almost know by heart on the third visit,and I need to perform an additional click before I even get to see the navigation area. Not to mention it's not obvious whether the page has fully loaded and that I'm supposed to click that huge intro image to enter the site.

Solution:

If your web site is intended for repeat visits, avoid intropages of this sort. If you must have one, make them full-fledged home pages, with the navigational area alreadypresent. That way, repeat visitors can directly jump to whatever sub-page they want to get to.

Of course, intro pages are still fine for vignette-style homepages, like movie web sites, which aretypically visited only once or twice before the user decides they want to see the film. Still, you might thinkabout having a "Skip Intro" link on the first page for those who come there a second time.

Think of Search Engines

Problem:

Many web site developers use frame sets as an easy way toalways keep the navigational area around without having to put it on all their pages. This has an inherentproblem: Search engines like Google, Yahoo or Altavista will open up found pages without the frameset aroundthem. The user will have the single result page without any way to navigate on your site for further information.Worse, often web designers try to save work by placing things like the site name and copyright information inother frames as well, which means the user only gets raw text without a clue who wrote it.

A similar problem applies to DHTML pages with layers, which some designers cunningly use to embed severalpages into the same HTML document. Sadly, that means that although the search engine will find something inthis document, the user will never see it if it's on another page than the first one. They will simply thinkit is a bad search result and move on.

Solution:

The frame problem can be solved by simply not using frames,and instead relying on server-side includes or PHP to embed the navigation file into your page.

Where that isn't an option, you can make life easier on yourvisitors by providing a "show navigation" link on your pages that allows bringing back theframeset. In addition to that, you can also add a JavaScript to your page that will automaticallyload the frameset when the page is loaded without it, however there must be an alternative, since manysecurity-conscious companies and users require JavaScript and other scripting languages to be turned offin their browsers.

To the DHTML issue I can only say one thing: "Only one page per HTML document, buster."

Don't Make People Seasick

Problem:

Some web site authors have the wonderful ability to createstunningly beautiful GIF or Flash animations. While these are a great attention-grabber, and definitely workfor stuffing lots of information into a tiny banner, be judicious in your use of them.

In particular, manyGIF animations run way too fast, or contain quickly flashing boxes that strain the eyes, or don't allot enoughtime for reading the different pages of the banner animation, or they take too long to switch between pagesbecause they have each word fly in from the top-left corner. This obstructs your information unnecessarily,and thus actively discourages reading of the information.

Another common mis-use is 3D-animated type, usedfor headlines. Here, half of the time the text is flipped, or upside-down, and thus hard to read, which isexactly what a headline shouldn't be, because it is intended to give a quick hint of what is below.

Other pages contain whole hordes of animated GIFs that keep running and spinning quickly all thetime while the visitor is reading text on the page, distracting the eyes, and running in un-synchronizedsequences that make the whole page "feel" wobbly and shifting, causing something akin to nauseain the visitor's mind.

Flash animators, be wary of using sound. Background Music is a matter of personal preferences, but e.g. alogo animation which plays a splashing sound every time a logo dips in the water can become annoying afterless than a minute, no matter whether you like water or not.

Solution:

Things like banners or other multi-page imagesshould run at a fairly slow speed (about 1 frame per second max.), to avoid unnecessary distraction of visitors. Of course, this is perceived speed. If this is actually an animation, you'll want about 24 frames per second for smoothmovements, but there should be at most one movement per second, so it feels slow and isn't distracting.Only attention-grabbers, i.e. warning signs or things like that may run any faster than that, and they shouldbe used only in a few select spots across the entire site.

Also, wherever you can, try to limit animations to a certain time span. GIF allows specifying how fast an animationshould run on a per-frame basis, as well as how often to repeat an animation. Usually, running an animation four orfive times is enough for the user to notice it anyway. However, make sure that the image the animation ends oncontains all relevant animation (e.g. a frontal view of the animated headline, or product name and site URL for abanner), and not just the last sentence.

Avoid blinking text, as it is only there half of the time, which essentially means the visitor has to wait forthe text to be "un-blinked" before they can read it. While most users don't notice such waits consciously,it helps to add additional sluggishness to the perceived speed of your site.

Example:

A good friend of mine, Steve Halls, has a funny example of a borderline case of animation abuse on his web site. He has two GIF animations, whichrun at different speeds, and where the background actually moves behind the animated image. It's bearable now, but originally he had three of those ... vertigo!

A really bad example was this page on laser surgery, which used to have 3D type that rotated and was only readable half the time. This page, BTW, has a history of abhorrent web design. If you use the wayback machine / WebArchive.org, you'll see that Java applets and scrolling text banners can be just as bad.

Make Your Links Obvious

Problem:

Many web designers think (rightfully), that underlined text lookshorrible, and the standard blue of links clashes with their site's color scheme. Thus, they choose to give linkscustom colors and styles. This frequently leads to confused users, because traditionally links have been blue andunderlined, and people start clicking at underlined headlines, or notice with surprise when they accidentally movethe mouse across a piece of bold text that it is a link.

Solution:

Links, being one of the most important navigation devices on websites, must be obvious. Yes, it feels like a crime against typography to underline text in the age of boldface andcheap italics, but in this case usability comes before design. Make your links obvious. Maintain at least one of the two characteristics they share on most of the web: At least underline them, or make them a clean blue.

If you definitely feel compelled to do neither, prefix links with an icon that indicates it's a link. People are known to recognize a small globe icon, or even better an arrow (like it's used for cross-references in encyclopediae), and give them the same distinct text style and/or color that clearly sets them apart from all other text on the page.

Finally, do not use the <u> tag, or any other way of producing underlined text on anything but a link. On the web, underlined text is synonymous with hypertext links, and people will simply start uselessly clicking your headlines. Use bold or italic, or bold and italic, or turn off bold or italic for the word to be emphasized, if they already are. Otherwise your site will (subconsciously) be perceived as having lots of "links that don't work".

Example:

Cinescape used to be a prime example of this problem on an otherwise cleanlydesigned web site, headlines were underlined, while the actual links to articles weren't.

Avoid Mouse-Over Scavenger Hunts

Problem:

Since the advent of mouse-overs in web browsers, there have beenmany attempts at improving site navigation by displaying additional information when the mouse moves over an item.

While this is generally a good idea, some authors hell-bent on using mouse-overs chose to actually obstructinformation by requiring you to mouse over certain items to find out what they do. The prototypical exampleof this is the all-black web page, over which you have to wave the mouse to cause links to "magically"show up. A more subtle one uses pale, half-transparent or blurred text that becomes readable when the mouse isover it.

Another horrible example is actually even worse: One designer decided to blur the text of the navigation linkthe mouse is over. While this may look cool at first, it is just as wrong as the other things I mentioned. When theuser points the mouse at something, they voice their interest in this particular object. They should get moreinformation, details. What they get in that case is less information. Worse, if they're distracted and forgetwhat they were trying to click at (e.g. Mom called in the middle of their browsing session), they have to movethe mouse off the blurred link, read it, and then move it backover it to click. Another perceived slowness that reflects badly on your site in the user's subconsciousness.

Finally, some designers decide to get rid of blue and underlined links to homogenize their design, thusmaking the only obvious way to find links waving your mouse over the text until the cursor changes into a pointinghand.

Solution:

Objects that are important enough to click at, should be importantenough to be readable.

Mouse overs should only be used to provide more detailed information to the user on a particular item, e.g. asmall preview of an image in a list. They should expand on existing information, not actually bring up informationin the first place.

Test with different systems

Problem:

Experience shows that there are many website authors who assumeeverybody is using the same computer system and browser as they do. They assume that everyone has their screenset to the same contrast level as they have, and that their visitors' eyes are just as good as theirs.

If you've stayed with me thus far, chances are that's no news to you: Every PC I've seen so far has had theirscreen contrast and gamma look a little differently (that's why you can change them in the system settings --because they often do differ). They also often had different screen sizes set, their users had differentideas regarding how large a browser window on the screen should be, and although one browser seems to be quitedominant in the market right now, there are still great numbers of users (especially on Unix, Linux and the Mac)which use different browsers.

I'm not going to tell you to cater to every browser. While in anideal world, my web site would even display beautifully in a text-only browser such as Lynx (and in fact, minedoes pretty decently, considering I didn't really have that in mind when I designed it), the fact is that somethings just don't work the same in all browsers.

However, most web sites that I see which contain notes like "best viewed with browser X at 1024x768 andmillions of colors" could easily be adjusted to display properly in all browsers if someone just took thetime to learn their craft. Do these designers think their users will buy a new screen or change their screen resoltion just to view their page? There are several different ways to do certain things in HTML, and while some of them don't work in all browsers, there is typically one that does.

Solution:

There is no universal solution. However, it isn't that much workto install a couple of different browsers on your computer, and get in touch with some people who have differentcomputers with another operating system than yours. On web design newsgroups, you commonly see postings fromgood web designers requesting Mac Users or Opera users or whotever to check out a site and tell whether it works.

Make sure you also test with users who have the same computer setup but a different screen, because each screenlooks a little differently, and what looks nice on your CRT may be too dark on a PC TFT, or too bright on a Mac. One helpful approach is to go to an internet cafe or other public terminal and try out your site there.

Think of less healthy people

Problem:

Many designers are, like me, young, and have still fairly goodeyesight, good ears and full control of their hands. However, most visitors to web sites aren't. Lots of peopleabove 50 have problems making out text below 12 points on the screen, a good percentage of people in France and the UShave problems telling apart certain colors (like red and green or yellow and blue). Other people have problemsperforming very small and fine-grained mouse-movements.

These people are completely healthy otherwise, but they have these small problems.

Solution:

Think of users that are less healthy than yourself when designinga page. Don't hard-code text sizes in screen pixels, and don't assume fixed widths or heights for windows, and donot enforce them. This way, people who have problems with their eyes, can simply click the "Larger" buttonin their web browser to make your web site easily readable, and they can enlarge their window to make the text fitmore comfortably.

Also, avoid nifty features like hierarchic popup menus. Yes, they are a great way to show off what you can code,and they also let you provide a complicated site navigation with little cost in screen real estate, but they alsorequire an additional click to open the menu each time, and they require very good control of the mouse. If you'vebeen using a mouse for half your life, that's not a problem, but if you're a newbie that has been using a mouse forone year, this can be quite a challenge.

Finally, do not use colors as the sole clue to something. Color should be a secondary clue along with an icon, ora text style or whatever. Color blind people are a large fraction of otherwise healthy computer users, and believe it or not, there still are some universities with greyscale screens where a light red is exactly the same shade of grey asa light green.

And while you're at it: use ALT-labels on images and other HTML tags. That way, you're both a little more friendlyto the blind and the users aren't entirely clueless if you have a broken link on one of your images. Not to mentionthat it helps search engines in categorizing your site's images.

Reader Comments: (RSS Feed)
No comments yet
Comment on this article:
Name:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

 
Created: 2004-03-29 @845 Last change: 2004-03-29 @845 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.