Future Recommendations

There are a number of future directions we think would be valuable for Sun to consider in deciding where to take TeamMail.

New Directions

There are some major integrations that could happen between TeamMail and other upcoming Sun products that we feel would greatly benefit both.

Calendar integration

This is huge. Over half of all users in our P1 user tests explicitly requested calendar functionality for task management. The majority of the requests fell into 2 categories - some differentiation between tasks and appointments (tasks that don't need to be acted upon until they happen), and a calendar-based visualization of due dates. We strongly feel that merging TeamMail with a calendaring/meeting system is the single most valuable proposition that has emerged from our project, and the clearest path forward.

"I'm used to having tasks linked to calendar entries more so than email"
U41 - P1 Diary Study

"I want differentiation between appointments and tasks because appointments I don't want to be reminded of constantly"
U40 - P1 Diary Study

"I wanted to see all the task due dates at once, like on the calendar"
U22 - P1 Diary Study

People Palette status awareness

Our 4th largest breakdown from our initial contextual user research was awareness amongst collaborators.

From the beginning, many of our design ideas incorporated real-time communication and coordination, but in scoping our project, we decided that integration with IM systems was better suited as a future direction. The People Palette was originally inspired by thinking of ways to support real-time interaction, and we feel Sun would be remiss if it did not seriously pursue at least the representation of IM status within the TeamMail client. If IM systems are still to be outscoped, it would not be too difficult to calculate some server-stored metric about a person's availability based on their pattern of email checking as an alternative.

Scaling to project management

One of the key value propositions of TeamMail is that our task management system is extremely lightweight, organic, and bottom-up, as opposed to the current heavyweight, externally/top-down imposed project management systems. While we made an explicit decision not to allow management concerns to overly influence out designs (because such influence almost always drives away end-user incentive to participate in the system), we feel that the lightweight system we have supplied might, in fact, be capable of supporting somewhat heavier weight management applications.

One of the more concrete designs we developed in this area was the 'Project Space' idea in P0 that we later decided was outside the scope of this project. The basic idea was that all activity associated with a project is visible to all project members in a project space accessible from a special folder in their email clients (initial Project Space idea 1, 2, 3, 4). The Project Space heavier than TeamMail's current incarnation in that it required users to go to a place outside of their Inbox and it exposed more information with less awareness of who can see what (any project member can see a task's status, whether or not they've been addressed on that task). Nevertheless, several of our test users felt that the true test of TeamMail's usefulness would be whether or not it would integrate well into a hierarchical organization, so we feel much more attention is due to the project space design and alternative ways to allow our lightweight tasks to evolve and interact to produce full project management solutions.

"What if a manager from another dept sent you this task but is that more important than this task that my boss sent me?"
U21 - P1 Diary Study

Unanticipated Uses

Our initial testing of the final prototype also revealed some interesting new opportunities for TeamMail from unanticipated user activity.


Revisions to TeamMail

There are some issues with the existing TeamMail design that could use some tweaking.

Filtering capabilities

We knew that it would be helpful to enable users to get a digest of their tasks, and we purposefully designed the '5 day forecast' Days Left indicator to be a sortable column to support this. This function was very well received by almost all users who discovered it (8 of 15), despite some trouble in determining where new email arrived. We soon learned, however, that simply sorting is not quite enough; there's still too much noise in the Inbox. Users wanted the option to pull tasks and emails apart and only see what is immediately relevant. Thus it is clear that a filtering mechanism is needed in addition to our sorting.

"Part of the whole reason of the task list is to see what you have left to do and even though it's really clear that those things below are emails, it would still be really nice not to see them."
U23 - P1 Focus Group 2

Reminders

We explicitly designed the task icons and Days Left indicator to make sure users were reminded of tasks they needed to pay immediate attention to. It seems we succeeded, but again, there is further to go - 5 of 15 users requested more explicit reminders to be available for tasks. We feel this would be a low cost, much appreciated addition.

"I find myself wanting to set event reminders along with tasks, even though they don't have a due date, exactly"
U23 - P1 Diary Study

Activity notification

When shared tasks underwent a change of state due to the actions of a collaborator, they get marked as unread in a user's inbox. This is meant to draw the user's attention to activity that they should be aware of. What we continually noticed in our P2 testing, though, is that once notified of a change, the user has a formidable task ahead of them to figure out what specifically about the task has changed. Many of these updates are really fairly trivial - does user A really need to know that user B is now 50% done instead of 25%? Perhaps, but it is clear this notification system deserves a second round of design.

Start date

Admittedly, we're getting into smaller fish here. A task start date is really not the most crucial part of a task system, but we felt it worth noting an interesting user response to this field. Our implementation allowed users to enter start dates, but those dates did not have an affect on any other part of the system. All who used it (which admittedly was only 2-3 of 15) did not continue using it for simply this.

"I tried to use start date once but there is no indicator in your inbox of different start dates so I stopped using it"
U20 - P1 Diary Study


Future Implementations

We have some implementation suggestions for Sun in the case that TeamMail becomes a part of their product line.

Columba, as a base platform, was invaluable in creating a fully functional email client prototype over the course of our 8 month project. On the other hand, our in-depth experience with modifying the Columba source indicates one thing very strongly - it is NOT a production level platform that Sun could build a product on. We found their code poorly documented, quite unstable, fairly platform-dependent, and overly complex in architecture - the result of rather idiosyncratic and non-standard choices in UI design.

As for the backend, it would be in Sun's best interests to make the functions of future versions of TeamMail as little dependent on email clients as possible. The functions of the TeamMail server could be incorporated into an advanced IMAP server that supports a TeamMail API as well, and perhaps automatically updates copies of IMAP messages server-side so that it is not the email client's job to manage task information. In fact, many of the client-to-server task management commands could be enabled by having the server embed dynamically generated HTML in emails, so that clicking a task button, for example, uses http to call a web service on the modified IMAP/TeamMail server.

Something else that would seriously aid in TeamMail's usefulness would be an RFC proposal for incorporating task features into email. We did not investigate the feasibility, but many such proposals are on the table at imc.org.


User Testing

Finally, we have some user testing suggestions after our experience on this project.

There is one crucial lesson we learned in our user testing of TeamMail - the test groups selected should be screened. It would be useful if they possessed at least one of the following qualities:

Also, it is worth it to note that the longer an email study, the better. Time pressure meant that we could only run a week-long test on most of our groups, but several months of user testing will be needed to fully analyze the usability, usefulness, and desirability of TeamMail.


Ethical Considerations

TeamMail allows for closer and more inter-dependent collaboration as users can more closely monitor who is working on what. But these collaboration features present interesting ethical questions, both for designers and companies looking to use the software.

Opportunity for deception

TeamMail provides information that is not vetted by an external source. So while teams might benefit from this sharing of information, groups are also susceptible to falsification. Individuals could potentially misrepresent both what they have done and convince others to depend on that false information.

Privacy

While groups and organizations might benefit from a more transparent flow of task information, individuals might not be willing or comfortable in exposing this information about their practices and habits. Further, this software opens the question of whether it is appropriate for groups and organizations to allow this kind of access to their members.

Trust

By targeting an informal workflow, users can change ownership status of themselves and others without their knowledge and/or approval. This opens the system to gaming in ways that were not available in email. Free riders could add themselves as owners at the very end of a task, thus giving the appearance that they participated in the work. Similarly, users could change other colalborators from task owners to observers, and give the appearance that those others have denied responsibility.

(In)Discretion

While collaboration in general has been susceptible to inflammatory comments of many sorts for a long time, the low cost of email makes it easier for these kinds of antagonistic communications. An informal TeamMail conversation can grow in an organic way, inviting new users at any time a current participant deems appropriate. Within this flexibility may lie the potential to embarrass users by exposing them to inflamatory content. While this already happens in e-mail (called flaming), users are not invited into live discission. It will be interesting to observe how TeamMail conversations affect contentious situations, and if users manipulate situations with hijinx on the brain.

Ethics Conclusion

TeamMail may create new venues to both build ties of trust between individuals, and new ways for those ties to be violated. It will be interesting to watch the use of TeamMail evolve as it grows into a more mature application under the stewardship of Sun.

TeamMail group member Bio's Next arrow