[Design] 0.7 Stamping Spec

[Mimi Yin]

In-line... :o)

On May 26, 2006, at 11:35 PM, Philippe Bossut wrote:

> Mimi Yin wrote:
>> + For first-time Received Items, the Item is In if you are in the  
>> To: CC: or BCC: fields, even if you sent it.
> What if you received the item from a mailing list? You (your email  
> address corresponding to the "me" identity) is nowhere to be found  
> in any of these fields. Should the item not be In then?

Yes, good point.

>
> There's a third category missing in your discussion. Seems like  
> emails can end up being neither in nor out. If it's not the case  
> (and we have only in and out), then the logic is more simple: the  
> "out" determination is fairly simple (you are in the From field).  
> For the rest, if it's not out, then it's in.

This is complicated, I will draft a separate email to address this  
issue. It has to do with Spheres and from 'what perspective' sharer's  
are looking at shared communications: From their personal  
perspective? From the group's perspective? From the sharer's  
perspective?

>
> I also don't see the semantic difference between "first time" and  
> "update" that justify having 2 different logics. After all, the  
> "update" could be a complete rewrite and look like a "first time".  
> If you and me were to share a collection, why would an email (not  
> sent to me) be "out" but the same message (with the same recipient  
> data) be "in" if it was an update of an existing one? I fail to see  
> the reason of having this extra logic.

Thanks for delving into this, there were some built-in assumptions  
behind this reasoning that should be articulated and discusses, but  
I'm not at all sure they're right.

The assumption is that the first time you send/receive an Item, it's  
the 'official' communication.
e.g. Bob & June invited me to their BBQ, nevermind that it was their  
daughter Carol that updated the event by adding me to the invite list.

However, once you've sent/received the 1st time, subsequent updates  
are all about 'who updated what'.
+ Junior added 3 more of his friends
+ Larry is bringing the slip 'n slide
+ Florence isn't coming, but she's sending over a mint jelly pineapple

It's all about which piece of meta-data is important to the user in  
which context.
+ The first-time you send/receive, the official FROM: and TO: values  
are important.
+ For subsequent eidts updates, who EDITED and UPDATED the Item are  
what's are important.

=====

However, there is also the case (partially illustrated in the  
Stamping Storyboards) where a small group of people collaborate on an  
Item before sending it out to a larger group, and so in the beginning  
the Froms and Tos aren't actually the FINAL Froms and Tos, they're  
the small group of collaborators instead.

The ideal workflow for this is:

+ User can enter in the FINAL FROMs and TOs right away (From: The  
Management, To: The Staff) BUT
+ User can mark the Item as a Draft and 'Send' it to a different set  
of people for Review, without sending it to the FINAL FROMs and TOs.  
The UI might look something like...

Send to checked:
[ ] From: The Management
[ ] To: The Staff
[x] Reviewers: Co-worker 1, Co-worker 2

So if Laura were drafting a communication on behalf of Tracy to the  
Board, Tracy would receive an Item in her Dashboard that looked  
something like this:

Draft | TO: The Board

The "important" piece of information for Tracy in this situation is  
that it's a Draft of a communication TO: The Board, not that it's a  
communication Sent by: Laura. Chances are, Tracey has lots of stuff  
in his Inbox that were Sent by: Laura and displaying that an Item is  
a Draft of a communication TO: The Board, helps Tracy distinguish  
between the dozens of Items Laura sends her every day.

People do this today by typing in the FROM/TO information in the Body  
of the email, but the metadata is lost to the clients sending/ 
receiving the email AND the user can't see the FROM/TO metadata in  
the summary table view as they scan their Inbox to triage mail.

=====
However, this seems extra-complicated to do in a 1st class way within  
the Beta timeframe. For now, if users want to 'emulate' this  
workflow, they can do that by:

1. Enter plain text (not email addresses) in the FROM: and TO: fields  
as a way of "recording" who they are without sending the Draft to them.
2. Enter valid email addresses in any of the fields: FROM, TO, CC OR  
BCC for whoever needs to Review the Draft.

In the Laura and Tracy example above, Laura might do the following:
=====
FROM: Tracy's valid email address
TO: The Board (not as an email address, just as text)
=====

NICE TO HAVE:
We could add the ability to right-click on an Item that allows users  
to "Send Items as Drafts". That way, when Tracy  receives the Item,  
she can see that it's a Draft and not freak out that Laura send the  
communication to The Board without giving her a change to review it.  
So Tracy would receive something like this:

Draft | TO: The Board

This workflow wouldn't be very discoverable, but early adopters who  
do things like read read-mes, could try it on for size, we could  
learn from it and tweak the design based on feedback.

Mimi :o)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060530/68b61354/attachment.htm