Design + Usability, Useful + Usable

On Dec 9, 2007, at 6:35 PM, hank williams wrote:
> The interface designer's critical task is to support and reinforce  
> the users
> understanding of the data model

Thank you Hank for articulating this. I think this may be at the core  
of issues you are running into.

In my mind, the purpose of design is to understand how people work  
(which goes hand in hand with figuring out what problem it is you  
want to solve). 'How people work', the problems they run into and  
pain points they have in turn drives how the software should  
function. Usability (which I think of as conceptually distinct,  
though in practice, hopelessly intertwined with design) is the work  
of re-presenting how the software works to the user in a way they  
will recognize as helping them. In other words, usability is the  
'language' by which the intent of the design is communicated to the  
user.

Another way to think about it is: The difference between design and  
usability as the difference between 'use-ful' and 'usable'. Useful is  
about getting the workflows right and anticipating user needs. Usable  
is about making it easy for people to figure out how to get the most  
out of the hopefully 'useful' product.

More often than not, aiming for 'useful' results in concepts and  
functionality that are 'ambiguous' and 'inconsistent' in the way it  
works. I believe this is because user workflows are complicated and  
full of exceptions. Surprisingly and fortunately however, workflows  
are often twisted and gnarly in highly consistent ways. In the end, I  
think it boils down to how you're looking at the problem: From the  
perspective of trying to understanding the inner workings of the  
tool; or from the perspective of trying to understand the workflows.  
The 2 are by no means mutually exclusive. I'm not proposing a binary  
view of product design. It's more a matter of where you start.

So in Chandler, if there are UI elements that are unfamiliar, or  
kinda of familiar, but not quite the same as what you're used to, the  
intent is to communicate how we've in some cases tweaked existing  
functionality to more closely map to usage patterns and in other  
cases completely up-ended existing models.

I think 'overlays' and 'collections' in Chandler are examples of  
where we've tweaked existing functionality.
+ Overlays are called overlays and have special widgets because they  
don't behave the same as checkbox, multi-selection.
+ Collections are called collections because unlike 'tags', they  
aren't mean to be used as a way to 'describe' you data and unlike  
'categories', they aren't intended to be used as a way of  
taxonomizing your data. Contexts are probably the closest thing. But  
we chose 'Collection' because it emphasizes the 'action-verb' aspect  
of the feature: Collect the stuff you want to see in 1 view, as  
opposed to the end-result of the feature: That view will become one  
of the contexts you sit in when managing your information.

Triage and Stamping are examples of ways in which I feel we've up- 
ended existing models.

Your feedback highlights the difficult situation in which we find  
ourselves.

We're trying to challenge, break and improve upon existing ways of  
solving problems. At the same time, we're disappointed that Chandler  
isn't immediately usable, isn't as immediately usable as an nth  
generation iteration on an existing approach. But the nature of the  
beast is that there are always trade-offs between innovation and  
usability and I fear that trying to optimize for both within the  
confines of the interface design will turn into an exercise in futility.

Even the fairly evolutionary transition from OS 9 to OS X threw  
people off for a long time. New improvements were considered  
unnecessarily confusing. I felt that way for a long time. But really  
it was a matter of readjusting my own expectations and breaking old  
usage patterns to form new improved ones around what OS X had to offer.

That being said, I'm not trying to make the case that the design we  
have today is done or perfect. The purpose of the Preview release was  
to:

1. Test out our 'design' theories about what was needed to solve a  
targeted set of user problems, namely: Why can't people seem to use a  
task manager for more than a week before abandoning it because it's  
too much work to keep up to date? In other words, how 'useful' can  
Chandler be?

2. Ship something usable enough to help us identify where we needed  
to improve wrt usability. What do we need to do to make Chandler more  
'usable'?

You and other users' comments have been extremely helpful in  
accomplishing both.

The takeaway for me is: Now that we've gotten Preview out the door,  
we need to turn our attention to helping people up the usability ramp  
with refinements to the interface where appropriate, better  
messaging, better demos and active user support on mailing lists and  
IRC. We've been really good about supporting users on the list and  
IRC and we are working to be just as good at everything else :)

Again, thank you everyone for your comments, keep them coming. I hope  
this provides a bit more context for the design decisions we've made.

Mimi

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design