[I originally had this at the bottom of the mail, but I think it
pretty well sums up the approach and reasoning behind our original
decision to try conflating the checkbox icon with the collection
icon, so I moved it to the top.)
I think this is something that mostly needs user observations. I
agree it's a sticky issue, but it was the solution we decided to try.
We went through a process. We considered many of the suggestions that
have been raised and we settled on the "checkbox on rollover"
solution as one worth testing in the field.
(We already know simple checkboxes work because of iCal and we also
already know having 2 separate columns, one for checkboxes and one
for icons works too. This was an opportunity to try something
untested in a low-risk way since 0.6 is only supposed to be Dogfood
calendar.)
We understood it was unconventional, but we wanted to leave options
open to unconventional solutions before resorting to.
1. Giving up on having collection icons completely and
2. Resorting to 3 columns of icons per collection row in the sidebar.
I think we should give it a chance to work or not work as well as
ourselves an opportunity to observe people using the sidebar and
collect feedback from a broad spectrum of users (especially ones that
don't think about how software is designed ;o) before deciding one
way or the other. More comments in line...
Davor, I'm curious to know what you think of the insignia on the
doorway metaphor I proposed in my last email...
On Oct 27, 2005, at 1:29 PM, Davor Cubranic wrote:
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.
If you don't need the checkmark until you mouseover the collection,
I'm not sure what's so bad about a hidden switch. That's what context
menus are.
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.
I think all of these apps would qualify as professional, power apps .
Our impossible mission is to provide users with a lot of power while
maintaining the feel of a simple consumer app like iCal.
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.
If you look back at the screenshot I included in the email you
replied to, communicating the collection icon + pressed in state +
color of the calendar is visual overload in such a small space, not
to mention incredibly hard to make visually consistent with the rest
of the icons in the sidebar.
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
<eclipse-export-dialog.png>
<gimp-layers.png>
<eclipse-breakpoint-view.png>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
