April 2, 2007

Functionality versus Usability

I think I finally figured out why I prefer Visual Basic to other programming languages. It strikes the perfect balance between functionality and usability.

I bring this up because I spent the entire weekend battling compiler errors in C++, adding in tons of casts in C#, writing helper functions in JavaScript, and all in all just getting frustrated by the amount of extra work I have to do in order to get even the simplest of things to work in life.

For example, I've got an RCA alarm clock set up in my bathroom. It starts out beeping very quietly, and over the course of a minute ramps up to where you can hear it from ourside our apartment. Nothing quite like having to traipse through two rooms in order to turn off the alarm to help you wake up. The only thing is that I'm usually so dead in the head in the morning that I completely space that it would normally take me seven or eight pounds on the "Off" button to turn it off. Turns out that the "Off" button on the alarm clock only works if the alarm clock "beep" is actively going on. Inbetween beeps, the "Off" button does nothing.

Now, this alarm clock has two seperate alarms on it.If both alarms are going off at once, the space where one alarm would be "Off" is where the other alarm would be beeping. In other words, hitting "Off" kills whichever alarm is beeping at the time. In this case, the method of adding additional functionality absolutely destroyed the usability of the alarm clock.

Don't even get me started on user experience issues in real life. At the DART stations, they have started installing new ticket machines that have significantly more functionality. You can purchase multiple passes and multiple types of passes at one time, which makes it more convenient for families and groups. However, unlike the old solid-state machines, these have monitors, so they require step-by-step Braille instructions on how to use them on the front. Only downside: the instructions don't work.

Step two of the instructions say, "For a $1.00 day pass, press button C. For a $0.50 single-ride pass, press buttons J, A, G & F." Button C does indeed purchase a day pass, but the other instructions act entirely differently. Pressing J cancels all previous orders, pressing A orders you a $2.50 day pass, and G & F are not bound to any functionality whatsoever. (The actual instructions should be press I, then C.)

So ask yourself one question: When you are designing your software, be it a library to be used by another programmer, a web page, a mod, a ticket machine, or an operating system, how much time do you focus on how much functionality you are adding, and what usability tradeoffs are you making for that functionality?

No comments: