Notes: Recurrence Discussion

Tuesday April 26th, 2007 ~3PM PST, (after the bug council) in Gotham.

Last week we reviewed the 'dashboard: recurring events' section on the 0.7 web UI spec: http://wiki.osafoundation.org/Projects/CosmoZeroDotSevenSpec#RecurringEvents (Not revised from last week.)

Agenda: This is really a suggested agenda. The goal I think we'd like to accomplish is to agree on what to implement on the web UI based on the desktop.

15 mins: This week we'll review the recurring events sections in the following specs with Jeffrey/Mimi/Sheila:

• Desktop dashboard spec: http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Dashboard-0.7.html
• Desktop stamping spec: http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Stamping-0.7.html
• Desktop updated recurrence information/spec: http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_6/Reccurence-0.6.html and edge cases documented on the wiki: http://wiki.osafoundation.org/Journal/PreviewRecurrenceSpec
  

15 mins: Jeffrey will be available to go over any edge case recurrence items which are of concern.
25 mins: Review the dashboard proposal on the web ui, ignore all the alternate proposals (by PPD) but to try and come up with the ideal proposal we can all agree on.
5 mins: document/next actions. etc.

Attendees:

• Jeffrey
• Sheila
• Bobby
• Matthew
• Travis
• Mimi (on the phone)
• Ted (one the phone)
• Priscilla

---

The server team did not feel they needed to review the specs for the desktop again so we just had a list of open issues for Jeffrey to go over. Basically the meeting was to make sure the server team understands how recurrence works on the desktop and all the technical/specific details.

Next actions:

• the server team will think about possible ways to simplify recurring of events on the dashboard and propose on the design list.*
• PPD compile the use cases where viewing and using/changing the dashboard on the web UI.

Issues raised:

• making a consistent decision on a modified instance on a daily recurring event series—item 3 is modified by start time, then the master is modified by duration, what happens? Edge cases like these may need to just have dogfood feedback to understand what users anticipate.
• how useful would the dashboard be if it was only displaying the master item in the occurrence, which would all be in the 'Now' section.
• sharing triage status on the desktop and on the web UI

---

Topics for discussion:

1. When to split
2. a. daily event
3. all events
4. triage status
5. pure attribute change
6. recurrence rule change
7. deltas to time
8. stamps adding/removing and modifying

---

Notes:

Please note there may be some disconnect in the notes because people were sketching on the on the white board.

• All the rules of recurring events on the calendar, when the dialog appear, when do you split recurrence and start a new .

• sheila confirming bobby's question: understanding I modify this attribute
• bobby: example, daily event—move the start date has changed.

• render in time the way we do it.
• when you drag it it's unclear on the
• on the form end time,
• what do we actually it do?
• iCal model you can either do duration or end time.
• choose
• Pick one
• duration and start time
• made a call, calls were made and not obvious

• if you take the event, modify it then change it back, is it a modification
• anything in the past is done, any thing in the time

• collection with a modification in it
• if you have a recurring event all of the modification is in the collection
• unmodify things when it doesn't look like there are modifications to it, when we hit the triage button

• bobby's worry about unknown unknowns
• what should I be rendering in my table view
• desktop is all about items, problem w/items change in items may mean proxy to wrap that item and change

1. start/time change
2. duration change
3. title change

• change all of those, all this and future, the changes will continue for that session
• example, change time: 3PM --> 4PM
• duration: 1 hour to 2 hours
• title change: Hi to Yippee

• change start time back from 4PM to 3PM

• usually do a delta to everything
• are we changing the start time or the new start time
• change the title: from 'Yippee' to 'Yeehaw'

• we always split when we use this and future—bug filed and it won't happen for preview
• modification for the 3rd recurrence, it does not get 'yeehaw-ed'

• if you change from 4 back to 3, deltas to time
• not true you're changing the master
• everyone starts off as Hi, , 2nd to be Yipee, exception to the rule, change itself and the master.
• everything in chandler is an item, an occurrence instance it always has master associated w/ it. the property inherit from.
• if the occurrence doesn't have an attribute on itself it will look for that attribute on itself, item/the repository
• do we allow all future and master, it's hard to know the last one.

