Role Management and Email on Campus: A Case StudyA Design Study of the Integration of

Email and Role Management for University Students

 

 

 

H. Ross Baker¹, Nicolas B. Duarte¹, Aydin Haririnia¹, Dawn E. Klinesmith¹, Hannah Lee¹, Leonid A. Velikovich¹, Alfred O. Wanga¹, Matthew J. Westhoff¹, Catherine Plaisant^1*

 

¹University of Maryland,  College Park, College Park, MD 20742.

 

Integration of Email and Role Management

 

^*Corresponding Author:

 

 

 

 

Plaisant-Schwenn, Catherine, Assoc. Director, Inst for Adv Computer StudiesHuman-Computer Interaction Laboratory , 3173 A.V. Williams Building

, University of Maryland, College Park, MD 20742, ph: 301-405-2768, plaisant@cs.umd.edu

 

 

 

H. Ross Baker is a computer scientist with an interest in linguistics; he is a graduate student in the Linguistics Department of Northwestern University.

 

Nicolas Duarte is an Electrical Engineer with an interest in molecular electronics and bioengineering; he is now a graduate student seeking his Ph.D. in the Electrical Engineering department of Pennsylvania State University.

 

Aydin Haririnia is a biochemist with an interest in protein NMR and crystallography, he is now a graduate student seeking his Ph.D. in the Department of Chemistry and Biochemistry at the University of Maryland.

 

Dawn Klinesmith is a civil engineer with an interest in structural engineering; she is a student in the civil and environmental engineering department at the University of Maryland, College Park.

 

Hannah Lee is a recent graduate of the University of Maryland with an interest in Physiology and Neurobiology.

 

Leonid Velikovich is a computer scientist with an interest in computer graphics; he is an undergraduate student in the Computer Science Department of the University of Maryland at College Park.

 

Alfred Wanga is an electrical engineer with an interest in electronic materials and devices. He is a student and will be attending graduate school at Penn State University.

 

 

 

 

ABSTRACT

 

In order to accommodate the increasing diversity of email users, applications have evolved in both their functionality and user interface.  In this study, we attempted 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 whichsurveys that  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 address these problems, we propose employing role management to organize messages calendar and contacts in an email program for students, using school, work and family roles., and to provide special functionality on demand.  We introduce describe a low-fidelity interface prototype and include user reactions and preliminary test results.  Our conclusion is that role management, integrated into email software, may help college students organize manage their email more effectively. 

 

 

 

contents

 

1. INTRODUCTION

2. PREVIOUS WORK

3. SURVEYS

4. PROPOSED SOLUTION

5. FEASIBILITY CONSIDERATIONS

6. DESIGN TESTING AND FEEDBACK

7. CONCLUSION

1.  INTRODUCTION

 

  Email use is becoming increasingly widespread among the general population [1], 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 complexity.

 

 

We propose to alleviate address these problems by exploiting the categorical nature of college-related student’s’  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 beare known ahead of time or and can be communicated remotelyautomatically.  This knowledge permits an email program to automatically organize many of the messages and contacts by grouping them visually for the user.  Furthermore, additional functionalitiesy such as integrated class directory listings and event calendars becomeare possible with the requisite back-end support.

 

The functionality described above is designed to aid a student while the latter assumes aby making use of a “school role”.  When dealing with other messages, it may be useful to introduce a “work role” or “friends family role”.  Role management in this paper refers to the organization of email-related information by context, the main or roles assumed by users.  Its potential benefits include filtering of relevant information by role/subrole and special functionalitycustomization within a given role.

 

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 [2E], 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.

 

2.  PREVIOUS WORK

  This section outlines prior research on email demographics, email-related problems and proposed solutions, and the application of role management to user interface design.

 

  The US Department of Commerce surveys show email usage use among the general US population at 45.2% in 2002, up from 35.4% in 2000 [3A].  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” [4C].  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.

 

 

   Along 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 [5D].  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 mail.

 

In 2001, Duchenaut and Bellotti concluded further that email is being widely used as a personal information manager (PIM) [2E].  Through interviews, they examined how people sort their email messages and deal with clutter in a business environment.  The researchers suggest thatsuggest, “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 beis to present a different interface, with different email management options, depending on a user’s role”.

 

