Thursday, October 28, 2010

Accessibility Lesson On Mozilla Drumbeat

The "ramps integrated with stairs" are very interesting. Nice-looking, too. Not sure I agree with every assertion - for example, I'm quite certain the disability creates the barrier - it's not a question of whether it's created by the wheelchair (which is, of course, an accessibility tool) or by the architecture.


P2PU Web Accessibility Lesson 1: Setting Motivation

Tuesday, October 19, 2010

Mental Models

"Because designers know too much, they form wonderful mental models of their own creations, leading them to believe that each feature is easy to understand." - Jakob Nielsen, http://www.useit.com/alertbox/mental-models.html

Tuesday, October 12, 2010

Thursday, October 7, 2010

Specific Specifications

I do a lot of government-related design work. They see specifications as coming in 2 flavors - detail specifications and performance specifications.

Most projects are described with performance specifications - describing what the product or service needs to do. That's the right way to request most work - "I need something that does X."

Relatively few projects are described with detail specifications - things that for compatibility or other requirements have to be built following a certain approach. That makes sense, too -- "I need something that does X, and it has to be built using Y." They define them pretty well here.

Sometimes a client comes out with a bizarre mix of the two types of spec. A performance spec is called for, but they fall into the trap of thinking that it is right and proper to impose an arbitrary -- yet non-specific -- condition on the approach taken in the project. A recent example of this is a client who wanted their online content to fit one of three levels of both interactivity and multimedia richness (yes, their spec was already getting blurred by linking the two areas). This is still manageable, though - their basic product would be vanilla HTML with minimal graphics -- middle school web design stuff; their high level stuff goes all out, branching navigation, games, videos with clickable hotspots that take the user to different outcomes; and their intermediate level falls in-between.

So far, so good. They define their types as basic, midrange, and complex and they describe the types of things they want to see in each flavor. Still good. But then the fail comes. They get excited. They decide to require that the complex multimedia / complex interactivity product be delivered with a "complex underlying technology."

Um - does delivering it over the internet count?

Now, advanced design is simple to the user - look at an iPod, does anybody really need the manual to use one? How will this client assess whether the product's underlying technology is sufficiently complex? What, if the users don't have trouble with it, it doesn't meet the spec? Or - looking at the "underlying" aspect of it - if the client can't make head or tail of how it works, is that complex enough? We can build you something that you'll never be able to update yourself - is that really what you want?

Specifications should make your needs clear. If you need it in blue to match your branding, fine. If you need it to be in Flash (or Silverlight, or HTML5, or Java -- remember Hotmedia, anybody?) because your users already have the plugin or don't have admin rights to install any new ones - that's fine and reasonable, too.

But a stipulation that "it has to be really complicated under the hood" is foolish.

File it under "pitfalls of organizational thinking."