r67 - 09 Aug 2007 - 16:59:57 - TedLeungYou are here: OSAF >  Projects Web  >  CosmoZeroDotSeven > CosmoZeroDotSevenSpec

NEWS

Sep 10th: Preview Release!

QUICK LINKS




Table of Contents

Cosmo 0.7 Preview Specification

In Progress

Overview

Goals and Objectives

The focus of Cosmo 0.7 is to take the next steps in supporting shared collections with Chandler Desktop users. The primary focus is to create the minimal set of features to display a list view of items beyond just calendaring events. This list view referred to as 'dashboard', is the primary focus of a Chandler Desktop user, Helen the Hub. When Helen the Hub shares a collection with Bart the Busybody/Coordinator Casual Collaborator, Bart can not only collaborate in meeting date and times on the calendar, but also check off task items he is supposed prepare for the meeting. In the previous releases, items beyond calendar events is not displayed in the web interface.

Part of the 0.7 release, it is also vital to incorporate dogfood feedback from users currently using Chandler Hub. The project will be reviewed in terms of performance, stability, other features that prevent some users from dogfooding Chandler Hub.

Background

Though many of the features in the dashboard have been specified in Chandler Desktop, (See 'Suggested Readings' section to review the dashboard and stamping spec in Chandler Desktop), this is to help outline some of the differences between the fully featured dashboard and the minimal set of features for collaboration between a CC and a Hub (Chandler Desktop user).

Target User

Here is a list of target users to help classify different types of users which have been brought up various times on the design list. This is just a tool for us to help identify users so that we are able to base prioritize features based on the user's needs. Satisfying the proposed target users for 0.7 (Preview) may also overlap other target user's we are currently not satisfying for that particular release. In addition to the proposed target users, we are also prioritizing features from users who are dogfooding the application. We would prioritize their features so that we can also satisfy their needs as well.

  1. End-user Casual Collaborator (CC) - A light CC (not regularly using Chandler Hub) user who has clicked on a URL/ticket sent from a Chandler Desktop user. A heavy CC (regularly using Chandler Hub) user who is not only using the CC UI (PIM features). Though is not an administrator. See CC diagram. Created back in May 2006
  2. OSAF Administrator - tools for the administering hosting Chandler Hub.

An example relationships between the CC and the Chandler desktop user are:

  • CC could be another Helen the Hub, Bart the Busy Body, Angie the Apex, Eli the Executive Assistant or Ivan the Individual Contributor. See target user descriptions?.
  • CC could be in the same working group as Helen the Hub or outside of the working group
  • CC does not use Chandler desktop to manage their information, however, CC does need to collaborate with Helen the Hub on a periodic basis
  • Collaboration can be sparse (a few times a month) to frequent (a few times a week)

The nature of collaboration between the CC and the Chandler desktop user is relatively low. For example:

  • Checking on Helen the Hub's schedule
  • Adding personal PTO time to a shared group calendar
  • Updating status on a task in a group task dashboard
  • Checking status on tasks in a group task dashboard

Collaboration that is not supported by Preview. Example:

  • The heavy back and forth collaboration such as like Angie the Apex and Eli the Executive Assistant managing and negotiating Angie's schedule.

Use Cases

Adding tasks to a collection
  • Bart the Busybody/Coordinator needs set up a meeting with Helen the Hub. Bart and Helen coordinate on an appropriate date and time and also items to bring to the SMASH program meeting, ie. projector, tape recorders, large pads of paper, markers, etc. Bart reviews the list to see which items he is tasked to bring.

View /Edit collections without an account. Review particular items on a list.

  • Helen the Hub coordinates with her book club group to coordinate food for the meeting. She sends out our read-write bookmarkable URL to the book club members and each CC user can add what they are bringing on the list without a Chandler Hub account. The day of the meeting, Helen reviews the list to see how many people are coming and write up a list of other preparations she might need to do or have people bring to the meeting.

Browse collections: Calendar/Dashboard view

  • Helen the Hub writes up the dates of her daughters dance recitals for the year in Chandler Desktop. She send out the bookmarkable URL to her family and creates a list to coordinates with her husband Bob. The tasks on the list might be who is responsible for bringing the costumes/tutus for their daughters and to help plan ahead of time as to who is going to pick up the in-laws.

Add an event to a collection and triage task items

  • Helen the Hub plans a holiday to London with her husband Bob. She creates a packing list of who is responsible for taking care of specific errands before they leave. Bob is at work and receives an e-mail from Helen. He clicks on a link to view the read-write collection list Helen created on Chandler Hub. He goes through his list of errands to do before the trip and checks items off as 'Done' once he completes his tasks. He also bought tickets to HayFever at the Haymarket Theater Royal. He enters the item and stamps it as a calendar event to place on her calendar.

Definitions

Requirements

  • Minimum set of features for dashboard for the Casual Collaborator workflows
  • Incorporate dogfood feedback from users
  • Time zone: The ability to view, create and set time zone information from the web UI.
  • Minimum tools required for the OSAF Administrator to run Chandler Hub
  • Interoperability: To allow users who publish their calendar information on the hub using other types of calendaring applications, ie. Cal DAV; iCal, Sunbird, etc., Atom; GCal. Feed Readers, etc.

Open Issues

  • User will not be able to remove/delete, unsubscribe from the web UI for preview. Advanced users will be able to do this from the account browser—Will this be an issue?
  • Time zone workflow. Finish this feature for 0.7?
    • Turning on time zone from ticket view.
  • Recurrence in the dashboard. The goal is to try to implement as close to the desktop as possible, but document all the unknown recurrence in a central wiki page.

Assumptions

  • This is a dogfoodable release. Dogfood feedback will be collected and may change the course of the features slated for Preview.
  • Unforeseen Chandler needs. Cosmo will continue working on features which will compliment Chandler.
  • Revise web UI layout to more closely resemble the desktop where it makes sense.

High Level Decisions

Preview does not mean a feature complete in the 1.0 product. It's a coherent set of features around collaborative calendaring and task management, targeted for a specific group of users. We are aiming at small groups and not large enterprise organizations. We expect to have more than one Preview release before we reach 1.0.

There are two primary users which we have categorized as users for Cosmo. They are 'End-user Casual Collaborator and the 'OSAF Administrator'. We've identified other types of users, but we've focused on these two users to help identify and prioritize the features for this release. See Cosmo target users for preview.

Suggested Readings

This document also refers to some items listed on specifications from the desktop. To understand some of the background and details of a fully featured dashboard, please refer to some of the desktop specification listed:

Dashboard

  • Chandler 0.7 dashboard specification
Stamping
  • Chandler 0.7 stamping specification
Recurrence
  • 0.6 recurrence for the desktop
  • Chandler 0.7 recurrence specification Updated with new scenarios/behaviors implemented with links to bugs, list discussion and specs.

Terminology

The following are terms used in the recurring events on the dashboard section:

Time edit/modification:

  • When the user makes a modification in the start/end time and/or moves the item along the time line directly on the calendar canvas.

Time edit/modification:

  • When the user changes the item in any of the form fields except time. ie. by-line, title, location, recurrence and description.
  • add/remove address: When the user add/remove using a 'communication stamp' to the item.
  • add/remove to/from the task list: When the user add/remove using a 'task stamp' to the item.
  • add/remove to/from the event on the calendar: When the user add/remove using an 'event stamp' to the item.

Stamping:

  • Stamping can be described as the quickest way to put unstructured data into the right context by defining what it is, by defining its Kind. This is a Task, put it on the Task list. This is an Event invitation, put it on the Calendar. Stamping is essentially an affordance for making semantically meaningful piles. Refer to the 0.7 desktop stamping spec for more information on stamping.

Kind:

  • The term 'Kind' refers to the type of stamp attached to an item. For example, if an item is stamped as a task, then the 'kind' is a 'task'.

Detached Item:

  • An item which has been been removed from the series of recurring events. An instance never fully detaches from a recurrence until all of the attributes are modified for 'Only this event' (instance).

The following terms are used in the time zone section:

Ticket view

  • The ticket view is an anonymous unauthenticated view of a single collection. When a user clicks on a bookmarkable URL, the browser opens a new window/tab taking the user to the 'ticket view'. Technically a user can be logged into the hub on a different window/tab, the ticket view doesn't know about the user's login state.

Bookmarkable URL

  • The bookmarkable URL is URL with a ticket attached to it generated by Chandler server after publishing a collection.

User Interface/Interaction

Updated 5/29/07

Moving forward with the header below. 5/29/07


Header and other revisions update: 5/11/07

  • Cosmo_Preview_Styleguide_DV_Top:

Let's walk through the workflows for when the tz and subscribe pulldowns appear and disappear.

1. User clicks on ticket-URL to view share in ticket view:

  • User log in links are there.
  • Subscribe pulldown is there.
  • TZ may or may not be there depending on whether collection contains tz data.

2. User subscribes to share and logs in.

  • User log in links are there.
  • Subscribe pulldown is no longer there.
  • TZ may or may not be there depending on whether collection contains tz data and/or whether user turned on tz support in UI.

Questions to think about: Should we optimize for the Logged-in view to look the nicest? ...since that's probably the view that any one person will spend the most time looking at. If we do, I think we don't want the user log-in links to sit above or below the TZ pulldown in the upper-right. It's kind of cramped.

Do we want to try and keep UI elements relatively static, as in not move them around between views?

  • Ticket view
  • Ticket view w/ tz
  • Logged in view
  • Logged in view w/ tz

What about having it all in a line at the top of the screen? See mock-up.

  • Ticket view:

Subscribe with... | Sign up! | Log in | | Help

  • Logged in view:

Welcome username | Log out | Settings | | Help

is optional.

It will look even better when we can have custom pulldowns.


Upated: 5/10/07

  • Rework timezone/subscribe header area
  • Get rid of plus icon, replace with Add text underneath
  • Streamline NOW/LATER/DONE buttons

  • Make buttons a middle-grey
  • Darker outline for RO (Rollover) effect
  • Flatten out selected sort column header

  • Rework dialog
  • Updated selection highlight and active link colors


Updating the sketches to accommodate the hide/show of a larger description field and to remove form elements under the task section. Dated 5/9/07

  • Short notes field. Default when creating a new item in the dashboard:

  • Expanded notes field:


Detail view explorations with collapsible stamping headers: Dated 5/3/07

How it differs from the desktop

  • Expand and collapsed header per stamp attribute.
  • 'Save' and 'Delete' buttons are fixed at the bottom so the buttons will not disappear below the fold.
  • Reworked layout so 'Title of the item' and area for notes always stay on top.
  • Reworked triage button so all states are visible to the user, front and center—no guess work if 'Later' follows after 'Done' etc.
  • Scroll bar appear for the entire detail view not only the description field. (need to confirm if user extends the fields, will the form fields be able to expand?)

Some of the rework is based on the Order of importance web UI discussion.

  • Accordion style show/hide on the detail view: all open:

  • Collapsed detail view:

  • Keeping the same desktop layout w/ the buttons fixed at the bottom: :


Open issues on the design mock up that needs to be refined.

Still working on:

  • Layout on the header area -
  • Confirm dashboard/calendar views are correct
  • Button states -
  • Graphic assets
  • Documenting recurrence in a centralized wiki page
  • Document style guide in a centralize wiki page
    • Comprehensive visual syntax guide for:
    • Font colors, sizes, styles
    • Button styles
    • Selection highlight
    • Glyphs
  • Pull together consistent language, error messages etc. Also to be put on the style guide. - in progress

Remaining open issues:

  • Pull together a proposal for Removing / Deleting / Unsubscribing / Unpublishing Pushing this out, should be able to do most of this in the account browser.
  • Follow-up with Bobby re: Time zones workflows for Preview to finalize UI proposal

  • Bucketize UI elements into 3 categories:
    • Stuff users need to see immediately, whether or not they're looking, Stuff users need to be find easily when looking for them, Stuff users can find on their own time.
    • Listed in the OrderOfImportanceWebUI. E-mail thread

  • Resolve mock-up size: 800x600 versus 1024x768 Table for now, will work in whatever is most efficient.

Things we decided:

  • We will use 'User name' (as opposed to username, User Name, user id, ID, etc).
  • We're assuming we can have a custom pulldown. _Addendum: We are not going to use custom pulldowns until Matthew has the time to investigate if user's will be able to tab into a custom drop down list. If not we may need to evaluate the importance of getting to the drop down list for power users/accessibility. We'll table this discussion for future—We'll revisit this issue for discussion post preview.

  • We're assuming we're going to have stackable row items in the Dashboard. As a result, were going to keep the sidebar around in both the Dashboard and Calendar views.

End of user interface/interaction.



Dashboard for Casual Collaborators

Updated 5/17/07

  • To learn more and understand the background of the dashboard, please read the overview outlined in the desktop dashboard 0.7 spec.

Requirements

Dashboard (Basic Table):
  • First order of meta data displayed in the five columns: Task(-ness), Who (Combined 'From' & 'To' attributes), Title (Multi-line display), Event start date/time and Triage status.
    • Stamping status: Task versus Non-Task
    • Who: 'From' stacked on top of the 'To'
    • Title: Multi-line display
    • Event start date/time: Properly formatted date column for event start date and event start time
    • Triage status: Now, Later Done
  • When the height of formated table exceeds the height of the browser window, scroll bars will be displayed to allow the user to scroll to view the entire contents of the table.
  • The text color is invert when the row is selected.
  • For the Who and Title columns, there will be a maximum number of characters where the rest of the information is cut off. After the information exceeds the maximum length, an ellipsis character appears last character place to inform the user that there is more information in the 'Who' and 'Title' columns.

Note: Items which have been stamped as a task will not have 'event start time' information. On the desktop there are complex 'important date' calculations for Date column. The date header column is dynamic based on the selected item on the dashboard.

Table Header:

  • The table header for 0.7 will have the Task(-ness), Who (Combined 'From' & 'To' attributes), Title (Multi-line display), Event date and Triage status. The 'sorted' column is selected, it will be highlighted and have a mousedown state.

Sort:

  • When the user first logs in or clicks on the bookmarkable URL, the table will default to triage sorting, with 'NOW' at the top, followed by 'LATER' and 'DONE'. If the user clicks on the 'Triage' header again, the column will sort in reverse order, with 'DONE' at the top, followed by 'LATER' and 'NOW'.

ISSUE:

  • There is currently a discussion on the list about Server Restraints and the Dashboard. This may affect the ability to reverse sort in the header and pagination.
  • Sort may not happen within the full data set, only on the data set returned.

Nice to have: Basic Table:

  • Expand/collapsible triage header 'NOW', 'LATER' and 'DONE'.
  • Ellipsing text that doesn't fit in a column
  • Re-sizeable columns widths.
  • From and To text to have a different text color then the e-mail address(es)in the Who column.
  • Automatically resize column widths so that the horizontal scrollbar never appears
  • Display read/unread items.
  • Keyboard support to navigate up/down the rows and multi-select using the Shift or Cmd/Ctrl keys.

Sort

  • Sorting by 'Event start time' is secondary when sorting by triage view. Within the 'NOW' section, the items will sort by the most recent item by start time located at the top.

