0.7 Dashboard

Authors: Sheila Mooney
 Last edited: Feb 22, 2007 Creation date: Feb 20, 2006

OVERVIEW

This document will eventually become the full spec for the Preview Dashboard. Originally we had put together a 4 stage proposal for a 0.7 dashboard which was to be scaled down to fit into 0.7's 3 planning phases. Since we are now thinking of extending the 0.7 release to be our Preview release, we have decided to replace the 4 stage 0.7 dashboard with a spec for the Preview Dashboard . As a result, this spec will not exactly match the original staged proposal.

From a design perspective, we are trying to iterate on the Dashboard based on dogfood usage. As a result, we hope to stage development of the Dashboard in a way that makes it possible for users to experiment with the workflows we've designed, even as we continue to build out all of the features. Much of what we are trying to accomplish with the Dashboard is new and for this reason, we believe that getting something out to users as quickly as possible is key to the success of the design. This means that even though we will try to detail out features we think we will need in future phases of the Dashboard, we fully expect to have to make changes to the design and/or add functionality as a result of user feedback.

This first iteration of the Dashboard focuses on implementing a basic table which includes a number of bug fixes and new features that aren't supported today. This will be followed by a several stages of Dashboard features defined around specific usage scenarios we want to test through dogfooding.

Along the way, we will try to outline table functionality we foresee needing in the future in order to help developers make better architectural decisions.


What is the Dashboard? What is the dashboard view?

The Dashboard is in part, inspired by GTD methodology and many of David Allen's insights into the problems with the ways in which people process information and get too easily sidetracked from important tasks in today's interruption-prone information workplaces.

However, the mainstay of the Dashboard design has always been how users have found ways to hack the software tools they have today in order to meet their specific needs.

The Dashboard is the runway view of all of your information. The closest thing users have to a Dashboard today is their email client Inbox.

It's where the user has their nose to the ground, processing new information as it comes in while managing and maintaining their focus.

The Dashboard is the point of origin for where users begin their information processing workflows. It spans all Kinds of information. It spans all Kinds of information across all of your projects and areas of responsibility. However, each user-defined collection is also presented to the user in dashboard view.

You can think of the difference between the Dashboard and user-defined collection dashboard views as one of altitude.

The Dashboard is:

A user-defined collection dashboard view is where the user can back away a little from the immediacy of RIGHT NOW and review projects and areas of responsibility from a longer distance. More forest, less trees. The dashboard view of user-defined collections allows users to:

Why do we need both a Dashboard and dashboard views of user-defined collections?

We found that users often struggled with keeping their Project plan in sync with the daily grind of processing new, incoming information. In Chandler, the Task Item users define in their Dashboards can be the same Item they keep track of in their Project collectoin dashboard views. The hope is, a feedback loop emerges to helps users maintain 'honest' Project plans that reflect the minute-minute Triage decisions they make in their Dashboards.

What is the user problem the Dashboard is trying to solve?

The Dashboard is the runway view of all of your information. The closest thing users have to a Dashboard today is their email client Inbox.

In order to understand the motivations behind the Dashboard design, we must first take a look at why we think the Inbox as a universal information store and task management tool is broken.

  1. The Inbox does not include all information that is important, relevant to you. It only includes inbound messages.
  2. The Inbox is not organized with respect what information is important, relevant to you, it is organized by when you received a message.
  3. If you flag messages as a way of marking that they are important to you, you are caught between an impossible choice. You can either sort your Inbox by flag to see all of your important messages together; or you can sort your Inbox by date in order to see all of your new messages. Unless you can keep the number of flagged items below 20 (some users we interviewed have hundreds of flagged items), you're unlikely to find a satisfactory way of seeing both.
  4. The Inbox is a trap. If you file messages out of the Inbox, you lose track of them. However, if you don't file messages out of the Inbox, your Inbox fills up and users find themselves re-scanning Inbox messages to figure out what they need to do. In other words, you can't organize messages until you're completely done with them. Organizing and archiving are conflated. (You can use rule-based folders to get around this problem, but there are limitations to smart folders, namely, discoverability and IMAP sync.)