In 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 [O6].  Two other recent papers [P, Q15, 16] were published in 2003 ondiscuss email organizeding 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 [3E].  However, in the case of college campus email useage, our surveys suggest that students assume a large number of relatively permanent roles.  Hence, a role management approach may be fitting.

 

  The 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 [7F].  Their proposal is rooted in earlier research from social psychology and organizational design [8, 9, 10G, 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” [11J].

 

In 1995, Plaisant and Shneiderman created a software prototype of a computer desktop that uses role management [12[K].  Their prototype attempts toillustrates how role management can 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.

 

   An example  form of role management specificallydesign for college use professors was introduced prototyped in 1997 by Kandogan and Shneiderman  [13, 14L].  This research focused on the window management aspects of the interface andey 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. In another domain, Barreau and Nardi [16, 17] have argued for the importance of location-based saving and searching, and have shown that the user's perception of their information space and the location of information within that space servesserve as a reminding function.   This is in contrast with Fertig, Freeman, and Gelernter [19] who suggest that users only need better tools to find the value in archiving without specific organization.

 

  To the authors’ awareness, no role-centric email applications are available to date.  However, tThe preceding research makes a case for exploring role management for email clients on campuses.  TheThis following sectionspaper describess information gathered about the use of email by the target student population, and the section titled Proposed Solution presents s a simple prototype interface illustrating of how a “student role” might be implemented in a role-centric email program. This research was conducted by an interdisciplinary “Gemstone team”[1] of undergraduate students.

 

 

3.  UNDERSTANDING STUDENTS NEEDSURVEYS

     
In order to learn about the concerns, preferences, attitudes, and needs of students, two surveys were conducted on campus.  By studying representatives of the college student population, information about email use was gathered and conclusions were drawn about the target population.  The first survey was distributed in November 2001 to students at the University of Maryland, College Park.  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.  Yeah, what about 35?

 

      The survey revealed that The resulting 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 Uuniversity’s network.

Figure 1.  Email Programs Used.Graph of Percentage of Respondents vs. the Email Client they Used (Survey #1)

  college students use email to communicate on a daily basis.  Of 35 students surveyed, 86% check their email several times a day and 100% check their email at least once a day.  In addition, 89% of students use more than one email address to send and receive email messages.  The extent to which students use email as a communication tool is evident in the frequency with which students check their email and the number of different email addresses that students have.

 

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”ghost” What did this mean? 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.  To assess the adequacy of current email software in meeting the needs of college students, students were asked to identify the email functions that they use regularly.  Some functions (e.g.  send attachment, forward message and delete messages) are used by nearly all students, while other functions (e.g. send signature file and send autoreply message) are used by only a few students.  Figure 1Figure 1 identifies email functions and the frequency with which they are used by students.  While some of the features are simply not relevant to the everyday student, other features are not used because of the complexity that surrounds the feature and the lack of exposure in the email program.  For example, 100% of respondents receive junk email; however, only 43% use filters to block the unwanted messages.  6% of students were uncertain of what filters are, and 40% believe filtering should be improved, particularly its ease of use. 

 

Figure . XXXXX

The latter findings are consistent with Duchenaut and Bellotti’s observations of business users [E].

Figure 2.  Email Function Usage.

  Eighty percent of those surveyed responded to questions on how students organize their messages with folder use.  This shows prevalent use of folders by students.  Questions on 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 topic of email organization was also addressed in the survey.  Students were asked if they use folders to sort and store email messages.  80% of students surveyed use folders.  Three quarters of these students have less than 10 folders.  The rest of the students surveyed have between 10 and 30 folders.  Email organization is relevant to college students as evidenced by 48% of students who save more than half of all the emails that they receive.  Only 21% of students save less than one tenth of all the email that they receive.

Figure 1. Use of various email functions as described by University of Maryland students in 2001 survey

 

 

 

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.

To better understand student use of email, students were asked to identify the people that they email regularly.  As expected, students use email to communicate with friends and family members.  63% of students also use email to communicate with coworkers (Figure 2).

Figure 2 . Person(s) to whom University of Maryland students sent emails as found in 2001 survey

 

Figure . XXXXX

 

   A section of the survey was devoted to the evaluation of current email software by students.  Students commented on email features that they like and dislike.  Students named the following positive features frequently::

 

fast speedspeed

simplicity

email notification

address book

folders

support for multiple email addresses

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 Search Criteria.

  The student attitude section of survey #1 asked respondents to list features they like about their current email program.  Students named the following features most frequently:

Fast speed

Simplicity

Email notification

Address book

Folders

Support for multiple email addresses.

 

Asked to list problems with their email program, respondents named the following user interface-related issues:

Difficulty changing how features work

Difficulty setting up

Suboptimal default settings

Lack of spell checking

Complexity from overabundance of features (feature overload)

Students also identified problems with current email programs.  The following issues were acknowledged by

 sstudents:

 

difficulty changing how features work

difficulty setting up

suboptimal default settings

lack of spell checking

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.

Despite a small sample size, the first survey provides a good deal of insight into student email use.  The survey revealed that current email software does not meet the needs of students fully and it can be changed to better accommodate students.  Disregarding the technical shortcomings of specific email programs, the following issues appear to present problems for students: insufficient exposure and presentation of complex features and limited tools for email organization.

 

In April 2002, a second survey was distributed to 47 individuals, most of whom were students at the University of Maryland, College Park.  Like the first survey, the second survey addressed problems that students encounter with current email software.  In addition, the second survey considered students' attitudes towards potential user interface changes.  

 

Although it is not a statistically accurate sample of the entire student body, sSurvey #1, despite not being focused towards a narrow goal, provides a great 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 overload).  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.

 

Students were asked to identify any email features that they avoid using and to explain why they avoid using them.  Three students responded that they avoid sending and receiving email attachments.  One student attributed his/her fear to viruses, while another user confessed that he/she doe not know how to send or receive an email attachment.  Two users said they avoid using email features, which they don't understand.  Another student wrote that he/she does not use the Find or the Search feature because it is not intuitive.  While there was no particular feature that the majority of users avoid, the inadequate presentation and explanation of features in email programs is clearly a problem for students.

 

 

Users of standalone graphical email programs such as Outlook were asked about details of their interaction process.  The goal was to find unused as well as popular features of the interface.  A revised design might should prune the formerunused, and increase the accessibility of the latterpopular features.

 

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 pull-down menu.

To further investigate filtering, students were asked if they understand and know how to use filters.

 

 

NineFigure . XXXXXXXX

 

9 %percent  of students confessed that they did not know how to use filters and 32% had an idea, but were not exactly sure.  Figure 4. Toolbar Buttons Used.

Functions used regularly but not found on the toolbar by several respondents include:

File attachment

Spell checking

Searching

Copy/paste

Signature

Folder related

Filtering

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 interest 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.

This feedback supports the conclusion that filtering is not clearly presented in current email programs.  A simpler, more intuitive filtering system would probably increase the use of filters.

 

In general, students were receptive to the idea of automation in email.  Most students (72%) told us that they would like to have their emails automatically sorted for them.  Students were also enthusiastic about an email program that changes to accommodate their personal preferences.  Two thirds of students surveyed said that they were interested in an email program that adapts to their preferences.  Most students, however, were not comfortable using an email program that keeps track of their usage patterns and makes inferences about their intentions (for the exclusive purpose of adjusting the user interface).  The unwillingness of students to give up this control raises questions about the viability of adaptive interfaces in email design.

 

 

 

4. 

PROPOSED SOLUTION

   Based on the feedback received, we set out to create design a user interface that alleviates addresses the main problems for college students: email overload and feature overload.  We believe that role management could addresses 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 calendar.

 

In 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, both for the user and for any administrative support, to reduce the switching penalty.  Finally the interface had to “degrade gracefully” to still be useful and usable when no information was available about the roles of the users or when the users were not willing to change their practice.

 

  The design process involved several many brainstorming sessions and a selective synthesis of ideas into a single interface.  After several revisions of sketched paper mock-ups, electronic screenshots were generated using computer graphics tools to better resemble an computer actual interface.  Those screenshots where used to collect feedback from potential users.  Finally we implemented a visual prototype to illustrate some of the interactions. Figure 3-4 and 55 shows a sample screenshots of the proposed interface.

 

The most significant departure from standard email clients is the presence of role selection role selection tabs.  Each role represents a separate environment where only messages, contacts, and functionality relevant to that the role are visible.  In the example of Figure 3 two specific roles are available - School and Work - with the School role currently selected.  The General role corresponds to the “standard” entry to the email interface where no roles specified.    Roles can include subroles. This is illustrated in our example where each class (e.g. ANTH 240, ENEE 435) is a subrole of the School role and the Work roles has a “circuit project” and “reports” roles.

Once a role is selected, the information panel located on the right side of the screen summarizes the most important organizational information of the role.  For the school role it shows University Announcements and the list of classes (Figure 3).  For the Work role, it shows general announcements and the two projects “Circuit project” and “Reports” (Figure 5).  For contextual cues, a different visual theme would distinguishes each role; this is limited to color in our prototype but can may includes colors, fonts, icon style, and otherssound effects etc., to clearly indicate which role is .currently being assumed.    NonethelessT, the roles are not mutually exclusive.  A given message or, contact , or function would beis visible in any role to which it is marked as related.  Essentially a role acts as a portalgateway to the most relevant messages, contacts, and funnctions relevant to the role.. 

 

Each role allows several views, which are modes of operation that monopolize most of the screen area.  The Mail view is the default view and provides an interface to the user’s mailbox (depicted in Figure 3 and 5 for school and work respectively. 

 

 

Figure 3. Role management email interface in School role under Mail view.  Arrows added to the screen shot indicate the linkage between parts of the display.  Here the student has clicked on ENEE 408E to show only the mail related to the ENEE 408E class. The contact list was filtered as well to show only students enrolled and instructors teaching that class.  Further filtering of the mail list can be done, here only announcements are shown.    One the ENEE 408E role is selected, a click on “calendar” will switch to the calendar for that particular class

 

.

An alternate view is the calendar view (Figure 4 and 6).  Each view is accessed by clicking on a button on the right below  thebelow the role tab[2]. 

 

The subroles and subtasks belonging to a role appear in the Role Information Panel on the right of the screen and are also represented by the a hierarchical treeview under “Sections” .  This treeview allows users to create additional folders if needed in the rolein Figure 5.  They could be nested within reason.  Similarly to roles, subroles and they folders behave non-exclusively—unlike the folders treeview in common email programs.  For example, when users switch from the Work to School role, they see all the messages and contacts relevant to school, until they focus on a specific subrole/class.  Similarly switching to the “ENEE 408E” subnode role will display all messages related to that courseclass, including messages from all three subsectannouncements, assignments and grades (Figure 3) and list all the contacts for that particular class.  ions.  To make the distinction clear for the user, these subsections would beis highlighted when “ENEE 408E” is selected.  Such aThe treeview creates a filtering hierarchy that gives the user control over the breadth of information presented. 

 

The views are vehicles for delivering role-specific functionality.  The most general alternative view is the calendar. Figure 4 shows the calendar view of the School role.  The school calendar displays data in a manner convenient for school-related tasks, such as presenting a semester layout (opposed to of a quarter layout for the work calendar).  The calendar can indicate with different colors class times, exams, assignments deadlines etc.    Again, the School role view shows all the events of the school role, while focusing on a particular class (by clicking on the right side information panel) will focus on the schedule of that class.The inclusion of children in the parent would beis mimicked in the treeview under Contacts: clicking on a root node with children could open a letter to all recipients in a group, represented as the child nodes.

 

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 novicesusers transitioning from non role-based email.  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 linked to a role.  The Sections treeview under General would can reflect this by providing a child node encompassing General-only content, which descends from a treeview 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 The school role directory could also automatically be providedincorporate the class lists.

 

Another proposed tool for role-specific functionality is the collapsibleThe information panel, visible located on the right side of the screen, .  The panel couldcan 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 can provides a summary of views that are not currently visible.  In Figure 46, 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 display of specific types of information delineated in email messages filtering accessible to the user via the role/subrole hierarchy.

 

 

 

Figure 4.  Role management email interface in School role under Calendar view.  Here the ENEE 435 class (or subrole) has been selected.   A semester calendar corresponding to the class duration is shown, color coded to represent class meeting time, assignements and exams, on top of a black and white view of the complete school role calendar.  Day events are listed for all classes as well but ENEE 435 events are highlighted.

 

 

Figure 5 and  6.  Role management email interfaces in the Work role for Mail (left ) and Calendar views (right) .   The work role is not as well defined as the school role.   Still users can define customized calendars (here a quarter calendar), or different options – e.g. a different signature file and automatic spell checking.   The contacts are limited and different from the school role, and play an important part in characterizing the role itself.

 

 

 

 

Need to add the scenario here

Brief version / outline:

For example,Consider how a typical college student, let’s call him Matt, may experience this role management interface.  Matt registers for classes at a university and .  The university guides him towardsreceives guidance on using a role management-based based email client.  Upon downloading and installing the client, Matt’s email is customized to include a school role, including with thehis registered classes he is registered for classes, from data available on awith the aid of a university server.  His classes directory listings are filled in with the email addresses and names of his classmates and professors.  The school calendar is populated with dates of university holidays, the last day of classes, as well as more class- specific information, such as final exam  dates. 

A sample implementation of the Work role appears in Figure 7.  Its differences from the School role include (but need not be limited to) a different subrole/task hierarchy and quarterly Calendar organization.

 

5.  FEASIBILITY CONSIDERATIONS

 

Consider the following scenario of use:  Matt, a typical college student, was just accepted at the University of Maryland.  He is requested to come to school with a computer and encouraged, possibly required, to download and get familiar with a recommended (role based) email program that has been tailored to university students.  When he installs the software, school calendar is already populated with class registration deadlines, university holidays, and the last day of class.  When Matt registers for classes he received automated acknowledgment email messages that includes metadata information about the class.  This information is used by the email program to setup the school role for Matt.  His calendar is updated (after he reviews the information and acknowledge the automatic loading in his calendar) and the contact list already includes information about the instructor and the teaching assistant. When class starts a reminder email indicates a classroom change and loads the contact information of classmates.  

When reading email Matt can now chose to read all his email at once (using the General tab), or focus on his School role first, then review the other messages.   While he is reading his school email, he sees in the information panel on the right that the ENEE 430 professor has highlighted that the upcoming group project 1^st deadline is approaching.  In one click he can switch to that class subrole and review the class calendar, which is useful since - as many other undergrad students – he never manages his personal calendar. He switches to the email view, but can’t quite remember the name of the fellow classmate he is supposed to work with so he scans the list of classmates.  He remembers the name… and sends email to setup a meeting.

 A few months later, Matt gets a part-time job in a local company.  At first, all his work related email appears in the General role.   After a few weeks, Matt has received emails from many people in the company and he spends 5 minutes setting up his Work role.  He drags messages sent by work colleagues onto the Work role to add their names in the Work contact list.  A few months later he already works on two projects so he creates two subroles for Work.   Years later the company adopts a role-based email system and when Matt graduates and quits his job, he can pass his role to another fellow student by emailing him the role information (calendar, contacts, selected important emails, todo lists, reports) all at once.   Soon he will also delete his entire school role all together…

 

Some details need to be included on theOf course many technical aspects have to be worked out  technical feasibility of thisto make this scenario come true. interface..  One important question is how the program could determine what messages and contacts fit under what roles.  In a general email interface this would be very difficult to achieve but in our context a lot of structure can imposed automatically thanks to the formal organization of University activities in classes and terms, which leads us to believe that a school role can realistically be setup. Secondly, our experience as students as well as the results of our surveys suggests that many students’ lives are clearly compartmented between school, work, old friends and family, and “others”, therefore increasing the chance of a correct role identification based solely on the names of the people listed in the email.   Students often use several email addresses to separate their emails - and roles.  Those different addresses could also be used to filter email in a unified interface.  The most next predictable approach is to assume nothing about a unmarked message until the user adds messages it to the desired role (a one-click and drag interface could do this).  All subsequent correspondence with the added person would beis included in that role until the user cancels the association.  Finally, iIf the sender used a role management enabledbased client, the role the message was sent from could provide information valuable to this process (i.e the message was most likely related to that role).  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 contacts and dates to a calendar or finding important news is may be 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 provide a customized email client and to run a server with class news or schedule updates.  University staff could define new rules as needed (e.g. the president of a student-lead activity would receive a new role with a calendar of deadlines, a specific list of contacts and a budget view). This Some of the centralization could be avoided by imbedding an alternative possibilitym: metadata supportin the email.  Using ideas promoted by the Semantic Web research Ththe 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.

 

Role based Despite such accommodations, special functionality is more unlikely tot o transcendbe useful for roles such as School, where the university or professors might provide supports and benefits can be gained without any extra work from users.  On the other hand pPeople under Friends and Family roles are not likely to provide servers or to embed metadata...  In these cases, the interface  would needs to “degrade gracefully”.  The software Merely identifying the people involved in the role might be useful.  The software could can provide templates for commonly-usedcommonly used roles like Friends and Family, including basic artificial intelligence to look for such things as birthdaystools to help the user with this process.  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.  In the worse case users read their email in the General role and nothing is lost. The main objective of limiting email overload is not compromised.

 

For advanced users customization of the roles will increase the benefits of using roles.  For example roles could use a different signature (formal for work, informal for school, home address for friends and family.)   Automatic spell checking might be enabled in the Work role but not the School role.   In addition to the increased likelihood of a remaining engaged in a role-based activity, the time saved by having those simple differentiations between roles can very well compensate for the extra time spent switching role.

 

6. 6.  DESIGN TESTING AND FEEDBACK

 

As a preliminary assessment of this role management interface, we conducted scenario testing and interview sessions.  20 Twenty 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 thought that the information panel aswas expendablenot always useful, but and most thought itwere satisfied to learn that it could be should be collapscollapsibleed.  The calendar’s weekly and daily views seems too detailed, since many students seldom used calendars to record personal information. 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 a few others initially mistook the Work role tab for campus job searches (which in fact could be the default setup for students who do not have a job yet!).

 

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.  Note that the testing was done on paper prototypes and without training so we could only observe if their first intuition about where to find the information was correct (opposed to seeing how they would explore the interface until they found what they needed).  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 orthe Mail view and use the contact lists.  When asked to check for snow-related class cancellations, 85% correctly selected the University News link in the information panel of the School role.  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.

 

  The 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 (remember that many undergraduate students don’n’t even even own a calendar and rely on instructors’ constant reminders...).   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 approval.

 

  The 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 presented well enough to be readily used—including special school-related features.  This indicates that feature overload may be reduced when functionality is filtered customized by role.

 

 

7.  CONCLUSIONS

 

Our research findings on campus email usage use have several implications for those designing future email clients:

 

 

Students use email differently from the average business users and would benefit from specially designed interfaces.  They communicate with a variety of well-defined and enduring  - groups of people, including many not related to schoolusually not overlapping - groups of people, and traditionally rely on multiple email addresses to separate their roles. .  Although school-related email use is heavy, functionality beyond simple messaging is surprisingly sparsely used. 

 

 

Current email clients do not adequately meet students’ needs.  Most Many 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.   Customizing the interface to their needs and providing PIM features from the start by facilitating the download of university or class schedules is likely to increase use and streamline email and calendar management.

 

 

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 mmessages will be misplaced. .

 

 

Role management may help contribute to relievelessening 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.

Role Management is not a silver bullet.  It obviously does not entirely solve the problem of email overall and software complexity but it allows users to focus on particular roles when they need to, speeding the browsing of email and contact lists which have become significantly smaller, review calendars that can be focused on given roles, and potentially giving access to a todoto-do- list or directories of documents that can be filtered by roles as well, all in an integrated environment.

Linking messages or contacts to a particular role remains a challenge for a general role management interface but we strongly believe that the University environment can provide the structure and support for role management interfaces that would help organize a large body of users with limited (at first) organizational skills..

 

 

The proposed interface illustrates one way that role management might be implemented; initial reactions from students are enthusiastic.  The creation and testing ofWe hope others will continue developing the idea of role management for University students or for other similarly structured environments.   Developing a fully functional a functional prototype would beis a challenge but should be the next the next step in evaluating the practicability of this this approach

 

Acknowledgements

We want to thank Ben Bederson, Bill Billam, Evan Golub, Ross Malaga and Kent Norman for their feedback as thesis discussants.  We also thank the Gemstone staff for their support during the project.

REFERENCES

1.  Gallup Organization, (2001). Almost All E-Mail Users Say Internet, E-Mail Have Made Lives Better. Princeton, NJ.

 

2. Ducheneaut, N., & Bellotti, V. (2001). E-mail as Habitat: An Exploration of Embedded Personal Information Management. 30-38. New York: ACM.

 

3. Economics and Statistics Administration, & National Telecommunications and Information Administration. (2002). A Nation Online: How Americans Are Expanding Their Use of  the Internet. Washington, DC. Retrieved November 18, 2002 from http://www.esa.doc.gov/508/esa/ANationOnlineEXSFeb02.htm

 

4. Jones, S. (2002). The Internet Goes to College: How Students are Living in the Future with Today's Technology. Washington DC: Pew Internet and American Life Project.  http://usinfo.state.gov/usa/t091602.htm

 

5. Sidner, C., & Whittaker, S. (1996). Email Overload: Exploring Personal Information Management of Email. Proceedings of the SIGCHI conference on Human factor in computing systems. 276-283. New York: ACM.

 

6. Duchenaut, N., Bellotti, V., Howard, M., & Smith, I. (2003). Taking Email to Task: The Design and Evaluation of a Task Management Centered Email Tool, Proceedings of the conference on Human factor in computing systems. 345-352. New York: ACM.

 

7. Shneiderman, B., &  Plaisant, C. (1994). The Future of Graphic User Interfaces: Personal Role Managers, People and Computers IX. 3-8. Glasgow, Scotland: British Computer Society. Early version also at http://www.cs.umd.edu/local-cgi-bin/hcil/sr.pl?number=HCIL-94-05

 

8. Biddle, B.J., & Thomas, E.J. (1979). Role Theory: Concepts and Research. New York: Krieger Publishing Company.

 

9. Roos, L.L., & Starke, F.A. (1981), "Organizational Roles", in Handbook of Organizational Design Vol. 1: Adapting Organizations to Their Environment, P.C. Nystrom & W.H.Starbuck [eds.], Oxford University Press.

 

10. Sarbin, T.R., & Allen, V.L. (1968), "Role Theory", in Handbook of Social Psychology (2nd Edition), G. Lindzey & E. Aronson [eds.], Addison Wesley.

 

11. Singh, B., & Rein, G. (1992). Role Interaction Nets (RINS): A Process Description Formalism. (Technical Report CT-083-92). Austin, TX: MCC.

 

12. Plaisant, C., Shneiderman, B. (1995). Organization overviews and role management: Inspiration for future desktop environments, Proc. IEEE 4th Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises. New York: ACM. Also at http://www.cs.umd.edu/local-cgi-bin/hcil/sr.pl?number=HCIL-95-11

 

13. Kandogan, E., & Shneiderman, B. (1996). Elastic Windows: improved Spatial Layout and Rapid Multiple Window Operations, Proc. Advanced Visual Interfaces, 29-38. New York: ACM.

 

14. Kandogan, E., & Shneiderman, B. (1997). Elastic Windows: evaluation of multi-window operations, Proceedings of the SIGCHI conference on Human factors in computing systems. 22-27. New York: ACM.

 

15. Kaptelinin, V., UMEA: Translating Interaction Histories into Project Contexts, Proceedings of theCHI 2003 conference on Human factor in computing systems. New York: ACM.

 

16. Venolia, G. D., Ceustaedter, C., Understanding Sequence and Reply Relationships within Email Conversations: A Mixed-Model Visualization, Proceedings of the CHI 2003 conference on Human factor in computing systems. New York: ACM.

 

17. Barreau, D.K. (1995). Context as a factor in personal information management systems. Journal of the American Society for Information Science, 46 (5), 327-339.

18)  Nardi B.,  Barreau , D., Finding and Reminding" Revisited: Appropriate Metaphors for File Organization at the Desktop, SIGCHI Bulletin Vol.29 No.1, January 1997

 

19. Fertig, S., Freeman, E. and Gelernter, D. (1996). "Finding and reminding" reconsidered. ACM SIGCHI Bulletin, 28 (1), 66-69.

 

20. Freeman, E., Fertig., S.  Lifestreams: Organizing your electronic life. In AAAI Fall Symposium: AI Applications in Knowledge Navigation and Retrieval, November 1995, Cambridge, MA.

 

.notes

 

 

Acknowledgements:  This project was conducted by a team of undergraduate students working independently under the guidance of a mentor. The Gemstone Program at the University of Maryland focuses on the development of the students outside the standard classroom environment, and challenges the students in the development of their research, teamwork, communication and leadership skills.  This paper was written by a Gemstone team including students from Civil Engineering, Biochemistry, Electrical Engineering, Physiology and Neurobiology, German and Computer Science.       

 

Authors’ Present Addresses:

Plaisant-Schwenn, Catherine, Assoc. Director, Inst for Adv Computer Studies, 3173 A.V. Williams Building, University of Maryland, College Park, MD 20742

 

Baker, H. Ross, 110 Deep Willow Drive Exton, PA 19341

 

Duarte, Nicholas, 19312 Olney Mill Rd Olney, MD 20832   

 

Haririnia, Aydin, 8110 Whittier Blvd Bethesda, MD 20817

Klinesmith, Dawn, 4230 Knox Road, Apt. 1526 College Park, MD 20740

Velikovich, Leonid, 25 Silver Moon Drive Silver Spring, MD 20904
REFERENCES

 

A) A nation online executive summary, (2002). Retrieved November 18, 2002 from http://www.esa.doc.gov/508/esa/ANationOnlineEXSFeb02.htm

 

B) Gallup July 2001 poll  http://www.gallup.com/subscription/?m=f&c_id=10784

 

C)  Pew internet (pdf):  http://www.pewinternet.org/reports/toc.asp?Report=71