Table Headers:

  • Column headers can have either text or an icon displayed. When the user mouse over the text, the column header will have a mouseover state to inform the user you can click on the header. ie. The header text color will turn to the blue link (#6699ff) color.

Other:

  • The ability to add new columns or change the existing ones (user-defined). Not for 0.7 but we should plan for it from an infrastructure perspective.

Difference from the desktop:

Basic Table:

  • Second order of meta data displayed in the columns: Communication status, Important Who, Reminder, Important Date
  • In line editing, including the ability to stamp/unstamp items, and triaging in the table.
  • Complex 'important date' calculations for Date column
  • Communications status column
  • Distinction between items that have been 'Edited / Updated / Sent / Received' in the Communications status column
  • Single smart 'Who' column is replaced by 2 dumb columns, one for From, the other for To
  • Ability to see 'Created by / Edited by / Updated by' in the Who column
  • Reminder / Calendar column

Sorting:

  • 'Event start time' will sort in the most recent date starting at the top. If the user clicks on the 'Event start time' header again, the column will display the last date/time starting at the top.
  • Sorting by the 'Taskness' will sort by 'Address' first, followed by 'Event' and 'Tasks', in the order of the sections in detail view. If the user clicks on the 'Taskness' header again, the column will sort in reverse order, with 'Tasks' first, followed by 'Event' and 'Address'.
  • Sorting by the 'Who' column, where 'From' and 'To' are combined, it will sort alphabetically by the first name in the 'From' field. If the user clicks on the 'Who' header again, the column will sort in reverse alphabetical order.
  • Sorting by 'Title' will sort alphabetically by the first letter of the description field. If the user clicks on the 'Title' header again, the column will sort in reverse alphabetical order.

Other:

  • Search

Quick item entry (not contextual):

  • The quick item entry is a text field located in the center directly above the dashboard. This is the only way users are able to add items to the dashboard. Users are able to type into the field, select 'Add' button and a new note will appear at the top of the dashboard. Whatever the user types into the quick item entry text field, it will be the same as the 'title' field in the Detail View. New item added to the list will automatically have a triage of 'NOW'.
  • If the dashboard is sorted in reverse triage, the 'DONE' section at the top, new items will still appear at the top of the list. Once the user refreshes their browser, it will resort correctly into the correct triage section. Quick item entry only appears in dashboard view, it does not appear in calendar view.

Nice to have: Keyboard support. When the user enters in the title of the note, the user will be able to hit the 'return' or 'enter' key on the keyboard to enter the event onto the dashboard.

Dashboard/Calendar view selector

  • There is a button which selects between the dashboard and calendar view.
  • The dashboard (table view) is the default view when the user logs in or clicks on a bookmarkable URL. So the dashboard button defaults in a mousedown state.

Detail View

Updated 5/18/07

Detail View: Adding an item with an Address, Task and Event stamps

  • To learn more and understand the background of the dashboard, please read the desktop stamping 0.7 spec

  • The detail view is divided into two expanding and collapsing sections for Address and Calendar Event stamps. The task section does not need to expand or collapse for 0.7. The user will be able to click on the header of each section to expand and collapse each section. The check box on the right of each header adds the Address, Task and/or Calendar event stamp to the item. The check box replaces the stamp button on the mark up bar in the desktop. When the check box is unchecked in a section, the form elements within the section grays out to a disabled state. The text color of the header in the section is turns gray when the item is unchecked. The disclosure triangle is still active and the section is still able to expand and collapse. The purpose of this is that the user is aware of what is under each section before the having to check (add a stamp to) the item.

  • When the user first adds and item from the quick item entry field, all the sections are collapsed and unchecked (no stamp are associated to new items). Having each header collapsed helps the user identify there are three currently active sections. When the user expands on a section, another section may fall under the fold. A scroll bar will appear, as a convention of the web/browser to indicate to the user there are items below the fold. The text entered on the quick item entry field will also appear in the 'Title' field once the user has selected the 'Add' button. A 'short' description field is available for the user to add small notes. A disclosure triage is available for the user to expand the description field to a larger area for notes.

  • In the calendar view, when a user creates an item by double clicking on the calendar canvas, the item created defaults to an event item. The event section is expanded in the detail view and the item is checked (stamped as an event ) by default.

Mark up bar:

  • This is a tool bar area above the detail view. On the web UI this will consist of the triage ('NOW', 'LATER' and 'DONE') segmented control, 'e-mail this event' button and the read only icon.
  • By-line: Is a text field which displays information on when an item is create and by whom. On the desktop, this also includes the updates, modification by whom, date and time. On the web UI if a CC user makes a modification to the item in the 'ticket view' (from a bookmarkable URL), the by-line will default 'Anonymous Chandler Hub'. When the desktop user syncs and sees the update, the by-line will read 'Modified by Anonymous Chandler Hub'. A CC also has the option of editing the by-line in the web UI and enter in their name to inform others who are sharing the collection. Although the by-line is located by the 'Remove' and 'Save' buttons, the text should look like it is editable, so it should have a 1px outline similar to the form field in the other stamping sections of the detail view.

Notes:

  • Add nice to have bug: When the user types into the description field, the field will expand as the user types.
  • To scale the detail view for additional sections/stamps added to the item, ie. personal annotations, maps, restaurant reviews etc. This may eventually grow for contributors to add mash-ups' etc.

Difference from the desktop:

  • Address, event and task buttons to add a communication, calendar event and/or task stamp to an item. On the web UI it this is replaced by the checkbox.
  • Expanding/collapsing headers for the address and event section on the web UI.
  • Enabling/disabling each of the address and event sections on the web UI
  • Triage button toggles three times to 'NOW', 'LATER' and 'DONE' on the desktop. On the web UI it is a segmented control to layout all the triage options available.
  • By-line is located at the bottom by the 'remove' and 'save' button disassociating from the address fields on the web UI.
  • There is no display/editable alarms in the Detail view on the web UI.
  • There is no assigned custom date ticklers from the Detail view on the web UI.

  • Reference e-mail thread on the proposal for detail view.


Dashboard: Recurring events

This section will need an update and will link to a master recurring event page outlining the difference between the desktop/web UI.

  • Bug #8778: Cosmo Recurrence Superbug
  • Bug #8584: Support for recurring events on the dashboard.

High level differences between in the dashboard the desktop and the web UI

  • Currently on the desktop a recurring event is displayed in the three triage sections, 'Now', 'Later' and 'Done' of the dashboard. If there is ever a time/edit modification to an instance, the item will appear as a separate line item on the dashboard.
  • On the web UI, the dashboard will not display combined recurrence instances. Only one recurrence will be displayed in the dashboard (Need technical recommendation as to display which instance, see [[#IssueA]['Issue' under 'Proposal A'). A text color change in line item on the table will inform the user of how many items are part of the series and if a modification has been made in the series. Design to create a mock up.
  • In addition to the text color change, an alert bar would also appear and inform the user with a message: 'A change has been made to a recurring event highlighted in orange. You may want to check you [calendar] to view changes.' The [calendar] links switches dashboard to calendar view. The alert bar would then roll up and disappear after a few seconds.

  • The desktop has a fully functional alarm feature. The web UI will only be displaying alarm set by users who have created/modified them in a shared collection.
    • On the web UI, alarms set by the desktop user may still trigger an event to be placed in to the 'Now' section in of the dashboard. This will occur only when web UI refreshes. (See [alarms section]—to be written.)

  • On the desktop, there is an e-mail 'communication' sent directly from the desktop. In the web UI, a 'mail-to:' link/button allows the user to send e-mail out of band from their desktop e-mail client.
    • E-mail populated from the web UI formats differently from e-mail sent through the desktop. See 'Receiving Chandler Items in generic email clients' section of the desktop 0.7 e-mail spec.


High level use cases:

The following is a list of recurrence use cases we plan to support for 0.7 (Preview):

  • A desktop user publishes their collection with recurring events on the server. A Casual Collaborator user shares the collection with the desktop user on the web UI.
  • A users who publishes to the hub and wishes to subscribe to a collection that has recurring events with another calendaring application:
    • Another calendar application; CalDAV, iCal, Sunbird.
    • GCal, Atom | Bug #6991
    • Feed readers
  • A user exports a calendar from web UI that has recurring events:
    • The recurring events may have been created or modified in Chandler.
    • The recurring events could have been created in another client ie: Apple iCal and re-exported.
  • Create a new event on the web UI and specify simple recurrence parameters.
  • Delete a recurring event.
  • Modify a recurring event.
  • Modify the recurrence rule for a recurring event, part-way through the event series.
    • Time modification
    • Text modification; any attribute change other then time.
  • Make exceptions to the recurrence rule.
    • Time modification
    • Text modification; any attribute change other then time.

Proposal A:

(The desired proposal.)

Display in the web UI dashboard

  • The dashboard for preview will display a single instance of a recurrence.
  • If an instance 'detached' from the original series of recurring events, then the item (is a new instance/series) and will be displayed on the dashboard. An instance never fully detaches from a recurrence until all of the attributes are modified for 'Only this event' (instance).
  • Any modifications in the middle of the series would not display on the dashboard. (Was this the a recommendation from cosmo dev team?) Instead, a color change of the text (in the table) would indicate a text/time modification has been made in the middle of a recurring series.
  • In addition to the text color change in the table, an alert bar would also appear and inform the user with a message: 'A change has been made to recurring items highlighted in orange. You may want check your [calendar] to view changes.' The [calendar] links switches dashboard to calendar view. The alert bar would then roll up and disappear after a few seconds.
  • Items created in the dashboard is a 'note' (no stamp information). Items created in the calendar is an event, default with an 'event stamp'.

Nice to have:

  • Recommendation: As soon as any attribute is modified for just this event. The line item will display on the dashboard.
  • If there is a time and/or text modification in the instance, it will display on the dashboard as a separate line item. This way the user is aware of the text/time modifications of an instance in the middle of the series.
  • An icon located in the line item of the recurring event item on the table would also inform the user of a test/time modification to the item.

ISSUE:

  • If we display just the master event as the single instance, as time passes, the master instance will never appear in the 'Now' section but always in 'Later' or 'Done'. Our recommendation is to either display the current occurrence if there is one. If there isn't, then display the next occurrence. In other words, the recurring event would either always be NOW or LATER. Unless all occurrences happened in the past, in which case the last occurrence would display with a triage status of DONE.

Questions: I would like to hear a technical recommendations as to which instance is best displayed on the dashboard in which the user could see it in the 'Now' section of the triage status.


Creating recurring events from the web UI.

Creating a new event with recurrence information from the dashboard

Only items which are added to the calendar by using the 'event stamp' have recurrence information.

  1. From the dashboard view, the user creates a new note in the 'quick entry box'. | Bug #8473: Create a new event: quick item entry box
  2. A new line item is displayed in the 'Now' section at the top of the table. This item defaults to a note. The item does not have a 'communication', 'task' or 'event' stamp.
  3. User adds the item to the calendar by using the 'event stamp'.
  4. The event stamp attributes appear; the form elements for the by-line, title, location, recurrence, time zone, alarm (display only) and description.
  5. Make the event recurring (select from the 'Occurs' drop down list).

Adding an address to a recurring event item using the 'communication stamp'

  1. An event item with recurrence information has been created using the 'event' stamp.
  2. Add an address by using the 'communication' stamp to the event item.
  3. On the detail view: the by-line (creation date) moves down dynamically. The 'From, To, CC, Bcc, Send as' form fields appears above the by-line in the detail view.
  4. The user continues to fill out the form fields and then selects 'Save'.
  5. A recurrence dialog pops up allowing the user to choose between 'All events', 'Only this event' or 'Cancel' Currently on the desktop. Verify w/ Mimi again.
  6. User clicks on the 'Email this item' button which will launch the user's desktop application to send the item out of band.
  7. The e-mail will display:
  • subject line: {name of the collection} | {recurrence information}{stamp (kind) information} change from Chandler Hub: {title of the item}.
  • body of the e-mail specific to stamping and recurring events include: {Stamp (kind) information}, {Recurrence information}, {Date information}. A seperate line item will appear if the event is an 'All day event'.

  • Note: There is a | (pipe) in the subject line between the {collection name} and the {recurrence information}.

Example of a recurring event in an e-mail using the 'communication' stamp:

To: cosmo-dev@osafoundation.org
CC: otis@osafoundation.org
Bcc: sassy@osafoundation.org
Subject:
{Cosmo} | {recurring}{event} change from Chandler Hub: {Cosmo Weekly Meeting}
Title: Cosmo Weekly Meeting
Location: Gotham conference room, 4th floor
Time zone: America/Los_Angeles
Starts: {05/17/2007 at 03:00PM}
Ends: {05/17/2007 at 04:00PM}
{This is an all day event.}
This {recurring event} occurs {biweekly} {ending on 01/01/2010 at 12:00PM}.
Description: Otis will add a few agenda items for the meeting this week.

  • Data within the {x} are information from the detail view.

Note:

  • Currently on the desktop, when you e-mail a recurring series it will e-mail the entire series and not allow options for the user.
  • There is currently no affordance to send the item as an e-mail through the web UI. Currently this is done out of band by clicking on the 'E-mail this event' link/icon, which launches the user's desktop e-mail client. An new e-mail from the desktop client will appear, subject line and body will appear pre-populated with the information from the detail view. See 0.6 spec for a more information.
  • When you remove the stamp information (kind) from an item, all the recurrence data is preserved. In other words, an item which once had recurrence information will preserve the recurrence information when re-stamped as a an event item again. This is to help users who might have unstamped items accidentally and not have to re-enter all the recurrence the information again. | Bug #8798 on the desktop.

Nice to have: Natural language parsing. When the user enters in a line item with dates, the item defaults to an event item with the 'event stamp' opposed to always defaulting to a note (with no stamp (kind) information).

Adding a recurring event item to the task list with the 'Communication' and 'Task' stamps.

  1. An event item with recurrence information has been created using the 'event' stamp.
  2. Add an address by using the 'communication' stamp to the event item.
  3. On the detail view, the by-line (creation date) moves down dynamically. The 'From, To, CC, Bcc, Send as' form fields appears above the by-line in the detail view.
  4. Add event item to task list by using the 'task' stamp.
  5. The user selects 'Save'.
  6. A recurrence dialog pops up only allowing the user to add a task to 'All events', 'All future events', 'Only this event' or 'Cancel'
  7. User clicks on the 'Email this item' button which will launch the user's desktop application to send the item out of band.
  8. The e-mail will display:
    • subject line: {name of the collection} | {recurrence information}{stamp (kind) information} change from Chandler Hub: {title of the item}.
    • body of the e-mail specific to stamping and recurring events include: {Stamp (kind) information}, {Recurrence information}, {Date information}. A seperate line item will appear if the event is an 'All day event'.

Adding a recurring event to the task list using the 'task' stamp

  1. An event item with recurrence information has been created using the 'event' stamp.
  2. Add event item to task list by using the 'task' stamp.
  3. The user selects 'Save'.
  4. A recurrence dialog pops up only allowing the user to add a task to 'All events', 'All future event', 'Only this event' or 'Cancel'
  5. User clicks on the 'Email this item' button which will launch the user's desktop application to send the item out of band.
  6. The e-mail will display:
    • subject line: {name of the collection} | {recurrence information}{stamp (kind) information} change from Chandler Hub: {title of the item}.
    • body of the e-mail specific to stamping and recurring events include: {Stamp (kind) information}, {Recurrence information}, {Date information}. A seperate line item will appear if the event is an 'All day event'.

Example of a recurring event & task in an e-mail:

To: cosmo-dev@osafoundation.org
CC: otis@osafoundation.org
Bcc: sassy@osafoundation.org
Subject:
{Cosmo} | {recurring} {event} change on Chandler Hub: {Cosmo Weekly Meeting} 
Title: Cosmo Weekly Meeting
Location: Gotham conference room, 4th floor
Time zone: America/Los_Angeles
Starts: {05/17/2007 at 03:00PM}
Ends: {05/17/2007 at 04:00PM}
{This is an all day event.}
This {recurring scheduled task} occurs {biweekly} {ending on 01/01/2010 at 12:00PM}.
Description: Otis will add a few agenda items for the meeting this week.

ISSUE:

  • This differs currently on the desktop when you send an item using the 'communication' stamp, and receive items in a generic e-mail client: {Sender's name} sent you a {kind combination} from Chandler on {Date sent}:

Questions:

  1. Would there be a need to have the sender's name if the information of the item is sent through e-mail from the user's e-mail client?

Since all items which have recurrence information are calendar events, in the subject line, the {recurrence information} and {event} data will be present on all the examples listed. For example: {collection name}: {recurring} {event} change on Chandler Hub {Cosmo weekly meeting}. If the item is not an event, the data 'event' will be removed and replaced with either 'message' or 'task' in the subject line of the e-mail. In addition, the {recurrence information} would also not appear if the item is not an event.

The following are possible combinations of stamp (kind) information on the desktop:

  • Message (Only use Message if there are no other stamps.)
  • Task
  • Event
  • Recurring Event
  • All-day Event
  • Recurring all-day event
  • Scheduled task (Task + Event)
  • Recurring scheduled task
  • In the case of 'Recurring all-day scheduled task', remove 'all day'; instead display 'Recurring scheduled task' in the subject line.
    • In the body of the e-mail, add the 'This is an all day event' as a separate line item. (This is current to the 0.6 web UI)

There are only 3 that apply to 'recurring events'.

  • Recurring event (includes Recurring @time events and Recurring anytime events)
  • Recurring all-day event
  • Recurring scheduled task

More information on stamping is located on the desktop 0.7 e-mail spec (Search: Receiving Chandler Items in generic email clients).


Simple modifications to the beginning, middle and end of a recurring event series.

  Text Modification (attribute change other then time) Time Modification
Beginning of a recurring event series 'All events', 'Only this event' or 'Cancel' 'All events', 'Only this event' or 'Cancel'
Middle of a recurring event series 'All events', 'All future' and 'Only this event' or 'Cancel' 'All events', 'All future' and 'Only this event' or 'Cancel'
End of a recurring event series 'All events', 'Only this event' or 'Cancel' 'All events', 'Only this event' or 'Cancel'

Note:

Complex modifications to the middle of a recurring event series.

Time modification on a single instance and then a text modification to all event items in a recurring series. Per attribute inheritance.

Use case example:

  1. Carl the coordinator creates a recurring event series in from the detail view from Monday to Friday 9AM to 10AM. User selects 'Save'.
  2. At some point later, Bob makes a time modification Tuesday event from 10AM to 11AM, in the calendar view.
  3. A recurrence dialog will appear with the following options: 'All events', 'All future events', 'Only this event' or 'Cancel'
  4. Bob selects 'Only this event'.
  5. The dashboard displays the Tuesday event separatly from the recurring event series.
  6. He then goes back and makes a text edit in the title of the first event from the dashboard view.
  7. A recurrence dialog will appear with the following options: 'All events' 'Only this event' or 'Cancel'
  8. Bob selects 'All events'.
  9. All of the events in the recurring event series, including the Tuesday event will accept the new text modification.
  10. Bob then selects the Monday instance and make a time modification and apply to 'All events'.
  11. All events except the Tuesday event, accept the new time modification.

Complex modification: Reordering instances in a recurrence.

When the user rearranges or attempts to reorder the instance before the previous or after the next instance in a recurring event series. For example, in a daily recurrence a user might try to move Wednesday back one day to Tuesday. In this case, the recurrence dialog will appear and only allow the following, 'Only this event' or 'Cancel'.

Use case example

  1. Carol the coordinator creates a recurring event series from the detail view from Monday 4/2/2007 to Friday 4/6/2007, 9AM to 10AM. User selects 'Save'.
  2. She modifies the date on the last instance. Changing 4/6/2007 to 4/5/2007.
  3. A recurrence dialog appear with the following options: 'Only this event' or 'Cancel'*
  4. Carol selects 'Only this event'.
  5. She decides to make a text change in the beginning of the recurring event series.
  6. A recurrence dialog will appear with the following options: 'All events' 'Only this event' or 'Cancel'
  7. Carol selects 'All events'.
  8. All of the events in the recurring event series will update the new text modification.

Complex modification per attribute basis.

  1. Helen the hub make a recurring event series in a collection and shares it with Charles the coordinator.
  2. Charles views the recurrence information on the dashboard.
  3. Helen makes a time modification to the attribute 'start time' of one instance in the middle of the series.
  4. She select 'Only this event' from the recurring dialog box. For this use case, this instance is called 'Tuesday'.
  5. Helen syncs her collection.
  6. Charles refreshes his browser and will notice a modification made in the recurring event item listed on the dashboard. The text of the line item is orange and the alert bar displays a message that 'A modification has been made to a recurring event. Go to the [calendar] view to see changes.
  7. He changes his view to the 'calendar view', by clicking on [calendar] in the alert bar.
  8. Charles makes a text modification to the title on another instance in the recurring event series.
  9. He selects 'All events' from the recurring dialog box.
  10. All items including the 'Tuesday' instance are changed.
  11. If Charles then modifies the attribute 'start time' of any instance in the series except the 'Tuesday' instance.
  12. Then selects 'All events' from the recurrence dialog box.
  13. All items except 'Tuesday' are modified.
  14. Helen syncs her collection and sees the modifications Charles has made.
  15. Helen modifies the title attribute of the 'Tuesday' instance.
  16. She selects 'All events' from the recurrence dialog box.
  17. All events including the 'Tuesday' instances are modified.

ISSUE: | Bug #8787: Don't split recurring event series when making a 'all future' edit in the middle of a series

  • Text edits differ from time edits. When the user makes a time edit on an event in the middle of the series, if the user selects 'All future events' it should not be 'detached' from the recurring series. The user then makes a text edit in the middle of the series, the 'All events', 'All future events' and 'Only this event' or 'Cancel' button will appear in the recurrence dialog box.
  • If the user makes a text edit at the beginning or in the end of a recurring event series, only the 'All events' 'Only this event' or 'Cancel' will appear in the recurrence dialog box. Bug#8056 on the desktop.


Triage with recurring events

  • When a user creates a new recurring event item on the dashboard it will triage into the 'Now' section.
  • When a user make a time modification on a recurring event and selects 'Only this event', the item would separate from the recurring event series and be displayed as a new line item on the dashboard.
  • If a recurring event item has alarm information and the alarm goes off, when the user refreshes the browser, the item will appear in the 'Now' section of the dashboard.

One to one mapping of recurrence items on the calendar/dashboard views:

State Calendar View Dashboard View
Simple daily recurrence

Simple weekly recurrence

One event change w/in the series

  • Currently there are two kinds of auto triage on the desktop. Items which are triage from the time/day it is. The second is from alarms which go off and move into the 'Now' triage section of the dashboard.

Proposal B

(Simplified proposal.)

This proposal is to help stage the work load for development if it makes sense from the technical point of view. If not then then this section can be disregarded.

The first goal is to be able to display the recurring events in the dashboard. Whether the CC user is able to stamp/un-stamp a shared event item may be secondary for Preview.

  • In this proposal, the stamping icons (mark up bar) would be display only on the web UI. The CC would would be able to view if an item has been sent as message, put on a task list and put on the calendar by the desktop user using the 'communication', 'task' or 'calendar event' stamp. A CC would still have the ability to edit other attributes in the detail view in addition to triaging the item on the dashboard. The CC will just not be able to modify an item type.
  • The ability for the CC user to make edits to the item by using the 'communication', 'task' or 'calendar event' stamp would not be functional by preview.
  • This is a fall back proposal if 'Proposal A' is becomes complicated and not going to meet the preview deadline.
  • Not all workflows have been outlined in proposal B, so there may still need more UI attention if the ability of stamp/unstamp is not functional by preview.

Use case for Proposal B

  • Helen the hub creates and shares a collection with Carmen the coordinator.
  • Helen has a task list of items for Carmen to do before their big meeting on Thursday.
  • As the week goes by from Monday to Wednesday, Carmen will check the shared collection on the web UI and check off the task list items from 'Now' to 'Done' on the dashboard.
  • Helen never has to remind Carmen via e-mail or other means as she can view Carmen's progress in her shared collection on the desktop.

Use case NOT satisfied in proposal B:

  • Helen the hub creates and shares a collection with Carmen the coordinator.
  • Helen has a task list of items for Carmen to do before their big meeting on Thursday.
  • Carmen will be able to change some of the task items into an event item.
  • Helen never has to remind Carmen via e-mail or other means as she can view Carmen's progress in her shared collection on the desktop.

End of recurring events section. Last updated: -- PriscillaChung - 14 Apr 2007



Resolving Time Zone in Ticket View Issues

This section is currently in progress 5/21/07.

Current workflow: ResolvingTimezoneInTicketView

UI Workflow:

  1. Desktop user shares a collection with time zone information.
  2. CC user receives a bookmarkable URL. User clicks on the URL. Chandler hub appears in the browser in 'ticket view'.
  3. The web UI displays the time zone picker default to 'Select a time zone…'. If there is no time zone information or if the time zone information is floating time, then the time zone picker would not appear in the web UI.
  4. The CC user decides to add the collection to their account.
  5. User logs in, the collection is added to their account.
  6. The account already has a time zone from when the user sign up for an account. The added collection will display according to the account holder's time zone.
  7. If the user has turned time zone off, then an alert bar will appear 'The {COLLECTION NAME} has time zone information. Turn on time zone support to view events correctly. [ √ ] Never show again. [Ignore] [Okay]'

ISSUES:

  • Javascript can't access the time zone info of the host per se, it can only get the current off set, which lets you GUESS the time-zone. —meaning the time zone displayed is the local system/browser time zone, but it cannot be saved or interpreted as the names listed in the time zone picker. See Bug#6195
  • When creating a new account on the hub, users are required to select a time zone. Would there be any issues in forcing users to select a time zone? This will eliminate the alert bar to appear for most of the users, unless the user specifically turned time zone off. Note: Requiring users to pick a time zone when signing up for a new account is currently Yahoo/GCal.
    • This will mean an update to the sign up workflow where currently it's optional.

  • Will the user still need to be prompted with an alert bar to inform that the collection has time zone information in ticket view?
  • Will having the time zone picker set to 'Select a time zone…' enough for users to realize there is time zone information with the current collection?

We may just defer the alert bar and see if we have any feedback from users if there is not enough visual cue to turn on time zone in the ticket view—otherwise we can display an alert bar post preview if necessary.

Note: Location of the time zone picker is not updated. See User Interface/Interaction Design for the latest revision to the header.

Time zone workflow:

  • Workflow is mostly correct. Note these are older mock ups and the location of the time zone picker, detail view, details on the new style guide colors etc. are out of date.

End of time zone section.



Sign up workflow

Updated 5/29/07 This is just an update to the sign up work flow to incorporate the time zone requirements.

Not final, need to follow up with update on the mock ups

  1. User types in hub.chandlerproject.org
  2. User is taken to Login page
  3. User signs up for an account, ' Click here to create one.'
  4. A sign up dialog appears for the user to sign up for a new account
  5. User fills out the fields in Sign up dialog incorrectly
  6. Error messages appear in the sign up dialog
  7. User submits their information. User needs to verify their e-mail account.
  8. User checks their e-mail to activate hub account.
  9. User clicks on URL in account activation email to activate account
  10. User is taken to a gateway page; e-mail is confirmed. User can either enter the web UI or select from the drop down list the calendar application they are using to publish their calendar information. See gate way page proposal Updated 5/29/07
  11. User clicks on 'Start using Chandler Hub'. User is taken to their hub new account.

Note: A user can also Sign up for an account from the Sign up dialog off of a Ticket View

If the user signs up for a new account off of a 'ticket view':

  1. User is currently viewing ticket view.
  2. User click on 'Sign up'
  3. A sign up dialog appears for the user to sign up for a new account. At the bottom of the dialog, '[√] I'd like to subscribe to this collection once I create my account. (default to: checkbox is checked) Bug #8720:
  4. User submits their information. User needs to verify their e-mail account.
  5. User checks their e-mail to activate hub account.
  6. User clicks on URL in account activation email to activate account
  7. User is taken to a gateway page; e-mail is confirmed. User can either enter the web UI or select from the drop down list the calendar application they are using to publish their calendar information. See gate way page proposal?
  8. User enters the web UI, default to the last collection they were viewing in from 'ticket view'.

Dogfood Feedback:

When a Chandler Desktop user unpublish (or delete) a collection while the Chandler Hub user is viewing the deleted collection (logged in).

  • Bug #8722:

Collection delete states

States Logged into account Bookmarkable URL (ticket) view
Collection is deleted during the user's session
  1. User refreshes the browser, select from another collection from the pull down list, or creates any events and clicks 'Save'
  2. Error message appears in a dialog box: 'This collection has been deleted and is no longer available. Please check back with the person who originally published the collection.' [Okay]
  3. Redirect user to next valid collection. (out of the box (OTB) collection dashboard view)
  1. User refreshes the browser, select from another collection from the pull down list, or creates any events and clicks 'Save'
  2. Error message appears in a dialog box: 'This collection has been deleted and is no longer available. Please check back with the person who originally published the collection.' [Okay]
  3. Redirect to landing page 'chandlerproject.org' (Landing page URL?)
Collection is deleted before user views the session
  1. User logs in to account.
  2. Default view, OTB collection dashboard view. Error message displays in a dialog box: 'The [NAME OF COLLECTION] collection has been deleted and is no longer available. Please check back with the person who originally published the collection.' [Okay]
  3. User clicks [Okay]. Default view, OTB dashboard. If the user clicks on the pull down list in the left nav, the deleted collection is no longer in the list.
  1. User clicks on bookmarkable URL from e-mail.
  2. Error message displays on web page: 'This collection has been deleted and is no longer available. Please check back with the person who originally published the collection.' [Okay]
  3. Redirects user to landing page 'chandlerproject.org' (Landing page URL?)


Consistent Language on the Hub and Desktop

We've started to compile a list of error message and terminology which we'd like to keep consistent on the hub and on the desktop: ConsistentLanguageHubDesktop



Technical Design

This section must be completed by the developer. Schematic of any kind (class hierarchy, object relationship) is welcome.

QA/Test Scenarios (Chandler Hub/Server)

Overview

Chandler Server 0.7 is primarily work to build out the minimal set of features for the dashboard. In addition, we'll also be incorporating dogfood feedback from users currently using Chandler Hub. The project will be reviewed in terms of how it handles performance, stability, and features that prevent some users from dogfooding Chandler Hub. The examples listed are detailed specific for QA to use as test cases.

In addition to the 0.6.1 test scenarios, users for 0.7 test scenarios will be able to:

Chandler to Chandler Desktop sharing

  1. Helen the Hub creates a work calendar in Chandler Desktop.
  2. Helen publishes this collection on Chandler Hub.
  3. She sends Henry (Hub, also a desktop user) her read-write bookmarkable URL (of her work collection) from Chandler Desktop.
  4. Henry manages his calendar+task information (PIM) on Chandler Desktop. When he receives Helen's e-mail, copy and paste the URL from the e-mail to Chandler desktop, under the Share menu/Subscribe field.
  5. Helen's work collection should appear in Henry's list on the left side bar of Chandler Desktop.
  6. When Helen makes an update to her work calendar and Chandler Desktop syncs, Henry will also see the changes in Chandler Desktop when it auto syncs.

Subscribing to a collection by signing up for a new Chandler Hub account

  1. Ivan the Individual Contributor receives a read-only bookmarkable from Helen the Hub.
  2. From his desktop e-mail client, Ivan clicks on the URL and opens a new tab/window from his browser.
  3. Ivan sees Helen's work calendar and clicks on the 'Sign up for an account' button/graphic.
  4. A 'Create an account' dialog pops up to enter in the user's account information. In the dialog, at the bottom, is a check box that says: [ √ ] I'd like to subscribe to this collection once I create my account. (default to: checkbox is checked)
  5. Once the information is entered, an e-mail is sent to his account to verify his account.
  6. Ivan goes into his e-mail client and clicks on the URL to verify his e-mail account is active.
  7. A new tab/window in the browser opens and displays the log in page.
  8. Ivan logs into his new Chandler Hub account, default to Helen's collection.

View/Edit collections without an account. Review particular Items on a list.

  1. Helen the Hub coordinates with her book club group about bringing food for a meeting.
  2. She sends out a read-write bookmarkable URL from Chandler Desktop to the book club members.
  3. Each book club member (CC users) clicks on the URL from their e-mail client, A new tab/window opens to Chandler Hub in the dashboard view.
  4. Each book club member is asked to add to the list of what what food items they are planning to bring.
  5. Book club members are able to do so without a Chandler Hub account.
  6. The day of the meeting, Helen reviews the list to see how many people are coming and write up a list of other preparations she might need to do or have people bring to the meeting.

Add an Event to a Collection: Edit Title, Location, Date/time, Notes field. Send e-mail out of band to confirm modification on the collection.

  1. Helen the Hub sends Ira the Individual Contributor her read-write bookmarkable URL to have him schedule a meeting with her.
  2. Bart is currently logged into Chandler Hub.
  3. Ira clicks on the URL from his desktop e-mail and launches Chandler Hub. The default view is Helen's dashboard with a bunch of items in it.
  4. Ira clicks on the calendar view button (from the view selector) and is able to see Helen's work week displayed in calendar view. This is visually easier for him to find an empty spot on the calendar.
  5. He is able to add an event, enters the title, location, date/time & notes field.
  6. He clicks on the 'E-mail this event' link and an e-mail is pre-populated with the name of the collection name and the title of the event in the subject field. In the body of the e-mail the title, time zone information, starts and end time, type of event, and recurrence information is pre-populated.
  7. Ira is also able to modify/add a personal comment to the e-mail before he sends it back to Helen to notify her that he's added his event to her collection.

Add an Event to a Collection: Edit Title, Location, Date/time, Notes field. Send e-mail out of band to confirm modification on the collection. While CC user has an account and is in session on Chandler Hub

  1. Helen the Hub sends Bart the Busybody/Coordinator her read-write bookmarkable URL to have him schedule a meeting with her.
  2. Bart changes his view from Chandler Hub to view his e-mail client.
  3. Bart clicks on the bookmarkable URL. A new tab/window opens on the browser.
  4. Helen's work collection is viewed on the browser default to dashboard view.
  5. Bart is currently logged into Chandler Hub. Bart clicks on the '+' to 'Add to [name of collection] to my Chandler Account'.
  6. Dashboard view refreshes, default to Helen's work collection in the left pull down list. A message at the top of the alert message bar (yellow bar at the top) 'The [name of collection] collection has been added to your account.

Note: If Bart clicks back to the previous window of Chandler Hub (before he clicked on the bookmarkable URL) the collection will still be in the old state before adding the new collection. If he refreshed the browser or creates a new event and clicks 'Save', the browser will then refresh to the new state of his account and the alert message bar will appear with the message: 'The [name of collection] collection has been added to your account.

Currently in 0.6.1, the CC would need to enter in the ID/PW when clicking on the 'Add [collection name] to account'. In this workflow, we are eliminating the sign in step if the user is already logged into the account and is in session.

Browse collections: To switch between calendar and dashboard views with/without an account.

  1. Helen the Hub manages a collection for her daughter's dance recitals.
  2. She writes up the dates of her daughters dance recitals for the year and sends out the bookmarkable URL to her family from Chandler Desktop.
  3. She coordinates with her husband Bob the busybody/coordinator who is bringing the costumes/tutus for their daughters and also going to pick up and bring the in-laws to the dance recital.
  4. The day of the recital, Helen is unreachable at work. Bob clicks on the bookmarkable URL to Chandler Hub. The view defaults to the dashboard, he selects the calendar view from the view selector to double check if he has the date/time right. He switches back to the dashboard view and checks to see if he is tasked to bring the costumes or to pick up the in-laws this time.

Edit collections: To change triage status from the dashboard with/without and account. (This is similar checking off items from a shared task list.)

  1. Helen the Hub plans a holiday to London with her husband Bob.
  2. She creates a packing list of who is responsible for taking care of specific errands before they leave.
  3. Bob is at work and receives an e-mail from Helen. He clicks on a link to view the read-write collection list Helen created on Chandler Hub.
  4. As the travel dates grow closer, the items which were once marked as 'LATER' are now marked as 'NOW' when Bob logs into his account.
  5. Bob goes through his list of errands to do before the trip and checks items off as 'DONE' once he completes his tasks.
  6. He also bought tickets to HayFever at the Haymarket Theater Royal. He enters the item using the quick item entry field and selects enter.
  7. He checks the checkbox in the calendar event section in the detail view to add an event stamp to the item. The item is now also placed on the calendar view.

Edit collections: Add a 'Task' to a collection: Edit Title, Notes field. Send e-mail out of band to confirm modification on the collection.

  1. Helen the Hub sends Bart the Busybody/Coordinator her read-write bookmarkable URL to a work collection named 'SMASH 06'
  2. Bart receives an e-mail in his desktop e-mail application and clicks on the bookmarkable URL.
  3. Bart and Helen coordinate on an appropriate date and time in calendar view.
  4. Bart is also able to switch to dashboard view to review the list and see which items he is tasked to bring to the 'SMASH 06' meeting, ie. projector, tape recorders, large pads of paper, markers, etc. He may add some more additional items to the list and task Helen to bring them to the meeting.
  5. Bart will enter the items using the quick item entry, selects return to have them the appear on the dashboard.
  6. The items on the dashboard will appear at the top of the list.
  7. Each item Bart enters on the dashboard, he will also check the checkbox in the Task section of the detail view to stamp the item as a task.

When a Chandler Desktop user unpublishes (or deletes) a collection while the Chandler Hub user is viewing the deleted collection (logged in).

  1. Bart has kept his browser open to Chandler Hub.
  2. He is currently viewing Helen's old collection, 'SMASH 06'.
  3. Helen the Hub deletes 'SMASH 06' from Chandler Desktop. She sends e-mail to notify users sharing the collection to update to her new 'SMASH 07' collection.
  4. When he refreshes his browser, select from another collection back to 'SMASH 06', creates any events (on the dashboard or calendar) and clicks 'Save'—An an error message will appear in a dialog box, calendar background is faded to 50% grey, error message: This collection has been deleted and is no longer available.' [Okay]
  5. The calendar defaults back to the out of the box dashboard view. (Or next valid collection)

Note: See state map listed in 0.7 specification for other test scenarios.

  1. If Bart is viewing a bookmarkable URL, the calendar will default to the error message: 'This collection has been deleted and is no longer available. Please check back with the person who originally published the collection. [Okay]'
  2. Redirect to landing page: 'cosmo.osafoundation.org'

  1. If Bart goes back to his e-mail and click on the bookmarkable URL, it will launch an error message page same as above: 'This collection has been deleted and is no longer available. Please check back with the person who originally published the collection. [Okay]'
  2. Redirect to landing page: 'cosmo.osafoundation.org'

All users with an account will always have an out of the box Chandler Hub collection, so even if a collection is deleted, there will always be one calendar collection in the pull down list in the left navigation. Bug#8722

Subscribing to the same collection (renamed collection)

  1. Helen the Hub sends out her bookmarkable URL to Iris the Individual Contributor.
  2. Iris already has an account on Chandler Hub. She clicks on Helen's bookmarkable URL and adds it to her account.
  3. Iris forgot she had already subscribed to this collection and had changed Helen's collection name from 'Work' to 'Helen's work' (display name) collection.
  4. When she logs into her account, an alert message bar will display at the top (in the yellow background). 'You have already subscribed to this collection. [Okay]'
  5. The message will also automatically disappear (roll up) after a few seconds.
  6. The collection should default to 'Helen's work' (the display name) renamed by Iris.

Note: If Iris did not rename the collection, when she clicks on subscribe [name of collection] collection to this account, it will still take her into Helen's collection after logging in and an alert message bar will also appear at the top (in a yellow background): 'You have already subscribed to this collection. [Okay]'. The message will also automatically disappear (roll up) after a few seconds.

Chandler Desktop users may set time zone information on a collection and Chandler Hub users are notified that the collection has time zone information.

  1. Helen the Hub is located in San Francisco and has sent her read-write bookmarkable URL from Chandler Desktop to Iris the Individual Contributor in New York.
  2. Helen currently has her time zone turned on to PST.
  3. When Iris receives Helen's e-mail, she will click on the URL and notice that the calendar she is viewing is set to PST in the time zone drop down.
  4. Iris has an account on Chandler Hub and decides to subscribe to Helen's collection.
  5. Iris clicks on the '+' add collection to her account. She logs into her account without time zones turned on.
  6. An alert message bar will appear (in the yellow background) at the top of the application to inform Iris that she is does not have time zones turned on. The message will read: "The 'Helen's work' collection contains time zone information. Turn on time zone information to view events and alarms correctly. [Ignore] | [Okay]"

Subscribe to Collection/Item via Atom feed (Will Atom be implemented by 0.7?)

  1. Brian receives Ted's read-write bookmarkable URL in his Google Mail (GMail).
  2. Brian would like to be able to view his calendar in his Google Calendar (GCal).
  3. He clicks on the URL and is directed to Chandler Hub.
  4. He selects 'and 'Other' from the 'Subscribe with…' pull down menu.
  5. A dialog box appears, defaulted to 'Other' in the pull down menu. He copies/pastes the Atom URL into the 'Add another calendar' section in GCal.
  6. Ted's collection appears as one of the calendars visible in Brian's GCal.
  7. When Ted updates and syncs his calendar information from Chandler Desktop, Brian's GCal will also be updated.

Adding a recurring event in Chandler Hub (test with both log on and with the bookmarkable URL)

  1. Helen the Hub sends out her work collection to Bart the Busybody/Coordinator
  2. Bart checks his e-mail and clicks on the bookmarkable URL
  3. Bart creates a couple of meetings, one bi-weekly meeting on Thursdays at 2PM. A weekly meeting on Tuesday at 10AM. A monthly meeting on Monday morning at 11AM.
  4. On the third Thursday the month, the Thursday meeting at 2PM would need to change the title/description of the event and to change the time from 2PM to 10AM.
  5. Helen deletes one event (only the first Tuesday meeting in April).

Performance testing

Here is a list of the most common use cases for users.

  1. Once a user clicks on a bookmarkable URL, how long will it take for Chandler Hub to display? Test w/ Office Calendar
  2. Once a user clicks on a bookmarkable URL, how long will it take for Chandler Hub to display? Test w/ a desktop user's calendar (either Katie, Sheila, Ted etc.)
  3. CC user bookmarks the URL sent from Hub user. Closes Chandler Hub window. CC user goes back to bookmarkable URL by clicking on the bookmark in the browser.
  4. Ticket view: Create a new item in the quick item entry box in the dashboard view
  5. Ticket view: Simple edit to an item on the detail view in the dashboard view
  6. User types 'hub.chandlerproject.org' in the address bar on the web browser
  7. Log in to Chandler Hub once user puts in their ID/PW and clicks 'Login'
  8. Switch from dashboard view to calendar view
  9. Double click to enter an event. Fill out detail view and 'Save'.
  10. Calendar view, user clicks forward two weeks forward and one week back.
  11. Sign up for an account—e-mail verification, user clicks on the e-mail link and check the performance on how long it takes for the browser to load Chandler Hub.
  12. Desktop user makes a change on a shared collection. Refresh the browser to view modification on the collection on Chandler Hub.
  13. In the calendar view, user 'jumps to date' 6 months from today on the 'Office Calendar' collection. Then test again with a desktop user's calendar collection.

Question: Shall we test scenarios where a group of users are hitting the server at the same time?

  1. A group of ppl publishing at the same time.
  2. A group of ppl subscribing to the same collection at the same time? ie. Office calendar
  3. Two people, a desktop user and a hub user modifying an event at the same time between the desktop, web UI and one other calendaring software.

API / Developer Platform

If relevant, how the feature will be made accessible to coders?

Security

Aspects of the design dealing with potential security issues.

Internationalization / Localization

Things to keep in mind for Internationalization. Caveats known at design time.

Accessibility

UI must be accessible (Section 508).

Build / Install

New info that coders need to know introduced by that feature. List here known dependencies in particular.


Changes

Author Edit date Description
Priscilla Chung 5/29/2007 Added/updated sign up workflow.
Priscilla Chung 5/21/2007 Added/updating time zone section.
Priscilla Chung 5/17/2007 Added/updating detail view section.
Priscilla Chung 5/17/2007 Expanded on the Dashboard CC section. Update QA performance test list.
Priscilla Chung 5/10/2007 Update mock up. Reworking the header area.
Priscilla Chung 5/3/2007 Update mock up. Proposal for detail view.
Priscilla Chung 4/25/2007 Updated mock up. Current design of the dashboard. Addressing list of design open issues to the mock up.
Priscilla Chung 4/14/2007 Added recurrence on the dashboard section.
Priscilla Chung 4/9/2007 Added QA test case scenarios/workflows.
Added performance test scenarios/workflows.
Priscilla Chung 4/2/2007 Updated mock up. Listed out design open issues.
Priscilla Chung 3/30/2007 First draft

toggleopenShow attachmentstogglecloseHide attachments
Topic attachments
I Attachment Action Size Datedown Who Comment
pngpng simpleDailyRecCV.png manage 60.0 K 16 Apr 2007 - 12:20 PriscillaChung simpleDailyRecCV
pngpng simpleDailyRecDV.png manage 65.3 K 16 Apr 2007 - 12:20 PriscillaChung simpleDailyRecDV
pngpng oneEventChangeCV.png manage 59.3 K 16 Apr 2007 - 12:21 PriscillaChung oneEventChangeCV
pngpng oneEventChangeDV.png manage 70.4 K 16 Apr 2007 - 12:21 PriscillaChung oneEventChangeDV
pngpng simpleWeeklyRecCV.png manage 53.4 K 16 Apr 2007 - 12:22 PriscillaChung simpleWeeklyRecCV
pngpng simpleWeeklyRecDV.png manage 56.2 K 16 Apr 2007 - 12:22 PriscillaChung simpleWeeklyRecDV
pngpng cosmoDB.png manage 179.9 K 23 Apr 2007 - 05:05 PriscillaChung cosmo dashboard w/ left nav
pngpng Cosmo_Preview_Styleguide_DV_Top.png manage 161.0 K 12 May 2007 - 11:18 PriscillaChung Cosmo_Preview_Styleguide_DV_Top
pngpng headerRedesignCVNLI.png manage 163.1 K 12 May 2007 - 11:20 PriscillaChung ticket view, switch to calendar
pngpng headerRedesignDBNLI.png manage 134.4 K 12 May 2007 - 11:21 PriscillaChung Logged In view, default to dashboard
pngpng headerRedesignCVLogIn.png manage 161.9 K 12 May 2007 - 11:22 PriscillaChung Logged In view, switch to calendar view
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r67 < r66 < r65 < r64 < r63 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.