Find citations on Bloglines or Technorati. View blog reactions
By category: Design, Engineering, Front End Engineering, Info Mgmt.
I spend a lot of time thinking about what it means (and takes) to build a high-quality, professional web site or application. I consider the whole spectrum, from macro concepts like Graded Browser Support, Separation of Concerns, and Progressive Enhancement to micro rules like never employ href="#" and always use the label element to bind text to form controls.
It’s difficult to compose a prescriptive list of all the issues a "perfect site" must satisfy. So, lately I’ve been think from a different perspective. Instead of "what it takes to be great," I’ve been asking myself "what does a great site NOT do? More specifically, I’ve been assuming a perfect site gets 100 points initially and then loses points for shortcomings.
Here are a few examples that I could use to measure a site:
- -1 point for each instance of href="#", (max of -5).
- -5 points for redirecting old browsers to a "you must upgrade" page instead of letting them see the plain linear content at least.
- -2 points for design degradation at +/-1 font-zoom level; -1 for degradation at +/-2 zooms.
- -1 for each form element missing an associated label element.
- -2 for a missing (or malformed) doctype
It’s too early to debate the mechanics (should it be -1 or -2 points), but I like the approach in general and am going to keep playing with it this week. One good way I’ve found to discover the list of things is to find a nice modern page, hit view-source, and start giving it a code review. Each thing that catches my eye probably belongs on the list, somewhere at least.
I’m quickly building a longish list — and will publish it before too long — but right now I want to ask: What would you put on the list?
Subscribe to this blog.
Ryan October 8th, 2007 - 5:44 pm
1) Non-semantic markup (endless divs, tables, etc)
2) onclick=”function()”
3) CSS classnames or ids named “redtopnav”
4) Font tags!
5) Tables used for layout
6) Over 2 CSS or 2 JS files
7) Images for headings instead of just using some good CSS & default fonts
8) Expressions to replace all png’s in a page with gifs (I’ve seen it!)
9) Content that is inaccessible to screen-readers or search engines (display:none; or heavy JS without graceful degradation)
10) 100% Flash sites. Most of the time only a small part of the site really needs to be in Flash.
11) Un-bookmarkable content. (No use of browser history management)
12) A general lack of LSM (Hard to quantify, but you know it when you see it)
I look forward to seeing the list!
Gopal Venkatesan October 8th, 2007 - 6:06 pm
-100 points for mentioning this site works with only browser X ;)
But seriously here’s what I’ve seen across the table in general,
1. -5 points for using divs or tables everywhere instead of using the appropriate paragraph, header, table tags where they make sense
2. -5 points for using the same color for visited, active links creating a confused user experience
3. -2 points for using images without the alt attribute, and an additional -3 for using them as submit buttons (again without an alt attribute)
Garrett Dimon October 8th, 2007 - 8:18 pm
I really like the concept here. I’ve always wondered about the same kind of thing, but always gave up on the “additive” approach. There’s just too much to do, and it’s so easy to forget or overlook some of the really fine-grained aspects.
However, there’s definitely a minimum bar of things not to do that makes a site usable in the technical sense of the term. I do think a significant part of it should be the browser-grading. It amazes how many “professional” sites for Fortune 500 sites don’t work in Safari.
Looking forward to see where this goes…
Anup October 9th, 2007 - 6:02 am
I too like your idea here. In particular talking about font resizing. many modern sites, even those built to web standards often don’t work well with simple resizing. A real annoyance for me!
I wonder if it is worth you creating an extension to Firebug, similar to how you guys provide the excellent YSlow!
Maybe this extension can be configurable to
a) allow additional factors to be added/removed by the user
b) allow scores to be modified by the user to suit their needs/preferences.
That would be quite a good code check. Of course, there will be some things that are quite subjective and not possible to detect properly through software alone, but maybe some things are useful to encode this way?
Joe Clark October 11th, 2007 - 5:51 pm
You should limit this to five criteria. Just five. If you can’t get those right, you’re in the wrong business. (But you’re probably doing better business than we are.)
Tables for layout is a gimme. demerit=–1 for tables=n, –2n for tables>1.
Aaron Gustafson October 13th, 2007 - 8:02 am
You have to be careful with the TABLE judgment. You’ll want to test for a TABLE that is the first and only child of the BODY element and for TABLEs that are descendants of other TABLEs.
Single TABLEs which exist within the content are perfectly acceptable, of course, but it is also possible to have a valid page that contains a semantic TABLE that is a direct child of the BODY (for instance, in the event that someone is just making a basic page with no need for divisions). In that case, however, it is likely (though not necessary) that the TABLE would have other block-level elements as siblings and the TABLE would (probably) not be the first element in the BODY (being proceeded by a heading of some sort or at least a paragraph).
In short, testing for abuse of TABLEs is a tricky undertaking. You may be best running a test to look for nested TABLEs, which _would_ be a layout hack.
Nate Koechley October 13th, 2007 - 8:34 am
@Ryan - great list. All of those belong on the final list.
@Gopal - thanks especially for the same-link-color one. While bordering on design, it’s important and sometime the result of poorly ordered CSS rules.
@Garrett - thanks for the “additive” word, that’s exactly right.
@Anup - great idea to make a tool of it. I’ll definitely consider that, or perhaps once I publish the list maybe somebody in the wild can take a crack at it.
@ Mr. Clark - solid advice to keep it lean. Thanks for that.
@Aaron - very good point, and some clever suggestions there for how to create a more viable test.
Thanks everybody! I’m glad you liked this idea, and I thank you all for your input. I’ll be writing more about this, so stay tuned and lets keep the converstation going.
thanks,
nate
Asbjørn Ulsberg October 14th, 2007 - 11:58 pm
Additional stuff I’d like to see on that list (in random order):
1. ‘href=”javascript:*”‘
2. Any transitional (like ‘font’, ‘bgcolor’, ‘target’, etc) markup.
3. Any ‘*frame’ element in the markup.
4. Transitional DOCTYPE.
5. Frameset DOCTYPE.
5. Huge lumps of inline JavaScript (should be shoved out to its own .js file)
6. Use of ‘document.write()’.
7. Use of ‘window.open()’.
Dennis Kehrig October 21st, 2007 - 8:39 pm
- Using GET (as in links) to initiate a state change (as in delete or even logout)
- Requiring cookies
- Trying to forbid to view the page source
jim g October 22nd, 2007 - 11:17 am
Maybe this is an obvious one and/or slightly off topic from this discussion, but I spent a lot of my early career maintaining templating systems designed to deal with these sorts of issues: It really bugs me when a website doesn’t have consistent headers/footers/navigation. Many websites out there still think of (and build) their site as a “collection of discreet pages” instead of a _homogeneous system_ that interacts as such. As a result, it’s pretty obvious when a website uses, for example, a cut-&-pasted header on multiple pages where the copies end up getting out of sync over time. This is obviously bad from a coding standpoint, but more significantly results in a negative and sometimes jarring user experience.
john October 22nd, 2007 - 6:50 pm
* 2nd on Dennis’s recommendation that requiring cookies is a problem — and ideally, the product would rewrite all URLs . . .
* All functionality show be exposed without requiring JavaScript…
ppk October 26th, 2007 - 9:42 am
Here’s the two rules I thought of while sitting in the Y! cubicle:
Check CSS for any occurrence of position or float. If they’re not there, the site uses table layout. (If they ARE there, the site might till use tables, though).
Check for empty elements. ( counts as empty)
ppk October 26th, 2007 - 9:44 am
Oops. Last line should read
<p> </p> counts as empty.
Adam Burmister October 29th, 2007 - 12:04 pm
@Ryan:
I don’t think you should be subtracting for onclick’s on elements, especially for high performance sites. Attaching at DOM0 will always be faster than attaching to elements unobtrusively. While it’s idealistic, it’s not always practical.
Also, putting limits on JS files isn’t always going to be a great idea. While you’ll gain performance with less HTTP requests by concatenating your JS files, you also run a risk of hitting an error in your JS file; and when that error is hit it means the rest of your JS file won’t be parsed and won’t run. It’s a bit of a balancing act.
@Nate: Good idea though, you should post a follow up list.
-1 for no print stylesheet
… also I have a pet peve of blah
Beth November 25th, 2007 - 2:56 pm
-1 for using spacer gifs
-1 for smart quotes
-2 for excessively large images
-1 for using the same title on every page of the site
-1 for missing shorthand opportunities like:
.foo{
margin-top:10px;
margin-right:10px;
margin-bottom:10px;
margin-left:10px;
}
Andy Pemberton December 19th, 2007 - 2:03 pm
These always get me:
- onclick=”javascript:someFunction();”
- a href=”javascript:window.location(someUrl)”
Speaking of, Nate - I had a related question for you related to fonts.css. I’m curious why you prefer to use the *property selector as a CSS filter for IE, rather than using IE’s conditional comment mechanism?
There’s been a lot of debate about Conditional Comments, CSS hacks/filters, and the like - and just was curious about your opinion.
-AP