Mimi,
Thanks for the detailed point-by-point consideration of the feedback.
There were so many tangents it was difficult to keep track of, but the
feedback was all really valuable.
Please see my responses below.
Mimi Yin wrote:
- Both testers were repeatedly confused about what the active
collection was,
Yup. I think we need to do better than the default browser selection
highlight. A darker selector with gradient and inverted 'white' text
will make a stronger impression I think.
A big part of the problem was a lack of clarity on the difference
between 'overlaid' (visible) and 'selected' (active). The user first has
to understand those concepts, and then connect those to the UI display
they're looking at (or ideally, actually infer that stuff from the UI).
Right now the only things that inform the user about the 'specialness'
of the selected (active) collection are:
1. Its lozenges are in the foreground -- not necessarily obvious (even
with opacity or color changes to the background collections) in a busy
overlay. Likely not immediately apparent to a first time user trying to
figure out the overlay/selection mechanism
2. The collection name with the same color swatch is selected -- we
absolutely need to make the selection darker -- that will help. But the
user still has to connect the color swatch to the lozenge colors.
The use of an explicit 'call out' came up quite a lot -- discussed at
the bottom of this e-mail.
* Is it really important to distinguish between
overlaid-because-selected and normal overlay? Most people not
involved in the sprint seemed to think not
It's important to allow distinguish between overlaid versus selected
collections because oftentimes, users overlay 'their personal calendar'
on top of FYI calendars like:
+ U.S. Holidays
+ Office Calendar
+ Their boss's calendar
+ Shared home calendar
Without a 'selected' collection, there's no way to specify which events
have '*priority*' over other events. (More concretely, when there are
overlapping events, which events appear on top?) Having the notion of a
selected collection allows users to keep more calendars overlayed
without losing sight of the events they really care about.
Looks like you misunderstood this piece of feedback.
They were referring to the overlay-state indication.
With checkboxes, all we can show is 'on' or 'off' -- which is a problem
when the selected collection is not explicitly overlaid, but selected.
(You have an unchecked checkbox, but the collection is still visible.)
So there are really three states:
1. Explicitly overlaid by the user -- visible
2. Not overlaid -- not visible
3. Selected, but not explicitly overlaid -- still visible
Both of the prototypes we did tried make clear this idea that "selected
collection is always visible in the overlay," because having the
checkbox unchecked -- but the collection lozenges still visible -- was
confusing to people.
In the feedback we got when we presented what we'd done, some people
suggested it wasn't important to distinguish between 'explicitly
overlaid' and 'overlaid by virtue of being the selected collection' --
i.e., that you'd simply go ahead and check the checkbox if the
collection got selected.
It's possible that we didn't describe the problem adequately, or that
there wasn't time for them to think it through completely -- the problem
being "what happens when a different collection gets selected?"
With checkboxes, there are two ways to handle it:
1. Just check the checkbox -- now when selection moves to another
collection, the user has to uncheck the checkbox manually to get that
collection out of the overlay, even if they didn't explicitly check it
in the first place. (That means effectively that navigating from
collection to collection will always take two clicks -- one to select
the new collection, one to take the previously selected collection out
of the overlay.)
2. Check the checkbox, but return it to its previous state when the
selection moves -- this takes the burden off the user, but it's weird
and confusing to have checkboxes turning themselves on and off of their
own volition. (This is what the first prototype does.)
In both cases, you probably want to disable the checkbox, to indicate
that the user can't take the collection out of the overlay if it's the
selected collection. (A side effect of this would be that if the
selected collection is not explicitly overlaid, you can't make it so.
You'd have to select a different collection first, and then you could
check the checkbox to add it to the overlay.)
I hope that makes it a little clearer.
I have some ideas for simple ways to make the view selector buttons more
clearly 'tabs' that control what you see in the summary pane.
I'd like to re-test this by giving people 3-5 minutes to just explore
the UI on their own time...and see if they discover the calendar view by
themselves.
Jeffrey, did you post that wireframe you were working on on Sunday? I
really liked the big buttons -- and since it's very similar to the
Desktop, Desktop users could leverage what they already know.
The areas of the minical that are clickable and non-clickable are not
obvious. Small indicators like cursor changes don't provide enough
guidance.
I think I need to see the video to get a better handle on this issue.
The user tried to click on the month name (I guess thinking it would
take her to the beginning of the month). Looking now at the minical, I
realize that everything is flat white with plain text -- both the
clickable stuff, and the non-clickable stuff. We should either make
everything clickable, or make the different visually apparent.
One of the test users found the use of super-saturated colors for UI
elements (collection icons, triage indicators) distracting from the data.
Hmm, the collection icons and triage status colors are some of the most
important metadata we need to convey. I need to watch video to
understand this better.
Since it's metadata, and not the user's data, we could consider still
using color, but dialing down on the brightness or saturation.
Users didn't perceive the "i" icon as obviously a letter "i," nor did
they understand what the button did. One of the test users popped up
the Info dialog, and reflexively and immediately closed it.
Use of checkboxes to indicate overlay state was confusing due to the
fact that checkbox often means something is selected. This is
compounded by the fact that the selection indicator in the Web UI is
way too lightweight.
Is there any reason why we don't use the same convention we do on the
desktop?
Do yo mean convention for selection? Or the entire widget?
The selection indicator in the Web UI is horribly faint -- one of the
designers at the Sprint couldn't even see it at one point because we
were using a a laptop, and he was viewing it from the side. I think it's
definitely time for us to beef that thing up.
A little context on what we did with the collection selector -- I got
feedback from multiple people at the Sprint that the current collection
selector widget on the Desktop is somewhat confusing -- ranging from
"What are those little things supposed to be?" to "I was able to figure
out how to use it after I played around with it for awhile." We actually
talked about some different ways to make it more obvious and
discoverable for first time users, since a big goal for us is lowering
the barrier to usage.
One of the guys from Oracle suggested that having an animation for the
little tab thing as it comes out would make it a bit more obvious. (To
be honest, I didn't know they were tabs until Jeffrey told me at the
Sprint -- although I'm only a casual user of the Desktop, so it might
have sunk in after more use.)
The other piece of confusion came from the fact that those little
controls do the overlay, but are still visible in views with no overlay.
(Apparently disabling doesn't do much for people, as we saw with the
form sections in the detail view.)
We looked a lot at the current custom widgets in the Desktop while we
were working on the whiteboards and later the prototypes. We threw
around a lot of ideas for indicating "visiblity" -- with all the people
flagellating the problem of the checkmark indicating "done," and the
checkbox indicating something was selected, it seemed the best choice to
go with something as blatantly obvious as possible.
Using a colored eyeball for the 'third state' of "not explicitly
overlaid, but visible because it's selected" was the way of indicating
the collection is visible, but not in the list of explicitly overlaid
collections. Unlike the disabled checkbox, it had the benefit also of
allow the user to toggle back on explicit overlay while the collection
was still selected.
Suggestion of auto-saving in web-UI. Google Docs auto-saves.
Auto-save, disable save button, leave text by save button with last
auto-save time. Keep a "feel good" save button, it's the final
action, make sure I'm not going to lose my data. Noted that Google
auto-saves after keystrokes end.
Yup, targeted to .11. Luckily, we've already discussed this issue in
great detail.
One thing I realized that never came up during the previous auto-save
discussion is how we would deal with auto-saving changes that require a
user decision -- e.g., recurring items.
Light gray label text over active form inputs gave the impression that
the input was disabled. Large, disabled text inputs were assumed to be
active. Consider a different strategy for disabling form sections.
Is this the Firefox bug again? I think we should just hide disabled
fields the way we do on Desktop. Saves space as well.
Logged bug: https://bugzilla.osafoundation.org/show_bug.cgi?id=11344
Not a bug.
One of the test users assumed that the light gray *label text* over
*active* form elements meant that the form elements were disabled. That
was without interacting with the app at all.
I definitely think it's worth re-examining disable-versus-disappear for
forms elements -- at minimum, for starters, for form sections.
Blowing away data in form elements when removing a stamp is bad, bad,
bad. The user might re-add the stamp, and would then have to re-enter
all the stamp data from square one.
Ya. mde are there technical issues here?
Logged bug: https://bugzilla.osafoundation.org/show_bug.cgi?id=11345
Nope, no technical issues. We can and have to do this. :)
The date-entry in the Web UI really is horrible. (We know this.)
Multiple people asked about a date-picker.
Yup, we have several bugs for this:
Mini-cal - https://bugzilla.osafoundation.org/show_bug.cgi?id=8396
Interim improvenment
- https://bugzilla.osafoundation.org/show_bug.cgi?id=10962
A tiny amount of work would improve usability a lot here, so I should
just knock it out.
The timezone selector is also horrible. One test user picked the
"Pacific" region (Australia-Pacific), and naturally assumed she'd
picked the Pacific timezone.
mde, bobby: What's preventing us from moving to
Moving to ... ? :)
There were strong opinions in favor of, and against, making the text
of stamp labels clickable. Arguments in favor are that it expands the
click space and is standard behavior in some OSes, arguments against
were that the label isn't obviously clickable, and it's a large change
that could accidentally be made.
Well it's a change that's easily un-done :)
Yes, and once we stop blowing away the data in that form section when
un-checking, it's not destructive. :)
The Desktop's approach to stamping (using a toolbar) doesn't have the
same problem because the stamping toolbar is separate from areas that
might be accidentally clicked.
Yes, I think we need to revisit the stamping affordances in a more
holistic way.
There was also a lot of feedback that having the activation mechanism
located close to the actual stamp, and having clear labels on them, made
it significantly easier to understand and use.
Placement of newly created items in the list view in the Web UI seemed
mysterious to a couple of people. Although once we started to discuss
all the potential ways to handle it, everyone started to see it was a
difficult problem, and is compounded by paging in the Web UI. No one
could agree on what would be the ideal approach. Same for editing,
where the edit would take the item out of view.
Did the test subjects have trouble finding newly created items?
No, that was not a problem -- it was merely not doing quite what they
expected.
However, in the Web UI, the current behavior is to sort by triage
status, and then add secondary sort on the title. That might actually
push the new item off page 1, if the user has a lot of Now items, so
this could be a problem. What does the Desktop do here?
The checkbox icon for tasks suggested "this is done" to many people,
neither of the tested users using the Web UI could figure out that it
indicated that the item had been stamped as a task.
Yes. I think using the "checkmark in a circle" icon that we use on the
Desktop might help. Also making sure that we have corresponding icons in
the detail view for stamping would help as well.
Changing the icon could make a difference, but I suspect that in a
circle or out, "checkmark" is a universal symbol for "Done."
Having a non-drag-drop way to add items to multiple collections --
even via a contextual menu on the item -- would be helpful, as
drag-drop is not necessarily discoverable.
I think this is more true of web apps than desktop apps.
Agreed, although I think we should implement the drag/drop in the Web UI
as soon as is feasible.
"Call out" active collection more, in Web and Desktop the selected
collection isn't immediately obvious. Ideally, tie sidebar selection
to main view more clearly.
I think a more robust collection selection highlight would go a long way
towards this. Implementing 'Show collection name in the window-title'
might also help as
well: https://bugzilla.osafoundation.org/show_bug.cgi?id=10604
My admittedly subjective impression is that it was also very much a
problem of proximity. It's not obvious what effect clicking in the far
left side (collection selector) has on the rest of the application.
The phraseology I kept hearing was needing something to "tie" the things
together.
Explicit labeling of the selected thing is something we used in numerous
places to solve similar UI problems at my old job -- where the
relationship between the selection widget and the results of the
selection action aren't completely obvious -- it made a really big
difference in user orientation.
Use of a labels for UI elements -- like "Collections" for the
collection selector -- would guide new users both in using the UI and
in the name of Chandler-specific vocabulary, without taking up copious
amounts of space.
I'm not sure about this yet. Not sure if it warrants the loss in screen
real estate.
There was also a lot of discussion of a "training wheels" mode that
would kick in on first login, and guide the user through some of this
stuff, or at least pop up some kind of indicator the first time a user
performs certain actions (like dragging an item into a new collection).
Thanks for the detailed look at each item. It's a lot of stuff to digest
at once. :)
Matthew
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