While many users insisted on doing everything in email: task management, scheduling meetings, storing contact information; and refused to use readily available tools that were specifically designed for tasks, calendaring and contacts management. This might be because email is panacea for all information management needs. However, people clearly ran up against problems with email once they got further along in their workflows. This indicated to us that something else was going on. Email was a great place to start, but it wasn't necessarily a great place to end up. So the questions we asked ourselves were: Why is email such a great starting place? And why does it fail people half-way through?

  1. Email is a great place to start precisely because it is a-semantic. When you email something to yourself or flag an email you receive from someone else, you don't have to decide if it belongs on a task list or your calendar. You don't have to decide when it's going to happen or what the due-date is. A single email can contain several information items that would otherwise need to be parsed into separate task items in your task manager and/or separate events on your calendar, all packaged together into a single message. In other words, you don't really have to know what it is. You just need to know that it's something that isn't finished.
  2. Email is a great place to start because most of the information you receive arrives via email. The easiest way to manage and store that information is to  do nothing, just leave it in email.
  3. However, once you've figured out what it is you're looking at, email is horrible place to end-up, precisely because it is a-semantic.

Given the user behaviors we observed, we identified the following problems as central workflow issues that the Dashboard need to address at a structural level:

  1. Users need a semantic free collection box for 'things they need to keep track of' and 'new things that they still need to process in order to decide if they need to keep track of them or not'.
  2. Over time, as users make progress on any particular piece of information, they need to be able to record the knowledge they've gained and decisions they've made, iteratively, aka add semantics. (e.g. This is a task, This belongs on my calendar, This belongs on my calendar for next week, This belongs on my calendar for next Monday at 2PM, This is a task that Terry needs to do.)
  3. Users need a better way to manage their focus. e.g. 'Things to keep track of' need to be sub-divided into at the very least: 'Things I need to keep track of right now' versus 'Things I need to keep track of for later.'
  4. Users need to set automatic ways to re-focus their attention on information.
  5. Organizing needs to be separated from Archiving.

The general term we are using to describe our solution to these workflow issue is Triage.

Background

Currently, in Chandler 0.6, all collections under the All, Mail and Task application areas display as tables in the summary pane. The In, Out and Trash collections in the Calendar application area also display as a table. Since the 0.6 tenets focused on building out the calendar view specifically, we did notexpend much effort on enhancing or fixing bugs in the existing table view and it remains much the same as it was in 0.5. In 0.7, we want the user to start experimenting with the general information processing workflows, which means that we expect users to be stepping out of the Calendar app area and using all App areas and the table view. As a first step, we need to revisit the existing table design and UI and look at what infrastructure pieces need to be put in place to make the Dashboard work properly. A table with basic functionality right will be the foundation for a building a framework that will support the Triage and task management workflows we want to have in the later phases of 0.7.

Use Cases

High-level classes of use cases, in order of importance:

  1. Getting information out of my face so that I can maintain focus on the task(s) at hand (without losing track of information). This includes Triage and Tickling.
  2. Processing information and making sure it ends up in the right context, where context is defined as where something needs to be so that I trip over the right thing at the right time. (aka Stamping and Tickling).
  3. Organizing information so that I can find it later (aka Tagging, Labeling, filing and linking).

ALPHA 2 DASHBOARD - BASIC TABLE

Goals and Objectives

The Alpha 2 goal is to get a basic table view up and running, which means work in the following areas.

Requirements

Sort: We need to have the ability to sort columns in a table. Both primary and secondary sort should be supported. The secondary sort is always the date column. (Sort is not working for the stamping columns in Alpha 2.) The specific design details of how sort works is most likely going to change for Beta. In Alpha 2, sort is limited to sorting by what appears in the Who, About and Date columns.

