Scheduling

Agenda

• (15 min) Review proposal - Answer questions
• (15 min) Brainstorm 2-3 different approaches to how we could model the proposal (focusing on 0.7)
• (45 min) Brainstorm and sketch out interaction workflows for scheduling/invitations (for 0.7)
• (10 min) Discuss how these interaction workflows for scheduling/invitations fit within the larger context of transporting generic Chandler information items.
• (5 min) Next actions

Summary from last week

• Step 1: Alice creates some content.
• Step 2: Alice creates a wrapper around the content (who to send the content to?)
• Step 3: Beau, Cloe are recipients of the content.
• Step 4: Beau and Cloe make edits
  • Beau edits the body of the content.
  • Cloe adds chatter, thanking you for the content, or pointing out a mistake.
• Step 5: Notification goes out about edits
  • small n notifications
  • Big N notifications
  • some people want to know about everything

• space of notifications: frequency of notifications, characteristics of items they care about, characteristics of changes
• 3 types of sharing
  • chandler calendar sharing
  • imip invitations
  • email
• email is the lowest common denominator
  • scenario: 2 people have ical/imip, 2 people don't
  • could send imip to two people, and send regular email to two people, but go ahead and default to lowest common denominator and just send email
• goal: provide unified way of sending content to people with different options (imip, email, chandler sharing)

Scenario

Characters

• Dom uses Pine
• Ernie uses iMIP
• Cloe uses Chandler
• Alice and Beau use Chandler and share calendars

History of interactions around the event

• Alice sends out invitation to people
• re: great idea
• re: are you sure this is the right date
• Beau changes the location (edit/update) (Beau is co-organizing the event)
• Cloe makes the location a link to the map (edit/update)
• Alice sends out final event invitation

The history is different for people with different clients

• All of Ernie's replies will be chatter -- he can't edit the original item and send an update
• All of Dom's interactions will be email

Ground rules

• Today
  • Event + email stamp ==> send event
  • Recipient sees subject line and body
• Improvement #1
  • See the meta-data represented in the body of the email
• Improvement #2
  • iMip event ==> turns into an event on your calendar
• Improvement #3
  • chandler event, send it and address it ==> goes out as iMIP request

• Al sends out an iMIP request to all 4 people (Improvement #3)
  • Beau can find the event in the iMIP request
    • The event is now part of Beau's own calendar
    • Event is refocused into NOW section of dashboard
    • Subsequent edits and event modify shared event
  • Cloe receives item as iMIP
    • A new chandler event is stored in her calendar (might use UUID?)
  • Dom gets text
  • Ernie's client interprets iMIP in some standard way

• 0.7 Strawbeing
  • Recieve iMIP
  • Send iMIP requests
  • Don't lock Cloe out (?!)
    • Cloe can send item in her own repository
    • Cloe can send email
  • We could in theory leave out feature of Cloe doing rich full fledged updates

0.6 Example

Esther maintains iCal office calendar, and Chandler office calendar.

• Today
  • Send email to everyone about pto
  • Add event to chandler office calendar
  • Esther adds event to iCal office calendar
• Lowest common denominator step would be to send to everyone, which would naturally happen
• Preferrable to add event to chandler calendar and it broadcasts email to Esther

0.7 Strawbeing (Shared framework)

• Do people buy in to strawbeing proposal as general description of target?
  • Technical concerns about how this will actually work
  • Questions about how iMIP works
  • Questions about how the Cloe scenario would work

• Steps in creating event and inviting people
  • Checking freebusy
  • Entering list of people
  • Selecting a time
  • Sending out invitation in some way people on other end can understand

• 0.7 constraints
  • Scheduling with a small group of people
  • Cosmo dependencies -- would be good to be doing this early-ish in the cycle (at least a first phase)
  • Try and take a simple approach and use the mechanisms that we have right now, even if it is not the ultimate ui that we want

0.7 Brainstorming

• Proposal
  • Separate freebusy from invitations
    • one can fail and the other is still useful
    • may only want to do one task and not the other
  • Collections of people in the sidebar, semantically different, don't mix them together
    • handle that you can open or close
  • Show only a vertical bar for time, not whole event
    • can accomodate multiple overlays better
    • separate visualization, your calendar vs freebusy info
  • Invitation workflow is separate, presumably in detail view
  • OI: Overlay shared calendars + free-busy calendars
    • In theory you could overlay calendars on top and bottom
    • What if shared calendars are only a subset of f/b information?
  • Freebusy calendars and shared calendars are distinguished: rendered differently on screen and actually different collections
    • OI: why?
      • may not have all information
      • shared calendar might not have all free busy information

• Proposal
  • Dedicated place in sidebar for contacts (avatars)
  • Select group of contacts you are interested in

• Proposal
  • Free-busy view, grey out areas that you can't schedule meetings
  • Would look like background of calendar
  • Just care about open areas
  • Free-busy mode for a view

• Observation
  • Like proposals where we don't go into a mode

• Observation
  • Some proposals are throwing up a lot of information all at once, don't want all that information in a glance
  • Perhaps you could do mouse-over to reveal more information

• Observation
  • Really same amount of information, but added texture (color) to help you interpret the information
  • Making data more opaque so that you can't see metadata might not help

• Next step
  • Mimi and Priscilla can mock up, keep conversation here at conceptual level

• Proposal
  • Schedule button or menu item replaces minical with experimental uis
    • Avoid hierarchical view inside sidebar
  • Different ways for toggling minical and area
    • tabs for choosing what gets seen in the pane
      • might be cheap, we can use existing widgets
    • buttons to toggle
  • People/freebusy area (and experimental ui) is not confused with full fledged collections
    • semantic differences
    • application bar doesn't apply to them
  • 0.7 context -- lots of collections might not in practice be a problem
    • only a few calendars shared?
    • you would have to add your own users (no it department to set up whole group)
    • at osaf: would we add more than 10 people to look at freebusy?
      • yes: all of osaf!
      • are you really sure?
    • maybe in the sidebar is first iteration? looking for easy short term options
    • might actually be easier in a separate place

0.7 Goals

• Not doing: Address an invitation and have it automatically select a freebusy view for you
  • (Freebusy will be independent of invitations)
• Not doing: Detail view is not prepopulated based on freebusy choices
  • (Objection is not in the design, just want to limit work)
• OI: How do things get into the freebusy list? (lower left side)
  • Alice publishes f/b from menu item, gets a url in return, locates his f/b on some server
  • Cloe types url into dialog
  • Freebusylist pops up and Al's info has been added to it
    • Server thing or client thing? sharing code handles this when you subscribe
• Not modal
• Want to be able to overlay freebusy calendars with normal calendars

• Invitation proposal
  • One time lob of content out (iMIP)
  • No subsequent editing/updating of items
  • Except for sharing -- notification by email only
  • No versioning
  • No edit locking

• Send button always activated, can always send out as email
  • First time send is iMIP, subsequent sends are email

• Ability to generate freebusy info from calendars you subscribed to?
  • Maybe I don't usually want to look at sheila's calendar, only want to see freebusy when scheduling
  • Clearly doable, might not be desirable

Next Actions

• Mimi and Priscilla do some screenshots
• Document proposals, phasing proposal
• Development discussion about implementation options
• Sheila writeup to the list, beginning of a spec
  • Try and list out assumptions about what we think is hard, so engineers can respond to that