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

[Mimi Yin]

On Oct 17, 2007, at 10:28 PM, Philippe Bossut wrote:

> - 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.

Yup. I was struggling with that. I added account next to the  
pulldown. I think it looks more balanced this way too, visually.

> - 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".

Hrm. I think it might still be important to emphasize the notion of  
'Update' as something separate from Send. (Also using the word Update  
calls it out as a unique 'feature' - speaking from the marketing  
perspective...) Can we see if users are still confused even with the  
'checkbox'? The Update button won't be available to them unless they  
check that checkbox, so hopefully there won't be any 'accidental'  
updates.

> - 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... :)

Yup. Added expando to the list on the wiki.

>
> 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
>>