Header: The table header should be visually polished and have all the affordances expected of native header widgets. The 'sorted' column should be highlighted, there should be a mousedown state on Windows and Linux, the columns should be resizable.  We would also like to the ability to add new columns or change the existing ones (user-defined). This may not be a visual goal for 0.7 but we should plan for it from an infrastructure perspective. Column headers can have either text or an icon displayed.

Search: For 0.7, we will have bare-bones support for search in a table view. Please refer to the separate search spec for more details.

Multi-select: Items in a table should be multi-selectable for drag and drop, cut, copy, duplicate and paste. This was left out of 0.6 and is an important requirement for 0.7 (Drag and drop is not working in Alpha 2.)

Visual polish: There are a number of bugs and enhancements we need to make around the presentation and layout of information in the table. This includes font faces, sizes and colors, column widths, margins and gutters.

Bugs: We know there are a number of existing bugs that need to be addressed in 0.7. Most of these are logged under 0.6 and were deferred since they weren't in line with the 0.6 tenets.

In-place Editing: In-place editing of individual cells in the table needs to be supported for all columns. In later phases, we would like to implement in-place editing with clickable icon widgets. We do not plan to support full spreadsheet-like keyboard navigation for 1.0 but will pick some reasonable subset. Beyond what is detailed in the Alpha2 section below, we will draft a separate spec for 1.0 keyboard support.

Drag and Drop: You should be able to drag and drop Items out of the table in order to add them to other collections. In later phases, we would like to support dragging Items in and out the table to and from outside of the Chandler window (e.g. to and from the desktop).

Keyboard Navigation: Some keyboard navigation with the arrow keys to navigate up and down the rows of the table and Multi-select via Shift or Cmd/Ctrl - Arrow keys.

Additional Columns: We want to clarify the end-user mental model of the domain model by adding in separate columns for the task stamp, communications status and the calendar stamp.

Cut Copy, Duplicate & Paste: Basic support for cut copy, duplicate and paste. This includes the ability to cut, copy and paste text (from selected rows) and cut, copy, duplicate and paste for selected table items (presumably, cut, copy, duplicate & paste will work for calendar items as well). Q. Do we need a separate spec for Cut, Copy, Duplicate and Paste?

Assumptions

1. The user will be using the Dashboard and dashboard views primarily for managing tasks, events and notes and any email communications resulting from calendaring or task management workflows. For 0.7 we are not assuming that Chandler will be used as an email client or event as a secondary email client.


Basic Table

Below is a wire-frame of the basic table layout for 0.7. The columns from left to right are: Task stamp, Communications status, Who, Title, Reminder, Date, and Triage status.

In the future, we would like to allow users to modify the columns displayed as well as the order in which they display (this is on the table for 0.7).

General table characteristics

Sorting and Column headers

After talking to Mimi, it's my understanding that we could not get the native column selection behavior working on Windows. If we can manage to get that fixed, great, if not, the summary table view should behave consistent with what we implemented for the calendar header on Windows.

Nice to haves

Task, Communications status and Reminder columns

The column headers for the Task stamp, Communications status and Reminder columns will have the following characteristics and behavior.

Task stamp column

Mail stamp/Communication status column

Reminder column (formerly known as Calendar stamp column)

We would like the Task column to mirror the stamping behavior in the detail view. However there is 1 inconsistency. If the Item is unstamped, we display no icon in the summary table view, whereas in the detail view mark-up bar, we will display an icon for the unstamped state. The inconsistency is motivated by a desire to keep the summary table view clean and uncluttered by 3 columns filled with 'unstamped' icons. In the detail view however, the stamped/unstamped icons appear only once and therefore we can provide a more discoverable UI that will make it easier for users to learn about stamping and leave stamping the summary table view to be discovered over time.

Multi-selecting Items

We would like to support multi-selection of Items in 0.7. As in the calendar view, multi-selecting items in the summary table should blank out the detail view. We should distinguish between Shift-multi-select and Cmd/Ctrl-multi-select We should be able to drag and drop multi-selected Items as well as cut, copy, duplicate and paste Items in both the summary table view and the calendar view.

