On 9 Mar, 2007, at 15:39, Mimi Yin wrote:
Hokay,
This really confused me, so I'm going to try and de-confuse myself.
1. When user hits Send, the communications status should not
change, as in, it should remain a draft and the 'Send as: pulldown'
stays put.
OK (and the disabling of the "Send" button is a user indication that
Something Has Happened).
2. If the user is offline, the status should change to queued.
(When the user goes back on line, will the message be sent
automatically?)
A question for Brian Kirsch (who should chime in if he disagrees with
any of this) ...
3. If the user is not offline, as in they are online and the email
gets sent, then the status changes to sent and the byline changes
from 'Send as: pulldown' to 'Sent by: xxx on xxx'
4. If there is a subsequent error detected, the communication
status changes to 'Error' and the 'Sent by: xxx on xxx' text turns
back to the 'Send as: pulldown'.
Ya?
Ya!
--Grant
On Mar 9, 2007, at 9:39 AM, Grant Baillie wrote:
On 8 Mar, 2007, at 16:34, Mimi Yin wrote:
Grant, I thought the idea of letting recipients change 'Send as'
to 'Sent by' via sharing would work, but I realized that that
wouldn't solve the case where the Chandler user is sending items
to either non-Chandler users or Chandler users they aren't
sharing with.
Hmmm ... non-Chandler users don't have a "sent" item state. And
Chandler users they aren't sharing can still figure it out from
the From: header in the message. Regardless, perhaps this
procedure, where multiple users try to propagate a similar change,
is error-prone.
What's hard about changing 'Sent by' back to 'Send as' if there's
an error? Is it changing the byline field? Or recovering the
correct email account to display in the pulldown. The first part
is crucial, but the second part is a nice to have I think. We can
just display whatever is the default account, even if it's not
the email account that was used to Send the message.
Currently the item state is Queued when we hand the message off to
be sent (by a background thread). Usually, soon afterwards the
background thread completes, and the UI changes the state to Sent
or Error. That way, the UI always reflects its latest knowledge
about the item.
However, we could just as easily do what you suggest: mark the
item Sent before handing it off, and then only change state on
error. (I think that the UI already behaves correctly in terms of
enabling Send As when errors occur). The Queued state could go
away (and be reserved for a future "Delayed Delivery" feature). Is
this OK for Preview?
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
