Chandler 0.6 Sidebar Specification

Overview

Goals and Objectives

In 0.6, our primary objective is to ensure that we support the basic calendaring use cases well. This includes managing a single personal calendar, managing multiple personal calendars, sharing a personal calendar and subscribing to either someone else's personal calendar or a group calendar. As of 0.5, the Chandler sidebar was unable to elegantly transition from managing a personal calendar to subscribing to shared calendars. There were also concerns as to whether the sidebar was even usable enough just for personal calendaring. We aim to address these concerns in 0.6 while maintaining the virtuality model that was esablished in 0.5.

Sheila Mooney

Spec owner

Mimi Yin

Spec contributor

John Anderson

Implementor

Background

As of 0.5, Chandler had a functioning faceted sidebar, albeit with two important caveats:

• There was no visual feedback in the sidebar itself to help users understand how the facets worked
• The underlying architecture for item collections is being reworked in 0.6 to better support the design
  

There was also no way to differentiate between personal and non-personal information. If a user subscribed to somebody else's personal calendar, their own personal calendar would get polluted with shared events. The transition from using Chandler as a personal information manager to using Chandler as a shared information manager was awkward at best and unusable at worst.

High Level Use Cases

These are the basic high-level use cases we will focus on supporting for 0.6.

1. Manage a single personal calendar

2. Manage multiple personal calendars

3. Share personal calendar(s).

4. Subscribe to someone else's personal calendar.

5. Subscribe to a group calendar.

6. Set up and share a group calendar.

Definitions

Requirements

To be filled in by Sheila.

Assumptions

To be filled in by Sheila.

High-level Decisions

Terminology

Date range
   The date range in view in the maincal.

Month range
   The month range in view in the minical.

Library collection

Not-mine collection

Mine collection

Appbar

Collection

Faceted Sidebar

User Interface/Interactions

High-level usability goals

To meet the high standards required of a usable calendaring application, we are proposing the following high-level changes to sidebar virtuality in 0.6:

• We do not expect the user to care about or explore beyond the calendar application area in Chandler, therefore, we cannot count on the user to understand the faceted virtuality of the sidebar.
  
• Rename the All collections to: My items, My mail, My tasks and My calendar
• Remove the In and Out collections across all app areas unless the user sets up email account information. (After discussing this with John, we ascertained that it would be difficult for us to remove the In and Out collections, just for the Calendar app area.)
• Introduce the notion of "Mine" v. "Not mine" collections so that users can continue to use their library "My calendar" collection as their personal calendar even after they subscribe to shared calendars.
  

Anatomy of the sidebar

• The sidebar is comprised of the App bar and a Sidebar pane containing collections
• The App bar contains 4 App areas: All, Mail, Tasks and Calendar
• The Sidebar contains item collections or groupings of content items
• The App bar filters the sidebar collections by Kind
  • The All app area filter allows for all 4 Chandler kinds: Notes, Messages, Tasks and Events
  • The Mail app area filter allows for only Messages
  • The Tasks app area filter allows for only Tasks
  • The Calendar app area filter allows for only Events
  • Currently, there is no way to select multiple App bar areas simultaneously
    
• Because of stamping, items can be of more than 1 kind. Therefore, a single item could appear in multiple app areas.
• The summary pane displays the results of the selected App bar filter and the selected sidebar collection.

1. Navigating between collections and across app areas

• There are 4 OOTB collections:
  • My items. The name of My items changes depending on the selected app area:
    • My mail
    • My tasks
    • My calendar
  • In
  • Out
  • Trash
• All other collections are user-defined or created as a result of sharing
• OOTB collections have special icons unique to each collection.
• The My items collection has 4 icons that change depending on the selected App area
• All other collections have the same name and the same icon across all app areas EXCEPT:
• The In and Out collections are hidden unless the user fills out email account information.
• Collection names are greyed out if they do not contain any items

View settings across App areas

• Window size
• Show and hide panes: Sidebar, Mini-calendar, Detail view
• Selected collection
• Selected item if possible (this is an open issue and we need close on the behavior for 0.6 - Sheila will own this).
  
• Overlays
  

 View settings per collection in the All, Mail and Tasks app areas

