r9 - 16 Apr 2007 - 12:06:56 - PriscillaChungYou are here: OSAF >  Journal Web  >  ContributorNotes > PriscillaChungNotes > CosmoDashboardRecurrence

Draft: Cosmo Dashboard Recurrence

in progress

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


Open Issues for Tuesday:
  1. Proposal B, the simplified proposal. If it's even an option?
  2. Displaying which event, the master event or the next occurrence. I would like to hear technical recommendations as to which instance is best displayed on the dashboard so the user can see it in the 'Now' section.
  3. An icon/text 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. In addition the alert bar display to inform the user of some modification in the series of a recurring event.
  4. PPD (nice to have) Recommendation: As soon as any attribute is modified for just this event. The line item will display on the dashboard.
  5. Editable by-line? When the desktop sends an item using the 'communication' stamp and receives the item in a generic e-mail client, the information displayed in the e-mail will have the same information, but the wording will differ slightly. Are there any reason to keep it identical?
  6. Bug#8787, don't split recurring event series when making an 'all future' edit in the middle of the series. (Bug#8056 on the desktop)


Alternate proposal but might be too complicated.
  1. Is there a way to display only 3 instances to give an illusion of a recurrence? My point being that a recurring event will be displayed in the 'Now', 'Later' and 'Done' sections of the dashboard. However in the 'Later' and 'Done' section, there would only be one instance that is a combination of the series which is in the near future and which has past. The line items in the table of these events which are in the 'Later' and 'Done' sections would have an indicator either by icon or by text, ie. 'three more in the series' to inform the user how long the series is. (A proposal similar to the desktop but not exactly)

Other dashboard questions: unrelated to recurrence

  1. Quick item entry box: would there be a keyboard short cut for return or do we need a button to submit an entry?



Terms:
  • 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.
  • text edits/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: 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).

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.
  • Any modifications in the middle of the series would not display on the dashboard. (Is this the a recommendation from cosmo dev?) 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.


Proposal B

(Simplified proposal.)

  • 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; similar to the 'Alarms' functionality 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 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.

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.

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:

  • There are exception to this chart. See next section on [[#ComplexModification][complex modifications].

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.

*Note:*An instance never fully detaches from a recurrence until all of the attributes are modified for 'Only this event' (instance).

  • User makes an 'Only this event' modification to attribute X on an occurrence (A) in a recurring event series.
  • User then goes to a different occurrence (B) in the series and changes attribute Y and applies it to 'All events'.
  • The change to attribute Y is applied to the occurrence (A) with a modified attribute X.

  • However, if the user had tried to make a global - 'All events' change to attribute X instead of attribute Y on occurrence B, then that change would not have been applied to the original occurrence (A) with the modified attribute X.

  • Conversely, if the user goes to the original occurrence (A) with the modified attribute X and changes attribute Y and applies it to 'All events'. That change to attribute Y should be applied to all occurrences in the series that have not already had a modification on attribute Y.

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: The images are a bit odd, I'll be updating this chart later.

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.


Based on the 0.6 desktop spec

Requirements

Interoperability: The iCalendar semantics will be used for recurrence rules for import/export as well as sharing. This allows recurrence events to be shared with other calendar clients and on CalDAV servers.

Display: The Chandler UI will only present a subset of all the complex recurrence rules that can be specified using iCalendar. If a calendar contains an event with recurrence that is more complex than available in Chandler, we need to support a mechanism to indicate this to the user and preserve the recurrence rules under the hood.

Modifications: If there are any modifications within a recurring event in the desktop, we need to support a way to modify a single event, the entire series or all future events.

Deletions: If we are deleting a recurring event in the web ui, we need to be able to delete a single event, the entire series or all future events.

Performance: Recurring events listed in the dashboard must not cause visual delay on the web UI when hundreds of recurring events are defined.

Recurrence work needs to support for interoperability.

  • iCal, Sunbird and other CalDAV clients.
  • Exporting to GCal. Atom?
  • Subscribing to collections.
  • Exporting collections.

Future enhancements: | See out for preview list for dashboard.

  • All edits to the events on the dashboard are done in the detail view. There will not be inline editing for preview on the dashboard. _Feature on is listed in the out for 0.7 Preview
  • Bug #8324: Custom recurrence rules.

Other stuff for the 0.7 spec:

By-line information:
  • If the user is viewing from ticket view, then the sender's name is 'ANONYMOUS CHANDLER HUB'. In ticket view the user has the ability to edit the 'From' field. When the

Alarms

  • Alarm information is displayed in the detail view but not editable on the web UI. If the alarm goes off, the item

-- PriscillaChung - 13 Apr 2007

toggleopenShow attachmentstogglecloseHide attachments
Topic attachments
I Attachment Action Size Date Who Comment
pngpng simpleDailyRecCV.png manage 43.8 K 13 Apr 2007 - 08:50 PriscillaChung calendar view: simple daily recurrence
pngpng simpleDailyRecDV.png manage 56.3 K 13 Apr 2007 - 08:51 PriscillaChung dashboard view: simple daily recurrence
pngpng simpleWeeklyRecCV.png manage 35.3 K 13 Apr 2007 - 08:52 PriscillaChung calendar view: simple weekly recurrence
pngpng simpleWeeklyRecDV.png manage 42.6 K 13 Apr 2007 - 08:52 PriscillaChung dashboard view: simple weekly recurrence
pngpng oneEventChangeCV.png manage 42.0 K 13 Apr 2007 - 08:53 PriscillaChung calendar view: one time event change in the series
pngpng oneEventChangeDV.png manage 27.1 K 13 Apr 2007 - 08:53 PriscillaChung dashboard view: one time event change in the series
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r9 < r8 < r7 < r6 < r5 | 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.