[Cosmo] Re: FLOSS usability sprint report

Thanks for writing this up Jeffrey. I have yet to see the video of  
the usability tests, but didn't want to block on that, so responding  
with some initial thoughts while I wait to see the actual tests.

I've done a quick pass at addressing some of the issues discussed  
below. http://chandlerproject.org/Notes/CosmoFloss

    * Connection between sidebar collection selection and summary pane
    * Connection between view selector buttons and summary pane contents
    * Connection between pagination widgets and triage table (not  
mentioned below, but has been brought up as an issue before)
    * Overlay widgets (simplified version of what we have on the  
desktop)
    * Add/Remove collections
    * Collection details icon
    * Task icon in the Triage Table

mde and Jeffrey: See questions / responses in-line.

On Nov 7, 2007, at 3:20 PM, Jeffrey Harris wrote:

> A few takeaways:
> - Neither person seemed to have any difficulty with the concept of  
> stamping, which was gratifying
> - 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.

> and wanted to be able to move or copy items between collections
I've logged a bug for this. https://bugzilla.osafoundation.org/ 
show_bug.cgi?id=11340 Context menu options for Add/Move would be a  
good start towards satisfying this.

EXCERPTS FROM NOTES
http://chandlerproject.org/bin/edit/Notes/FlossSprint2007?t=1194908123
>    * Is it really important to distinguish between overlaid-because- 
> selected and normal overlay?  Most people not involved in the  
> sprint seemed to think not
>    * If overlaying many calendars, why not mimic Outlook's UI for  
> availability?
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.

> General
>
> The view switcher in the Web UI is fairly non-obvious. Bigger  
> buttons, more central placement, use of color, use of tooltips --  
> all these things would steer the user to using them.

Jeffrey, were the test subjects asked to find the Calendar? I have a  
feeling that one of the reasons why web UIs generally have text- 
buttons is that text-buttons 'test' better. The downside of text  
buttons is that they take up more space and take longer to parse.  
Imagine all road signs as text.
+ Go
+ Prepare to Stop
+ Stop
+ Right Lane Merging Into Your Lane
+ Left 2 Lanes to 101S. Right 2 Lanes to 280S.

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.

> Orange and Green colors on the web ui almost match NOW and LATER  
> colors, probably want them different, since they're very separate  
> concepts

Yes, the colors are off right now. We could also get rid of the  
colors in the Triage Table View and only display them in the  
Calendar, which would minimize confusion.

> There's a bug in the web UI that confirmation doesn't come up when  
> creating a new event or switching viewed collection.  When that  
> dialog does come up, it should say the name of the item, and the  
> dialog text should be larger than it currently is.

I'm not following this. Which dialog are you referring to? The Save  
edits dialog? Is this bug already logged?

>
> The use of 'note' versus 'item' was confusing. The distinction that  
> everything is an item, and that all items start off with a default  
> note stamp might be unnecessarily subtle. Consider just "Create a  
> new item" prompt for quick item-entry.

Logged bug: https://bugzilla.osafoundation.org/show_bug.cgi?id=11341

>
> 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.

>
> 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.

>
> Collection selector
>
> Discoverability of sharing a collection: maybe change icon to down  
> triangle/pop-up-menu, use context menu?

Logged bugs:
+ Change collection details icon to be a down arrow - https:// 
bugzilla.osafoundation.org/show_bug.cgi?id=11342

+ Add context menu support for sidebar collections - https:// 
bugzilla.osafoundation.org/show_bug.cgi?id=11343

> 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?

>
> Detail view
>
> 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.

>
> 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

> 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

>
> 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

> 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

>
> 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 :)

> 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.

>
> List canvas
>
> 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?

>
> 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.

> Desktop
>
> Greyed out collection icons in desktop suggests overlays are  
> possible, there's no feedback about why it's disabled.  Also not  
> clear that they're greyed out until you shift between calendar and  
> list view

Until we support overlays in the Table View, we could get rid of of  
the overlay icons in the non-calendar views. I think this made more  
sense when the overlays in the Calendar were preserved when you  
switched to the other App Areas. Somehow, that functionality got lost  
along the way.

> Chandler's use of drag-to-add instead of drag-to-move confused  
> various UX people.  Perhaps pop up a dialog when dragging items to  
> a new collection for the first time, to alert new users that drag  
> adds?

I think adding Add to>> and Move to>> context menus might be a good  
idea.
+ Cosmo: https://bugzilla.osafoundation.org/show_bug.cgi?id=11348
+ Desktop: https://bugzilla.osafoundation.org/show_bug.cgi?id=11347

>
> After creating an account, background subscribe automatically  
> downloads collections, but there's a pause, and no text describing  
> what's about to happen.  After bringing down server collections,  
> confused about whether existing or future desktop collections will  
> automatically get pushed to the server.  Prefer to have a dialog  
> choosing whether to sync which collections from the server.

Yes, this is being addressed here https://bugzilla.osafoundation.org/ 
show_bug.cgi?id=11237

>
> The word Triage is potentially problematic, since it's specialist  
> vocabulary from either the medical field, or specific to GTD.  
> Consider using a different word. On the other hand, if it's such a  
> central concept, considering it a 'branded' term, and adding some  
> UI affordance for first-time users to educate on what the concept  
> means.

I think we're intentionally borrowing the concept from medical  
triage. It's a metaphor :) This would be one argument for keeping the  
Triage button as Triage.

>
> The Triage icon looks exactly like the icon for 'recycle,' which  
> confused several people, who associated it with the Windows Recycle  
> Bin. They thought it would trash the selected item.

Yea. Have been waiting for somebody to bring that up. Not sure about  
"actually" being afraid that the Triage button = Delete. But point  
taken and will keep on the look out for more feedback on this.

> The concept of "delete" versus "remove" was confusing. The words  
> have very similar meanings in normal English vernacular. Consider  
> "Remove from all collections" instead of "delete" (setting aside  
> the fact that technically the Trash is a collection).

Yes. Targeted for 0.7.3: https://bugzilla.osafoundation.org/ 
show_bug.cgi?id=9583

>
> 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.

> Both Web UI and Desktop
>
> Several people said they'd try to keep Web UI and Desktop UI as  
> consistent as possible to avoid confusion when users switch between  
> the two UIs.

I think we need to re-consider this in the context of 'usage  
scenarios'. What are people using the web UI versus desktop client for?

I agree though that we should keep visual syntax and vocabulary as  
consistent as possible.

> "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

> 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.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design