I just thought of 2 more things:

===
1. We should spec out how the Communications status column interacts with Sharing.

Read, Unread, Needs reply...should be personal. Although in some situations you can see how you might want those attributes to be shared (e.g. 2 lab assistants processing support requests)

FOR ITEMS THAT HAVE BEEN SENT OR RECEIVED FOR THE FIRST TIME
In versus Out-ness should be shared...unless the sharee/user is in one of the Addressing fields on the communication. 

If the user appears in one of the Addressing fields, then In versus Out-ness is derived from where the user shows up in the Addressing fields.

+ For first-time Sent Items, the Item is Out if you are in the From: field, regardless of who sent it.
+ For first-time Received Items, the Item is In if you are in the To: CC: or BCC: fields, even if you sent it.

This has consequences for what shows up in the Who column as well.
+ For first-time Sent Items, the Who column displays the To: and CC: and BCC: attribute value(s), regardless of who sent it. (Hahaha, is BCC a private attribute? Perhaps it's only something the Sender and the people in the From: field can see?)
 + For first-time Received Items, the Who column displays 

THE IN AND OUT-NESS OF UPDATES SHOULD NEVER BE SHARED
+ An Update is inbound if somebody else updated the Item, regardless of whether the user is in the From: field or not.
+ An Update is outbound if the user updated the Item, regardless of whether the user is in the recipient fields or not. 

===
2. Error applies to more than just outbound Items. It applies to all shared items as well. So the flavors are:
Error - newly created item
Error - edited item
Error - inbound, first time
Error - inbound, update
Error - outbound, draft, first time
Error - outbound, queued, first time
Error - outbound, first time
Error - outbound, draft, update
Error - outbound, queued, update
Error - outbound, update

Errors include:
+ malformed email addresses
+ failure to connect with your smtp server
+ rejected from recipient's mail servers
+ failure to sync
+ conflict

Nice to have: Banner at the top of the detail view of Items with errors, explaining the nature of the error.

=====
Mark-up bar: [Triage]   [Address item] [Add to Task list] [Add to Calendar]   [Never share]

|| Error: Could not connect to your outgoing mail server. Please check account settings. ||

From:
To:
CC:
BCC:
Sent by: 

TITLE
location
...
=====

:o) Mimi


On May 26, 2006, at 9:55 AM, Sheila Mooney wrote:

Grant,

Those are great suggestions. I will work with Mimi to make those edits.

Thanks,
Sheila

On May 26, 2006, at 9:23 AM, Grant Baillie wrote:


On May 25, 2006, at 11:50, Sheila Mooney wrote:

Mimi and I have put together the first draft of the 0.7 stamping spec for review. This details the motivations behind stamping, the usage scenarios and the visual affordances we need in order to make this work. As discussed in the staff meeting today, stamping will now be an Alpha4 goal and Mimi and I will be working with Grant to figure out what functionality needs to be staged beyond Alpha4.


Stamping is very tightly coupled with some of the dashboard work and I hope to have a dashboard draft ready for the list in a couple of days.

I have also added this link to the spec list in the 0.7 planning page.

Hi, Sheila et al

A couple of editorial comments after my first reading:

- The "Communications Column" section would be a lot clearer if the second bullet item ("The user can click on the Communications status column to cycle ...") were moved to before the first.

- The 36-item list of different column states is a little daunting. It might be nice to preface this with a summary of how the Who column will display some of that state (via "UP"/"TO"/"FR"). It was also unclear to me (till Mimi explained it) that the "Unread", "Read" and "Needs Reply" states referred to communications with no addressing information.

--Grant

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to