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
