e-wot?

This is one of those simple yet useful lists. I enjoy a good list, I do. By Dustin M. Wax at Smashing Magazine.

Click for 7 Essential Guidelines For Functional Design

1. Consider the product’s goal.
2. Consider who will be using it.
3. Consider what your audience intends to do with it.
4. Is it clear how to use it?
5. How does your user know it’s working?
6. Is it engaging to your users?
7. How does it handle mistakes?

Mark Boulton draws a parallel between good airport sign design and good web design. Click for Airport sign design - dont’ screw with conventions He cites the source of his post as coming from this Paul’s Corner post

My favourite point about signage:

The number of passengers capable of reading (and correctly interpreting) a map is negligible. By and large, maps are display windows for the presentation of airport facilities and not substitutes for signposting.

Other points

• Sign colours should make the signs instantly discernible from their visually chaotic surroundings
• Use words that make sense to the user - avoid concocting clever gibberish
• Use sans-serif fonts like Frutiger, Gill sans reg, Clearview or Meta
• Test the signs to make sure they work

Mark Boulton says:

It’s not difficult to draw parallels with airport signage (in fact, most wayfinding systems) and website design. Good signage should enhance a user experience, it should help a user complete their task, and it should do it in a way that is unobtrusive.

Yeah. I find this sort of thing very compelling. Let me put on my trainspotter’s anorak …

About ten years ago I got interested in the possible relationship between good traffic sign design and good website ’sign’ design (meaning typography and layout). I tried to find out if there were any rules on typography, color, prominence for road signs that could be applied easily to web design. I couldn’t find any precise rulings on this in any UK traffic regulations, although I’m sure there must be some. I figured that any rules in a road traffic context for sign design might be useful to apply to web typography. Some kind of signage algorithm, maybe? =)

I’m still particularly fascinated by how the best traffic sign design has obviously been adapted to account for the speed at which people might be driving: everything becomes bigger, simpler and more conspicuous. Greater care is taken over where signs are placed so that drivers can clearly read them in time to act on the information they contain. This strikes me as very similar to good web design, which I’m sure takes account of the speed at which people move through pages in their browsers. Not the same kind of ’speed’ as a in car, but a similar problem of limited attention.

PBWiki has just announced improvements to their user interface. They’re inviting people to test the beta. http://pbwiki.com/content/pbwiki-beta

The thing that caught my attention was this bit about improving PBwiki’s wysiwyg editor:

“When we launched our Point-and-Click editor a year ago, we noticed a quick upsurge in our usage. The easier it is to edit, the more people use PBwiki.” link

So if your wiki’s text editor is easy to use, more people will use your wiki. Common sense, but good to see it stated.

Congress, RIAA and Universities prepare for P2P “arms race”
“The only successful, robust way to address problems that involve personal responsibility and behavior is with social rather than technological tools,” he said. “If we instead try and restrict behavior technologically… the only result will be an arms race that nobody wins.”

Gotta love that quote.

Dave Pollard has written a ‘methodology for Web 2.0 collaboration experiments (in reluctant organisations)’. It’s a neat roadmap for getting collaboration experiments off the ground in contexts where cost, risk, culture and complexity are concerns.

Here’s a summary of his steps:

1. Champions self-organise. One point he makes here is to co-opt all Web 2.0 users (wikiers, bloggers, online appers, social networkers, etc…)
2. Champions get together face-to-face to understand the situation and brainstorm opportunities. Adapting to the context/culture, not trying to change it.
3. Design & create experiments extending existing relationships and integrating with legacy technologies.
4. Run the experiments
5. Monitor, celebrate success, learn from failures

I particularly like his points 1 & 2, because they focus on the people - the soft side. I think this aspect is often left out in the early stages of too many projects. Early stakeholder engagement done well is essential for the success of any project - particularly projects that are about collaboration.
click for Dave Pollard’s article