deltas to time:

• change the 3rd occurrence and change the title from Hi to Yippee
• make an all change to start time, 3PM to 4PM
• need to change the recurrence ID, for modifications they are
• for all changes and this and future.

• if we change the start time of this occurrence 3 to 5PM, first change 3 to 4, specific
• don't change the 3rd (modified) item.

• Mimi, friday put it on last saturday—we don't know what ppl intentions are really
• Mde moving one day,
• in a daily changing the date
• whatever the interval is, such as moving a day from a weekly recurrence—documented on the spec.

stamping:

• have a recurring stamp, if you unstamp the event-ness it
• unstamping event-ness not allowed
• mail stamp for preview applies for the entire series.
• pop up something that alerts — address stamp applies to all
• add a stamp to a specific instance
• remove the task-ness, dialog pop up
• can I add a stamp to the master: and it has some property, can I overwrite the property on the modification on occurrences.
• mail stamp that apply to all, but the address
• could have different values for that stamp for address, some could send to some ppl whereas others could apply to other in a occurrence.
• iCal will barf, doesn't work with iCal
• might be other stamps, will allow modification
• look through multiple stamps then for just one.

• master that it occurred to, doesn't inherit the stamp from the master
• location is inherited from the attribute on the event stamp
• whether something has a stamp
• you can have an attribute with a stamp
• attributes, giant main space variable thing
• some seperate set of properties
• mail/addressees changes apply to all
• mail stamp attributes apply to the master and cannot be overwritten, the body is just a description on a normal item, titles can be changed. Address, can only be changed.

recurrence rule changes:

• what we used to do is if you made a change you would, use to blow everything away
• EIM: keep all the old stuff, need to follow up with Grant
• daily event, this is turned into a weekly meeting
• recurrence rule, only this event.
• blowing away the modification
• everyday recurrence, modify the third occurrence, then modify 2nd to become weekly—the 3rd modified one (start date change) sticks around. More conservative.

triage-status

• one for now, later done
• if you want find what did I move from 3PM to 5PM, and want to be able to see it in the table view
• when you create something new, it is in the now section
• everything has an explicit triage status—nothing means now
• 2 different types of triage status
• actual triage status and section triage status
• button triage status and section triage status
• next to the item
• section triage status, where it should be sorted in the table
• often are different
• new item it showed up as new, both are now
• actually, I want to triage this to be done, section triage status to
• button triage is the real triage status
• section is persisted.
• if you close the desktop and come back, not really a cache
• button triage is done, section is now
• click on the button
• where you sort on the table, is exactly where you are now and then change
• if you click triage button, removes section triage status and put everything in the appropriate place.
• not just section triage status
• when you get something in new, preserve the sort order,
• when you get something in new, we store the last of that last change.
• the item should not change when clicking the button triage
• section triage status change
• section is not passed through the EIM, temporary holding
• non recurring-ness
• section triage status, to appear in a different status, section triage status change
• if the triage button is selected, and the new item is now done after
• the moment I make it occur, we don't want the item to jump around.
• we might that occurrence completely disappear
• recurrence is in now, later and done.
• when you add the occurrence rule if it's three hr, event it's clearly now, if it's an all day event, then it's now.
• reminders and triggers which fire.
• if you have an item which is later item and
• later occurrence

• anytime is like all day events.
• the big different, don't show busy time in the minical for it.
• visibility time
• no automation
• any birthday can have an alarm to set before that to jump into now.
• the later section is sorted,
• theory: you're mostly going to be looking at now
• current time
• last week, new item, 1PM to 3PM, daily
• display another new item in done in yesterday
• keep the same item selected.
• as soon as you click triage, clear everything up. things will reorder
• get rid of any recurrence, multiple 'done' for example
• get rid of the last week one
• look through all the recurring items, get rid of the last week, keep yesterday, later tomorrow, now today.
• 2PM to 4PM, that additional modification will show up in the table—it shows up in later.
• even if it's not a modification
• midnight; things move into 'Now'
• often you'll see done and later collapse
• section triage status, change item to done,

