[Design] Stamping Storyboards Revised (a little)

[Mimi Yin]

Brian K and I reviewed the Stamping Storyboards to talk about how  
email threads might work in the Beta / 1.0 timeframe and along the  
way, I noticed a few errors in the storyboards, some things that have  
changed since the storyboards were created and some things that  
should be changed based on Brian's feedback.

As Brian K moves forward with email work for Alpha 4, it seems this  
is an opportune moment to revisit the Storyboards to flesh out design  
and engineering issues.

Please review the new storyboards and respond with any questions or  
comments.
http://wiki.osafoundation.org/bin/view/Journal/ 
StampingStoryboards#StampingWorkflow

Sheila, we will need to work together to update the Stamping Spec  
accordingly.
Brian K, please reply with amendments if I have misrepresented or  
missed anything.

Main changes:
1. In an effort to simplify the design, the Addressing Stamp in the  
Mark-up bar no longer displays different icons in tandem with the  
Communications status column.

2. Sent on, Updated on and Edited on dates have been added to the  
detail view.

3. Brian K pointed out that users might be confused about why the  
Send/Update button grays out sometimes. So I made the following  
changes. Other suggestions are welcome:

+ After sending an item, the Send button label changes to 'Sent'
+ After sending an item, the 'Send via' in the detail view changes to  
'Sent via'
+ After sending an item, the detail view displays the 'Sent on' date

The above is also true for Updated items.

Some issues that came up:
1. Security. If users can receive event items in Chandler via email,  
how do we prevent someone from spamming users with recurring events  
that could potentially crash the repository (e.g. 10,000 recurrences,  
etc).
+ e.g. When we pull down new event items via email, we don't  
automatically construct a stamped communications/event item from the  
email. Instead, we first ask users if they want to view the event and  
display the contents of the event in the body of the email, just like  
mail apps do with .ics attachments.
+ Question: Is this just an email issue? Is this also a problem for  
sharing? RSS?

2. When displaying message headers, we need to be able to display  
both the short message headers, the long message headers and the raw  
source. The long message headers and raw source will be too long to  
display in the detail view. We will probably need to find a way to  
either pop them up in a separate window or put the text into a  
scrollable field like the notes field.

Thanks,

Mimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060706/ce075011/attachment.htm