• Selected item
• Scrollbar position (Sheila will own finding out whether or not we can do this).
  

View settings across collections in the Calendar app area

• Displayed date range
• Mini-calendar displayed month range
• Mini-calendar selection
• Day v. Week view

View settings per collections in the Calendar app area

• Selected item (should highlight the previous item we had selected in that collection).
• Scrollbar position (not working - need to log as a task).
  

View settings that persist per App area

• Columns
• Column sort (see notes below - moved to 0.7)
  
• Column widths
• All, Mail and Tasks collections display in Table view
• Calendar collections display in Calendar view
• Calendar day v. week view
• Calendar date range
• Calendar scrollbar position (not working)
  

View settings wrt Minical

• Minical selection persists between collections across the All, Mail, and Tasks app areas
• Minical selection is always a day selection in the All, Mail, and Tasks app areas
• There are 2 ways to get into the Calendar app area:
  • D-clicking on a particular date in the mini-cal takes the user to
  • the Calendar app area,
  • in the selected collection,
  • either in day or week view depending on what the user was looking at the last time they were in the calendar app

• Clicking directly on the Calendar app area, in which case, the mini-cal display is a slave to the main calendar
  • the mini-cal month range should correspond to the date range in the main-cal
  • the mini-cal selector should be either a week or day selector depending on whether the main-cal is in week or day view
  • the selected week or day should correspond to the date range in the main-cal
    

• Once the user is in the main calendar, the minical month range, selector type (week v. day) and selection are slaves of the main-cal date range
• However the user can change the month range of the minical WITHOUT changing the date range of the maincal. ie. the minical can fast forward to display March of 2005 while the maincal is still displaying the 3rd week of January 2005.
• The minical displays either a day selector or week selector depending on whether the user is in day or week view in the maincal. There is no way to switch between day and week view from the minical.
• When the user leaves the Calendar app area:
  • if the maincal was in day view, the minical selection stays the same
  • if the maincal was in week view, the minical selection switches to the day selector and automatically selects the first Monday of the week
• See minical spec for more details about how the minical works.

User runs Chandler for the first time.

• The Calendar app area is selected
• My calendar and Trash are the only 2 collections in the sidebar.
• The My calendar collection in the sidebar is selected.
• The summary calendar view is set to week view and displays "This week".
• My calendar contains a single welcome event set to "Today" from 12-1PM which is in view and selected. Since we are defaulting to the calendar view on startup, we can use this event to contain the 0.6 welcome note in the event body.
  
• Run Chandler a subsequent time.
• We maintain the app bar button selection from when we closed Chandler.
• We maintain the sidebar collection that was selected from when we closed Chandler.
• All view settings are maintained from the previous session EXCEPT:
  
  • Calendar always resets to Today's week if the user
  • Closes the Chandler window
  • Quits and restarts Chandler

2. Navigating between collections in different app areas

• The selected collection stays the same as we switch app areas.
  

The next set of requirements address what item is selected as we navigate across app areas for a specific collection. Please see the notes in red below.

• The selected item stays the same as well UNLESS the selected item does NOT match the kind of the selected app area, in which case:
  • nothing is selected and
  • the detail view is blank 
• If the user is switching to the Calendar app and the selected item was NOT an event:
  • nothing is selected,
  • the detail view is blank,
  • the calendar is in either week or day view, depending on which view the user was in the last time they were in the Calendar app area
  • the calendar date range is set to whatever it was the last time the user was in the Calendar app area
• If the selected item DOES match the kind of the selected area:
  • the item selection persists and
  • in the All, Mail and Tasks app areas, the scrollbar position should change such that the selected item is in view.
• If the user is switching to the Calendar app and the selected item WAS an event,
  • the same event item is selected
  • the detail view displays the selected event item
  • the maincal should be in either week or day view depending on which view the user was in the last time they were in the Calendar app area
    
  • the maincal date range should override the persisted date range from the last time the user was in the Calendar app area, such that the selected item is in view and 
    
  • the scrollbar should override the persisted position from the last time the user was in the Calendar app area, so that the selected item is in view.

3. Sidebar interaction

