When tempted to vent your frustration in the form of a question ("What makes them think this is a good thing?" "Why are they asking us to do it that way?" and the ever popular "Who's bright idea was that?"), try imagining you are being asked the question and that you have to provide a serious, reasonable answer.
It might help. It might even put the situation into perspective. It will definitely provide you an opportunity to look just a little bit better -- better than you will if you blurt out the pointless question.
Wednesday, November 10, 2010
Better Choices
When faced with a new project, you have a dizzying number of options. Your experience and knowledge will trim those down considerably - you have a good idea of what will work, and what probably won't.
Still, there will be a lot of choices. And frequently - through habit or reflex or the simple comfort of the known - you'll make similar choices to those you have made in the past. And that can be fine. Wise, even. Assuming you have usually made the right choices.
Too often, you find yourself in a "here we go again" situation, not because you're dumb or incompetent but because the options you're used to selecting often lead to similar pitfalls or pinch points. Doesn't mean your path won't work - just that the same pain appears.
When you become conscious of this, it means you should back up, breathe, and think about how to make better choices.
Still, there will be a lot of choices. And frequently - through habit or reflex or the simple comfort of the known - you'll make similar choices to those you have made in the past. And that can be fine. Wise, even. Assuming you have usually made the right choices.
Too often, you find yourself in a "here we go again" situation, not because you're dumb or incompetent but because the options you're used to selecting often lead to similar pitfalls or pinch points. Doesn't mean your path won't work - just that the same pain appears.
When you become conscious of this, it means you should back up, breathe, and think about how to make better choices.
Tuesday, November 9, 2010
Saving Daylight
Does changing the clocks really make anything work better? Or is it busywork for society, pretending that we're doing something to improve efficiency (saving energy would fall under that heading), make daily life more user-friendly (arranging things so the farmers can work or so the kids can go to school with the benefit of daylight would fall under that one), and so on. But in a 24-hour world... in a world with electricity for that matter... is it just spinning our wheels?
Most of us are not dependent on natural light. Farmers get up in the dark, regardless of what the clock says (and livestock do not respect government edicts to 'change time'). The kids might have another week of going to school in the light (after a week of going to school in the dark because we changed the clocks to Daylight Savings Time last spring), but now they come home in the dark. Meanwhile we have sleep disturbed, appointments missed, traffic accidents.
So, for all the disruption, what is really gained?
Most of us are not dependent on natural light. Farmers get up in the dark, regardless of what the clock says (and livestock do not respect government edicts to 'change time'). The kids might have another week of going to school in the light (after a week of going to school in the dark because we changed the clocks to Daylight Savings Time last spring), but now they come home in the dark. Meanwhile we have sleep disturbed, appointments missed, traffic accidents.
So, for all the disruption, what is really gained?
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
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."
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."
Subscribe to:
Posts (Atom)