Office of International Information Programs, U.S. Department of State. (2002). College Students Outpace General U.S. Population in Internet Use. [Online] Available: http://usinfo.state.gov/usa/t091602.htm

D) Whittaker, Sidner: http://www.shef.ac.uk/~is/whittake/emlch96.pdf

E) Duchenaut, Belotti (Habitat) http://portal.acm.org/citation.cfm?id=383305

F) http://techreports.isr.umd.edu/TechReports/ISR/1994/TR_94-48/TR_94-48.phtml

Shneiderman, B., Plaisant, C.(1994), The Future of Graphic User Interfaces: Personal Role Managers , Keynote address, in People and Computers IX, British Computer Society HCI'94, Glasgow, Scotland (Aug. 1994) pp.3-8.

G) Biddle, B.J. & Thomas, E.J. (1979), Role Theory: Concepts and Research, Krieger Publishing.

H) Roos, L.L. & Starke, F.A. (1981), "Organizational Roles", in Handbook of Organizational Design Vol. 1: Adapting Organizations to Their Environment, P.C. Nystrom & W.H.Starbuck [eds.], Oxford University Press.

I) Sarbin, T.R. & Allen, V.L. (1968), "Role Theory", in Handbook of Social Psychology (2nd Edition), G. Lindzey & E. Aronson [eds.], Addison Wesley.

