[Design] [Proposal] Who are tasks assigned to in Chandler?

[Mimi Yin]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20071017/798d1d5c/attachment.html