Hank,
I think your points about the need for improved simplicity and usability
in the Chandler UIs are in general very good ones.
We did a bunch of work on the collection selector and overlays during
the FLOSS Usability Sprint last month, and some very similar
points/questions came up.
Unfortunately Jeffrey's original post to the mailing list seems to have
been chewed up, but here's the wiki page we put together as a report:
http://chandlerproject.org/Notes/FlossSprint2007
Mimi's initial response to the enormous pile of feedback is here:
http://lists.osafoundation.org/pipermail/design/2007-November/007887.html
hank williams wrote:
By the way, overlay is another one of those words that is not
necessary. All you are doing is selecting calendars. google calendars
doesnt need fancy jargon to describe this feature.
Google Calendar came up in comparisons a lot, and I agree they've done a
good job of making things very simple.
One thing they've done is taken away the concept of a "selected" or
"active" calendar. There is only "shown" and "not shown" (the same as
our "overlay").
Since there's no "active calendar," when you create a new calendar
event, you have to pick *at that point* which calendar you want to put
it in. Google does a good job of guessing which one, so it's not usually
that annoying, but it's not necessarily automatic.
Imagine a user has three calendars showing -- Home, Work, and Office.
When she creates a new event, what calendar does it go into? Chandler
has a "selected" ("active") collection, so it goes into that one. In
Google calendar, you have to make a choice on the individual event
itself when creating it.
So, while the word "overlay" itself may be kind of jargony (we could
just say "shown" and "not shown"), it's not the same thing as "selected"
(at least in our current design).
One improvement over the current confusing state might actually be to
take the Google approach of pushing the question off until the point of
creating a new calendar event. It's definitely worth considering.
The other strategy suggested by some of the user-experience
professionals at the Sprint was to call out the selected collection in
some way, so users know (1) there is an "active" collection where newly
created items will go, and (2), which one it is. Consensus was for a
nice, obvious label saying "Active Collection: Blah-Blah Collection."
We have a couple of bugs open for this:
https://bugzilla.osafoundation.org/show_bug.cgi?id=11355
https://bugzilla.osafoundation.org/show_bug.cgi?id=11354
Part of the confusion in the Web UI also revolves around the use of
checkboxes to indicate the show/not-show state.
Checking a box seems to indicate in a lot of people's minds "selecting
something," so at least one of the users in our tests thought that a
checked collection was a selected one. We have made the selection-state
more obvious in the Web UI, and I think it does improve the situation,
but there is definitely more we can do.
I believe the custom widget set used in the Desktop is aimed at fixing
this same problem. I personally find it more confusing to use, and think
that the checkbox on/off state is at least more visually obvious despite
its associations with selectedness.
During the Sprint, we did a couple of prototypes trying to make things
clearer:
http://www.fleegix.org/demo/floss_usability_2007/proto_1.html
http://www.fleegix.org/demo/floss_usability_2007/proto_2.html
The second one uses an eyeball to indicate shown status. It's a usage
common in graphics programs where multiple layers can be shown/hidden,
but only one can be selected.
I hope all this info is useful -- the overlay/selection problem may not
be quite as simple as it seems at first blush. I don't think we have
anything close to the optimal design, but it is something we're working on.
Matthew
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