J) Singh, B. & Rein, G. (1992), "Role Interaction Nets (RINS): A Process Description Formalism", MCC, Austin, TX, USA, Technical Report CT-083-92.

K) Plaisant, Shneiderman  http://portal.acm.org/citation.cfm?id=223761

Plaisant, C., Shneiderman, B., Organization overviews and role management: Inspiration for future desktop environments, Proc. IEEE 4th Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, (April 1995).

L) Kandogan, E., Shneiderman, B., Elastic Windows: improved Spatial Layout and Rapid Multiple Window Operations, Proc. Advanced Visual Interfaces '96, ACM, New York, NY, (May 1996), pp. 29-38.

M) Eser Kandogan, Ben Shneiderman, Elastic Windows: evaluation of multi-window operations, Proceedings of the SIGCHI conference on Human factors in computing systems, (March 1997).

N) Eisenstein, Puerta Adaptation in automated user-interface design

http://portal.acm.org/citation.cfm?id=325787

O) Duchenaut, Bellotti, Howard, Smith

Taking Email to Task: The Design and Evaluation of a Task Management Centered Email Tool

CHI 2003, April 5-10 2003, Vol No.5 Issue No. 1 pp345-352

FIGURE CAPTIONS

 

Figure . Use of various email functions as described by University of Maryland students in 2001 survey

 

