[Design] What is the meaning of From: and To:?

[Mimi Yin]

I wanted to address a point that came up during yesterday's Design  
Session 3 on Stamping and Communications.
The notes can be found here, embedded in the original write-up:  
http://wiki.osafoundation.org/bin/view/Journal/StampingStoryboards

Q: Won't it be confusing for the user to see From: and To: appear  
when they use the 'Communications' stamp if the From: and To: don't  
necessarily correspond to the From: and To: fields of the Email that  
is used to wrap and send the Information Item?

The issue I'm addressing is documented here:
http://wiki.osafoundation.org/bin/view/Journal/ 
StampingStoryboards#FromAndToIssue

We talk about how From: and To: were closely associated with Email in  
most people's minds and that if we wanted them to mean Organizer and  
Invitees instead for invitations, we should call them Organizer and  
Invitees.

I explain that we wanted to keep From: and To: because we wanted the  
Communications fields to remain fairly generic, so that people would  
feel comfortable using them in a variety of situations, without  
having to think too hard about who the Organizer was and who the  
Invitees are. However, I didn't have a good example on hand.

The example I used was: Sometimes, when you're setting up a meeting,  
you first confer with other people to get their input on the Proposed  
Agenda, the Time and who to Invite before actually sending out the  
official invite. For example:

Esther needs to send out the invitation to a Fundraiser for Mitch on  
Mitch's behalf. She pulls together a draft and sends it to Mitch to  
review. Mitch receives the Fundraiser Invitation to review from  
Esther. Esther is not the official Organizer and Mitch is not an  
Invitee. Part of the ensuing Chatter or discussion *about* this  
Invitation is who to actually invite and who it should officially be  
from. After a few iterations of reviews, Esther and Mitch decide to  
put Kapor Foundation in the From: field. However at the beginning of  
the process, neither she nor Mitch knew what would be appropriate to  
put in the From: field.

Calling it an Organizer: field would make it even more of a blocker  
because Organizer has even more specific semantics than From:.  
Calling it From: on the other hand allows the field to mean all  
things to all people at all times. In the beginning, the Invitation  
draft is From: Esther for Mitch to review. Over time, the From: field  
comes to mean Organizer as Esther gets ready to send it out to the  
real Invitees of this event.

However, this is not an especially common use case. A few use cases  
that are maybe more common are:

In the Design Session, we discussed how, not all things on the  
calendar are necessarily traditional Events (meetings, appointments,  
parties). Things like Birthdays, Holidays, PTO, Flights. If we  
changed From: and To: to Organizer: and Invitiees:, it would make  
sending your brother your Dad's birthday and sending your spouse your  
Flight information semantically confusing. What does it mean to be  
the Organizer of someone's Birthdate? or of a Flight or a Holiday?  
Keeping the Addressing fields generic allows people to use it in  
whatever way they find appropriate.

===

We touched on this in the meeting yesterday, but I wanted to  
reiterate that this de-coupling of From: and To: fields in the  
Information Item from the From: and To: fields of the underlying  
Email is ONLY SOMETHING A USER WILL ENCOUNTER *IF* THEY START EDITING  
EMAILS AND EDITING THE FROM: FIELD. In other words, it's only  
something users will encounter once theyve broken through the email  
mental model.

In fact, one could argue that the very reason we're using From: and  
To: _instead_ of Organizer: and Invitees: is that it will feel more  
like normal email for new Chandler users.

User A, who is truly wedded to the Email mental model will never end  
up Sending an Information Item that is *not* From: User A.

The only way User A may get a shock is if another Chandler user (B)  
Edits and Updates an Information Item sent by User A and User A  
receives an Update that is Updated by: User B, yet still From: User A.

However, the hope is that the separate Updated by: field will clue  
User A into what has happened.

===

It's important that we are aware of these potential pitfalls in the  
design. However, at this point, I think the best way to understand  
how we might change things for better is to actually implement some  
piece of the proposal and Dogfood it and test it. In the mean time,  
we can also try testing the workflow with different attribute names  
for From: and To: with users. However, what we choose to call the  
From: and To: fields doesn't really affect the implementation design?  
Because regardless of what we call it, we know we want to separate  
the Email From: and To: from the Information Item From: and To:

Mimi :o)