TickerWatch, further usability considerations
I am archiving older pieces I have written on other sites, making this the definitive home for all my work. This is one of several I am porting over from my GameDev.Net user journal. Enjoy!
The first thing that struck me about the TickerWatch prototype was that I was composing the event/call list incorrectly. I had placed a ListView control on a Form which was supposed to display either the categorized view or the prioritized view based on user setting.
Stupid.
The categorized view is not a single list - implying that a list item has properties displayed in each column - but rather five separate lists! The prioritized view is then a composition of those five lists into one, with elements sorted according to some external ranking. Obviously, I needed a better implementation, so I've been building a little control to handle all this for me. If I wasn't so distracted by Smallville reruns last night, I should have finished that.
[On a tangential note, does anyone else find it fascinating that the Legend of Superman is being reinvented by that show without an explicit reboot? DC Comics is given to "resetting" their characters - the last Superman reset was in 1984, in which Clark Kent became his primary persona as opposed to merely being a dork alter-ego/secret identity, and what one movie has described as Superman's commentary on humanity - but this reinvention is progressing without fanfare.
Lex Luthor is a childhood buddy; how will he grow up to not recognize a no-glasses Clark Kent as Superman? His parents are a little too sophisticated - and Clark himself a little too fashion-aware - for his mother to make him a suit with underwear on the outside. The "S" logo can no longer be explained as the family crest.
This should be interesting.]
Anyway, the other element that became immediately apparent was a usability one. I initially designed the interface such that right-clicking on the event/call list brought up a context menu allowing users to switch between categorized and prioritized views.
Stupid.
This is not a discoverable interface. Despite what we may consider an intuitive operation, most users do not utilize context menus. If it isn't immediately obvious that something can be clicked and browsed/explored, it probably won't be. So I took that out and plopped the list into a tab control instead.
I wish I could show a screenshot. It's a lot like the Administrative interface from the earlier screenshot, but with just two tabs labeled "Category View" and "Priority View". The Administrative interface will simply add the "Editors" and "Configuration" tabs beside those two. Now all the major application views are instantly visible.
Operations (read: dialog boxes and commands) are not launched by tabs, however. That's one of the most disgusting design approaches I have ever seen. Tabs switch between modes of looking at data and metadata (data about data). Metadata is a discussion unto itself, one I hope to get into shortly, so we'll leave that for another time.
Too Much Usability
All this lead me to consider when an application can have "too much usability" - when its interface becomes so laden with obvious decision points as to hinder the workflow. On a certain level, TickerWatch is still an unintuitive tool, but that's because it's domain-specific. When creating an interface, the profile of target users is critical in determining what is self-evident and what isn't.
This, of course, is what makes general-purpose usability such a challenge. How do you develop applications that are applicable to all potential users? What is self-evident to a chemical engineer, a software developer, a five-year old who still thinks Barney is real (and cool), a Namibian schoolteacher and a rural shepherd? Where is a reasonable point to set the usage barrier such that it doesn't impede workflow but doesn't exclude too many from benefiting from the tool?
Good question.