• D-click in a blank area in the sidebar to create a new collection
• Select Collection>>New from the menu
• Newly created collections are automatically named Untitled and the text is selected, ready to be renamed
• OOTB collections cannot be renamed
• Renaming shared collections only changes the collection name on the local machine (this is handled in the sharing spec).
  

This section is also described in the 0.6 Item Deletion and Removal Spec.

• There are 3 ways to delete collections:
  • Right click on a collection and select Delete from the context menu
  • Select the collection in the sidebar and go to the Collection->Delete menu item
  • Select the collection in the sidebar and use the Delete Key
    

• When the user tries to delete a "Mine" collection: A dialog pops up "Do you want to delete the Collection or delete the Collection and its contents? Okay, Cancel.
• When the user tries to delete a "Not mine" collection:  A dialog pops up "36 of the items only appear in this collection. If you delete <collectionname> you will delete these items as well. Okay, Cancel
  

• The Delete option (collection menu item, context menu) should be greyed out for OOTB collections.
• Using the Delete key on an OOTB collection does nothing.
  
• Deleting a collection that is an inbound share is the same as:
  • Unsubscribing from the share AND
  • Deleting it from your repository
• Deleting an inbound share does not delete the collection from other sharee's repositories
• Deleting an inbound share does not delete it from the server
• When a user tries to delete a collection that is an outbound share, they are prompted with a dialog:
  • Other people may be subscribed to this share. Are you sure you want to delete and unpublish this collection? Okay, Cancel

• Dragging items between collections always adds items to the destination collection EXCEPT
  • Dragging to and from the Trash is always a move
  • Dragging an item from the Trash to a "Mine" collection automatically addes the item to the user's Library collection(s) as well (ie. My, In, Out)

• Collections cannot be dragged and drop in the sidebar
  

• The summary pane displays the sum of the selected collection + activated (checked) collections.
• Collections that have icons display the checkbox affordance when the user mouses over the collection row in the sidebar.
• Collections are activated by clicking directly ON the checkbox.
• Activating a collection does NOT automatically select the collection.
• Selecting a collection does NOT automatically activate the collection.
• Users should be able to switch selection between collections without activating them.
• Multiple selection in the sidebar should be turned off for 0.6.
• See the Calendar spec for more details.
  

4. Sidebar icons

• There are different icons for:
• OOTB Collections - to the left of the names for My XXX, In, Out and Trash. This icon could be replaced by the checkbox icon for activating the collection.
  
• User-defined Collections - The checkbox icon to the left of the collection name (this behavior described in the calendar spec).
  
• Outbound shares - to the right of any collection published.
  
• Inbound shares - to the right of any collection we subscribe to. The share arrow appears over the "Not Mine" square by default.
  
• Partial shares. Partial share icons display next to collections in the All app area when only portions of the collections have been shared. For example, if an user has only shared the Calendar portion of their My items collections,
  • a partial share icons displays next to My items in the All app area
  • no share icons display next to My mail and My tasks in the Mail and Tasks app area
  • a full share icon displays next to My calendar in the Calendar app area
