Mimi Yin wrote:
For 0.6, we've decided to get rid of specialized icons for each
collection and instead, only offer a checkbox, thereby simplifying
the design.
I think this is a step in the right direction. The current behaviour
(paraphrased from the 0.6 spec) is:
1. collections can be overlaid on top of the selected collection. The
calendar calls the overlays "activated (checked) collections".
2. collections are activated (checked) by clicking on the checkbox
3. the checkbox appears when the user mouses over the collection in
the sidebar
Arguably, this is counter-intuitive: an affordance (a box that can be
checked) should not be hidden until the user happens to mouse over it.
Otherwise it's hardly an affordance, but more like a hidden switch.
In 0.7 we will have to address how to bring the collection icons back
in without cluttering up the sidebar.
I agree. With more than just a few collections, having icons to easily
distinguish them will help. Plus it can carry additional information
about a collection's status, such as whether it's read-write or
read-only, system or user-defined, etc.
I've started some informal drive-by usability exercises, my main
worry is not so much with the visual disparity between the collection
icons and the checkboxes, but more that most users won't GET that the
"thing to the left of the collection name" is a checkbox at all
(simply because it does not look anything like the system
checkboxes). We originally wanted to use system checkboxes, but
decided that that would be REALLY visually jarring.
Maybe they don't have to look exactly like the system checkboxes, only
still recognizably so? For example, I'm attaching two screenshots from
Eclipse IDE that show list items with both checkboxes and icons. Now, I
use Eclipse a lot and so I may be too used to its interface, but I think
these both look good and make it obvious what the possible action is.
Losing the space hurts, but hey, it's only 16 pixels. :-) Alternatively,
we could maybe learn from Photoshop and Gimp: their concept of layers in
an image is not that different from overlaying multiple calendars. I'm
attaching a screenshot of Gimp's "Layers" dialog, which uses the eyeball
as an indication of which layers are currently visible. A pin is another
possibility.
The user I tested last night (someone who falls in the "Mom"
category, but is also a small business owner who is dying for a read-
write shared calendar) didn't get the checkboxes at all (not even the
ones next to the user-defined collections and tried to overlay the
calendars by dragging and dropping one calendar onto another in the
sidebar. (Granted she was a Mac user and as a rule tries drag and
drop for everything).
Or, maybe each collection should be shown as a button that can be
pressed in? That way it clearly can only be pressed, and not dragged.
I'm not sure if this would work with long lists of collections though.
However, the very real problem of not understanding that you should
"click" on the icon on the left means that we have to be as explicit
as possible about checkbox-ness. As a result, we considered and
rejected several options that might have solved the "visually
jarring" problem, but would have failed to communicate "click on me
to check me off". Things like:
1. Overlaying a checkmark on top of the collection icon.
2. Overlaying a dot on top of the collection icon.
3. Making the collection icon look depressed when it's checked.
The question we have to ask ourselves is...at the point when the user
rolls over the collection and reveals the rollover state...do they
understand they need to click on the icon on the left to make the
calendar "stick" and overlay.
They do not right now and I don't think they will even if we improve the
icons. I am convinced that the checkbox and the icon should be separate.
An icon is useful for expressing state such as collection's type or even
read/write vs. read-only status, but not to serve double duty as both a
rich graphical indicator and a switch. It would be great to have a more
"fluid" interface that felt dynamic (and cool) and used screen space
efficiently to boot, but I'd vote to go with something "safe" (i.e.,
using more conventional-looking UI elements) for now, since just getting
used to the concept of collections is a hurdle your users haven't gotten
across yet.
Davor
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
