There are many errors of web design that are committed again and again. Regrettably, the larger the organisation behind the website, the greater the risk that these, often amateurish, errors are made—web designs seem to be driven by a pseudo-professional naiveness that actually raises fault to virtue...
This is the more paradoxical, as there are many other websites that discuss various errors like the ones below; but apparently these are never read by the eventual decision makers.
Still, it is better to light a candle than to curse the darkness:
The below contents have grown out of hand, and will likely be moved into more specific pages over time.
In the time since the original writing (mostly in 2009 and 2010) there have been many changes to the Web that are not usually reflected below. Most notably, Flash, which is mentioned repeatedly, has been disavowed even by Adobe and almost disappeared from the Web. Other relevant changes include (but are not limited to) modern browsers often blocking 3rd-party cookies and preventing pop-up windows per default, which has had or will have an effect on use and abuse.
My own habits, situation, and whatnot have also changed in various ways relative statements below, including that I abandoned Opera quite a few years ago, have an ever lower tolerance level for advertising, and have moved several times.
A site-structure that makes it hard to find information. I visit to be informed—not to spend half-an-hour browsing and searching for a piece of information that might or might not be there. At least provide a sitemap, think the navigational structure through, and do not deliberately hide e.g. contact information (lamentably many companies actually try to prevent direct contacts).
Web designs with poor readability; in particular, use of idiotic color combinations. Light yellow text on a white background?!? Dark green and brown?!? If the user cannot physically read the text, what use is the website? Other related problems include a coloring scheme that borders on the painful (never mind the unaesthetic), e.g. a bright lilac.
When choosing colors, it is very important to consider that different users have different settings for brightness, contrast, etc.—even in the unlikely event that lilac looks good on the designer’s computer, it might not for other users. By using common color combinations, the risk of offending the eyes of users is minimized. Make your site memorable through excellent contents—not color explosions.
Sites that unnecessarily require JavaScript (not all uses are unnecessary). Many users deliberate turn off JavaScript to diminish security risks, avoid intrusive pop-ups, and reduce the amount of moving content on pages.
Admittedly, this critique is becoming a little dated by now (2009); firstly, most modern browser allow blocking of specific JavaScript actions (e.g. “open new window”, “disable status bar”) without turning JavaScript of entirely; secondly, many ready-made libraries (e.g. RichFaces) make heavy use of JavaScript—and, unlike the average home-made solution, bring an actual benefit for the user.
Nevertheless: When in doubt, do not use JavaScript—and never use it
gratuitously (e.g. in an a tag where a normal link would have
been appropriate).
And by a later now (2023), I find myself disagreeing with the above optimism:
Firstly, working with selective blocking is not truly practical. Many annoyances can be avoided, but far from all, and the underlying security and privacy issues largely remain. In a worst case, selective blocking can make a site seem to work, until, at a critical moment, it does not. Advice to users: Block everything per default and only allow individual sites access to JavaScript when it is truly needed and in a sandbox of some sort (e.g. a separate browser instance or firejail instance).
Secondly, on regular sites, JavaScript does not bring me, as the user, benefits. There are some special purposes sites, e.g. Elster (TODO integrate previous texts on Elster), where JavaScript could have brought benefit with a sensible implementation, but where the implementation is not sensible. I note that e.g. eCommerce was well functioning in the days before JavaScript became dominant—more so than today. Advice to decision makers: Make sure that your site works without JavaScript. Bonus functionality with JavaScript might be welcome, but the site must work without it.
Thirdly, there is increasing reason to believe that JavaScript is wanted for nefarious purposes (e.g. unethical surveillance of users and profile building), with e.g. “Please enable JavaScript for a better user experience!!!!!!!!!” being a mere excuse.
Fourthly, Cloudflare and similar “protection” mechanisms abuse JavaScript for purposes like discriminating between robots and human users. If this is allowed to go on, we will eventually be forced to allow JavaScript for each and every site that we encounter, or surfing will be impossible. If sufficiently many users were to refuse JavaScript such abuses would become too expensive in lost traffic. (I am not optimistic about reaching a critical mass, however.)
Sites that unnecessarily require cookies. Cookies can be abused by unethical third parties, e.g. to track user movements on the Internet—including gathering of information on their real-life identities. For this reason, sensible and knowledgeable users often turn cookies off or restrict them to sites they trust. Correspondingly, a website should only use cookies when there is a valid reason to do so, e.g. to provide a shopping cart, remember user-specific settings, or to track logins. Even in those cases all functionality that is not directly related to the cookies must still be usable without them (e.g. searching for a product without putting it in a shopping cart).
If you do require cookies: Always make sure that they come from the site that the user is actually browsing! It is an absolute given for experienced users to disable “third-party cookies”—even when they have ordinary cookies enabled.
In particular, the interpretation that users and browsers make when they encounter a third-party cookie is “This cookie is not connected with the website I am surfing, but is used by a third party to do something secondary, typically tracking my movements or some other use that I am better off preventing.”—if you have a legitimate use for cookies, you have no legitimate reason to disassociate yourself from them. (If you check into a hotel under a false name, most will assume that you are not the true you—and many will assume that you are up to something not-quite-kosher, if they find out.)
Failure to inform the user in advance, or at all, that certain functionality is needed. To continue the shopping-cart discussion: It is not uncommon for a site to not mention that cookies are needed when the user puts items in the shopping cart. I have had at least two cases where I was faced with an empty shopping-cart when trying to “check out”—with no indication from the site that something was not in order. (By activating cookies and going through the same items again, the purchase could be completed.)
Notably, checking whether cookies, JavaScript, whatnot, is supported and activated is comparatively easy—it does not take psychic powers.
Interestingly, when these checks are made, the corresponding message is often downright rude, creating the impression that the user is the one who has done something wrong; or factually incorrect (a favourite is to claim that the browser is too old or lacks a certain functionality, where the functionality is, in fact, just turned off). Possibly, I am being small-minded and/or not a representative case, but claims like "Your browser is out-dated. Please go to [link to Microsoft] to update to the latest version." actually anger me: I use a modern and highly standards-compliant browser (Opera)—no standards-compliant website has a valid excuse to not function properly.
To take a specific example from the Swedish paper Svenska Dagbladete:
Du måste uppgradera din Flash-plugin
Flash kan hämtas gratis från www.adobe.com(You must [emphasis added] upgrade your Flash-plugin
Flash can be retrieved free-of-charge from www.adobe.com)
The reason for this “must”: The article contained a completely unnecessary Flash animation, instead of the traditional, completely unnecessary, still image... Anyone interested in the actual article had no need whatsoever for Flash—in fact, the legitimacy of using a Flash animation here at all is highly disputable.
As a general rule, the only assumption that a website should ever make about the user’s settings and the browser’s capabilities is “turned off” respectively “not available”. The only exception is standard HTML and CSS. Corollary: If a website requires cookies, JavaScript, Flash, whatnot, it has an obligation to explicitly check for these capabilities and (if appropriate) politely notify the user of discrepancies between requirements and capabilities. In special cases, e.g. intranet applications, other means of notification, e.g. a user manual, might be a legitimate alternative.
Unfortunately, most websites seem to use a self-centered, silent assumption that all capabilities are turned on—disregarding that surfing with such settings is both significantly less enjoyable and more dangerous than with more sensible settings.
Sites that only work with Flash. Flash is a non-standard format, has no real justification in the world of HTML, is not (well-)supported by all browsers, and brings security risks; further, many users deliberately turn it off to not be bothered by extremely intrusive adverts (the main use for Flash—advertising is one thing; advertising that turns a site into a chaos of movements and colors, however, has no justification). Above all: I have never seen a use of Flash that could be justified from an information POV.
Sound files that play automatically. These are extremely intrusive, can cause disturbances in the office, lead to malfunction or odd complications when the user is already using another source of sound (e.g. a softphone), or otherwise cause problems—including giving the unsuspecting user a nasty shock when a too-loud message appears.
In particular, information should never be given in this manner: The web is a text medium. Further, the proportion of users who will not hear the message in the first place is significant: Not only can sound be deactivated, but loud-speakers/head-phones can be turned off or on too low a volume (or not be present at all), another application can block access to the sound-card, ...
Intrusive pop-up windows. These waste the user’s time and energy. Further, they violate the user’s right to control over his own computer.
Specifically, regarding pop-up adds: The naive marketeer should be warned that these annoy or even infuriate the vast majority of users, and that the number of newbies who fall for them does not come close to outweighing the lost good-will.
A twist is that many pop-ups come from third parties, notably through ad-affiliation programs. These pop-ups bring some benefit for the third party—at a severe cost for the actual website (and its users). It pays to forbid such abuse through e.g. contract stipulations.
Links that open in a new window/tab. It should be the decision of the user, and the user only, where a link opens.
New windows of a temporary character, e.g. a pop-up to select a date from a calendar, can be justifiable—there is use and there is abuse. When in doubt, however, use plain links opening in the same tab.
Links (in particular in menus) that do not allow the user to open them in a new tab/window. Typically, this is a side-effect of incorrect application of JavaScript—only very rarely can it be justified to have a link call JavaScript instead of another page.
A special case is over-specification of targets in anchor tags: If a target is not actually needed, it should not be added. Things might run smooth as long as the user enters the site through the main page, and only ever opens links in the same window/tab and stays in the pre-defined frame set (this is normally a problem limited to frame based solutions). However, as soon as this is not the case, havoc ensues. Assume for instance that a website uses a frame-set with one or two static navigation frames and a content frame for the actual pages, and that the internal links of content pages redundantly target the content frame: If a user enters a content page directly, e.g. over Google, any click on internal link will open a new tab/window, because the referenced target does not exist in this scenario. If he closes the new unwanted window, it will only open again at the next click. A second click on another link can over-write the contents of the new frame. Should the user deliberately open links in new tabs, then any subsequent clicks in the individual tabs will lead to changes in another, common tab. Etc. (There might be some variation in behaviour depending on the exact browser used.)
Navigation that unnecessarily relies on images. Example: I recently saw a time-line implemented as an image with (possibly) six clickable sections. Each section led to a discussion of the relevant part of the time-line. This is idiotic and user unfriendly: Most users will have problems knowing that there is something to click (as exemplified by the explicit textual mention of the clickability—a sure sign of an unintuitive interface) and exactly where to click for what effect. Users who have diminished sight and rely on reading software will be entirely lost. (Not to mention the possibility of users who have images disabled per default, e.g. to accommodate a cell-phone connection or to minimize exposure to advertising. Additionally, the layout of many websites takes a significant turn for the worse when images are turned on—something that web designers would do well to consider—and I, personally, often have images turned off for that reason.)
A better solution would have been to have a list of textual links clearly marked with the corresponding time interval (e.g. 1860–1930). To make the graphic an additional means of navigation to the same contents could conceivably be a good idea; however, it should not be the sole means of navigation.
Subsequently, I have found out that Google makes a similar mistake in its archived-news search. Cf. http://news.google.com/archivesearch?q=teste (retrieved on 2009-07-22, note that this behaviour might change over time).
A special case is menus (and similar constructs) that uses images for the clickable entries (acceptable), but fail to provide an “alt”-tag (unacceptable). A closely related issue is the use of same-color foregrounds and backgrounds, where the text is present even without images, but only readable when the default background has been replaced with an image.
Yet another is the use of images where a link should be used. Consider http://mathschallenge.net/e (2010-03-02). In the middle of the page is an icon followed by the text “Click icon to contact mathschallenge.net”. The link should have been on the text, not on the icon. That the text was needed to clarify the icon implies that this was one of the many cases were an icon brings a negative value. Formulations like “Click X to Y” are generally a bad idea—here e.g. “Contact us if you have questions or feedback.” would have been a much better choice.
Distracting movements on the pages. I visit to read, and everything that moves, blinks, scrolls, ... is a distraction and an annoyance—irrespective of whether it is the site’s own content or external ads.
Pages that do not work in standard-compliant browsers. That a non-compliant browser with a large market share (i.e. IE) is supported might be in order—that support of standard-compliant browsers is forgone, is inexcusable.
Pages optimized for a particular resolution or browser. It entirely out of line to expect the user to adapt his screen resolution for a particular website; in particular, because the only reason for this idiocy seems to be to ensure that a particular layout is displayed correctly down to the last pixel. Good web-design implies that a site works well irrespective of resolution, browser used, etc.
Notably, designers must not be naive about the (pixel) width (or height) of the browser window: I have repeatedly seen incompetent designers ask questions like “What is the most typical monitor size?”—and believe that they are on the safe side, if they comply with this number. Apart from the many displays that are smaller than the “typical” size, there is one gigantic flaw with this line of reasoning: Not everyone will actually use the entire monitor width for his browser. In fact, among more experienced users it is uncommon. Even when the entire monitor is used for the browser, the actual viewing field for the page might be smaller due to tool bars, window decorations, and whatnots. As a rough rule of thumb, a page should work, even be it with compromises, without horizontal scrolling and major distortions even at 40 % of a normal monitor. The nit-wit who goes with a fix assumption of 1280 pixels because this is “typical” should have gone with 512-or-more pixel.
Use of PDF documents instead of HTML. Having to switch applications just to watch textual content is bothersome, and PDF documents waste both bandwidth and computer memory. Further this shows a lack of underlying professionalism: Rightfully, a document should be kept in a logical format (e.g. based on XML) from which PDF, HTML, whatnot, is generated as appropriate. The use of PDF clearly implies that the organisation has failed to do so. (Or that it is so keen on bringing across layout and images, instead of content, that it prefers PDF due to the larger amount of layout control—again displaying a lack of professionalism.)
See also e.g. http://www.complang.tuwien.ac.at/anton/why-not-pdf.htmle.
On rare occasions someone actually links to other formats, most notably MS-Word. This is even worse: PDF at least has the advantage of being reasonably platform independent and having free quality readers and plug-ins available—this is not the case with most other formats, certainly not with MS-Word. Further, everything from MS-Office is highly inadvisable for security reasons.
One of the few exceptions to a strict ban on other formats is plain-text, which interacts well with HTML; however, neither rich-text (too limited) nor PostScript (once allowed, but with too little support in the Windows world) qualify. Non-text formats are, obviously, a different matter altogether, but would typically work on a “download and use locally” basis (legitimate examples of this include programs, movies, music, zip- and tar-archives).
Incorporating an occasional PDF document, in particular one from a foreign source, can be acceptable; however, having a HTML page link to a dozen different “brochures”, “information sheets”, or similar, is highly user unfriendly. Similarly, I have repeatedly seen companies who present a listing of all open positions in HTML, but where each individual entry, absurdly, is a PDF file.
Using PDF documents without very clearly stating that they are PDF documents is inexcusable. At the very least, a corresponding icon or a “(PDF)” should be added to the link, so that the user suffers no unpleasant surprises or handles the link suboptimally.) The same applies to links with other non-HTML contents. Recently, when visiting the Swedish online paper http://www.dn.see, I have clicked on perfectly normal looking links, expecting to see an article—and been lead to a “WEBB-TV” page with a Flash-based pseudo-TV feature instead of the text. Inexcusable!
Use of contact forms instead of email. (Particularly annoying when the site has the audacity to refer to this as “send us an email” or similar.) This has many disadvantages, including that the contact is not present in the user’s email client, that he gets no “bounce” in the case of an error, and that extra effort has to be spent. Further, the forms often require activation of cookies and/or JavaScript to work.
Note that “we do this to avoid spam” is not a valid reason: By using various alternate means of display, the problem of spam can be avoided, e.g. “john dot smith at domain dot com” instead of “john.smith@domain.com”, or an image of the text instead of the text it self.
Requiring entirely unnecessary inputs. Consider again a contact form: Subject, email address, and the actual message is what rightfully can be required. The name of the sender should go in the message, yet is often divided into two mandatory fields (first name, last name). Whereas the name can be forgiven, e.g. if a back-end tool is used where the name can be pre-filled through the form, other cases are unforgivable: Many sites require telephone number, cell-phone number, fax number, street address, age (!), and/or other irrelevant items. (Only acceptable if there is a very strong obvious need; however, usually only unethical data gathering and an attempt to deter users from contact come in question as explanations. Some sites treat a simple attempt at contact as if it were an application for an insurance policy.)
Forms that simply do not work: It is not uncommon (even when I have JavaScript, cookies, etc., turned on) for a form to return an unspecified error on submit. Other instances include claiming that a mandatory field needs a value, despite being filled out; and claiming that an input field contains data in the wrong format—without indicating what the correct format would be... A typical error is not stripping white-spaces before checking a format: In a recent instance I copy-and-paste’d an email address into a field, and received the answer (roughly translated from German) “Enter a value that is a legal email address.”. As it eventually turned out, I had accidentally copied a space at the end of the address. Notably, this is an error which could have permanently stumped a beginner.
More generally, it is odd that most websites seem oblivious to copy-and-paste, e.g. that they require a repetition of an email address—where every sensible user would just copy-and-paste it the for the repetition, likely even the original entry. Another example is fields that are pre-filled with e.g. “Enter your name here.” and where this text is automatically removed when a user types into the field, but not when he pastes into it. Presumably, there is a JavaScript check for a key-press/down/up event, but none for other input possibilities. Seeing that there is little to gain by such “instructive” pre-fillings, I would recommend not using them at all.
Over-use of sessionsw to track context information that belongs in links. If we consider e.g. a listing of books in an online store, it should obviously be possible to have the detail pages for several different books open simultaneously. Unfortunately, many websites do not base the display on which book belongs to what link, but instead have a single session variable identifying a single “current” book. Clicking on the link to book A would set this variable to point to book A, and then a page would be called which is rendered based on the current contents of the variable. (And so on, for B, C, ...) If a user now opens books A, B, and C in short order, the variable is overwritten and the rendering can be broken, e.g. resulting in all three pages displaying book C... Even if the rendering is done correctly, there is a considerable risk that actions taken on the respective page (e.g. “put in shopping cart”) are applied to the wrong book.
A particular problem occurs with items that can be edited by the user, hypothetically online auctions that he has started: If auctions A and B are open simultaneously, it is possible for edits on auction A to overwrite the contents of auction B—something that the user will typically only discover after the fact.
On websites that take care not to abuse sessions in this manner, and instead pass book/auction/whatnot IDs on through all relevant links, such problems do not exist.
Division of content (e.g. an individual article) into too many pieces. In this day and age there is no reason to not serve a three-page article in one HTML page; often, this can be extended to ten-page articles (at which point the article format should be reconsidered). Certainly, serving even one inappropriately large image or, yikes, Flash file will outweigh the size of a ten page article. Navigational ease should be achieved by in-page navigation and the user’s/browser’s own means and wishes.
A limited right to use more than one page exists through the natural wish to track user interest—calling subsequent pages indicate that the reader continued past the first page. However, the legitimacy of this right, when compared to the inconvenience for the user, expires with a division into two parts.
I have heard the claim that many companies do this to increase the readers exposure to advertising. If so, this is fundamentally flawed: The same amount of advertising can be added on one large page as on several smaller ones—unless, obviously, the site tries to cheat its advertisers by placing large amounts of adverts on parts of the page that the user will eventually never read, because they extend beyond the end of the actual page contents. (Cf. this discussion of an online news paper.)
Further, this added advertising on a long page will be more effective, because the typical banner blindness and the tendency to skip the top of the page are partially circumvented.
Forcing a frame-set onto a deep-link, or redirecting deep-links to the home page: This is somewhat understandable, considering e.g. where most advertising can usually be found; however, the negative effects on the user are too large. Consider redirects from a user perspective: One moment, he is looking at the information he is searching for; the next, he is redirected to somewhere he does not wish to be. Now, he has to search for the page he was already on—or will be so annoyed that he goes somewhere else, in the hope of less user-unfriendly behavior.
Forcing a frame-set, OTOH, could be possibly have been justifiable, were deep-linking the only reason that a user would access the framed page directly; however, it is equally possible that he used browser-functionality to deliberately focus on the one frame, instead of the entire frame-set. (The reason for this would typically be to use the screen better, simplify bookmarking, or avoid annoying movements, e.g. a news-ticker, in the navigation frame.) Forcing him back into the frame-set is extremely rude—and will likely cause correspondingly hard feelings.
(It can also be disputed whether frames are still, or were ever, a good idea at all.)
Forcing users to make unnecessary choices. Example: Many websites of store chains start by requesting a users ZIP code, in order to redirect him to the nearest store’s microsite (or to restrict searches to what is available there, or similar). However, this need not be in the user’s interest—or make him buy more. I, for instance, would like to check what is available at all and then, if applicable, make a choice of store. Notably, in Cologne most chains I would visit (e.g. electronics chain Saturn) have several stores within the city limits. Further, even chains that do not allow online ordering, usually allow placing orders for not-in-local-stock items in the individual stores—making the choice of store something that can be postponed until actually needed.
All-in-all, the user’s time and effort is wasted with no particular gain for either party. (Excepting, possibly, the gathering of statistical data concerning ZIP codes; however, if this is the purpose, it should be stated up-front and be voluntary information—not only can no-one prevent me from entering fake information, but I might actually be forced to fake it to get the right store selected for me...)
A special case: Prompting a user who logs in to his account with e.g. “Please fill in this survey.” or “Do you want to try our new upgraded account?” on an intermediary page between the log-in page and his account page. Here some justification can be seen, because this is a reasonably effective way to contact everyone who could be interested. However, it is still highly intrusive and many (most?) users will be annoyed, rather than interested. Whereas I do not rule this option out entirely, I would urge to use it with caution; further, that other means, e.g. a notification in a side-bar, are tried first. (Valid alternatives to this do not include a pop-up window, which would destroy even more goodwill—and stand a risk of being automatically blocked or manually closed, without being read.)
Adding such delays with an opt-out option for the future is only a marginal improvement. In particular, always assume that the user has a negative opinion (of e.g. newsletters, suggestions, delays, whatnot)—unless he has explicitly opted-in. (This is a central rule of user-friendly and ethical web development.) Notably, an explicit opt-in has not happened when the alleged consent is hidden in e.g. the T&C’s, or when the user cannot register without automatically opting-in—this is nothing but cheap trickery.
Use of browser (typically IE 6) specific instructions (“Right click and select X to Y.”). This will lead the user astray if another browser is used, if the browser has been customized, or if another language version of a browser is used. Note, in particular, that German versions of MS Windows and IE typically have been translated into German, leaving the low-end users without an option in this regard. (I assume that this is the same in most other countries.) A presumptuous link “Click here to bookmark!” can hardly be excused: It is a waste of space, an intrusion upon the user, and unlikely to work in a generic browser—even leaving aside the fact that not all browsers use the term “bookmark”, or, necessarily, the concept of a bookmark.
Further, beware that such instructions might fail on other counts, e.g. because a left-handed user has switched the order of the mouse keys on his computer.
Use of “tab index” in forms. There are a few cases where this can be justified; however, typically, it is best to let the browser decide on how the focus moves when tab is pressed (or the corresponding functionality is triggered by other means): Altering the tab indexing will very likely confuse and annoy the user, make navigation unpredictable, and can even cause errors of the “press tab, press return; oh God, no, not delete!” kind. True, changing the tab indexing can make it easier for users to reach the most likely fields/buttons in the most likely order, but only if the user knows this order. More likely than not, this is not the case; and a much better solution is to group the fields/buttons in the right physical order to begin with. (Also note that the designers assumptions about the order preferred by the user might well be wrong.)
Ignoring the user’s language preferences: Most browsers let the users set their preferred language(s) for content; however, very many multi-lingual websites ignore this setting. Instead they check the user’s IP address, make an educated guess as to where his computer is situated—and deliver content in the local language. Apart from the IP address not being a fool-proof indication of the location, there is no guarantee that the user prefers, or even understands, the corresponding language: Consider tourists, expats, language learners, countries with multiple official languages (e.g. Switzerland), ... In contrast, the browser settings (that should be respected already as a matter of principle) are much more likely to be correct: Browsers are typically delivered with the language set to the correct local default (German in Germany, etc.), and those users who have deliberately changed the value usually know what they are doing—if they do not, well, that is their problem, not mine, the other users’, or the website’s.
A particularly annoying variation is the automatic redirection to a country specific website that e.g. many search services use: A user who deliberately goes to e.g. www.google.com will often explicitly want to use the com version—redirecting him to www.google.de does him no favour. Yes, there are those who would want to use the de variation, but do not know of it. This, however, justifies only a blended-in comment (“Did you know that we have a dedicated German site?”). It does not justify a forced, automatic redirect.
Many websites, in particular online news-papers (cf. also my discussion of online news-papers), have a false sense of their own importance, and insist on users registering, filling in surveys or similar, before letting them access content that is accessible no-strings-attached elsewhere. These sites do both themselves and their users a disservice: The intelligent user goes to one the many other sources that contain the same information. Notably, it is not uncommon that papers copy shorter articles from e.g. Reuters verbatim, leading to near identical articles appearing everywhere. Even for longer articles, the addition of new content is the exception, not the rule; and even for own features on “current events”, most papers will end up divulging roughly the same information.
(I reluctantly admit that there are many out there who lack in “web-savvy” and indulge in these idiocies; however, this should be weighed against the other users scared away, the users who give fake information, and the users who otherwise circumvent such obstacles.)
The above should not be confused with voluntary registrations and surveys that have no strings attached; e.g. when the registration gives the ability to post comments or customize the appearance of pages, but the main contents are available to anyone. Nor should it be confused with forced registrations that have an actual justification, e.g. when a service is provided that is not available elsewhere.
Many sites proclaim e.g. “After a short one-time registration, yada, yada.”, not mentioning that the user will still be forced to actually log-in every now and then (in particular when using several computers), needs to keep a password available, etc. The extra effort involved here can be a much greater problem than the registration, per se.
Also note that many websites abuse the information provided by the user to send unsolicited newsletters, advertising, and similar. This naturally makes users reluctant to register—even if the website currently in question does, in fact, not commit such abuse.
Having a change in a select list (the HTML built-in drop-down menu)
toggle a submit of the current form.
This comes in two problematic versions:
Firstly, this has some limited justification when the state of the page itself changes (e.g. when the fields in an address form depend on the country selected). However, this is likely a suboptimal solution, and the user would be better of if the selection of country came earlier. Notably, he might already have filled in other fields unnecessarily, or accidentally have changed the country to now see his entries lost. Further, the delay that occurs while the page reloads is an annoyance. If a “dynamic” change is wanted, other solutions e.g. DHTML based ones, should be considered.
Secondly, the change can serve as a one-step submit, where the user just changes the selected entry, instead of changing the selected entry and clicking submit. This might seem like a favour to the user, but rarely is: It is a non-standard use of standard components, which is a deadly sin in UI development and leaves users confused and/or surprised—the page does not behave like it “claims” to behave. Further, this is usually done by forgoing the submit button altogether, which makes the page unusable without JavaScript. Further, the user might have a valid wish for the submit to not take place automatically, e.g. because he considers various options. I strongly recommend always using only submit buttons to trigger a submit—under no circumstances may the submit button be left out, even when an automatic submit is provided.
Both cases, further, can be unnecessary uses of JavaScript, which is highly user-unfriendly (cf. above); and can lead to unnecessary delays while the user corrects an unintentional or incorrect selection.
Note that the above does not refer to e.g. CSS-based menus and similar
drop-downs: It is perfectly acceptable to have e.g. a language choice on the
start page implemented by a CSS “drop-down” with individual link entries for
the individual languages—calling
a new page is the standard behaviour for a link, but not for a select
entry.
Reloading the page automatically (particularly common with e.g. live results from sport events). This brings very little for the user—he can easily reload manually when needed, and most modern browsers allow the user, himself, to specify an automatic reload. It does, however, have several disadvantages, including that a reload can occur when the user is actually reading the contents, which would leave him looking at an unreadable page until the reload is completed (which can take time, because these sites are often slow). Further, a lot of unnecessary traffic is caused, and a user who has stopped his Internet connection (after the original load) can be left looking at an error message.
Idiotically, some online newspapers also employ reloads—even though their material is not likely to change in short intervals. This can lead to (and, in my case, has lead to) worst case scenarios where a user opens a dozen links for later reading, and finds that the frequent reloading makes his browser near unusable.
If we look at the site provider’s situation, he shots himself in the foot: He must pay more for traffic, his servers are under heavier stress (making surfing slower for the user in the process), and his users are pissed off. The only conceivably rational reason (as opposed to the irrational and incorrect notion that it would be a service to the user) is that this makes it easier to track what users remain where for how long. Implementing a reload for this reason, however, is unethical and user-hostile. Further, it is likely to be a very imperfect system, considering e.g. users who open several articles at once, users who have to answer the phone, and users who simply forget a certain tab until the next day.
Similar, but less drastic problems, stem from websites that unnecessarily forbid caching of their pages.
On reconsideration, I see at least two other reasons that could explain the reloads: Firstly, a wish to artificially inflate page-hit statistics; secondly, an attempt to replace the advertising content on the page for greater exposure. The first is of disputable value, because such cheating is likely to be noticed in the long run. The second is hard to argue against, apart from the question whether such a brute-force implementation can be justified over e.g. switching banners by means of JavaScript.
In neither case, IMO, does the gain outweigh the disadvantages.
Doing automatic re-directs upon errors. A common worst-practice when an error (most notably a 404) occurs is to re-direct the user to a specific error page, the start page of a website, or similar. This might seem like a neat solution at first glance; however, it is highly user unfriendly. Consider e.g. a user who has manually entered an URL incorrectly, or has clicked on a link by someone else with a minor typo: Normally, he would now be able to correct this error, e.g. by changing a “.htlm” into “.html”; however, after a re-direct, he is stuck with another URL, and has to re-enter the entire address. Similarly, if he surfs based on a link list (own or provided by someone else), he can normally easily identify the problematic original URL and take corresponding actions (even be they only to delete the link from the list), but with a re-direct, he has to manually investigate the issue. In addition, with a redirect to the homepage of e.g. an online newspaper, he might not even be sure what went wrong or that something went wrong; certainly, he will lack the information needed to search the site for a possible new URL of the article.
Instead, a corresponding error page should be displayed under the URL used. Note that this does not prevent the sending of an error code.
Note: Redirects that occur when a page has been moved, and the new address is known by the server, is another matter entirely. If the wanted content can be delivered by a redirect, by all means do so. Even here, however, it can often be a good idea to keep the original URL and show a page along the lines “The page you requested has been moved to [new URL]. Please update any links/bookmarks accordingly.”
Focus stealing and similar intrusions. There seem to be at least two variations of this (both to be avoided): Firstly, the highly pretentious sites that just assume that they are so supremely important that they have the right to steal the user’s attention, interrupt whatever he might have been doing, etc. on their whim and/or deliberately try to sabotage his interactions with other websites. Secondly, the sites that naively try to “help” the user by guiding him to the point where they assume that he wants to be. Because this assumption will often be faulty (and then causes a severe disturbance), and brings very little when it is correct, this is actually a disservice to the user.
Various JavaScript tricks that deliberately or through incompetence sabotage the users surfing, including removing the status bar, fiddling around with his history, blocking the context menu (“right-click menu”) of his browser, and similar. Simply spoken: No website has any kind of right to make such intrusions. Further, no website has much to gain by this—including those who block the context menu in the naive wish to prevent copying of their contents: Anyone who really wants to (including all professionals and pirates) can easily circumvent this “protection”, but the average user is stuck with a disproportionate damage when other context menu entries become unavailable.
Various similar idiocies include starting windows in “kiosk” mode, making new windows fixed in size, etc. They all have in common that they for no valid reason reduce what the user can do, without any kind of gain for the site it self.
(An exception to the kiosk-mode veto is e.g. selection dialogues; this exception does not apply to e.g. the fixed-size veto.)
Beginning a page with so lengthy a non-content introduction that the user cannot access the actual contents without going a screen downwards. This is particular common in forums where even an individual thread can have a lengthy “Welcome to the YYY Forums! Yada, yada, please register, yada, yada,...” that, literally, takes up an entire browser screen. If the user then, e.g. when looking for a particular piece of information, has opened ten different threads, he is forced to unnecessarily scroll down one page at ten separate occasions. This is particularly annoying, because the effort normally spent on the page is roughly doubled (from “give it one look and close it because an imperfect match” to “find beginning of the actual contents, give it one look, ...”).
Such information, if present at all, should be kept either very brief or at the bottom of the page.
The site http://www.linuxquestions.org/e is a splendid example of how not to do it: The introduction is OK on the start page; however, the same is repeated on each individual page—severely reducing the usability. Notably, Google’s indexing also gets stuck on the introduction, and the searcher often miss out on the actual question in the search-result listings. (Statement applies 2009-08-04 and a long time before that, but could change over time. Update 2023-08-03: The last time that I visited successfully, the problem was still present—almost 14 years later. However, visits are rare for another reason, namely that connections are usually blocked with a rude claim about needing cookies—something particularly weak for a site dealing with Linux and, therefore, having a target audience that is unusually computer-knowledgeable.)
Another variation (sometimes seen in online newspapers) is a page that begins with an external banner, followed by internal advertising and layout, followed by a complicated navigational structure, followed by a headline in a large font, followed by a much too large image. The result is the same: The actual contents are visible only after scrolling down a full page. Note that this could be explained by a poor conversion from the print to the online format: In print, beginning an article with a large image is not a major problem, because sufficiently much of the actual text is immediately accessible anyway; online, this a very different story. Further, having a large headline within the article brings little benefit in an online paper: The reader has already deliberately opened this page to read (whereas, in a print edition, the article might still be in competition with other contents on the same page).
A head-line of a more decent size, less internal advertising, and smaller images that are embedded in the text is the way to go. If the paper wants to provide the reader with larger images, it should follow the established standard of having a larger image with the same content open when a smaller image is clicked (with the added benefit of reducing the band-width wasted). A navigational structure should not span more than one row (for a left-to-right, personally I prefer top-to-bottom).
Using a misleading file suffix on links: Consider e.g. a link to a page
which contains the opportunity to download the file dummy.ogg. Some
sites (including, regrettably Wikipedia) chose to use an URL and/or a display
name for this page ending with “.ogg” (instead of e.g. “.html”).
This tricks the user into believing that
the link leads to the file, it self, and might make him download the link
contents directly (or
feed the URL to a tool like wget)—but as the link contents are not the
file, but the download page, he now has saved an unusable HTML page instead
of the file. Because it is in the mutual best interest of both the site
provider and the user that the link is not misidentified, it should not be
mislabeled in this manner.
Possibly work-arounds include using a link text of “download page for dummy.ogg” instead of “dummy.ogg”. (With details depending on the exact circumstances.)
Using formulations like “For more info on XXX click here!”. This is bad for several reasons, the most widely relevant that it disturbs the flow of reading in an highly unnatural manner. A more severe problem for a smaller group: When using tools to filter out the links of a page separately (e.g. for use with a screen reader or some navigational tool), what remains is the word “here”, which is entirely useless.
A better solution would be to use “More info on XXX.”, an even better to integrate the link in the actual text. (Note that the intrusive and rude exclamation mark is replaced by a full-stop.)
Linking well is sometimes undeniably hard; in particular, as the types of formulations and formats used in traditional texts often give poor results—while the HTML formulations can look awkward, if read as if a normal text. Another complication is that linking on a too long text (like this rather longish example of how to not do it for ideal readability) can cause problems with both readability and text-flow (and, in a secondary issue, aesthetics). I even admit to having linked on words like “this” myself, although in less idiotic formulations, before being aware of all issues involved.
In the end, it is often necessary to make compromises in order to not spend undue time on resolving every individual link formulation (as the recurring reader can see in my own writings); however, the example discussed is simply unprofessional and reader hostile, and should never be introduced into a text.
Changing the looks of standard components too much. This can make the site behave unexpectedly in the eyes of users. Consider e.g. simply reversing the typical default colors of visited and unvisited links. Other examples include removing the underlining from links, messing with buttons and scrollbars, etc.
A limited change can be acceptable, if it enhances the design; however, it is vital that the changes do not reduce the clarity of the page. For example, I have changed the default colors of links, to use shades of blue and red that are less bright and in better harmony with the background color than the default values—but even that was not with a perfect conscience: Some browser could theoretically have different default colors, and some users could have configured own defaults (although the latter would likely be able to override the site settings anyway).
Making it hard for users to register (or otherwise successfully submit forms) by unnecessarily emptying fields when errors occur.
A typical example would be a user who fills out all fields, enters a CAPTCHA correctly, receives an error for a missing mandatory input, and is forced to enter a new CAPTCHA. This is idiotic: If the user has entered it correctly once, then it can be reasonably assumed that he is a real user, and the marginal improvement of security reached by a renewed entry is dwarfed by the disadvantages for the user. (Obviously, this does not apply when the CAPTCHA, it self, was entered incorrectly.) Other fields often involved are checkboxes for “Yes, I agree to your T&C’s.” where the user’s consent is required several times around, and “Yes, I agree to let you spam me.” where the checkmark mysteriously keeps re-appearing... It is not uncommon, however, for more or less arbitrary fields to be involved—presumably, due to sloppy programming.
The fields that are almost always emptied, and that pose one of the greatest annoyances, are the “password” and “repeat password”. However, this is not something that the websites can control when they use the HTML password-element—as they should. It is possible to program around this using normal input fields (possibly aided by JavaScript tricks), but I would advice against it.
There have been arguments againste the password field; however, if these are valid, changes should be done by the browser implementers—not by the individual websites.
A better way to save users from re-entering passwords, is to keep forms short, make them error tolerant, and otherwise reduce the risk that a user needs to re-submit his data at all.
Another example is not giving a listing of all errors in one go, but force the user to correct and re-submit a form several times before all errors are gone. I recall a project database with a long listing of fields, of which none were marked as mandatory, where my initial submit was rejected by pointing to about a quarter of the unfilled fields being mandatory, I filled out these fields, a new error came that another quarter were mandatory, I filled out these fields, a new error came—and I decided that my time was better spent elsewhere.
These examples are particularly annoying, when combined...
A common problem is an entry page that, through incompetence, blocks the users from accessing the actual site. There are a number of variations on this, including having a start page with a Flash-animation (“splash page”) that is only by-passable for those using Flash (not even having a plain link “Click here to go straight to X.”) and a token page that redirects the user to another page through JavaScript (redirects should be done with the appropriate HTTP mechanisms).
A related, but less severe problem in the splash family: An entry page without content, typically containing something along the lines of “Welcome! Enter here!” or “Please select your language!”—both of which slow down surfing with no actual benefit. In particular, language choices should be done automatically (in approximation) by the browser, which has a preferred-language setting; and later adjustments should be done on the content pages themselves, e.g. by having a set of flag icons or a drop-down list with languages in the menu.
Generally, splash pages, screens, whatnot, are a bad idea in almost all contexts (not limited to the Internet), and the world would be a better place without the vast majority.
Valid exceptions for websites are limited to cases where the user must be informed about or consent to something. A notable example is a page that filters users based on whether they are older than 18 or not. (While obviously ineffective, such pages can still serve as legal protection.) Another is where the entire site requires login for access; however, outside of sites with a preformed set of users (e.g. employees of the same company) this is rarely justified, and a division into pages with content that does and does not require login should be made.
Use of “auto-focus” of form fields (e.g. using CSS or JavaScript).
This might seem like a good idea at a casual glance, but is highly user
unfriendly in almost all cases. Consider e.g. the current behaviour of some
search engines: The user makes a search, a new page is loaded with a pre-filled
and auto-focused search-field above the search results, the user hits
space or page down to see the lower half of the page—and finds
himself involuntarily typing into the search field instead of scrolling
(incidentally also deleting the old input).
Even on pages where no such obvious side-effects are present, autofocus can lead to confusion and unexpected problems, because the page does not behave like the user expects it too.
This is particular bad for users who need an accessible browser, and navigate largely with a keyboard or a keyboard replacement: Not only will key inputs be swallowed as above, but attempts to select links or fields by tabbing can lead to very odd consequences, because the starting point is not what it should be.
If auto-focus is used at all, I recommend that it is limited to specific applications, preferably intranet ones with which the users spend sufficient time to learn the quirks.
Use of page-internal scrollbars (e.g. through an inline frame of unfortunate dimensions): This limits the usability of the browser (notably paging), can make for confusing layouts, and occasionally leads to disastrous situations where the scrollable area extends outside the view port.
It is better to integrate these sufficiently well into the page that the only scroll bars are the page-wide ones. Concerns like “But I want the user to always see my footer!” are not valid.
Legitimate exceptions can (sometimes; not always) include multi-select boxes and similar.
It is never, absolutely never, acceptable to hide a T&C, EULA, or similar in a small scrollable text-area. These should always be viewable as ordinary text included in an ordinary page, in an ordinary manner. (The same applies, m.m., to other obfuscation techniques, like the use of all caps.)
Generally, it is my impression that company websites are very keen on using “bleeding edge” web technologies—but, in return, trail behind five years when it comes to browser technology, user habits, etc. This can be seen e.g. by how often Flash (“cool” web technology—which many users hate, and which brings very little in usability and information transfer) is used and how many sites simple do not work with tabbed browsing (browser technology, which is extremely popular among the actual users). A discussion specifically of issues regarding tabbed browsing is available.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.