- Email is widely
used for an extremely varied range of purposes. An important core
of email messages are the communication between people about common
tasks such as organising to meet each other, working on a joint
document such as a poster or planning the details of a social event.
- The fundamental
role of email is the broad support of message-based asynchronous
communication. This gives it the flexibility to support an arbitrarily
diverse set of user communication. This is an important part of
the reason that it has been so successful and widely adopted.
- At the same time,
it gives no explicit support to any one common class of tasks. This
means that there are many times when a user can find it challenging
to perform a task. For example, if the user receives a substantial
volume of mail, it can be difficult and tedious to work systematically
through all the messages related to that task. They will typically
be interwoven with the mail for other sets of tasks.
- Traditional e-mail
clients provide two forms of support for such management of tasks:
folders for classification of common mail and threading mechanisms
for recognising mail items that are an ongoing part of a conversation.
- IETMS explores
approaches to improving support for management of email conversations
by extending the power of the basic mail classification and threading.
Our goal is to assist users by automatically grouping the messages
of each conversation and by supporting the user in tracking the
status of the task.
Task-based email conversations
- In the context
of e-mail, a task can be defined as an exchange of naturally chained
messages. We call this conversation. It may involve an arbitrary
number of people. This may be just one, where the user talks to
themselves as they progress through a task but typically, it will
involve several people.
- The mail standards
RFC2822 and MIME specify headers which are recognised by most mail
clients. Some are very useful for predicting which mail items are
responses to an ongoing conversation.These include: Message-Id,
References and In-Reply-To. When
a person uses a MIME-compliant mail client to reply to a message,
the client includes a header with the Message-Id of the original
message in the References
or In-Reply-To
field of the reply message. This is illustrated in the example mail
below which has replies to the message with the id listed in the
References header. The mail also illustrates the valuable role of
the Subject line:
the MIME-compliant client preserves the same Subject
in reply messages, although it may add
re:. Major mail clients can use
such fields to automatically thread messages which have the same
message id or subject.
- This has some
serious shortcomings. The most serious is that people are undisciplined.
They often use the reply facility of a client to save typing an
email address. Such messages appear to be part of a conversation
but are not. Sometimes, people send mail as part of a conversation
but do not use the reply feature. Some people do not use MIME-compliant
mail clients. There is no support for declaring a conversation complete
or tracking other aspects of its progress.
From xxxx@it.usyd.edu.au Wed May 08 14:27:14 2002
Received: by staff.cs.usyd.edu.au with postie; Wed, 08 May
2002 14:27:14 +1000
Received: from mumps5.cs.usyd.edu.au.
by staff.cs.usyd.edu.au.; Wed, 08 May 2002 14:27:12 +1000
Date: Wed, 08 May 2002 14:27:06 +1000
From: XXX XXX <xxx@it.usyd.edu.au> Subject: Follow this up
To: staff@it.usyd.edu.au Message-Id: <1020832032.89.367098486@it.usyd.edu.au>
References: <5.1.0.14.2.20020508115535.01ade0e8@postbox.library.usyd.edu.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
*click image to enlarge
IETMS
- This builds upon iems,
the intelligent email sorter. This is similar to many mail clients,
with a window for the currently selected folder, one for the currently
selected mail item in that folder and one for the folder names.
The IETMS extensions support definition of conversations. In the
interface, shown above, they appear similar to folders.
- An important elements
of the iems interface is that it can use automatically induced rules
to presort the inbox. IETMS extends this by distinguishing which
incoming email messages are part of a conversation. This is illustrated
in the figure below. Then the inbox sorts the email within it, placing
mail predicted to be part of each conversation together and other
mail is still presorted into the predicted folder.
- To predict whether a
message belongs to a particular conversation, IETMS collects various
sources of evidence. This includes the MIME-headers for message
id and subject. It also uses the list of people involved in earlier
parts of the conversation: the more common the list of people on
two messages, the greater the likelihood they are part of the same
message. Finally, it uses text classification algorithms to analyse
the body of the text as an additional source of evidence. The last
will typically be rather limited in general since message bodies
will tend to be short. However, as one of a range of evidence sources,
it has some potential power.
Evaluation - Conversations About Scheduling
Meetings
- Evaluation of
the predictive power of IETMS is being conducted in the context
of the task of scheduling a meeting. As illustrated in the figure
below, this involve a quite complex series of email interactions.
The figure illustrates an example where the user initiates the conversation
by composing and sending a mail item requesting a meeting. This
might be sent to many people. As illustrated in the figure, once
the meeting initiator has sent the invitation mail, they need to
wait for responses from each of those invited. They may receive
a timeout or other error message. Otherwise,
once there have been enough replies, the initiator can declare the
meeting scheduled or not and this conversation is complete.
- The IETMS interface
provides a specialised interface wizard for the meeting scheduling
task. This ensures that the meeting initiator considers the standard
elements of a meeting: the time, duration, place, people to invite,
information to be provided to them, such as a description of the
purpose of the meeting. Status tracking is included along with an
automated reminder if a person fails to reply to the initial meeting
request within a defined time.
Future Work
- “Scheduling a Meeting” is one of
many tasks that could be performed using e-mail. Future work should
explore extension to other tasks.
References
- D. Comer and L.
Peterson. Conversation-based mail, ACM, 4(4):299-319, November 1989
- B. Croft and L.
Lefkowit. Task support in an office system. ACM Transactions on
Office Information Systems, 2(3):197-212, July 1984
- S. Flemming and
A. Kilgour. Electronic mail: Case study in task-oriented restructuring
of application domain. In Proceedings of IEEE: Computers and Digital
Techniques, number 2, pages 65-71, Marks 1994
- P. Resnick. RFC2822
Internet Message Format, http://rfc2822.x42.com, April 2001
- J. Takkinen and
N. Shahmehri. Coordination in message-based environments: Restructuring
internet e-mail to accomplish tasks
- J. Takkinen and
N. Shahmehri: Task-oriented restructuring of an application domain:
A multi-agent architecture for doing things in internet email. In
Proceedings of the Hawaii InternationalConference
on System Science, 1999
- S. Whittaker,
Q. Jones, and Terveen L. Managing long term communications: Conversation
and contact management
