Re: [Cosmo] Re: FLOSS usability sprint report

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