Chandler at FLOSS Usability Sprint 2007

• FLOSS homepage
• notes and mockups from the 2007 sprint on Chandler

Video recordings of the User tests

• Test 1
• Test 2

Overlays: the main focus of the sprint

Design Goals

1. Display multiple calendars at one time
2. Select (make active) a single calendar at a time
3. Visually communicate visible (overlay) state
4. Visually communicate selected (active) state
5. Visibility must be tied to selectedness -- e.g., the selected (active) collection will always be visible

Constraints

1. Allow user to switch between collections with a single click
2. Changes to selection shouldn't affect original overlay state
3. Scrollbar may or may not be present
4. UI sits in the left sidebar -- limited, fixed width, but arbitrarily long collection titles
5. Collection selection determines what shows up everywhere else -- should be prominent

Nice-to-haves

• Show all / hide all, or Ctrl+click for show only this collection
• Some way to ascertain ownership of read-only collections
• Visually distinguish writeable vs. read-only
• Drag/drop for customizing the order the collections appear in

Mockups

The sprinters created a variety of whiteboard mockups.

JavaScript prototypes

After pondering and discussing the various mockups, Matthew created several JavaScript prototypes for overlays:

• The current behavior: http://www.fleegix.org/demo/floss_usability_2007/proto_0.html
• Alternate layout: http://www.fleegix.org/demo/floss_usability_2007/proto_1.html
  • Checkboxes on right, so they're less prominent
  • Disabled checkbox when collection is selected
  • Added "Active: Some collection"
• Another layout: http://www.fleegix.org/demo/floss_usability_2007/proto_2.html
  • Keep "Active: Some collection"
  • Use eye to display overlaid state
  • Distinguish between always overlaid (black eye) and overlaid-because-selected (eye with colored background)
  • Allow overlay to toggle even when the collection's selected

Feedback on first seeing prototypes from other sprinters

• The eye icon is used by Photoshop for indicating layer visibility, familiar to some, but Photoshop may not be a good source for familiar/high usability UI
• Color isn't a good signal for important UI concepts, because color blindness is prevalent
• Overlay icons seemed small for people with less-than-perfect-vision, color was hard to distinguish
• 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?

Feedback from dozens of short conversations

Web UI

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.

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

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.

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.

The areas of the minical that are clickable and non-clickable are not obvious. Small indicators like cursor changes don't provide enough guidance.

One of the test users found the use of super-saturated colors for UI elements (collection icons, triage indicators) distracting from the data.

Collection selector

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

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.

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.

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.

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.

The date-entry in the Web UI really is horrible. (We know this.) Multiple people asked about a date-picker.

The timezone selector is also horrible. One test user picked the "Pacific" region (Australia-Pacific), and naturally assumed she'd picked the Pacific timezone.

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

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.

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.

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

Google calendar doesn't have a selected calendar, when adding items a collection has to be chosen. One advantage of this is that multiple collections could be chosen simultaneously. What's Chandler's workflow for adding item to multiple collections? Could add Paste special in edit with dialog with checkboxes for target collections

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?

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.

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.

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.

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

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.

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.

Collection selection is a reflection of context, a bigger deal, conceptually, than overlaying data from another collection. So change active collection is a heavy-weight behavior, changing context, whereas overlaying collection is light-weight, changing picture. Not sure how to do interaction design for this, but the current design doesn't seem to reflect this very clearly.

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

Triage buttons: could add a drop down, NOW \/ to suggest that the button is clickable, allow one click selection of everything

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.

-- JeffreyHarris - 07 Nov 2007
-- MatthewEernisse - 07 Nov 2007