Summary

Initial meeting to discuss proposals, musings and issues listed in Jeffrey's notes from 02/16/2005 involving how we are going to represent Chandler events and tasks in iCalendar format for the purposes of export and sharing as well as handling imported events from other calendar clients. We ran out of time and require a follow-up meeting to continue formulating proposals for 0.6.

See: JeffreyHarris20050216

Attendees

• Jeffrey, Alec, Mimi, Sheila

Notes

• Jeffrey walked through current assumptions for import/export of calendar events and what works, what doesn't.
  • Importing vEvents, vTodos - simple assumptions.
  • Timezone info mapped to UTC.
  • Recurrence, import 1st 10 events but no way to display in 0.5
  • Import multi-day events but no ui for 0.5.

• Discussion about mapping VTODOs
  • when over various mapping scenarios.
  • Option 1: import tasks with due dates as Chandler tasks and set tickler alarm (auto-generating ticklers).
    • Users may not want this if they have a huge list.
    • Talked about use cases, common vs edge case.
    • What happens if VTODO has a due date and and alarm. They may have startdate, duedate and alarm.
  • Option 2: Being able to import VTODOs on "Import" but don't share task info or allow export.
    • This would allow 1 time import of task list. We could probably have a simple UI giving the user 2 options, import as tasks or as tasks with ticklers.
    • In the sharing scenario, we wouldn't try to map the tasks to iCalendar. Scheduled tasks would be handled as events.
    • This differentiates the 2 scenarios which probably makes sense.

• Discussion about alarms.
  • Currently spec has alarm information NOT shared. This makes sense in the scenario that I am sharing my calendar with others, the alarms are only meaningful to me. In the context of publishing your calendar so you can use it from 2 different clients, sharing alarms might be required and this creates several issues.
  • We need to do a bit of thinking about this and look at the various use cases. Will setup a separate discussion and include Morgen when back from vacation.

• Mapping Anytime events that are not All Day
  • We started to talk about this then Mimi wanted to revisit the date-time widget since she felt it may be too confusing to have a straight anytime event if we can only have traditional date-time fields not the text entry one she wanted.
  • We will revisit options for this since the anytime event is a good concept and it's possible we can have a more sophisticated widget in the future.
  • We will have a follow-up meeting to continue the discussions next week after Mimi thinks about the design.

• Event duration = None
  • Due to a bug in the current build, Jeffrey brought up the issue of an event with a date time and no duration.
  • After investigating, Sheila determined that this was a 0.5 requirement and we simply have a bug. Might get fixed in 0.5 or early 0.6.

Next Steps

• Mimi is going to revisit the date-time widget UI design (we need to do this for 0.6 anyway) since we realize we need something simpler than her original Kibble proposal. She will come up with a couple of alternative designs prior to our next meeting.
• Sheila will think about complications of sharing or not sharing alarm/reminder information and setup a separate discussion for this. This will wait until Morgen returns from vacation after March 1.
• Sheila will schedule a follow-up discussion with Mimi, Jeffrey and Alec once Mimi has the date-time widget design ready. Aim for week of March 1.
• Sheila will look into what we have discussed about timezones so far.