The September 1 issue of CIO Web Business ran a cute little article called “The Dirty Dozen.” One of its columnists reached out and asked various people what they hated most about web sites, then put the comments together in an article. But there were a couple of omissions, I thought.
First, although everyone was clear about what they didn’t like about web sites, no one really offered suggestions for a fix. And second, no one asked me what I thought.
Well, I have my forum too, so here’s an addendum to the work of the good folks at CIO – with luck, correcting both those oversights with My Stinky Seven.
Browser Incompatibility
Web designers and publishers: In case you haven’t noticed, there really are still two major browsers out there. Microsoft may be winning (may have already won, for that matter) the browser war, but even 30 percent of the browser marketplace is a fair amount of eyeballs.
When you build a web site, make sure that every piece of it works on both of the big browsers.
My most often noticed failure is the display of blank pages on Netscape browsers. This is usually caused by having pages built within a table structure, where the opening and closing table tags don’t match: IE allows it and Netscape doesn’t. But there are plenty of others (ASP-driven pages that Netscape thinks are executable files is another hot spot of mine).
The fix is simple… run them on both browsers before you launch.
Generic 404 Pages
Server-generated (generic) 404 pages are the perfect way to lose a visitor. And it should never happen, considering that there is little that’s simpler than creating a branded, navigable response to a dead link.
On UNIX servers, add an entry into the htaccess file that points to a specific .htm page containing the customized 404 response. On NT, enter the selection into a dialog box out of the Microsoft Management Console.
And remember, it’s not enough to make sure that your own site links are all working -over time you will publish and remove dozens of pages that are indexed on the search engines and not removed – they’re still pointing to you.
Typos
Spell checkers are a nice thing to have. But they’ve made us a little lazy, haven’t they? They don’t find missing words, or the wrong word spelled correctly.
Consequently, there’s not a web site around that doesn’t carry a load of errors. And of course, not everyone spell checks their work anyway, do they? (I fondly remember reading the word “Intenet” on IBM’s web site.)
The answer: Proofread the old fashioned way…you know, carefully. Read each page slowly out loud, one word at a time. Or proof with a partner, reading the page aloud while the other follows along. I know, it’s basic stuff.
So basic, nobody bothers to do it.
Dead End Configurators
I love configurator functionality. Sites that offer me a set of choices and then seek content that fits the criteria I specified. It’s such a straightforward (and to this day, in my view, under-utilized) way of focusing content for individuals.
But I get very frustrated when I take the time to enter my selections – and the time it takes to wait while the front end queries the database – only to be presented with “No Matches.”
There are two things I’d suggest:
Either test all the combinations ahead of time and develop functionality that stops a dead end query from being entered, or simply make sure that you don’t present anything that won’t build a match.
- At least, give people a default selection when you can’t match their query. It could be a general pointer to the basic topic they’re looking for, suggestions on how to enter better queries, or some other useful response. “Better luck next time, sucker” just doesn’t cut it.
On-Site Search Engines as Primary Navigation
In a world where you have so many opportunities to provide navigation and discovery vehicles for your visitors, to force them into the land of Booleana by putting up a search engine (especially without configuration help) is, in my view, a disservice. At least the way the engines work today.
Within a short time, as XML becomes a standard, it will be possible to develop engines that really do return useful targeted results.
But until that day comes, use on-site engines as a last resort.
Splash Screens
Why, oh why, would anyone do this? We all know that people who come to the web are on a hunt for something. There’s not a research effort that doesn’t report that people who come to do business online already know what they’re looking for (that’s right, people don’t browse on their browsers). All splash screens do – static, with redirection, or animated – is retard the hunt. That’s why most of those space wasters give people an opportunity to “Skip this screen.”
It’s like the old joke: “Doctor, it hurts when I do this…”
So don’t do it.
Secondary Windows
I’m a pretty experienced web user, and I still get confused when a site opens up a secondary window – usually as a device to hold on to a visitor when the site links to another domain.
What they really do is create confusion on desktops, which are not the clearest interface in the world to deal with in the first place. After a couple of those additional windows, you have proliferated browser icons on your computer to the point that you don’t know where you began (especially if you – as do I – have more than one browser window open at a time anyway).
The solution? Either frame the page, or don’t link externally.
What’s Your Hot Spot?
OK, I’m feeling better already. Venting is fun… you should try it.
In fact, why not send an email to me here and let me know what frosts your browser. Next month, I’ll follow up with highlights of the most often mentioned. Until then… happy browsing.