• Error: server error, can't synch this collection etc.
• Offline/Online: if the user subscribes to or publishes a share, they have the ability to manually take it offline (doesn't get synched).
  
• Not Mine collections will have an indicator the these items do not appear in the user's All collection. For shares, there is a square around whatever other icon is visible. For non-shares, there is a dot surrounded by a square.
  
• Please see http://wiki.osafoundation.org/twiki/bin/view/Chandler/SidebarSpec for more detailed drawings

Sharing icons for Mine items (items appear in the All Collection)

• Outbound share:
• Inbound share:
• Partial outbound share:
• Partial inbound share:
  

Sharing icons for Not Mine items (items do not appear in the All collection

• Outbound share:
  
• Inbound share:
  
• Partial outbound share:
  
• Partial inbound share:
  

Other sharing states

• Error (Mine): 
• Error (Not Mine):
  
• Offline (Mine): 
• Offline (Not Mine):
  
• Not mine collection dot (appears in the square for non-shared collections in not mine state): 

5. Designating a collection as "Not mine"

In 0.6 will will support the preliminary notion of user spheres with the Mine and Not Mine affordance for collections. By default all user-collections created in Chander will be designated as Mine, meaning that all the items will exist in the base All collection. By default, all collections created by  subscribing to a share will be designated as Not Mine, meaning that these items do not automatically appear in the All collection. The user can change this default behavior for these collections but using a menu item under the Collection menu. Keep in mind that Mine and Not Mine for an item is based on it's inclusion for that state as it applies to a collection. It we change the state from Not Mine to Mine for the selected collection, all the items in that collection will appear in the All collection.

Since it's possible in Chandler to drag an item from one collection to another, we can drag and event from a Not Mine collection to a Mine collection. In this case, since the item is included in one Mine collection, it will appear in the All collection as well.

There is a new item under the Collection menu to modify the "Mine" or "Not Mine" status of a particular collection. This means that all the items in this collection will also be part of the All collection (Mine) or excluded (Not Mine). The menu item behavior is described below.

• For all out of the box collections, All, In, Out and Trash, this menu item reads Keep <collection name> out of my <app kind> and is greyed out for these collections at all times.
• By default, for all new user-defined collections that are created, this menu item appears as Keep <collection name> out of my <app kind>
• By default, for all subscribed to shares, we will automatically designate them as "Not Mine" type collections. They will however have a way to overide this default when in the subscribe dialog. If they except the default, this menu item changes to  Add <collection name> to my <app kind>. Otherwise, the menu item will read the same as above.
  

• Users can designate user-defined collections as "Not mine" by selecting the "Keep out of My items" from the Collection menu item
• All items created in the collection are NOT automatically picked up by the user's Library collections: My items, In and Out
• However, the user CAN explicitly add items from "Not mine" collections to "Mine" collections and vice versa. (ie. My items, My mail, My tasks, My calendar, In, Out and any user-defined collections that have not been designed as "Not mine" collections). In other words, a single item can live in both "Not mine" and "Mine" collections.

• Users can designate collections as "Not mine" after the fact.
• All items already living in the collection are sucked out of all other "Mine" collections.
• All items already living in the collection are NOT sucked out of all other "Not mine" collections.
• [OI] Is this hard? This is a nice to have. We can disable the "Not mine" option for collections that already have items.

• This is a checkbox option in the Subscribe dialog, detailed below.
• Users can designate a shared (Inbound or Outbound) collections as "Not mine" after the fact as described above.
• All items added to shared (Inbound or Outbound) "Not mine" collections by OTHER sharees are treated the same way as items that are created in-place in the collection. In other words, they are kept out of the user's "Mine" Library collections.
• A particular sharee's "Not mine" setting does not affect other sharees

UN-designating a collection as "Not mine"

• Users should be able to UN-designate an item as "Not mine" OR RE-designate an item as "Mine". This means that the items should get picked up by the users Library collections (My, In, Out)
  

6. Importing calendars

• Imported calendars should always create a separate collection in the sidebar.

7. Sharing a collection

See Sharing spec for more details

8. Focus

• The selection focus is always in the summary pane.
• Ctrl / Cmd - click changes the focus to the sidebar.
  
• The focus should never be in the sidebar or the mini-calendar by default.
  

9. Editing the item in the detail view and summary pane

• Editing any field in the detail view should automatically update the corresponding field in the summary pane upon clicking or tabbing out of the field. [OI] Just wanted to confirm that we still can't make commits in real-time?
• Editing any field in the detail view should NOT remove the item from the collection UNTIL the user clicks away from the item in the summary pane.
• Editing any field in the summary pane should automatically update the corresponding field in the detail view.
• Editing any field in the summary pane should NOT remove the item from the collection UNTIL the user clicks away from the item in the summary pane.
• [OI] Ted, do you want me to go through each field individually for all the different kinds, making thing anytime events etc?
• TedLeung - you don't need to do that unless there's something really different, like "a date picker widget pops up" or something like that. I'm assuming that any visual details for the affected areas are already on "List 1"

10. Stamping and Unstamping items

• In any collection in the All, Mail, and Task app areas, stamping or unstamping the currently selected item should update the stamp columns in the summary table view immediately.
• Unstamping an item of a particular kind does not cause the item to disappear from the summary table view or the summary calendar view until we click away from the item in the summary pane.

11. Menus

The collection menu contains the following items:

• New
• Delete
• Rename
• Duplicate (see notes below)
  
• Calendar color >>
  

• Subscribe
• Share ...
• Manage ...
• Copy URL(s) to clipboard
• Sync ...
• Take ... offline

• Keep ... out of My

Assume that the blanks above indicate separators.

OOTB collections cannot be

• Renamed
• Deleted
• Duplicated

... = name of collection selected in the sidebar

For more details on which menu items are active v. greyed, see Context menu spec and the Sharing spec.

12. Visual polish

• See screenshot for more details
  
• Left and right margins should be 7 pixels
• 5 pixel gutter between collection icons and collection name
  
• Font size: Medium
• Collection and checkbox icons live to the left of the collection name
• Sharing and "Not mine" status icons should be right-aligned in the sidebar
  

13. Updating items in a collection (Stretch)

• Collections should be updated when the user goes to view them. The status bar should give the user information about what's being updated.
  
  • 10 messages were added by ShareeUser
  • 5 events were deleted by AssistantUser
  • 3 messages were deleted by you in a different email client, etc... (not for 0.6)
    
• [OI] Ted asked: Are these example feedback messages or are they specific messages that we expect to see? I'd like to see the set of message we expect to see, so we can make sure that the lower levels of the system actually provide enough information to construct these messages.
• MimiYin think I would need to work on this with you and Brian K and Morgen. I'm not sure I know what all of the scenarios are for why items would appear or disappear from any given collection. Not only do we need to understand what the scenarios are, but we also need to know how much Chandler can actually figure out. For example:
  • An item might disappear because the user deleted it from a different IMAP client.
  • Would Chandler know who deleted it? if it was deleted via IMAP or Sharing?
  • When it was deleted?
  • What client was used to delete it? etc...
• Caveat For .6, we can probably focus mostly on the Sharing scenarios and worry less about email.
• [OI] TedLeung - we should probably work with Morgen / Brian K to get a first cut at the list of reasonable messages.
• [OI] TedLeung - are use cases 6 and 7 also supposed to cover changes via background tasks? I think that the answer is yes, but just want to be sure.

13. Search collections (Stretch)

1. When users search within a collection, we should display the # of results in the sidebar next to the collection. The # of search results should update in real time as items are found. (John said this fell out naturally.)
2. It would also be nice if we could simultaneously search across all collections in the sidebar and display the # of search results found in each collection next to each collection name in the sidebar. The # of search results should update in real time as items are found.
3. When we have email, we will need to be able to display the # of unread messages in each collection. This should be updated in real time
4. As well as Mail is synced
5. As rules are fired
6. When users add and/or remove unread items from collections
7. [OI] TedLeung How much search is in scope for 0.6

Usability Test considerations

1. Do users want selection and overlays to persist across application areas? or would they prefer each application area to have it's own persisted set of selections and overlays.

QA/Test

GUI Testing: Ad-hoc

One big design choice, was whether the sidebar should be implemented as three separate wxGrid tables, one for each kind filter, or a single wxGrid. This was a difficult choice because the design calls for some features to act as if there were three separate wxGrids and some features to act as if there were a single wxGrid. For the 0.6 release we chose to implement the sidebar as a single wxGrid.

The decision of how to handle the mapping between different Views (also known as trees of blocks) and Sets (also known as the ItemCollections) will be handled by the sidebar's TrunkParentBlock, not the sidebar itself. The idiosyncratic behavior of each of the different ItemCollections will not be hardwired in code, but specified in data so that it will be easy to apply the behavior to different ItemCollections in the future. As much as possible, all of the display specific information of particular Sets of data, e.g. color will be separated from the data itself.

Some aspects of the design require not just a View (user-interface) and a Set (list of items), but also another piece of View-specific information that needs to be remembered and associated with the View and the Set. An example of this is the selection. It doesn't belong to the View, nor does it belong to the Set, and it needs to be persisted and wired up to the View and the Set when they are displayed together. For 0.6 there are no plans to implement this separate View-specific information.

One important dependency of the sidebar is the change from ItemCollections to Sets. This change is a prerequisite for a number of features, e.g. color in the icons and bugs in the sidebar, e.g. notification bugs.

Comments

Philippe's Comments - May 19th, 2005

Usage of "My" (as in My items / My calendar / etc...)

This is my pet rant but I really must insist: I do not believe that violating basic grammar rules makes software easier to use.

This "My" fad started with Yahoo back in the days and made sense in the (then new) context of a web app so that users could identify "their" stuff from the rest of the public Yahoo properties.

Still, even there, it makes basic discussion painful ("I think this is in your my contacts list...") but, in the context of a desktop app, it makes no sense at all: after all, this is your computer. Who else's items, calendar, etc... could that be? Furthermore, if the computer is used by several people, it makes the possibility of confusion even higher (everything is named "My items" so you don't know if it's really you or someone else...). And if you want to have several identities, forget it...

I really think that the main ex "All" collection should have a user defined identity name. That will also make sharing less confusing since this name will be used on the server.

I think this is something that needs to be tested with real users while doing usability testing, especially in "multiple identities" context.

Mine - not Mine

Looks to me that we are introducing one level of hierarchy in the collection list. Should we make that more clear? e.g.: visualize it as a real hierarchy? Or create a separation between "mine" and "not mine"? I know there's an icon for it but I found it confusing... (see below).

Deletion

I see that collection can be selectable (good) though it does not have focus (bad).

Warning dialog: Can't we "Undo" a deletion (and then avoid the dialog)? How many levels of undo do we support? (that's really an architecture question for devs)

Warning dialog in deleting an outbound share: We need a "do not show this dialog again" check box in this dialog.

Sharing icon status

Hard to decipher without a legend though I understand the need and I don't have a really better idea : this is not easy to design for sure...

May be should not superpose link and not mine status? (I know: real estate)

May be we should separate visually mine and not mine collections?

Anyhow, we definitely need a really good tooltip on hover on those things... :)

