Hi Mimi,
Thanks for reviewing this. I like the proposal and its spirit. I think
it'll clarify things a lot (will avoid for instance people to hit
"Update" when they don't mean to send an email again...). Couple of
thoughts:
- I think we still need some text in front of the "send as" pull down.
The fact that it's on 2 lines now is somewhat disorienting I feel.
- Now that we are explicit with "send update email", I'm wondering if we
need to change the Toolbar icon to the "Update" arrow. It seems to me we
could make things more simple by using uniquely the "Send" icon and text
and enable/disable it. After all, in "send update email", the verb is
"send" not "update".
- I think your "4-Nice to have" suggestions would be really useful. For
tasks in particular, it would make clear what this "to:" field is about.
- Last, really nice to have: expando... :)
Cheers,
- Philippe
Mimi Yin wrote:
I'm not exactly sure how to tie this proposal point-by-point to the
this thread on how to turn our Addressing fields into an intuitive way
to assign tasks, but here's a sketch of how we might go about doing
this for 1.0:
See wiki spec for
mock-ups: http://chandlerproject.org/Notes/EditUpdateWorkflowImprovements
*1. By default, stamping an item to address it does *not* necessarily
mean that you will send it out as an email.* This means a couple of
things:
* The only addressing fields that appear are 'To:' and 'CC:' Even
though CC is an email convention, I think it's very helpful in
assigning tasks and sending out invitations to meetings. It's really a
concept that should be extended beyond email, not restricted to it.
* The communication status column does *not* display a
'draft-status' icon.
* Send button does *not* activate as soon as user enters something
into To/CC fields.
* The Mail application area needs to be changed to something more
generic. Something that says 'communication' rather than email per se.
The icon should be changed to match the Addressing stamp.
* Below the 'To:' and 'CC:' fields is a checkbox where users can
opt to 'Send the item as email'.
*2. Checking the 'Send as email' box does a number of things:*
* 'From' field appears, auto-populated with the user's name
* Send as pulldown appears, auto-populated, same as now, with first
SMTP account listed in the Accounts dialog
* Communication status column displays a 'draft-status' icon
* Send button activates
*3. When editing sent/received** **messages, users have to explicitly
check the 'Sent email update' **checkbox in order for all the
'email-like' features to activate:*
* Update button activates
* Communication status icon displays 'draft-update' status
* Additionally, as Philippe has lobbied for in the past, in order
for this design to work, we *will* need to display the byline (at the
top of the DV) at all times (instead of mixing the byline with the
email pulldown).
*4. Nice to have: **More specific attribute labels for Tasks and Events*
* When addressing a task item: To becomes Assigned to:
* When addressing an event item: To becomes Invite:
I believe this proposal will address a whole host of usability
problems we've had with the whole addressing stamp workflow. In
particular:
* Draft status popping up when people have no intention of sending
email or update emails
* Users not understanding that the Update button is for email only
and isn't needed to apply to sharing edits
* Users not understanding that the Addressing stamp can be used for
more than just email
However, what is the cost? Is this do-able (implementation + testing)
in a 3 month timeframe? (Obviously this depends on what else we need
to work on.)
Mimi
On Oct 11, 2007, at 2:42 PM, Jeffrey Harris wrote:
Hi Mimi,
How about this: If a message also has the task stamp, we - rename
To -> assigned-to, - rename From -> assigned-by,
Do you think this is necessary? Seems like if To --> Assigned to:,
then From is sort of obvious. I've always felt there's something
vaguely fascist about 'Report/Assigner for Tasks and Organizer for
Events'.
I agree, the standard names for these field implies a structure that I
don't think matches most people's actual workflow for tasks (or events).
Fascist is maybe a little strong...
So, exposing a From: field to me when I'm trying to assign a task just
doesn't make sense to me. It screams email just as much as cc: or bcc:
to me. But if we hide the field most of the time, I don't care what we
call it.
What about Owner for Tasks? I think that's more egalitarian and
faithful to the kind of work dynamics we're espousing. At OSAF we
always talk about task owners, not assignees. Assignees implies
hierarchy. But perhaps owner isn't universal enough.
I like Owner better than Assigned-to, too, but it might be needless
jargon to add to the existing load of Chandler-specific jargon. Or
maybe not needless, labels set a tone, for sure.
Maybe we can leave the From: field blank by default for newly created
items and hide it unless the user fills something in?
I'm having trouble understanding what this means. Do you mean, once we
have collapsible email fields, hide the From: field, except when
email-fields are expanded (or when an explicit From: has been set)?
Would we by default hide the send-as drop-down, too? And does all this
apply to plain-ol' message-stamp-only items, or just to Task+Messages?
If I'm understanding all this right, it sounds good to me.
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
