I have updated the Email and Stamping specs with the results from the
following bugs and list discussions:
+ Figure out way to work in EIM Sharing and WebDAV sharing into
Accounts dialog: http://bugzilla.osafoundation.org/show_bug.cgi?id=8053
+ Re: Edit / Update workflow question: http://lists.osafoundation.org/
pipermail/design/2007-March/006619.html
+ Disallow creation of new messages in "In" collection: http://
lists.osafoundation.org/pipermail/design/2007-March/006650.html
+ Questions about name that appears in detail view bi-line: http://
lists.osafoundation.org/pipermail/design/2007-March/006569.html
+ Interesting idea to avoid EIM conflicts: http://
lists.osafoundation.org/pipermail/design/2007-February/006396.html
Changes are in pea-soup green.
Changes to the Stamping spec: http://svn.osafoundation.org/docs/trunk/
docs/specs/rel0_7/Stamping-0.7.html
I've mostly moved stuff out of the Stamping spec so that we only have
to describe/maintain it once:
The sections I've removed from the Stamping spec include:
The Detail View
For the following sections, please see Email spec for details: http://
svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Email-0.7.html
+ Addressing fields
Stamping and Bridging the Gap with Email clients
For following sections, see Email spec for details: http://
svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Email-0.7.html
+ Sending Items
+ Editing Sent/Received Messages
+ Receiving Items in generic email clients
+ Receiving Items in Chandler
+ Stamping and Reply, Reply All, Forward
+ Queueing up messages and dealing with the aftermath of an Outgoing
email error
===
Changes to the EMAIL spec: http://svn.osafoundation.org/docs/trunk/
docs/specs/rel0_7/Email-0.7.html
Simple simplifications of the Account Dialog
Chandler Hub Sharing
WebDAV Sharing
This is logged as: http://bugzilla.osafoundation.org/show_bug.cgi?
id=8053
Sending Items
5. Note: When Editing Sent or Updated items, the previous Sender: or
Updater: should be automatically added to the Chandler CC: field of
the message if they are not already mentioned in one of the
Addressing fields: From, To, CC, BCC. See list discussion: http://
lists.osafoundation.org/pipermail/design/2007-March/006619.html
(From the Stamping spec:)
6. Note: If the Sender or Updater of a message is listed in the
Addressing fields and is therefore going to be a recipient of the
message as well as the Sender, Chandler will be smart enough to NOT
pull down the message again into Chandler. However, the message will
arrive in the Sender's other email clients.
(From the Stamping spec)
Editing Sent/Received messages
When editing and updating items in Chandler, the Addressing fields
stay the same, the item UUID stays the same, the iCAL UID stays the
same. The only change is in the byline. The byline changes from
displaying in static text, whoever last created, sent, edited or
updated the item to a pulldown where the user can select an email
address with which to send the update.
Replying and Forwarding from different collections
See list discussion here: http://lists.osafoundation.org/pipermail/
design/2007-March/006650.html
Users should be able to reply to and forward messages from anywhere
in the UI, except for the Trash collection. However, if the user
creates a Reply or Forward message while in the IN collection, we
should not add the Reply/Forward message to the IN collection, but we
also shouldn't switch the user out of the IN Collection. See more
detailed behavior below.
Trash collection gets a pop-up:
New items cannot be created in the Trash collection.
[Okay]
IN collection
+ Don't switch context, as in don't leave the IN collection
+ De-select the message item the user is replying to / forwarding
+ Display the Reply/Forward in the Detail view
+ Add the Reply/Forward to the OUT collection (which will mean it
will get picked up by the Dashboard collection as well?)
All other collections:
+ Don't switch context
+ Add the Reply/Forward item to the selected collection and
automatically select it.
+ Display the Reply/Forward in the Detail view.
+ Add the Reply/Forward to the OUT collection (which will mean it
will get picked up by the Dashboard collection as well?)
Queueing up messages and dealing with the aftermath of an Outgoing
email error
When the user hits Send or Update in the toolbar:
+ Send as: or Edited by: pulldowns remain
+ Communication status icon in the Triage table stays the same
+ The only thing that changes is the Send/Update button, it greys out
+ Only when the item has been successfully sent, does the
Communication status icon change to reflect Sent or Updated status
+ Only when the item has been successfully sent, does the Send as: or
Edited by: pulldown turn into static Sent by: and
Updated by: text.
If the user is offline and hits Send or Update in the toolbar:
+ The Triage Table should display a Queued icon in the Communication
status column for that item-row.
+ The byline should change to Sent by: xxx on xxx
+ The Send or Update button should grey out when that item is selected.
When the user goes back online:
+ The message should be sent
+ The byline should change to Sent by: xxx on xxx (with the new time
when the message was actually sent)
If it turns out that an error is detected on a 'Sent' or 'Updated'
message:
+ The Triage Table should display an Error or Alert icon in the
Communication status column for that item-row.
+ An error message should appear in the same red-banner area used for
displaying Pending Changes, aka Conflicts
The Sent as: or Updated by: byline should go back to a Send as: or
Edited by: pulldown
See list discussion here: http://lists.osafoundation.org/pipermail/
design/2007-March/006569.html
What appears by default in the byline when an user creates a new item
or edits an existing item?
For draft message items: Send as, Edited by
+ Send as:, Edited by: field turns into a pulldown when users create
a new message or edit an existing sent/received message.
+ Once an Outgoing email account has been set-up, the item is updated
(so that the message can be sent) and the Send as: pulldown should be
updated.
+ Note: Emailness prevails": that is to say that if an item is
stamped as a message, the message items rules always apply.
Byline hack for Preview
For preview, we will be displaying the 'last user to edit or update'
an item, regardless of whether or not their change has been applied.
This is not the 'ideal behavior', but we will not have time to
address this before Preview. I have logged a bug to make sure we
address this post-Preview: https://bugzilla.osafoundation.org/
show_bug.cgi?id=8529
We did this in order to preserve 'lastModifiedBy' so that if User A
receives a change from User B and then User A syncs with Chandler
Hub, User A doesn't all of a sudden become the last modifier of the
item. Instead, User B's status as the last modifier should be
preserved on the item.
See list discussion here: http://lists.osafoundation.org/pipermail/
design/2007-February/006396.html
Byline and the notion of an Edit Session
We need some notion of an edit session so that the byline can display
correctly.
An edit session consists of all edits made to an item while it is
continuously displayed in the Detail View.
When users create a new item, the byline should display Created by:
for the entirety of the 'edit session'. (I believe currently, the
byline changes from Created by: to Edited by: as soon as the user
commits out of one field and edits a second field in the detail view.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
