Hank,
The single big functional difference between iCal and the Chandler
collection selector is a requirement that we added to make it easier for
people who aren't overlaying multiple collections: You shouldn't have to
click twice to navigate between collections.
hank williams wrote:
I dont see it. As far as I can tell chandler and iCal have exactly
the same underlying design in this regard. Chandler just makes it more
confusing - almost seemingly with intent.
Also, iCal does another thing which I have said before I think would
be helpful, which is the ability to hide the information panel on the
right to minimize clutter.
Indeed much could be learned from ical.
In iCal, selecting a calendar also checks the checkbox (as you would
expect) -- but that means that selecting a different calendar requires
you to un-check your previous selection to remove it from the overlay. I
personally find this pretty annoying, although I can see the benefit in
the simplicity of it.
In Chandler, selecting a collection *overrides* the overlay state so
that the collection is visible (whether it's checked or not). Naturally
in a calendar view (and unlike Photoshop) there is no compelling case
where you'd want to select a "layer," but not be looking at it.
This makes the UI significantly easier to use when you aren't using
overlays, but it does complicate things. The overlay now has three
states: visible, not-visible, and visible-only-by-virtue-of-being-selected.
Despite the visual confusion this creates (collections may be visible
despite being unchecked), I'm also far from convinced that this is
special enough to warrant inventing a completely new widget set.
For the selection-override, you could simply check-and-disable the
checkbox to indicate that it's showing and can't be un-shown, and then
return it to its previous state when selection goes elsewhere. This is
what the first prototype I linked to in my previous e-mail does:
http://www.fleegix.org/demo/floss_usability_2007/proto_1.html
There are two drawbacks to this design:
1. The disabled checkbox tells you nothing about what the state was
before the user selected the collection (and hence, what it will go back
to if the user selects something else).
2. The user can't change it (from
visible-only-by-virtue-of-being-selected to visible). To change it, the
user would have to select a different collection.
The visible-only-by-virtue-of-being-selected state is what the colored
eyeball in the second prototype attempts to convey to the user:
http://www.fleegix.org/demo/floss_usability_2007/proto_2.html
"In the overlay, but only there because it's selected." This design does
not have either of the disadvantages of the previous design, but it does
use a somewhat special UI element (the eyeball). That of course is
mitigated by the following:
1. The eyeball is familiar to anyone who's used a graphics program.
2. The eyeball behaves precisely as a checkbox (all it's doing is
replacing the check image with an eyeball, it still just toggles), so
behavior is obvious.
3. The eyeball has obvious connotations of "visibility."
ICal decided to forego some ease-of-use in favor of simplicity.
We might be shooting ourselves in the foot by trying to make things even
easier to use. Our requirement for single-click navigation complicates
things -- but I still think we can preserve our existing functionality
and simplify the UI for it.
Matthew
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
