I'm wondering if walking through a specific scenario might help.
Think the really simple use case of:
Here's a list of places to go visit in London, add one to the list:
British Museum
Hyde Park
Parliament
Fleet Street
Picadilly Circus
This message gets sent out to 2 friends who have visited London
before. Each friend edits the email by adding 2 suggestions to the list.
In traditional email, this would generate a long thread, with perhaps
each person adding 1 or 2 items. The thread might get split and then
you have to backtrack through the thread to compile all the suggestions.
The list also gets broken up by these things reply thingies: >>
In edit/update...it's just one list. If you file that list into your
Travel collection, all subsequent updates to that list also show in
the Travel collection, you don't have to keep re-filing it. And there
isn't a long string of emails to compile...it's all just 1
item...which is what you wanted in the first place, a single list of
places to visit in London.
There will still be a need to have traditional email conversations,
like this one, where users won't want to edit the email they
receive...but we can't tell a priori if the message someone sends out
will turn into a conversation or will be a 'Note' document that gets
edited and updated over time. In fact, I think that many messages
will have both: Parts that are edited and updated as well as an
attendant conversation thread.
See more in-line...
On Feb 22, 2007, at 5:51 PM, Phillip J. Eby wrote:
At 05:25 PM 2/22/2007 -0800, Mimi Yin wrote:
Hi Phillip:
I assume you mean Note items + Message stamp? As in, you're not
talking about emailing non-Message items around?
We want to support edit/update for plain message items as well. There
are lots of use cases for collaborating on just a message:
+ Working on a draft of an announcement together
+ Working on a proposal
+ Compiling a list of places to visit in London
+ Putting together a packing list
I guess I'm not clear on how that isn't addressed by normal email
workflows.
Or to put it more clearly, since we don't have in-field conflict
resolution for the body, it seems to me that edit/update is
actually *less* useful than normal email would be for this use
case, since normal email at least preserves a history of changes
(through the existence of prior emails on the subject), and
includes a conversational flow that would be lacking here.
Or perhaps I'm entirely misunderstanding how edit/update is
supposed to work? But it seems to me that for text uses of the
type you describe, it would be a giant leap backwards compared to
the primitive email clients through which we are having this very
conversation. :)
Also, in our user interviews, we repeatedly saw people start the
scheduling workflow with a plain email... without a specific date/
time proposal. We want users to be able to do edit/update while
they're working out when a meeting is going to happen...and then
stamp the message item to add it to the calendar, when they're
ready to.
Which you'd still be able to do, even if we didn't do edit/update
for non-calendar items.
If we don't support edit/update for non-task/calendar items...I'm not
sure how users could collaborate on meeting agendas prior to stamping
the message to add it to the calendar.
By the way, I'm not saying we should abandon the idea of edit/
update for non-calendar items, just that it seems like it should be
a different process from the normal sending of an email. I think
that the idea of attaching a document (or any other item) to a
message should be distinct from the idea of having a conversation
with someone *about* a document (or other item).
I think I'm having trouble figuring out how we would make the
distinction. Do you have something specific in mind?
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
