Conflict Management UI Meeting

Agenda

• Mimi - run through the proposal sent to the list
• Talk about issues/concerns
• Brainstorm alternative proposals/modifications

Notes

• Currently we resolve conflicts when users edit different attributes
• We mainly run into this when users edit the same attribute.
• Some issues with computed attributes ie: display date - bug that should be logged.

• Conflict always occurs between what is on the server and what is in your repository.
• You resolve this one at a time.
• What if you don't resolve the conflict and something else happens?

• Always resolving only 2 conflicts.
• If we have 3 people editing, you always resolve a conflict with what's on the server.
• If I received a conflict, but before I had a chance to resolve, the server version changed again, I would be prompted twice to resolve conflicts.

• Email updates could be in addition to sharing conflicts.
• User receives a number of updates via email.
• Keep the before state of the email and the current version.
• Different than with the server - more peer to peer conflicts.
• Could treat the email similarly - always presenting a choice between old thing and new thing.
• Email could be thought of as sharing multiple collections.
• If an item is in more than one collection, we can still end up with the 3-way problem.

• Mimi's mockup - "none of these" would be replaced with an edit field, users can type in a combination of options or some other text.
• None of these doesn't really make sense, the user needs to choose one option or the other.
• Can we simplify the conflict management UI dialog?
  • We need to have all the same editing options as the detail view fields.
  • Or we can have some other editing paradigm to do all this in this dialog. Give the user some other tools.
  • Whatever text is a problem can just go in the dialog and the user can cut and paste everything manually.
  • You can close the dialog without resolving but that item won't sync.
• If someone sharing sent and update that conflicts with the server - anyone receiving that update can resolve this conflict.
• Can we know how many conflicts the person will have to resolve? How many times they will have to go through this process.
  • Grant says yes on this.
• Proposal: dialog with a big text box with all the stuff in it.

• Visual stuff in the detail view - how hard is this stuff.
• The only really "must have" is the banner message at the top. The other stuff in the detail view is nice to have.
• Affordance in the table we also need and treating this item as an update.
• All errors should be handled the same.

• Mimi - adding conflicts to the notes field - just gets appended.
• The notes field just gets longer and longer - someone can clean it up on some point.
• BStearns - structurally the conflicts have to be different from the notes field.
• Alternative is another field that doesn't get shared - the one that shows up in the dialog.

• May not get all the email stuff resolved until we sit down and work on the algorithm.

• Reid owns dialog work
• Morgen is responsible for sharing sync algorithm
• Email sharing??? Brian K, PJE, Morgen
• Bryan S - table affordances

Next Actions

• Send modified proposal to the list - detailing the sharing scenarios
  • New dialog
  • Assumptions around resolving the conflicts in sequential order.
• Follow-up with a proposal around email once Bkirsch and others have had a chance to have the detailed discussion on merge/conflict architecture and email.

-- SheilaMooney - 08 Jan 2007