Posts in Category "Human Interface"

A Crippled Human Interface

This is the first entry in what I intend to be my daily blog. I’ve been kicking the idea of a blog around for sometime – for me the question has been, “what should the purpose of the blog be?” My team already has a public face with the “Adobe Source Libraries”: so time spent working on a blog is time I’m not spending on code, documentation, a paper, or, more likely, answering e-mails. I decided a blog could be cathartic – a way to clear out the random thoughts rattling in my head before sitting down to focus on other work. (Of course, it could just be distraction in which case this will likely be a short lived blog.) So if your looking for deep insights, you’re likely better off reading something like my friend “Jon’s new blog.”:

The random thought for today has to do with a crippled human interface. I spend a fair amount of time thinking about human interfaces from the engineering side – a significant portion of Adobe’s application code is dedicated to the human interface and it is a focal point for our declarative programming efforts in ASL. I define a human interface as:

* A system to assist the user in selecting a function and providing a valid set of parameters to the function.

The definition of a GUI can be obtained by prepending “visual and interactive” to system. A key word in this definition is “assist.” There are many ways to assist and sometimes things go wrong – a little like the old story of the Boy Scout who insists on helping the old woman to cross the street against her will.

This morning I was rudely awakened by just such a case of assistance gone wrong. I’ve been on a mission to find a good alarm clock which can wake me to my “iPod mini.”: Last Christmas I was given an “iHome”: – the device is quite wonderful, except the minimum volume for the alarm is loud enough to wake the neighbors. It quite literally will blast you out of bed. I’m a fairly light sleeper and I can wake to just a little soft music – at the right volume it will wake me but not my wife. Because of this problem I returned the iHome.

The next alarm clock I tried was the “iBlaster.”: I didn’t even bring this one home, I tried it at the store and it had exactly the same problem. The interface is so close to the iHome that I’m certain they share the same internal circuitry.

Next up, the “Fisher Studio Standard.”: I purchased one of these yesterday and set it up last night. Again, I believe this device shares many of the same components with the iHome (and iBlaster) – but I had some hope. It appeared to be a “2.0” version of the interface. As I set the alarm it “asked” what volume I’d like – anywhere from 10 to 99. Except I want 2 and there is no way to get 2. 10 wasn’t nearly as loud as the iHome or iBlaster so I gave it a try. My wife was kicking me faster than I could hit the off button so this device is also heading back to the store.

I’m certain that the lower limit for the volume on all of these devices is an attempt to prevent me from picking a volume which is so low that I miss that important meeting – some very concerned UI Scout is trying to make sure I cross that road. There needs to be another merit badge for UI designers – one that teaches that the purpose of the human interface is _not_ to prevent me from getting to valid parameters. A perfect solution on these devices would be to have a volume level of 10 be the default when first setting an alarm, but let me pick the level I want.

If you have any suggestions for a good iPod alarm clock, post a comment.