If you multi-select events in 2 different sidebar collections (you have them overlayed), both selected events become saturated, but there is no change in selection in the sidebar. (See iCal for the desired behavior.)

In the future it would be really neat if we could display a detail view for multiple Items at once which allowed users to edit attributes across multiple Items at the same time. See iTunes for behavior.

In-place Editing/Keyboard Support

In place editing of table items should work correctly in 0.7. The user should be able to edit the Who, and Title columns. At a minimum, we should support the ability to edit the Title column. Editing dates could be useful for adding custom-date ticklers and adding Items to the calendar, but there are some complexities here so we will leave this out for 0.7. (This wouldn't be complex if we could store gobbledy-gook in the start date field.)

It's reasonable to assume there will be some keyboard support in 0.7 for navigating the summary table view and editing items. This has not been fully spec'd out but we have a running list of questions/issues.

General Table Bugs

As a result of the narrow calendar focus of 0.6, quite a few table/stamping bugs were deferred to future releases. Most of these should be reviewed and a good portion of them cleaned up in 0.7. This work will be phases across all Alpha releases. There is a wiki page listing all of the items identified so far (this is not extensive). We will review these and add them into the Alpha releases as appropriate.

0.7 Table Bugs



PREVIEW DASHBOARD

In Alpha 4 we will continue work on the Dashboard by adding some finishing touches to the basic table functionality that fell out of Alpha 2 and introduces Triage status and custom-date Ticklers for all Items, not just Calendar events. Much of the work we need in order to get a basic Dashboard up and running centers around the Stamping workflows. Although this spec contains some sections of the Stamping spec, it is strongly suggested that you read the Stamping spec as well in order to get the complete picture of the Dashboard workflows.

Rather than try and detail all the incremental dashboard features for each Chandler milestone (Alpha4, Alpha5 etc), we felt it was easier simply to spec out the dashboard features we want to have for Preview and PPD will work with the developers on an ongoing basis to stage this over multiple milestones. What gets implemented first depends on many different factors but PPD has included a priorities section indicating what they feel is more important to iterate on first. Getting to a proof of concept dashboard for Preview is an incremental process.

Navigating to the Dashboard

Users go to the Dashboard by selecting the Dashboard collection in the sidebar. We are changing all the "My" collections to Dashboard for Alpha 3 (see details in the Sidebar spec). If we want to see the Dashboard for all our Items, we go to the Dashboard in the All app area. Alternatively, we can see Dashboards for just Messages, Tasks and Calendar by clicking to the appropriate App area in the App bar. In this respect, the dashboard is simply a type of view and users have various dashboard views which can be narrowed depending on what type of view we want to have of the data.

The "Keep out of My Items" menu items will NOT be automatically replaced by "Keep out of My Dashboard". We are intending on changing the names of these menu items which is yet to be discussed on the design list.

The Task, Reminder and Communication Columns

There are 3 important columns that provide the user with visual affordances and feedback to manipulate items in the dashboard. The Task column is the most straightforward. The Communication column is used to provide a wide range of visual feedback ie: read, unread items, and whether items have been sent, received, updated etc. The Reminder column indicated whether or not the item has event information and/or has a tickler associated with it. The behavior for all 3 columns will be further described below.

Other than separating out the Stamp column into separate Task, Communication status and Reminder columns, we didn't do much work on supporting Stamping in the table view in Alpha 2. In Preview, users should be able to Sort on those columns by clicking on the header. It's important to note that we will not have a (descending or acending) sort arrow displayed in the header for these columns. It's less important that we different between ascending and descending for these columns because the columns are iconic don't have an alpha-numeric order

Task Column

Mail/Communications status Column

The Communications column works slightly differently from the Task column.

The user can click on the Communications status column to cycle through the following 3 options:

Clicking on an Unread Item row also marks the Item as Read

Unlike the Task column, the Communications status column does not map to the Communication stamp (in the markup bar). It does not toggle to turn this item into a communication. It displays 14 communication states x 3 options for each state: Read, Unread, and Needs reply = 42 states.

Communication states:

Each icon has 4 interaction states:

For more details and design context, please see Stamping Spec: http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Stamping-0.7.html

For more details on recent visual design tweaks, please see: http://lists.osafoundation.org/pipermail/design/2007-April/006954.html


Once FULLY implemented, the proposed sort order is: (NOTE: Bryan and I are trying to work out the exact sort order.)

Originally spec'd out sort order:
Revised sort order:
Note: Not all combinations of the 3 different groups of communication states above appear, because, as noted above, some states are specific to whether the item is a message or not. Also, if a message-specific state is listed, “First-time communication” is implied if “Update” is not present.

The Communications status column should be sub-sorted by the Triage status column.

The following table lists the icon names actually used by Chandler for the above. (Since there are variations for rollover, active, read, etc, these are only prefixes for the real filenames):

Icon Filename Prefix
created/editedMailPlain
plain draftMailPlainDraft
inbound draftMailInDraft
receivedMailIn
draftMailOutDraft
sentMailOut
draft-out-updateMailOutdateDraft
updatedMailOutdate
draft-in-updateMailIndateDraft
received updateMailIndate
queuedMailQueued
errorMailError

PLEASE NOTE: We may not necessarily have all of these 42 states working for Preview. We are going to start by implementing the basic read, unread, needs reply support. After that we will handle received, sent, errror. The next set will bet updated and error. We may defer queued and draft from Preview all together. From a domain model perspective, we needed to map out all the states but may not handle all of them in the UI. Some people have been concerned that all these states will be confusing for the user. Technically, all of these exist regardless of whether or not the user is aware of them. Most of the time, users will only see a small group of them.

Determing Inbound versus Outbound

Open issue: Does this include email addresses associated with Sharing accounts?
Open issue: Currently, we are not sharing BCC, so there are no circumstances under which users will 'receive' message items where they are mentioned in the BCC field. I have logged a bug to track this for Post-Preview because I believe there are scenarios where sharing BCC will be useful: http://bugzilla.osafoundation.org/show_bug.cgi?id=8206

When to display an Error or Alert icon

See list discussion: http://lists.osafoundation.org/pipermail/design/2007-March/006620.html

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

If a conflict arises on an item while syncing a collection:

If a conflict arises on an item via edit/update:

If a sharing error occurs on an item while syncing a collection:

If a sharing error occurs while syncing a collection, but the error does not affect any particular item:

If an error occurs while downloading mail (POP and/or IMAP):

If an error occurs while sending mail:

Whenever there is an error/alert on an individual item, the error or alert message should display in the red banner area at the top of the detail view (below the mark-up bar).

Read/Unread status Workflow

For more on read/unread status behavior, see the section below on Recurrence.

Reminder Column (formerly known as the Calendar stamp column)

Once we have Ticklers, we will want to turn the Calendar stamp column into an 'Add a custom-date tickler' column where users can toggle between adding and removing custom-date Ticklers. The column would still display Calendar date status, however adding a custom-date tickler will override the calendar stamp, much in the same way that marking an Item 'Needs reply' in the Communication status column overrides communication status icons.

User motivations:

When clicking in the Reminder column, users can cycle through the following 2 options:

There are 3 possible Date states in the Reminder column:

Each icon has 4 interaction states:

Descending sort order for the Reminder column: 

Activating the Reminder icon in the Reminder column blanks out the Date column for that row, overriding whatever Date should be displayed in the Date column. User motivation: This provides users with a way to 'tag' Items as 'Needs to be assigned a Tickler date.'

However, once the user assigns a Tickler date, the usual Date column rules apply. For example, if the custom Tickler date is not the right Date to be displayed, both the Tickler icon in the Reminder column and the Tickler date in the Date column will be overridden by the Calendar stamp icon and the Event Start-date and time. (See below in the Date column section for specifics).


Triage Status

Triage centers around quickly processing information into Now, Later and Done buckets in order to provide users with a better framework for managing their focus. All Chandler Items regardless of Kind: notes, communications, tasks, events and eventually resources and newly defined Kinds have a Triage status. Triage statuses are mutually exclusive. Out of the box, there are 3 status values: Now, Later and Done. In the future, we imagine that user will be able to define their own and add and remove status values.

Why do we think our target users will use the triage status? Assumptions derived from user interviews:

Out of the box, all table views will be sorted by the Triage status column with the following sort order: NOW, LATER, DONE. Click on the Triage status column header to reverse the sort order. See below for how Items are ordered within NOW, LATER and DONE.

For now, we have chosen to NOT have a separate section for NEW items to separate NEW items from those that appear in the NOW section. This will be discussed further on the design list and we are prepared to respond to feedback from users once we have the basic triage workflows up and running. We would like to start with just having 3 triage statuses for now and will re-evaluate once we have had some experimental usage.


Triage Status Model

Each item has a triage status that colors the NOW/LATER/DONE buttons shown in the dashboard and at the top of the detail view. The dashboard is divided into sections by triage status when sorted by the triage column; within each section, items are sub-sorted by how recently their triage status changed; an internal timestamp, "triageStatusChanged", is used to track this.

Normally, this same "button" triage status is used for sorting in the dashboard; however, because we occasionally want to pin an item in place when changing its button color, or move an item to a sort position other than what its button triage status would call for (see specifics below), a secondary "section" triage status overrides the button triage status if it's present. All items have button triageStatus (and triageStatusChanged); section triageStatus and sectionTriageStatusChanged are optional.

These attributes combine to work like this:

Also, we internally track whether we should automatically set triage status on the item when the user changes dates on the item (see below for details). This "doAutoTriageOnDateChange" flag defaults to "on" (enabling auto-triaging), but is updated by certain actions described below.

The button triage status attributes (triageStatus and triageStatusChanged) and the doAutoTriageOnDateChange flag are shared, only if the user chooses to "Share triage status" in the sharing dialog for a given collection. Note that if the user chooses to "share triage status", alarms must be shared as well, to avoid attribute wars (and spurious conflicts) of triage values. The section triage status attributes (sectionTriageStatus and sectionTriageStatusChanged) are never shared. (Behavior of these attributes at sharing time is described below.)

Triage Status Display

Triage status is displayed as two buttons: in the rightmost column of the dashboard, and in the markup bar in the detail view. Both these widgets are clickable, and act like buttons: they have active, rollover, and mousedown states, for each of the three status values NOW, LATER, and DONE:

Triage status and unread-ness changes

Triage status changes fall into three categories: explicit actions by the user, implicit user actions, and internal auto-triaging. Certain sharing changes can also mark an item "unread" again.

Explicit user actions affecting triage status:

Implicit user actions affecting triage status:

Automatic operations affecting triage status:

Note: The various automatic triaging (button triaging and section triaging) options described above are never mutually exclusive.

Sharing, Edit/Update and Error changes to an item affect the sectionTriageStatus of that item. However that does not preclude other automatic triage operations from having their way with the item.

If the change was a change to the item's date/time, then auto-triaging based on date/time changes should also take effect.

The only situation in which buttonTriageStatus would not be updated when there is a change to date/time information on the item is if the item in question has has its doAutoTriageOnDateChange flag set to false by the user or by sharees (if Triage status is being shared).


Ticklers

We would like to give users the ability to set alarms on all Items, regardless of Kind.

UI elements

  1. Clickable set custom-date Tickler widget in the Reminder column
  2. Add Reminder field to detail view of all Items 
    • Reminder field appears right above the Notes field for All Kinds of Items.

Workflow: Setting Ticklers from the Table view

  1. Click the set custom-date Tickler widget in the Reminder column
  2. Default Reminder date is set automatically: End of Today: Todays' date + 5PM
    • This is where we might be able to experiment with Darshana, for example
    • If it's before noon, automatically set Tickler to End of Today
    • If it's after noon, automatically set Tickler to Tomorrow
    • Other natural language Ticklers: End of this week, Next week, in[#] weeks, End of this month, Next month, etc
  3. Click Tickler icon in Reminder column to remove Tickler
  4. Tickler date persists even after it has fired

Workflow: Setting Ticklers from the Detail view

    1. For non-Event Items, edit the Reminder field in the Detail view:

        2. For Event Items, the pull-down options are as follows:

        In the future we would like to add natural language options such as: End of day, Tomorrow, End of this week, Next week, [#] weeks, End of this month, Next month, etc. However for now, a custom date option will suffice.

          The Date Column

          With the addition of Ticklers, what appears in the date column becomes a bit more complicated. Dates should appear in the Date column in the following manner:

          Recurring Events

          There should be separate instances of recurring events (for a single series) in each Triage Status section, if applicable.

          Nice to have: Pruning of recurring events

          Whenever possible, if users end up with 'extra' instances of a recurring event in a triage section, we should try to 'prune' the recurring event series and recombine instances that don't actually need to separate instances in the Dashboard (e.g. User changes the Title of a LATER instance and then changes it back to match the series Title.) It doesn't look like we'll have this for Preview, but it's logged as: bug: 7903: https://bugzilla.osafoundation.org/show_bug.cgi?id=7903

          Sending, Editing and Updating Recurring Events
          In the Preview timeframe: Send, Update, and adding, removing and editing the Addressing fields will always apply to the entire event series. However, only 'edited' instances will be popped to the top of the NOW section in the Dashboard view.

          If the user makes a global Edit to a recurring event series and then sends out an Update, all instances of the recurring event in the Dashboard will pop to the top of the NOW section in the Dashboard. (We know this isn't ideal, but it's a first step for Preview. When we have a notion of clusters, we might be able to represent global edits as a single row item that can expand to show more instances.)

          If the user Edits a specific instance in a recurring event series and then sends out an Update, only that instance will pop to the top of the NOW section in the Dashboard.

          If the user makes a 'This and Future' edit to a recurring event series and then sends out an Update, the 'This and Future' edit will be represented at the top of the NOW section in the Dashboard by the 1st instance that was changed.

          For more information on how replies and forwards will work with recurring events, see the Sending, Replying to and Forwarding Recurring Events section of the Email spec: http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Email-0.7.html

          Marking up Recurring Events: Triage, Unread/Read/Needs reply status, Task stamp, Custom reminder dates

          Marking buttonTriageStatus, Adding, Removing and Editing Custom Reminder Dates will always apply to individual occurrences no matter where you are, Dashboard or Calendar.

          Marking an item as Unread/Read/Needs reply will always apply to the entire recurrence series.

          Invoking the Task stamp should pop-up the dialog asking users if they want to apply/remove the stamp to the entire series, the single occurrence or this and future occurrences, regardless of where you are, Dashboard or Calendar.

          Note: Ideally, we'd like users to be able to make recurring events as Read/Unread/Needs reply in the same way we Triage recurring events.

          Sections

          All dashboard views should section on triage status only. Most of this is basically working as of Alpha2 but there are just a few minor changes we would like to make in the area of visual polish and semantic clarity.

          Out of the box, all table views are sectioned by Triage status in the following manner:

          Click on the Triage status column header to reverse the order of the Triage status sections: DONE, LATER, NOW

          Click on a different column header to sort/section on a different attribute.

          Nice to haves

          Dashboard with sections



          Multi-selecting table items (nice to have)

          We believe users will often want to do the following tasks in batch:

          It is less likely, but still a possibility that users will want to perform the following tasks in batch:

          As a result, we would like to eventually support the ability to:>

          1. Multi-select Items in the table
          2. Click in the Triage, Communications status, Reminder and Task columns to apply a single setting to all selected Items in 1 step.

          Proposed workflow:

          1. I select 10 Items in the table
          2. I click in the Communication status column for 1 of the selected Items, which is currently marked as Unread,
          3. All 10 Items are now marked as Read
          4. If I click on a row that is not one of the 10 selected Items, then the click only applies to that particular row and does NOT affect any of the 10 Items I have selected.

          This should also include multi-selecting items in order to drag and drop them into another collection.

          Nice to have: Explicit Reordering for Triage status

          Explicit reordering means that the user can drag and drop items within the table to reset the order in which Items were set to a particular Triage status value. (e.g. Item A was the 3rd Item set to NOW in my list of 37 NOW Items. I want to see it back at the top again. I will reset Item A to be the 38th Item set to NOW in my list of 37 NOW Items.)

          Open Issue: Should explicit order be maintained on a per collection basis? or across collections?

          Proposed staging for Preview

          Things to do first:

          Things to do next:

          Nice to haves (in order of priority)

          The following images are dashboard mockups for each phase listed above: Things to do first, things to do next and stuff that can potentially be deferred until Post-Preview.

          Mockup - Things to do first:


          Mockup - Things to do next:


          Mockup - Full Preview Dashboard:



          POST-PREVIEW DASHBOARD

          There are a number of features we have discussed in the past that can't make it into the first Preview release. We wanted to keep these sections in the spec since we will come back to those once we have Preview finished. We also expect some of our Preview users to ask about future features and felt it was useful to have some of the current designs and issues documented.

          Multi-line table display

          Supporting multi-line display is particularly important for tasks. We expect that we will eventually need to display more information in both the Who and Title columns. This should be a setting that the users can turn on and off for all Items or set on a per Item row basis.

          How many lines should we display? Should we always display 2, 3 regardless of the length of the text? Do we adjust the number of lines depending on how long the text is? How sophisticated do we make the algorithm? How do we parse keyboard short cuts for carriage return within a cell versus moving out of the cell versus moving to the next row in the table?

          Sorting and Sectioning in the Who and Title columns

          There are currently 3 ways in which we can implement Sort/Sectioning in the dashboard view:

          1. Sort on the attributes that happen to appear in the Who and Date columns at any given point in time. (John Anderson thinks he has a simple solution for this.)
          2. Clicking on the Who and Title column headers pops-up a drop down where users can choose to sort on a particular attribute:
            • Who column: From, To, CC, BCC, Sent by, Updated by, Edited by, Created by
            • Date column: Tickler date, Start date, Date sent, Last modified date, Date created
          3. Clicking on the Who and Title column headers sections these columns in the following manner:

          Nice to haves

          A more detailed discussion of the pros and cons of these approaches and user motivations/workflows can be found at:

          http://lists.osafoundation.org/pipermail/design/2006-June/004799.html

          User-defined Sections

          Although we know we need to support more flexible sections in the table view at some point in the future, at this time we have not worked out the appropriate detailed design. We would like to explore this in early 0.7 to collaborative braistorm alternatives with the development team and through the design list. Until then we just want to make the dev team aware that we will be working on this so we do not make any architectural decisions that would prevent us from implementing some solution in the future. It's possible we will do something in 0.7 but this is currently undecided.

          Some open questions: Are Sections attached to a column in the table? Do Sections have semantic meaning the way collections do? Can users section by any column? Can users section by any attribute? How many levels of Sections should we accommodate? Can users define their own Sections? Can Sections be promoted to the Sidebar as collections? Are Sections Items as well? with Detail views? Can users share Sections? Are Sections re-orderable? Can users save configurations of Sections. Does each Collections have a single configuration of Sections? Or can a single Collection have multiple configurations?

          Clusters

          New item creation with CLI-for-dummies

          See wiki spec at: http://wiki.osafoundation.org/Journal/QuickItemEntryProposal

          Overlays in the Table

          This is currently being discussed on the list...http://lists.osafoundation.org/pipermail/design/2006-June/004818.html

          Special Considerations

          QA / Test

          API / Developer Platform

          Security

          Internationalization / Localization

          Accessibility

          UI must be accessible (Section 508).

          Build / Install

          Cuts

          Handle CONFIDENTIAL or PRIVATE events specially.

          Useful Links

          History

          Author Edit date Description
          Sheila Mooney and Mimi Yin
          		 Jun 9, 2006
          		 First official draft