Figure . Person(s) to whom University of Maryland students sent emails as found in 2001 survey

 

Figure . Percentage of students with knowledge of filtering and its application to email

 

Figure 4. Role management email interface in School role under Mail view

 

Figure 5.  Role management email interface in School role under Calendar view

 

Figure 6.  Role management email interfaces in Work role for Mail and Calendar views

 
FIGURES

 

Figure . Use of various email functions as described by University of Maryland students in 2001 survey

Figure . Person(s) to whom University of Maryland students sent emails as found in 2001 survey

Figure . Percentage of students with knowledge of filtering and its application to email

 

 

 

 

 

 

 

 

 

Figure 4. Role management email interface in School role under Mail view

 

 

 

 

 

 

 

Figure 5.  Role management email interface in School role under Calendar view

 

Figure 6.  Role management email interfaces in Work role for Mail and Calendar views  

Appendix 1: The gemstone team:

 

H. Ross Baker is a computer scientist with an interest in linguistics; he is now a graduate student in the Linguistics Department of Northwestern University.

 

Nicolas Duarte is an Electrical Engineer with an interest in molecular electronics and bioengineering; he is now a graduate student seeking his Ph.D. in the Electrical Engineering department of Pennsylvania State University.

 

Aydin Haririnia is a biochemist with an interest in protein NMR and crystallography, he is now a graduate student in the Department of Chemistry and Biochemistry at the University of Maryland.

 

Dawn Klinesmith is a civil engineer with an interest in structural engineering; she is a student in the civil and environmental engineering department at the University of Maryland, College Park.

 

Hannah Lee is a recent graduate of the University of Maryland with an interest in Physiology and Neurobiology.

 

Leonid Velikovich is a computer scientist with an interest in computer graphics; he is an undergraduate student in the Computer Science Department of the University of Maryland

 

Alfred Wanga is an electrical engineer with an interest in electronic materials and devices. He is now a graduate student at Penn State University.

 

Catherine Plaisant was the mentor of the team