Missing Section : Navigation

User should be able to navigate the list of collections with the arrow keys and rename, move, delete, show (and select) contextual menu all without using the mouse.

Actually, users should be able to navigate across the whole app using only keyboard. For instance tab should move to the next list and shift-tab to the previous, i.e. moving the focus from the collection list to the summary view. See Thunderbird for good (though not perfect) navigation.

This is an Accessibility requirement (see Section 508 for the federal Rehabilitation Act law and UAAG 1.0 for a good W3C spec on how a software should implement it.)

Menu

Can the user choose the collection icon? (not in 0.6 though...)

John's Comments - July 7th, 2005

Implementation

Philippe suggested that I moved this paragraph to comments and label it as a rant. However I'm hoping that even though it sounds like a rant, that we learn lessons from our sidebar experience and incorporate more knowledge of our the available widgets at our disposal into our design process. I think this would improve our design and simplify the implementation.

By far the most important consequence to the implementation of the proposed design was the decision not to take advantage of the vast set of existing widgets at our disposal. This leaves few choices for the implementation and increases the development time by more than an order of magnitude. The proposed design can't be implemented using any standard widget from any UI toolkit on any of the platforms. Outside of implementing a complete custom widget, which is a potentially enormous task, the only obvious choice, other than considering a design that takes better advantage of existing widgets, is to use wxWidget's wxGrid, which is powerful enough for us to completely control all of the drawing code and doesn't use any native widgets, so we can completely control the behavior by overriding or rewriting portions of it. wxGrid is a fairly large and sophisticated piece of code, at around 15,000 lines and at least a man year's effort, so starting with it saves considerable time, but at the same time imposes a steep learning curve. It also has the downside of not being able to automatically track changes to each platform's UI toolkit updates.

Even with the wxGrid code, all the user-interface of the buttons, rollovers, mouse interactions, and drawing of rows in the sidebar are all completely handcrafted and written mostly from scratch. The idiosyncratic behavior of the sidebar as it relates to the kind filters, summary view, and how different items in the sidebar have different behaviors makes the sidebar not useful in any context outside Chandler, so for this reason the sidebar has been removed from CPIA.

History