Role Management and Email on
Campus: A Case Study
In order to accommodate the
increasing diversity of email users, applications have evolved in both
functionality and user interface.
In this study, we attempt ed to determine whether email user
interfaces can be improved to serve a specific target population: college
students. We present our results from
college campus surveys which examine email usage patterns and
subjective experiences among college students.
From our survey feedback and related research, we conclude that email
overload and feature intimidation are the greatest hindrances to email
communication on campus. To ameliorate
problems, we propose employing role management to organize messages and contacts
in an email program ,
to provide special functionality on demand.
We introduce a low-fidelity interface prototype
user reactions and preliminary test results. Our conclusion is that role management,
integrated into email software, may help college students organize their email
Email use is becoming increasingly widespread among
the general population, and particularly among college students. However, surveys presented in this paper suggest that
college students are not adequately served by current email software. The problems discovered include difficulty
organizing a large number of email messages and contacts, as well as failure to
use email application features due to their poor exposure and perceived
We propose to
alleviate these problems
by exploiting the categorical nature of college -related email correspondence. The contacts and messages involved in intra-college communication
often belong to well-defined groups (e.g. students and professors in specific
classes), which may be known ahead of time or communicated
remotely. This knowledge permits an email program to
automatically organize many of the messages and contacts by grouping them
visually for the user. Furthermore,
additional functionalit y
such as integrated class directory listings and event calendars are
possible with the requisite back-end support.
The functionality described above is designed to
aid a student
while the latter assumes a
“school role”. When dealing with other
messages, it may be useful to introduce a “work role” or “ friends role”. Role management in this paper refers to the
organization of email-related information by context, or role. Its potential benefits include filtering of
relevant information by role/subrole and special functionality within a
Much recent work has been dedicated to facilitating
task (or activity) management in
email by grouping together temporally
and semantically related messages
and/or resources (e.g. a conversation thread or documents related to a specific
task). While this method of
organization appears promising, it currently targets mostly users in a business
environment. Business users typically
engage in a variety of ephemeral tasks
related almost exclusively to their work role [
E], but college
students often assume a multitude of roles
(school, work, family, etc.) and subroles (different classes) which are
relatively permanent. We propose the
alternative strategy of role management
in a college environment to reflect the nature of such correspondence.
section outlines prior research on email demographics, email-related problems
and proposed solutions, and the application of role management to user interface
US Department of Commerce surveys show email usage among the general
US population at 45.2% in 2002, up from 35.4% in 2000 [ A]. College students represent a continuation of
this trend. A study by the Pew Internet
and American Life Project in 2002 indicates that “college students are heavy
users of the Internet compared to the general population… in part because they
have grown up with computers. [The
Internet] is integrated into their daily communication habits and has become a
technology as ordinary as the telephone or television” [ C]. The study found that 72% of
college students check their email at least once a day. 68% report subscribing to one or more
academic-oriented mailing lists.
with its increasing number of users, email has been used in an increasing
number of ways. In their 1996 study of email overload, Whittaker and Sidner
observed that people were using email for task management and personal
archiving [ D]. They describe the goals of task management
as “[ensuring] that information relating to current tasks is readily
available”. The researchers conclude
from a study of Lotus NotesMail users that keeping email organized presents a
major problem for some email users, resulting in backlogs of unread and unanswered
2001, Duchenaut and Bellotti concluded further that email is being widely used
as a personal information manager (PIM) [ E]. Through interviews, they examined how people
sort their email messages and deal with clutter in a business environment. The researchers suggest that “to
better support the use of email as a PIM tool, organization of folders should
be more flexible… the management of to-dos and reminders within email should be
supported”. The interview results
indicated that available software did not
adequately expose such features.
They raise the following question based on their research: “Would it be
possible to leverage a model of users’ roles and organizational environment in
the design of email clients? One
possible way would be to present
a different interface, with different email management options, depending on a
2003, Duchenaut and Bellotti introduced a prototype of a task
management-centric email client, and received mostly enthusiastic feedback from
business users who tested it [ O].
Two other papers [ P, Q] were published in 2003 on organiz ing information
by task or activity. The
researchers’ choice of task
management over role management
appears to suit observed business usage patterns, where employees often juggle
many short-lived tasks—all within the single role of their job [ E]. However, in the case of campus email
our surveys suggest that students assume a large number of relatively permanent
roles. Hence, a role management approach may be fitting.
amount of available research on role management in software is presently
limited. In 1994, Plaisant and
Shneiderman introduced the idea of role management in
application to software user interface design [ F]. Their proposal is rooted in earlier research
from social psychology and organizational design [ G, H, I]. The researchers quote Singh and Rein: “Role
theory views individuals as occupying positions in organizations… Roles are the
building blocks of organizational phenomena as division of labor and
specialization” [ J].
In 1995, Plaisant and Shneiderman created a
software prototype of a computer desktop that uses role management
[K]. Their prototype attempts to ease coordination between World Bank employees in their
everyday duties, particularly those working on multiple projects. The presented design uses multiple views
corresponding to the personal, workgroup, and institutional roles of an
employee. When using a specific role,
its relevant section of the view can be zoomed to fill the entire screen.
A form of role management for college use was introduced
in 1997 by Kandogan and Shneiderman [ L]. Th ey introduced a hierarchical windowing
scheme that employs elastic windows to fill the screen area without overlapping [M]. Top-level container windows correspond to
roles, such as Research, Teaching, and Industry in the case of a professor;
each can be maximized to fill the screen.
These windows contain child windows representing specific subroles, such
as different classes that a professor teaches.
User testing with scenarios yielded a statistically significant
performance advantage over a conventional windowing system.
To the authors’ awareness, no role-centric email
applications are available to date.
However, the preceding research makes a case for
exploring role management for email clients on campuses. The following
section describe s information
gathered about the target student population, and the
section titled Proposed Solution present s a simple prototype
a “student role” might be implemented in a role-centric email program.
In order to assess the adequacy of current email
software in meeting the needs of a college
student population , the first of two surveys was
conducted. The results suggest that
current email software is not adequate for
many of the respondents. Furthermore,
the observed usage patterns are distinct from those of business users. A second survey probed for opportunities to
improve email interfaces for college students.
It examined the relative usefulness and exposure of specific email
features and asked for subjective opinions regarding potential enhancements.
Survey #1 measured student email activity and
inquired about specific features that students like or dislike. A total of 80 surveys were distributed in November
2001 on the College Park campus of the University of Maryland; 35 valid
responses were returned. 34 of the
respondents were between the ages of 17 and 23.
statistics show relatively intensive email usage: 100% of respondents indicated
they check their email at least once daily, and 86% check several times a
day. Additionally, 89% of respondents
stated that they have multiple email addresses. Figure 1 shows the breakdown of email programs used (some
respondents use more than one).
Non-Hotmail Internet email includes Yahoo Mail, AOL, and Netscape
Messenger. PINE is a text-based
menu-driven email client on the U niversity’s network.
Figure 1. Email
The survey asked to check off
email functions that a student uses on a regular basis. The responses are shown in Figure 2. While nearly every respondent performs basic
functions, some “ ghost” features are
relatively unused. Low utilization is
expected of features that are inapplicable to most users; however, there are
indications that complexity and poor exposure also alienate users from certain
features. For example, although 100% of
respondents receive junk email, only 43% reported using filters to block it, 6%
were uncertain of what filters are, and 40% suggested that filtering should be
improved—including its ease of use.
The latter findings are consistent with Duchenaut
and Bellotti’s observations of business users [E].
Figure 2. Email Function Us age.
how students organize their messages revealed prevalent use of folders, employed
by 80% of those surveyed. Among folder
users, 75% use the message subject as a criterion for filing messages into
folders, 43% differentiate by sender, and 18% organize by date.
The number of folders was kept below 10 by 75% of
respondents. This restrained approach
contrasts with the median of 27 folders reported by business users [E]. One possible explanation is that the
students’ sorting hierarchy is more permanent , while
business users admitted to using many temporary folders. The alternative explanation that students
simply eliminate older items appears improbable, because 48% said they keep the
majority of the messages they receive.
Another 31% keep between one-tenth and one-half.
When looking for a specific message, only 46%
indicated willingness to conduct a search of their inbox. Duchenaut and Bellotti observed that the
sorting feature often provides a more convenient alternative [E]. Figure 3 shows the preferred search criteria
amongst those willing to search.
Figure 3. Message
attitude section of survey #1 asked respondents to list features they like
about their current email program.
Students named the following features most frequently:
Support for multiple email
Asked to list problems with their email program,
respondents named the following user
Difficulty changing how features
Difficulty setting up
Suboptimal default settings
Lack of spell
Complexity from overabundance of
features (feature overload)
An anecdotal example of feature overload is the
fact that the multiple-signature feature was reported as a problem . Among other reported issues, those related to improper automation
include auto-deletion of messages to compact space and failure to automatically
save outgoing messages. Respondents
also voiced a concern that junk mail filters may block legitimate
messages. Finally, general
functionality-related problems include storage space limitations, inability to
attach large files, failure to block junk email, susceptibility to viruses, a
large memory footprint, and confinement to one computer (77% found access to
email from multiple computers important).
Another significant departure from business users
is the students’ tendency to use email for non- school
purposes. While businesses often
discourage using corporate email for personal purposes, the same is not true of
universities. At least 40% of
respondents admitted to communicating with each of the following by email:
significant other, sibling, parent, another relative, friend, and coworker. These are fairly permanent relationships,
unlike the temporary contacts of business workers.
Although it is not a statistically accurate sample
of the entire student body, s urvey #1 provides a degree of
insight. It appears that current email
software is not entirely adequate for many of the respondents. Disregarding the technical shortcomings
limited to specific email programs, the following issues appear to be
unresolved: limited tools for organizing one’s email messages (indicating the
greater problem of email overload ); and poor exposure and presentation
of a complex feature set ( feature
Examining these problems further and evaluating potential solutions was the
goal of survey #2.
Survey #2 was administered in April 2002 to 47
individuals, most of whom were students at the University of Maryland, College
Park. All 47 produced valid
responses. The survey inquired about
specific details of respondents’ interaction with their email program. It also probed for features that users
avoided and reasons for the avoidance.
Finally, subjective questions were asked regarding respondents’ attitudes
towards potential user interface changes.
Users of standalone graphical email programs such
as Outlook were asked details of their interaction
process. The goal was to find unused as
well as popular features of the interface.
A revised design might prune the former , and increase
the accessibility of the latter .
Menu and toolbar shortcut button usage were the
first items examined. Among applicable
respondents, pull-down menu use fluctuated with personal differences. 36% ranked their menu bar usage as frequent,
32% as medium, and another 32% as infrequent (7-9, 4-6, and 1-3 on a scale of 1-9,
respectively). Respondents were asked
to indicate which toolbar shortcut buttons they used on a regular basis; Figure
4 shows the results among applicable users.
These statistics suggest a general preference of the toolbar over the
Figure 4. Toolbar Buttons Used.
Functions used regularly but not found on the
toolbar by several respondents include:
To further investigate the adequacy of the
filtering feature, respondents were asked if they knew how to use
filtering. 9% replied that they did not
know, and another 32% were unsure. This
impaired awareness supports the notion that inadequate exposure diminishes the
accessibility of the filtering feature.
The user attitude section of survey #2 revealed
that 72% of respondents would like to have their emails sorted into folders for
them. Also, 72% expressed interest in a
feature similar to AutoCorrect that fixes common typing and grammatical errors.
The remaining questions explored user interest in
adaptive interfaces [N]. When asked
their level of enthusiasm for an interface that visually
adapts to their personal preferences, 66% exhibited at least some interest (6-9
on a scale of 1-9). However, most users
wanted to be prompted before changes: half the respondents wanted notification
before any changes, and another 17% wanted to be informed before any
non-trivial changes. In fact, 70%
preferred to make changes to an interface themselves. Finally, user attitudes towards privacy were examined. 42% of respondents indicated discomfort with
a program that keeps track of their usage patterns (for the exclusive purpose
of adjusting the user interface).
Users’ limited willingness to give up control raises questions on the
viability of adaptive interfaces in email design.
Survey #2 reveals several user interface
improvements that the respondents would find helpful, as well as
constraints. For cleaner feature
presentation, the toolbar is a tempting target for visual design changes or a
better selection of exposed buttons.
However, automatic changes to a toolbar’s selection are hazardous—users
appear wary of such changes. Also,
feature overload could be mitigated by hiding rarely-used features, making them
accessible only through the pull-down menu.
As far as dealing with email overload, folder filing and filtering need
better presentation to overcome their present obscurity. These features must also work predictably to
reduce user anxiety over misplaced email.
on the feedback received, we set out to create a user
interface that alleviates the main problems for college
students: email overload and feature overload.
We believe that role management could address these
problems in two chief ways. First,
organizing messages by role and subrole reduces email overload—students often assume a fair number of enduring
subroles between which messages could be divided. Second, the ability to select a current role permits hiding
functionality irrelevant to that role, alleviating feature
overload. A lighter feature set also
leaves more room for special functionality in a given role, such as a school
designing a role management user interface, criteria for simplicity were
established. The interface had to be
sufficiently familiar to current
email users. Ideally, novices could use
the program exactly like existing
email software while they explored the role management functionality. The additional overhead from using role management ought to be minimal ,
for the user and for any administrative support, to reduce the
design process involved several brainstorming sessions and a selective
synthesis of ideas into a single interface.
After several revisions of sketched paper mock-ups, electronic screenshots
were generated to better resemble a computer interface. Figure
sample screenshot of the proposed interface.
The most significant
departure from standard email clients is the presence of
selection tabs. Each role
represents a separate environment where only messages, contacts, and functionality
relevant to that role are visible.
For contextual cues, a different visual theme
would distinguish each role; this may include colors, fonts,
icon style, and others . Nonetheless , the roles are
not mutually exclusive. A given message , contact , or function would
visible in any role to which it is marked as related. Essentially a role acts as a portal to the most
relevant messages, contacts, and fu nctions .
subtasks belonging to a role are represented by the treeview
under “Sections” in Figure 5. They could be nested within
reason. Similarly to
roles, they behave
non-exclusively—unlike the folder treeview in
common email programs. For example, the “ENEE
408E” node will display all messages related to that course, including all three
subsect ions . To make the distinction clear for the user, these
subsections would be
highlighted when “ENEE 408E” is selected.
Such a treeview creates a filtering hierarchy
that gives the user control over the breadth of information presented.
The inclusion of children in the parent would
in the treeview under Contacts: clicking on a root node could open
a letter to all
recipients in a group .
The General role is special because it encompasses
messages and contacts from all
other roles. Consequently, the General role acts like a regular email
application and satisfies the criterion of providing a foothold for novices. The other purpose
of the General role is to hold correspondence that either does not fit any defined role, or that the user
has not yet assigned to a
role. The Sections treeview under
General would reflect this by providing a child node
encompassing General-only content, which descends from a root node
that contains everything.
Each role may allow several possible views, which
are modes of operation that monopolize the screen area. The Mail view is the default and provides an
interface to the user’s mailbox (depicted in Figure 5). The arrows illustrate the left-to-right and
top-to-bottom subordination between the four adjacent panes, similar to
existing email clients.
The views are one possible vehicle for delivering
role-specific functionality. Figure 6
illustrates one such possibility—a school calendar view. The calendar can display data in a manner
convenient for school-related tasks, such as presenting a semester layout. A school directory
could also be provided .
Another proposed tool for
role-specific functionality is the collapsible information panel,
the right . The panel
be used to screen the most important information (such as clickable top
contacts and reminders) from each subrole.
It could also be clicked to select
the current subrole, as an alternative to the Sections treeview. Finally, the bottom portion of the
information panel provide s
a summary of views that are not
currently visible. In Figure 6, it reminds
the user that new mail has arrived, which could be found in the Mail view
(clicking the reminder would switch to it).
While auto-selection of important information may
not be reliable, the assumption of a school context and additional back-end
functionality could improve accuracy. The information panel is essentially the automated equivalent
to the user via the role/subrole hierarchy.
Some details need to be included on the technical feasibility of this interface . One important question is how the program
could determine what messages and contacts fit under what roles. The most predictable
approach is to assume nothing until the user adds messages to the desired role
(a one-click interface could
do this). All subsequent correspondence
with the added person would be included
in that role until the user cancels the association. Unassociated messages and contacts remain only in the
General role. This method could be seen
as a simple form of filtering.
Another issue is delivering the desired
role-specific functionality. For
example, automatically adding dates
to a calendar or
finding important news is beyond standard email capabilities , and
cannot be accomplished reliably by present AI. One way to facilitate such features is with
back-end functionality at the institutional level. This may require a university to run
a server with news
or schedule updates. This centralization
could be avoided by an
alternative possibility : metadata support. The email client could
provide tools for embedding role associations, news items, schedule changes, or
other meta-information into outgoing messages. Upon receiving such messages, the client
could reliably read and act upon the information (with requisite security
considerations). Metadata-unaware email
clients would simply ignore the data.
Despite such accommodations,
special functionality is unlikely t o transcend roles such as
School, where the university or professors might provide
support. People under
Friends and Family roles are not likely to provide servers or to embed metadata. In these cases, the interface would need to degrade gracefully. The
software could provide templates for commonly-used
roles like Friends and Family, including basic artificial
intelligence to look for such things as birthdays. Ultimately, when no
assumptions can be made about a role, the system continues to provide the
benefits of splitting content between roles and subroles—a simple form of
filtering controlled by the user. The main objective of
limiting email overload is not compromised.
DESIGN TESTING AND FEEDBACK
As a preliminary assessment of this role management
interface, we conducted scenario testing and interview sessions.
20 students from
the University of Maryland were interviewed during November-December of
2002. The testing procedure involved
printed prototype mock-ups, and was designed to measure the subject’s
understanding of the interface. Before
testing, initial impressions were asked and recorded. Several scenarios calling for simple tasks were then
presented. No prior training or
demonstration was provided. The
subjects were encouraged to verbalize their thought process, and their remarks
were recorded. A follow-up interview
was conducted afterwards.
From the initial impressions, many of subjects
considered the interface
excessively “busy”. These subjects were asked what information
they would eliminate, and how well the information was organized. Several subjects identified the
information panel as expendable, but most were
satisfied to learn that it could be collaps ed. Feedback on the organization of information was generally
positive, and the hierarchical views in the Calendar received praise. One student commented that it was easy to
focus on short-term activities without losing sight of long-term goals. The majority of subjects recognized the
purpose of role folders right away; some others initially
mistook the Work role tab for campus job searches .
In the scenarios, the subjects had little trouble
recognizing the involved interface features, including the view selection
buttons, the information panel, and the contacts treeview. Asked to look up the dates of next
semester’s spring break, 75% correctly selected the Calendar view and
manipulated the pull-down semester menu. Starting from the Calendar view, the subjects were asked to email
their class instructor. 60% took the
shortest path by using the instructor email link in the information panel,
while the rest preferred to switch to
Directory or Mail view s. When asked to check for snow-related class
cancellations, 85% correctly selected the University News link in the
information panel. To send a mass
email to everyone in a class, 70% made the optimal choice by clicking the
class’s root node in the Contacts treeview inside the Mail view.
follow-up interviews examined the interface’s perceived viability as a personal information manager (PIM). This issue is relevant to the target
audience, since 65% of the subjects admitted to using a date book or another
kind of scheduler. 70% said they would
consider using a program like the one presented in place of their current
planner (if they had one). 65% said
they would use the program to check their daily agenda . While
such statements may not predict actual usage, they suggest a generally positive
reaction. The remaining questions
involved automation, and the students remained opposed to unattended changes:
75% wanted to be notified of changes to their schedule and to be asked their
non-functional nature of our prototype precluded testing the interface’s
capacity for managing email overload.
However, the preliminary testing results suggest that major features of the interface are sufficiently
well exposed to be readily used—including
special school-related features. This
indicates that feature overload may be reduced when functionality is filtered by role.
findings on campus email
usage have several implications for those
designing future email clients:
Students use email
differently from business user
s. They communicate with
a variety of well-defined and enduring groups of
people, including many not related to school . Although school-related email use is heavy,
functionality beyond simple messaging is surprisingly sparsely
clients do not adequately meet students’ needs.
Most students use planners and report a
willingness to use email for personal information management (PIM) tasks;
however, the majority fail to use the functionality provided by current
software for such tasks. Feature
overload is the apparent culprit.
The same problem
applies to tools for managing email overload.
Most students keep a significant portion of their incoming mail. They would like to have the messages
automatically sorted into folders, but don’t seem to know how—or worry that
Role management may
reliev e the above
problems. It addresses both email and
feature overload by acting as a user-controlled filter and selecting only
relevant messages, contacts, and functions to be simultaneously presented
interface illustrates one way that role management might be implemented;
initial reactions from students are enthusiastic.
The creation and testing of a functional
prototype would be the next step in evaluating the
practica bility of this approach