• what you focus on changing to triage.
• things are move into later or now, most likely done
• triggers which are moved from later to now
• now is today, and it's triage status is green, when that thing fires, it also creates a later recurrence
• make sure all the right occurrence appears in the past.
• another thing which happens, if tomorrow
• change the triage status to become 'Now' from, when you click the triage button, it goes into now—create an extra recurrence to become later.
• change it back to later, the old later will disappear

Alarms

• alarms start time arriving will move things into the 'Now'
• alarms set, the start time takes precedence to go into the 'Now'.
• if it's not explicitly triaged. Alarm
• leaving an alarm
• if it's now, it just stays there forever
• alarm and then triage it back, it will change from done to being —makes something now
• interesting Now firing cases, it's in now, then 2 days later, it's still in now, then it moves to the top of your list.
• end of the meeting passing will not go into 'done'
• auto triage have an event then drag it,
• d click and create an event in future, you don't know the triage status in the calendar, and it will say 'Later'.
• when you click triage it will go away.
• drag it in the past it will
• alarms triggering

Auto triaging

• auto triaging based on changes to the date time based on events, tickling placing it to now, because time passes—the alarm fires
• changing the triage status
• bryan uses the auto triage term to mean: when a reminder or a start time fires
• triaging on events, as it moves closer
• initial pull of the page is huge—do we push those?
• you don't want it to happen on the front end
• 5 or 10 events change, does not get serialized
• EIM is the only thing
• auto triage on date change
• attribute do auto triage on start time change
• if we change the event time, you don't want it to be done if you explicitly change
• we're not serializing unless they differ from the defaults
• yesterday is done, and
• something moves into
• things in now should get serialized
• sharing do you want everyone to have the same triage status.
• web ui store triage status, does the web UI need their own triage status
• store things that are now.
• earlier then now, after all of the now
• server persists some data, translation and if it's just triage status throw it away
• talk to the server EIM—you don't have a share
• in a triage specific space

• sharing triage status is not the problem: the desktop allows you to share, the web UI doesn't. Weird thing one desktop users, collaborating w/
• hub user could be subscribed to the same collection, consults the web UI and doesn't not look the same
• sharing filter, for preview hard code what gets shared and not shared. for now.
• giving ppl choices.

Flag this issue for sharing triage status on the desktop and on the web UI

• I would like to share triage status with you,
• when you're not aware of what's going on and talk to someone else,
• Morgen and Jeffrey storing what their filters are, not able to store EIM, user key = what their field, webDAV property--> out of time for preview to do that
• disable the ability to chose, attribute to

• how we're sharing modification stuff
• are ways things can be stored, server to do somethings, speaks a different dialect.
• simplified proposal, no triage status for recurring events
• master was always in the now

• everything in now, all the master, everyone birthday in 'Now'
• dashboard is 5 or 10 recurring events in now — was useless.
• sharing someone's existing calendar vs. a fresh calendar
• sharing a dashboard
• start fresh a new collection
• not every collection that the hub
• PPD collection was a not very useful on the dashboard
• collaborating on a small project.
• make the dashboard something
• simplification is something like have an arbitrary window of time, and only show the upcoming things which are close
• someone birthday, arbitrary window of time.

• What are the use cases where viewing and/or using/changing the web UI useful in the dashboard?
• the dashboard was plausible promise
• evaluate what's useful for a hub user
• absolutely to Travis point for users coming to the triage status
• CC are not sitting in the web UI.
• CC do need to find the one item in the dashboard (if it happens to be a recurring series/modified recurring series) and make the one change/modification.
• they could potentially go into the calendar view to make the one change—though the application defaults to dashboard

-- PriscillaChung - 26 Apr 2007