OpenIDWeb design and usability guidelines
Usability.gov’s Research-Based Web Design & Usability Guidelines lose instant credibility for being available only as a 39.2 MB PDF file [ Update: this statement is incorrect—see my correction ], with all of the usability and accessibility problems that brings with it. I’m on a fast connection here so I downloaded them anyway to have a look. There’s actually a lot of good things I can say about them—the document is attractively laid out, the guidelines clear and easy to follow and each is backed up by references to academic research (hence the title). There are however some guidelines with which I completely disagree, in particular the ones in chapter 4, entitled “Hardware and Software”:
4:1 Design for Common Browsers
Guideline: Design, develop and test for the most common browsers.
Comments: Designers should attempt to accommodate ninety-five percent of all users. Ensure that all testing of a website is done using the most popular browsers.
Rubbish. Designers should attempt to accommodate 100% of all users (in as much as content should be accessible to them), which really isn’t difficult if you stick to the standards rather than designing with a particular browser in mind. The 95% statistic is particularly worrying as they link to The Counter.com as a source of browser statistics, which currently shows Internet Explorer as holding 93% of the market.
4:2 Account for Browser Differences
Guideline: Do not assume that all users will have the same browser features, and will have set the same defaults.
Comments: Visually impaired users tend to select larger fonts, and some users may turn off backgrounds, use fewer colors, or use font overrides. The designer should find out what settings most users are using, and specify on the website exactly what assumptions were made about the browser settings.
Great guideline, lousy comment. How does specifying on a site what assumptions were made about the browser settings help anyone? It’s almost like having “best viewed in Internet Explorer at 1024x768 with 32 bit colour” plastered on to the front page. No one is going to change their settings for your site, so telling them what is assumed isn’t going to help them one iota.
Tellingly, the guidelines make no mention of using web standards or validating pages anywhere in the document. While there’s lots of useful stuff in there, this omission (and the clangers highlighted above) mean the overall package should be examined with a critical eye.
I. G. - 2nd November 2003 14:42 - #
I'm downloading the big baby. Your remarks are full of sense. They should have provided an HTML version of the guidelines book, and not mentionning the use of web standards sounds incredible for some usuability guidelines.
P01 - 2nd November 2003 15:27 - #
Sorry, Simon, I'm a little bored and perhaps inclined to post what's not relevant; but, in case it is ...
I agree that the last sentence in the comment on § 4.2 is bad, but I think the comment as a whole, is helpful.
Teaching a child to read is an interesting experience: you suddenly realize that what is obvious to you - because of total familiarity - is clouded to them. Similarly, if you put yourself back in the position of someone who only has a smattering of HTML and ask yourself, Is § 4.2 (without the comment) clear now?" you might say, "No!".
What I notice is that "browser features" and "defaults" are abstract terms. The comment does give examples, and examples make the abstract concrete.
George Orwell says:
and I agree with Orwell that that is, on the whole, a bad thing. I can imagine someone who isn't used to X/HTML looking at that section without the comment and wondering what the abstract terms mean. The examples help to make that clear.
Michael - 2nd November 2003 15:42 - #
Michael: There is nothing wrong with the examples; and giving concrete examples of features that a user is easilly able to adjust does help to focus the thoughts on the designer on what might be change between design and viewing. Unfortuantley, the action that the section suggests is totally wrong. In fact I would go as far as to say that what is suggested is the exact opposite of the correct action to take based on the observation that some users change the default settings. Section 4.2 should probably read more along the lines of:
(aside - is that an abuse of blockquote? Ii suspect it probably is, but I can't see any other way to seperate out 'text that would be part of the document' from 'text that is my own prose')
Even what I have written above fails to mention the immense customisation abilities offered by user style sheets (advice like "always set a foreground colour and background colour together" would be good in this context), the problems with form elements ("don't rely on a a specific width for form elements; this may break platforms that have different widget implementations" or better still "don't try to style form widgets at all, ever, since their styling behaviour is undefined in CSS and not portable").
jgraham - 2nd November 2003 17:19 - #
Christian - 2nd November 2003 21:46 - #
btw, The Counter.com is deactivated since May...
Sérgio Nunes - 2nd November 2003 23:24 - #
I admit it was a rather large download; thus taking me around five minutes to grab. I would agree from those citations their comments were a little peculiar since they were based upon assumptions made by the web developer.
Overall there was probably some good information within the Guidelines, though some of their ideas appeared to be just pulled from other material without much though of the implications, therefore some comments looked rather disjointed and makeshift.
Robert Wellock - 3rd November 2003 11:05 - #
jgraham, perhaps using the <ins> element would be an acceptable method of marking up insertions or additions to a quote?
Unfortunately that's an illegal tag on this comment form!
BenM - 3rd November 2003 12:58 - #
Adam Bramwell - 6th November 2003 02:07 - #
Simon Willison - 6th November 2003 02:39 - #
sonneries - 19th October 2004 10:29 - #