More web site Knick Knack

In the last article we listed some of the seemingly good but superfluous elements web designers clutter their sites with. We covered:

This time we will wrap up with some more examples and a list of ideas how to spot cluttering knick knack.

This time we make the wheel purple

One common mistake that web developers do (or are asked to do and don't feel confident enough to refuse to do) is to reinvent basic behaviour of the operating system or the browser.

A lot of content is a drag

Many a time inexperienced designers, who haven't grasped that the dimensions of a web site are not in their powers but in those of the visitor, will come up with a content area of fixed dimensions. Realising that there will be too much content to fit in the space, they design a flashy scrolling area using their own scrolling DHTML or Flash widgets, discarding the inbuilt browser scroll options. The standard scrollbars may look boring in the eyes of a designer, but they have several benefits:

A "roll our own" scrollbar solution has the following problems:

Let's take a closer look at a standard scrollbar, and what functionality it offers, to see what we would have to replicate with our own script:

A scrollbar allows us to either use the arrow buttons to scroll up and down or drag the slider to scroll faster. The slider also indicates us where we are in the whole text and how much text there is to come. Screenshot of a standard scrollbar

The longer the text, the smaller the slider gets. This indicates not only where we are in the text, but also how much more there is to come. Screenshot of a standard scrollbar in a longer section

Clicking on any section of the area the slider resides in will move it there. Richer applications also offer fast scrolling buttons and buttons for going to the top and the bottom.

These are a lot of features our scrollbar should have to match the ones that come free with the browser and the operating system - most of them a nightmare to implement cross-browser (when using DHTML).

We have to ask ourselves if we are up for that, and if we are up for maintaining the script in the future to make it work with the browsers to come. Also, we have to ask ourselves how we could improve the scrollbar. Reinventing something should represent an improvement of the original product, after all - simply matching the features is not enough.

The site in the site

Another example of replicating existing behaviour is web sites that keep a whole site within one document - either by hiding and showing page sections via DHTML, as one big flash movie or via frames. Seemingly, this is a great idea, as visitors load the page once and go from there. With Flash or dynamic loading we don't even have to load the whole document, but retrieve bits "on demand".

What these solutions do though is change the visitor's browsing experience. When we surf the web, and end up on a page we didn't want to go to, the automatic reaction is to use the back button or the keyboard shortcut that brings us to the last, cached, page. When we don't allow the browser to jump from page to page, and thus adding them to the history list, going back will initialise the site. The visitor will have to start over again, and search where she has been before, something that can be quite frustrating, especially when the visitor needed to provide data at some stage. Many a hack tries to work around this problem, all of them dependent on scripting or hidden IFRAMES or other ugly cheats.

It takes some users a long time to get accustomed to the idea of browsing the web, and we expect them to be very interested indeed if we want to make them forget what they have learnt.

Browser history and setting of bookmarks are powerful tools that should not be disabled.

The Russian doll symptom

Ever since CSS and DOM support allowed developers to show and hide elements, this feature was used for some good but also for a lot of evil. It can be nice for visitors not to have to see all the elements of a page but it is easy and tempting to overdo the hiding. If a visitors needs to guess which elements of the site expand into more and more options or needs to find out by hovering the mouse around then something went wrong. This is especially the case with so-called "dynamic" or "clever" forms. Let's face it - filling forms online is a drag and most probably the biggest reason for visitor frustration. If every selection in a form triggers more and more options to be filled visitors can easily get fed up with it halfway through. Let's give the visitor a chance to fathom how much content there is or how much data we need her to provide before we send her into the depths of our products. A simple indicator that this is step 3 of 7 to fill out can prevent a lot of frustration.

If we want to hide a lot of page content and have the visitor expand and collapse it we should also provide a chance to store the current settings to avoid losing the current state when the page gets reloaded.

Fly my pretties, fly...

DHTML layers moving erratically around the page were quite an eye opener when browsers of the fourth generation came to be. Snowflakes falling down the page and words trailing the cursor were the bee's knees and gave our web sites a "Wow" effect. However, the third and fourth time we visited the page, they became more of a "Grr", as they are there for their own purpose, and do not give the visitor anything of value. Technically impressive though they are, it is better to keep them in the drawer labelled "amazing feats of the past". Why exactly would one need a clock around the cursor when the operating system provides one in a more convenient spot?

That being said, there are uses for DHTML layers that do make sense. One would be to use them to display images without loading them in another browser window, or displaying the information provided in a title attribute in a nicer way

.

Changing the cursor

Even before CSS2 and its cursor property allowed us to change the display of the cursor - or pointing device, as the CSS specifications call it - there was a wish to do so. This lead to a plug-in called "comet cursor" which came free and made every web site a lot cooler - until people realised that it also spied on them.

Changing the cursor can make a lot of sense at times - for example when you develop a web application that allows for resizing of images or picking a certain area within another. Another quite common good use is to indicate to the visitor that there is more information than meets the eye - for example teaching Microsoft Internet Explorer that an acronym was properly marked up:

HTML:
<acronym title="Cascading Style Sheet">CSS</acronym>
CSS:
acronym{cursor:help;background:#eee;}
Output:

The available cursor styles do all have their meaning though and visitors will know what they are for. If we use a crosshair cursor on our navigation mainly because it looks cool it might annoy them, as they expect more to happen than just a reload of the page. So, unless we really do provide more functionality, it is best to allow the browser to choose the different types of cursors.

Baring it all

One knick knack you see on a lot of personal homepages is too much personal information. Why would a visitor want to have a Java applet showing the current temperature and wind conditions in our hometown? Why do some people feel the need to publish their winamp playlists on the web (and thereby efficiently making web searches for certain music a real nightmare)?

In a time of identity theft, credit card fraud and email and contact data harvesting for spamming reasons it is better to keep a low profile on the site - if you want to give more information, do so once you have been contacted.

One typical example would be people publishing their family tree on the web site. If you have done that, take into consideration that most banks will ask you your mother's maiden name as a security question. Someone who got your credit card data wouldn't even need any computer skills to cause havoc - a telephone, some conversational skills and a gullible call centre assistant is all it takes.

Scripting Obfuscation

One seemingly cool feature that emerged only in recent times (about a year ago) is using Javascript to make sure that evil email harvesting bots of spammers cannot follow email links on the site. These scripts come in several flavours. One might be:

<script type="text/javascript">
me='coolwebmaster'+'@'+'mysite.com'
document.write('<a href="'+me+'"> '+me+'</a>');
</script>

Others might write a me[at]foo.com and turn that into a mailto link via scripting. Apart from not being safe, these scripting solutions dwell in the same category as right-click protections: The normal visitor gets hurt more than the evil spammer. Visitors without Javascript might not even be able to contact you, no matter how much you explain to them how they need to copy and paste obfuscated emails. The spam war is lost - as soon as your email is readable online, you will end up with spam. Let your email server or ISP deal with the problem, don't make it one of your visitors.

Forewarned is forearmed

So, how do we spot web site knick knack when we are considering new features for our share of the web? There is no general rule - as the type of our web site or application and our audiences are different (YMMV), but some danger signs are easy to remember:

This article was originally published at Devarticles.com.

Back to icant.co.uk.