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
