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
