Final Prototype Design Rationale
Shared Tasks
Shared tasks (and email) are the basic concept behind P2. A shared task is a public collaboration object that acts as a normal email in all recipients' email boxes, but can be updated by any party involved and, when subsequently viewed by other parties, will display the most up to date information. This information can be in the form of message posts to the shared object (rather than replies), newly-attached documents (instead of a separate, redundant email), status updates (e.g., if someone completes their portion of the task), or ownership changes (if a new collaborator is added to the one task rather than being forwarded a static copy). The following sections will detail exactly how we implemented these features of shared tasks and emails.
Task Space -vs- Project Space
Our support for shared tasks diverged radically from our previous designs which had used a Project Space to enable publicly shared, dynamic tasks. We found in our P0 testing that the Project Space, rather than bringing all information to one place, actually made a separate space from the Inbox that users were bothered to go look in and were confused as to its point. Thus we redesigned the collaboration space to fit comfortably and conveniently inside a single email so that not only do users not have a separate repository of information to search through, but users can apply whatever organizational pattern they use on their email system already to these shared collaborations.
People Palette
One of the largest breakdowns we found in our contextual inquiries was collaborators' difficulty in keeping track of responsibilities, activity, and status of other collaborators on a task.
Standard email clients do not make any attempt to support these facets of group and task awareness. We sought to incorporate a feature that makes these factors highly visible, and prominent.
The people palette is found to the left side an email window. The widget at the bottom of the people palette controls and modifies access to the shared space. History is shown as individual elements are modified. For example, if an owner changes their status to observer, or deletes the shared space from their Inbox, their status shows a modified clipboard, indicating that they previously had ownership. Users can upload their images to the TeamMail (we suggest that collaborators not use animated gif images).
Conversation Threading and Document Posting
One of our primary design goals for TeamMail was consolidating all information relevant to a task in one place. This is our answer.
The conversation area replaces reply/forward chains of emails that result in unreadable, unorganized, and unmanageable bodies of email that clutter users' Inboxes and folders. Task-relevant communication is now conducted by making a post to the email (with or without an attachment), and these posts are organized in reverse chronological order in the message body, starting with the original email. One could think of this as a sort of instant group weblog generated within any shared email or task. If one does not want to make a communication public to the task, replying or forwarding the shared object ignores all shared aspects of it and will work the way any normal email works, paying attention only to the original recipients and content.
Since documents are such a quintessential aspect of knowledge worker collaboration, post attachments are used to distribute updates and replacements to existing documents on a task, along with new attachments, exactly like mini-emails. One of the features of document posting that we designed but did not get to implement is that of versioning - the current implementation simply dumps documents into one large folder on the server, making collisions of document names highly likely within a task and between tasks. It addresses these collisions by simply overriding old versions, but a fuller implementation would properly auto-name files to enable older versions to continue to be accessed.
Update Notification
After a change is made to any publicly shared aspect of a task (status, ownership, posts, due date, etc), all collaborators on the task are notified of it by having that email or task show itself as an unread item in their Inbox. The 'date received' column does not change to reflect the modification date because to do so would risk the users' ability to know where the item is, if it moved of someone else's volition. This feature ensures that users will keep aware of activity on tasks they care about.
Task Bar Redesign
In P2, the Task Bar continued to evolve. By conceptually decoupling "shared" from "task," we were free to represent the two concepts with two separate interface widgets. We elected to keep a button to indicate task, and provided a nearby check box to indicate a shared state. Because the task button would now need to express more complex states (task/no task, shared/not shared, overdue/on time, read/unread, finished/not finished), we placed an icon beside the button. Moving the icon from the button surface to its side allowed us to keep the label stable, regardless of button state. This was a considerable improvement over the P1 button. When users click shared, a graphical link appears, bridging the physical space between the shared widget and the due date widget. This link symbolically ties the two logical entities, indicating to the user that due dates for shared tasks and emails are also shared data. Because our users showed that they could clearly distinguish tasks from email, we desaturated the color from a bright orange to a softer yellow. We also moved the completed check box to the right side of the panel. While users highly valued the feature, they tended to use it infrequently (tasks finish once, but due dates might change repeatedly). Subsequently, we chose to marginalize it in favor of other features that users were more likely to use repeatedly. Because we also observed that the task bar was taking up significant real estate, we repositioned the open/close widget so that it did not take up vertical space when the task bar was closed. This shrank the bar to be less than half its original size. We also linked the percent complete and status widgets with the completed check box, so that the contents of one affected the contents of the others. Likewise, when users move a task from 0% to 25% complete, the status widget automatically changes from "not started" to "in progress."
Task Icon Redesign
 |
 |
| P1 Task Icons | P2 Task Icons |
Based on feedback we received in our P1 testing, we looked to differentiate task icons from email icons. We colored the email icons yellow to assist in this. We added a shading to all icons to provided consistency with other icons found in Columba. In P2, we felt iconography was needed to communicate if a task was shared or not within the Inbox. We incorporated a small happy face on top of the icon to indicate if it was a shared task or email.
“I NEVER notice the difference between the mail
icon and clipboard.“
U20 P1 Diary Study
