Bridging the gap...

• Why do we care about INTEROPERABILITY?
• Different Strokes for Different Folks

get intro from mimi

Meeting organization scenarios

Scenario: Sheila is organizing a meeting w/Philippe, Bryan, Mimi re: Detail View

• Email Scenario:
  • Look at her own calendar, office calendar, contextual knowledge
  • Sheila emails the participants, with a time proposal
  • Sheila includes an agenda, might link to documents
  • Participants email to the group (I can't make it, I can make it)
  • Participants amend the agenda, add or remove participants
  • Can go back and forth a number of times

• Outlook Scenario:
  • Create a new meeting proposal
  • Enter participants names
  • View freebusy
  • Pick a time for (almost) everybody
  • Pick a location (and resources)
  • Hit SEND
    • Counter proposal
    • Mtg organizer re-broadcasts
    • Accept and update agenda
    • Email to confirm
  • Override other meetings*

Adding information to a common store scenarios

Sketch out workflow for adding information to store, and communicating that to other people...

• Wiki
  • Add info anywhere in the wiki
    • RSS feeds pull
    • Send an email
    • ask wiki page
  • Grant checks RSS or Jeffrey sends an email on IRC

• Bugzilla Scenario
  • Create a new bug
    • Component owner gets email
    • cc'd people get email
  • Reassign to a new owner
    • adding information
    • ding fields
    • email gets sent
  • outside of bugzilla communication
    • email that references a bug

• Common characteristics of communication of information
  • add people
  • new information
    • content
    • metadata (start time, end time, component)
    • chatter (not always preserved, or might be in multiple channels)
      • bugzilla, email, irc, verbal
      • some chatter only goes to a subset of participants
      • problem: new person added mid-workflow has trouble catching up

• How do organizations differ
  • geographically dispersed/centralized (timezones)
  • hierarchy
  • function
  • size
  • process-individualistic
  • focus: heterogenous/homogenous (

• Assumptions of Outlook model (structured organization as opposed to osaf or less structured organization)
  • assumes other organizations with their own organizations: people do not have access to one central server (can send to other organizations -- that is why it goes over email)
  • single meeting organizer
  • single model for both large and small meetings
  • shared assumption of work hours
    • Mimi asks Philippe:
      • which days you are in the office and which days you are not in the office?
      • which days you are spending time with your daughter?
      • can someone schedule a meeting with you at 7am?
  • assumes a structured work day
    • lpfi always prefers to list out 4/5 work times (not use invitations)

Chandler

Mimi's proposal for where we should go -- want clarification questions

• (1) Content, where owner sends that content out to a bunch of people
• (2) Responses from a bunch of people
  • changes to metadata (add a new person)
  • changes to content
  • add chatter
  • (ability to distinguish between the 3 is important)
• Transportation is varied
  • email
  • sharing/server (cosmo)
  • im/irc
  • proxy for verbal (imagine ui to add in your notes from verbal conversation)
• Differentiate between types of "notification": notion of a "ping" vs just an update
  • Big N (actively ask for someone's attention)
  • Little n (every time an update happens)
  • Changer determines whether the notification is Big N or little n

• In either scenario...
  • Philippe puts up a wiki page
  • Esther puts up an event on a calendar
• ...thread of interactions that people see
  • little n notifications
  • big N notifications that go in "NOW" section of dashboard
  • chatter
• User should be able to distinguish between each axis
• Versioning:
  • Recipient can distinguish between chatter and changes to content
  • UI display mechanism to see that allows you to differentiate between edits (change the agenda) to content and chatter (add a comment)
  • user should be able to quickly identify the conceptual difference, whether or not this is the same Item with same UUID is an implementation detail

• Example: If you add new people to event, may only send "N"s to newly added people

• Ecosystem
  • (Al) Chandler user I (sharing)
  • (Bo) Chandler user II (sharing)
  • (Cloe) Chandler user III (not sharing)
  • (Dom) Non-chandler user (uses pine as email client and no calendar)

• Goal: single workflow
  • (0) Al creates "lunch at Zebulon" on shared calendar (with Bo) (v1)
  • (1) Chandler user Al sends out something to Bo, Cloe, Dom
    • thing sent: iMIP + Chandler Item (with UUID) + email text
  • (2) Invitation received
    • Bo gets the same Chandler Item (v2, 3 people added to event)
    • Cloe gets an Item (v1: Lunch at Z with 3 people)
    • Dom gets text
  • (3) Bo or Cloe sends an edit or update
    • Bo and Cloe can see
    • Dom just gets email chatter
  • Series of "N" notifications
    • (N) Al sends event
    • (n) al fixes mispelling of zebulon
    • (N) Dom replies RE:
    • (n) bo fixes
    • (N) Bo replies RE:
    • (N) Bo edits
  • Al and Bo get little n and BIG N notifications
  • Cloe and Dom get only BIG N notifications
  • Al, Bo and Cloe can do edit/updates to actual item
  • Dom only participates thru chatter
  • Emails that arrive might not show up in your inbox but might get handled behind the scenes?

• Scenario: Al puts event in "Later". Cloe makes an update with an N. Event now popus up in "Now". (Refocus on lunch event)
• Question: are communication items different from event items?
  • up to engineers: implementation details
  • doesn't clearly fit either model
  • need to be passing around different items that have a relationship to the original item
  • also needs to be some kind of reconciliation process?
  • bo is going to get a big N and little n notification from 2 different sources

Q: By what mechanism does cloe change the item?

• Goes to event invitation item
• types new stuff into body field
• send button changes to an update button
• she clicks update

Q: how do we know the capabilities?

Come back later: how do the interaction workflows actually work?

Alternatives...

• Different technologies require different workflows
  • Item has a Notify button... Al can notify Bo, Bo is invited
  • Al creates a separate invitation item, wraps invitiation, sends to Cloe and Dom
  • Split workflow thread: Al and Bo communicate via the share, update the item on the server and ping each other when they make significant changes
  • Al goes to his email client, and sends mail to them separately, discussions about agenda, participants, etc. on a separate thread
  • Possible 3rd item: Al can send a Chandler Item to Cloe, Cloe can do edit and update on Cloe's own item

Observation: Notification button is good because someone can force a notification, in case we get little n notifications wrong.

Sharing, huge affordance, autoupdating. Unless everyone is on same system that can recognize iMip or sharing via Cosmo, get someone is excited about new tech, but at least you go to one place, type in email and have one workflow. We need to compete with the single one workflow (as annoying as that workflow is). Otherwise unlikely that they will stick with the new technology. Because they are not always interacting with people in the system, they fall back on email as it works for everyone, one system is easier. Trying to raise the lowest common denominator.

Next action: write up the ideal workflow, each participant and stage so that we can refer back to it. Goal: can we come up with interim solutions that take on shape of ideal workflow?

• Versions
  • distinguish between chatter and content
  • inherit labels
  • replace in view
• Notifications
  • PING
  • put in someone else's focus
  • negotiation affordances
• Phasing
  • context sensitive tooltips
  • separate clean UIs for susequent sends
  • clusters
  • events with no proposed date or multiple proposed dates