Personal Role Management:

Overview and a Design Study of Email for University Students

 

Catherine Plaisant and Ben Shneiderman with

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

 

December, 7th 2004

 

Human-Computer Interaction Laboratory, Institute for Advanced Computer Studies,

University of Maryland, College Park, MD 20742,

 

Abstract

           

Evidence is accumulating about the difficulties that users have in managing their work using contemporary graphical user interfaces. Current designs offer a hierarchy of folders containing documents and taskbar operations to launch/exit applications.  We propose a Personal Role Management strategy that emphasizes management of the multiple roles users have in their professional and personal lives.  Each role involves coordination with groups of people and accomplishment of tasks within a schedule.  We define Personal Role Management and summarize our earlier work that led to this strategy.  This current project focused on understanding how Personal Role Management might improve email for college students.  College students often assume distinct and predictable roles.  Their student role is structured by the rhythm and interactions of classes, projects and exams. In both their family role and their work role for local companies, they deal with separate groups of people. We describe scenarios of use of a role-based email system, an interface mockup and user reactions.  This research suggests that using those roles as a driving component for designing an email interface might address problems identified in our surveys and interviews of college students.

 


1. Introduction

 

Our daily activities are rich and complex as we switch among many roles at work, at home, and in our community.  A professor may be a teacher of several courses, advisor to students, member of academic committees, principal investigator of grants, conference organizer, editor of scientific journals, and liaison to industry.  Most job descriptions include multiple responsibilities: even a salesman may deal with categories of clients, train new employees, manage the company car pool, and supervise the website maintenance. Work needs to be juggled with personal roles, such as being a soccer player or volunteer fireman, and family roles, such as being a parent, a home remodeler, a Parent-Teacher Association member, or a remote caregiver for an older adult.  

 

We talk about wearing “different hats”, and about the things we do in our “other lives”.  This language provides hints to the importance and the distinctiveness of those roles.  Different roles require different states of mind, different levels of pressure, privacy, and professionalism.  Those hats may also symbolize how we highlight different personality traits in different roles.  Nevertheless, we conduct our activities using the same computer environment.  Some applications may have ways to customize their appearance and behavior to fit users’ needs and wishes, but the underlying environment remains unchanged as we switch between those often very distinct roles.  The question for designers is: how could we design graphical user interfaces that provide more efficient actions by taking account of role distinctions?

 

Some users attempt to create distinct roles by having separate email accounts or even separate computers for their work, household, hobbies, etc.  We define roles as enduring (a month to many years) efforts of an individual, for which there are mostly distinct sets of people, events and documents.  A task is a short term (an hour to a week) effort for an individual, whereas a project is an enduring effort for a group of people.  Organizations are typically concerned about project management, so they emphasize tools for coordination among individuals and critical path techniques to speed completion of the team effort.  Since we are concerned with enabling a person to manage their multiple roles inside and outside their organization, we emphasize document management, calendar support, communication needs, and attention switching among multiple roles.

 

Current graphical user interfaces are based on the physical desktop metaphor of documents, files, folders and applications to manipulate them.   To fulfill their obligations within a role, they have to think in terms of low-level actions such as launching applications, opening files, navigating directory structures, and searching for information.  Then they have to save results as new documents and send them to others.   Aside from the possibility of saving files in role specific folders, the graphical user interfaces do not take into consideration the need to handle separate roles in a separate manner.  Worse still, they do not allow for rapid role switching.  

 

A typical scenario might go like this: John is the principal investigator of a large grant.  He has been working for an hour on the project report.  File explorers and email tools are focused on the correct project folder; word processors show the right set of documents; the web browser history is now full of the relevant web pages he just looked at.  His windows have been resized and laid-out in a convenient way.  Work seems to be moving along nicely, but now John needs to switch to another task.  One of his many roles is to be the chair of a symposium, for which a conference call is scheduled in 5 minutes with the representative from the printer’s office.  John starts by browsing the contact list to recognize the name of the printer, but he fails in this task because the list is too long.  He switches to the word processor to open the planning document that might contain the printer’s name. Unfortunately the list of the documents opened recently are all related to the principal investigator role of writing the report, so he patiently navigates the file hierarchy up from the recent report directory and then down to the symposium directory.  After carrying out a search, he recognizes the file name that deals with the printer and gets the phone number to call.   But before starting the call he switches to the calendar application and flips nervously thru the weekly views to refresh his memory of the symposium’s camera-ready deadline and the ship-to-printer deadline that were set earlier.  Finally he opens a web browser and browses his long list of favorites to find the symposium webpage.  After the conference call is over, he switches to setting up a doctor’s appointment for his son and writes a letter to his son’s teacher to request permission to take his son out of school during lunchtime.  He also responds to a call requesting an immediate change in the web announcement for the holiday party he organized.  Later on he returns to the project report, but he has to spend a few minutes to reopen windows, resize them, and re-navigate each application to the right folder.  He complains that the list of recently opened documents is useless now, and that default folders are mapped to the wrong place.  

 

In contrast, a Personal Role Management environment would allow John to instantly switch from being a project manager to being a symposium organizer in one step.  He would find his environment focused on the selected role: file browsers would be opened in the relevant home directory, recently opened files would be based on the tasks he performed last in that role, the contact list would appear filtered on the contacts relevant to that role (making it easy for users to recall names they forgot), the calendar would highlight the relevant deadlines entered while that role was selected, and key applications and documents could be saved and opened at once.

 

We proposed the Personal Role Management strategy in 1994 as a guiding concept for the next generation of graphic user interfaces. The first generation was the command line interfaces that required users to know about computer concepts and syntax. These were replaced by second generation graphical user interfaces with the desktop metaphor, icons, and folders. Next, the third generation emphasized a docu-centric approach, in which applications faded into the background while multimedia documents become the center of attention. Our proposed fourth generation user-centered design emphasizes users’ roles, collaborators, and tasks rather than documents. Each role involves coordination with groups of people and accomplishment of tasks within a schedule.   

 

As interface environments have allowed multitasking, some users have managed to support roles by keeping multiple windows open simultaneously.  By running window managers that allow multiple desktops, sometimes called rooms [e.g. Henderson and Card, 86;  Robertson et al. 99], it is possible to simulate a Personal Role Management strategy.  However, this approach does not address key issues of organizing documents, contacts, calendars, web favorites, and recent files   In such multiple desktop environments, focusing on a role corresponds to a change of location in the virtual space, but the behavior of the individual applications remains unchanged as they remain blind to the change in the context they are being used in.   

In contrast with the research on role theory [Sarbin and Allen, 1968; Biddle and Thomas, 1979; Roos and Starke, 1981], or Computer Supported Collaborative Work [Singh and Rein, 92] which focuses mainly on the coordination of individuals within an organization, Personal Role Management focuses on helping individuals manage their multiple roles.  Newer frameworks, such as activity theory [Redmiles, 2002] view work as driven by various needs, in which people seek to achieve goals. Activity theory proponents provide useful insights for accomplishing organizational goals, but they have not provided adequate frameworks for understanding how users view their multiple roles inside and outside the organization.

2.  Early explorations

Our original work on Personal Role Management was based on an observational study of World Bank employees.  The study looked at project life-cycle, document management, email practices, training and availability of software tools and identified problems that World Bank employees regularly struggle with which seems generic enough to be significant in other organizations.  One of those problems was the juggling of many roles within the organization. Managers often managed several projects at once and also had various roles within their business unit or group. For example an employee could be in charge of two projects (a healthcare clinic in Algeria and the construction of a drinking water supply system in Mali) member of three task forces, editor of the magazine, and organizer of the holiday party. A great deal of personal organization is required to manage those roles whose goals, collaborators, tools and documents are mostly distinct.

Our exploration led to two main concepts: Personal Role Management and organization overviews.  Organizational overviews were proposed as a consistent background for presenting results of searches in databases but also as a way to map the multiple personal roles an individual has in an organization and serve as a resizable control panel used to switch roles (Figure 1 to 3).  The prototype showed Personal Role Management as a strategy that allowed knowledge workers to organize information according to their roles in the organization.   The roles were defined as having a vision statement, a set of people, a schedule and a task hierarchy. The vision statement is a document established by the individual or the superior.  It may facilitate training or transfer of responsibility.   The set of people is a contact list narrowed down to show only the most relevant contacts for this role.  The schedule is focused on a specific role and the relevant files and tools are shown. Moving in and out of a specific role, or switching roles is instantaneous and seamless (Figure 4).  A role overview icon, even when very small, can be used to switch roles, and enlarged to reveal more details when needed. When John receives a call regarding a different role, shifting to that role is done with a single click on the overview, or using a keyboard shortcut.

A low-fidelity prototype was developed to illustrate the Personal Role Management strategy [Plaisant and Shneiderman, 95a].   The strategy was first presented in a keynote talk by Ben Shneiderman at the British HCI conference on People and Computers in 1994 [Shneiderman and Plaisant, 1994], and a longer description of the work appeared a year later [Plaisant and Shneiderman, 95b]. 

 


 

 

 

 

 

 

Figure 1.  A new employee of the bank would see this role overview before they are assigned a new job.  On the top left is the bank’s main organization structure.   And the 3 other boxes are to organize and cluster the roles related to the business unit, and users’ workgroup personal roles.


 

 

 

 

    

Figure 2 (left): As roles are assigned to our new employee they can be organized on the overview and used by personal role managers.     Such role overview can also be shrinked to the size of a large icon and displayed at all time to allow users to switch roles easily.   Keyboard shortcuts can also speed role switching.  

 

Figure 3 (right):  Here we see the same organization overview but simple visualization techniques summarize the amount of unread emails (M) and Todo items (*) for each role, alerting users of which roles may need more attention today.   

 



Figure 4.  Three steps of the animation of a mockup prototype showing how selecting a role in the role overview  (which appears as a large icon on the top left) opens the selected role which fills the screen, and reveals the calendar, contact list and file hierarchy focused on the role.  The role overview is still visible on the top left for rapid switching to another role.


Personal Role Management was also used to illustrate a window management environment called Elastic Windows [Kandogan and Shneiderman, 97].  The hierarchical layout (Figure 5 below) indicates the hierarchic relationship between the contents of the windows by the spatial cues in the organization of windows. It provides the users with an overview of all their roles, where they can pick any role or parts of it and start working on it. Hierarchical grouping provides role-based context for information organization. It also supports graphical information hiding capability where window hierarchies can be collapsed into a single icon (or other primitives) making the approach scalable. Collapsed hierarchy of windows can be saved and retrieved, which allows users to reuse a previous window organization.

 

Figure 5: An illustration of later implementation of a University Professor role manager prototyped with Elastic Windows.  This professor is advisor to a number of graduate students in a number of research projects (3 recent ones and 5 earlier projects are represented here).  He teaches two courses this semester at the university (CMSC 434 and 828S), is industry liaison to three companies, and has personal duties. 

 

 

While most discussants are sympathetic to Personal Role Management, a common critique is that roles are often interrelated and that it can be difficult to separate them.  Sometimes users work with the same people on multiple projects and even organize social events or family vacations with them.  Our documents may be reused in different contexts and calendars also need to show all events for all roles, especially when scheduling a new event or just planning the day.  There is a legitimate danger that managing roles may consume more time than it saves. We recognize that role management may not be useful to all users, but nevertheless, we believe that many users hold distinct and stable roles (i.e. with a mostly distinct set of collaborators, documents and schedule for month, years, or longer).  Therefore, there is a strong advantage in filtering the interface environment to reveal only the relevant information and allow users to focus their attention on that role.  A short list of contact names might remind users of things to do - just as it is happening when one see collaborators in the hallway.  A focused view of the calendar will remind them of deadlines and plans and a focused view of the file system might save some navigation steps. Of course, personal role managers need to allow for user control of the amount of focusing that occurs when they switch roles, and in some case they may not be able the filter or focus their environment at all when new tasks arise.  

 

A pragmatic way to define roles in a role management environment is as the subset of real-life roles that are distinct enough to allow for beneficial automatic customizing of the environment. For example a university faculty member’s multiple roles as researcher may not be distinct enough to be seen as multiple roles in such role-based environment (because colleagues may be involved in multiple projects and overlapping research topics).  On the other hand, it is likely that being the chair of a conference, a member of dean search committee for another college, or a member of an elementary school parent-teacher association will be very distinct roles that can be identified fairly easily. 

 

The creation of new roles is also a challenging issue.  Some roles may be inherited from other users, or provided by organizations.  For example a professor is given a teaching role that includes a schedule, a set of students, and preset documents.  A new mother on maternity leave might pass a particular work role and all its components to a temporary replacement.  Roles may also be split as they become more complex, such as when a subcommittee is formed to concentrate on a specific issue.  Roles may be merged, such as when two sales teams reorganize under one manager.  Finally new roles can be created on the fly by simply initiating a role and performing work in that role.  For example if users create a new role for themselves as a carpool coordinator that role will become more defined as they send email, create documents or enter events in their calendars within that role.  Switching roles must be easy and rapid, with clear feedback about the active role. 

 

It is natural to ask about automatic creations of roles from templates provided by organizational designers.  It is easy to understand how professors could be sent roles from the registrar or department chair based on registration data, assignment of teaching assistants, and the university calendar.  Just as creation of Excel or Word macros or templates has become a specialty in many organizations, the creation of role templates could greatly facilitate adoption of Personal Role Management.

 

3.  Case study of role-based email for college students

The Personal Role Management strategy was recently revisited by a team of University of Maryland undergraduate students who investigated how it might improve email interfaces for university students.  Although all users assume multiple roles, college students constitute an interesting example of users assuming fairly distinct and predictable roles, at least when they start as freshmen.  Their school role – or student role - is structured by the rhythm and interactions of classes, projects and exams. Their family role is usually disconnected from school, and they are often employed outside of campus, work role, interacting with yet another separate group of people. Our team of students conducted small surveys looking at email usage patterns and subjective experiences of students on campus.  These surveys suggest that email overload and feature intimidation are the main hindrances to email communication on campus. 

We looked at how Personal Role Management in email can exploit the categorical nature of college students’ email correspondence.  The contacts, schedule and many of the documents involved in class communication typically are well-defined (e.g. students and professors in specific classes), which are known ahead of time and can be preset automatically.  This knowledge permits an email program to automatically organize many of the student’s messages and contacts by grouping them separately.  Class directory listings and specialized views of calendars become possible with the requisite back-end support. We describe scenarios of use, an interface mockup and user reactions.  Our research suggests that using those roles as a driving component for designing an email interface for college student might address some of the problems identified in our surveys and interviews of college students.

 

User groups in other settings may also benefit from role-based email interfaces as long as some of their roles as sufficiently distinct to allow some level of automatic role detection, and to benefit from customization of the interface for different roles. 

 

3.1  Related work on electronic mail

 

In their 1996 study of email overload, Whittaker and Sidner observed that people were using email for task management and personal archiving.  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 described further how email is being widely used as a personal information manager (PIM).  Through interviews, they examined how people at work 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 is to present a different interface, with different email management options, depending on a user’s role”.

Duchenaut et al. developed a prototype of a task management-centric email client [Duchenaut et al., 2003] which received positive feedback from business users who tested it.  Two other recent papers discuss email organized by task or activity [Kaptelinin, 2003; Venolia and Ceustaedter, 2003]. The choice of task management over role management may better suit some business usage patterns, where employees juggle many short-lived tasks—all within a single role [ESA&NTIA report, 2002].  However, many users have multiple distinct roles, and often integrate non-work aspects of their personal lives in their email activities [Nippert-Eng, 96], introducing distinct social groups of people, events and tasks which should be managed separately from work activities.  Our informal surveys suggest that college students often assume a number of distinct roles, therefore a Personal Role Management strategy may be fitting for college students.  Because our student team had first-hand experience with the life of college students and access to a large number of friends and classmates to interview they decided to focus on this particular user group.     

 

In another domain, Barreau and Nardi [1997] 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 serves a reminding function.   This is contrast with researchers who suggest that users only need better tools to find their documents in archives that are organized only by temporal sequence [Fertig, Freeman, and Gelernter, 1996; Freeman, Fertig, and Gelernter, 1996].

 

The U.S. Department of Commerce surveys show email use among the general U.S. population at 45.2% in 2002, up from 35.4% in 2000 [ESA&NTIA, 2002].  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” [Jones, 2002].

 

The rest of this section summarizes information gathered about the use of email by the student population, and presents an interface mockup illustrating how a “student role” might be implemented in a role-centric email program. This work was conducted by an interdisciplinary “Gemstone team”[1] of undergraduate students at the University of Maryland (the last eight authors).

 

3.2 Understanding students needs


In order to learn about the concerns, preferences, attitudes, and needs of students, two surveys were conducted on campus.  The first survey, a small general one, was conducted in November 2001 with students at the University of Maryland, College Park.  The survey was distributed outside one of the dormitory cafeterias during dinner hours.  It showed that 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.

 

To assess the quality 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) were used by nearly all students, while other functions (e.g. send signature file and send autoreply message) were used by only a few.  While some of the features were simply not relevant to them, other features went unused and respondents’ comments suggest that it was because of their complexity and lack of visibility in the email program.  For example, 100% of respondents reported receiving junk email and 43% used filters to block the unwanted messages.  At the same time, 6% of students were uncertain of what filters were, and 40% believed filtering should be improved, particularly its ease of use. 

 

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.  75% of these students had fewer 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 saved more than half of all the emails that they receive.  Only 21% of students saved less than one tenth of all the email that they received.

 

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 5).

 

 

Figure 5 . Persons to whom the 35 survey respondents sent emails to.

 

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

·        simplicity

·        email notification

address book

·        folders

·        support for multiple email addresses

 

Students also identified problems with current email programs.  The following issues were acknowledged by students:
  • difficulty changing how features work
  • difficulty setting up
  • lack of spell checking (in some tools)
  • feature overload

 

Despite a small sample size, the first survey provided some insight into student email use and helped develop a second survey.  In April 2002, the second survey was distributed to 47 students, most of whom were students at the University of Maryland, College Park.  Like the first survey, the second survey addressed problems that students encountered with current email software.  In addition, the second survey considered students' attitudes towards potential user interface changes.  

 

To investigate filtering, students were asked if they understand and know how to use filters.  9% of students confessed that they did not know how to use filters and 32% had only a vague idea.  In general, students were receptive to automation in email.  Most students (72%) told us that they would like to have their emails automatically sorted for them.  Also, 66% of the students were also enthusiastic about an email program that changes to accommodate their personal preferences.  Most students, however, were not comfortable using an email program that keeps track of their usage patterns and makes inferences about their intentions (even for the exclusive purpose of adjusting the user interface).  

 

3.3  System mockup

Based on the feedback received, the students set out to independently design a user interface that addresses two major problems for college students per their observations: email overload and feature overload.  They investigated how Personal Role Management may address these problems in two ways.  First, organizing messages by role may manage email overload.  Second, the ability to select a current role permits hiding functionality irrelevant to that role, alleviating some feature overload.  A lighter feature set also leaves more room for special functionality in a given role, such as a custom class calendar organized by semester.

 

In designing a role management user interface, the students established criteria for simplicity.  They believed that the interface ought 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 Personal Role Management ought to be minimal to reduce the switching penalty.  Finally, the interface must degrade “gracefully” and be useful and usable when no information is available about the roles of the users or when the users were not willing to make use of the new features.

 

After several revisions of sketched paper mock-ups, screenshots were generated using computer graphics tools to better resemble an actual interface.  Those screenshots were used to collect feedback from potential users.  Finally, they implemented a Visual Basic prototype to illustrate some of the interactions. Figures 6 to 9 show sample screenshots of the prototype.

 

The most significant departure from standard email clients is the presence of role selection tabs.  Each role has a separate view, defined by the user or preset by the university, where only messages, contacts, and functionality relevant to the role are visible.  In the example of Figure 6 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 role is selected.    Roles could include subroles, for example each class (e.g. ANTH 240, ENEE 435) is a subrole of the school role providing further filtering in the school role[2]. 

 

 

 

Figure 6. 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.

 

Figure 7 shows the calendar view of the School role.  The school calendar displays data in a manner convenient for school-related tasks, such as using a semester layout, as opposed to a financial quarter layout for the work calendar.  The calendar can use different colors to indicate class times, exams, assignments deadlines etc.   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 particular class.

 

When a role is selected, the information panel located on the right side of the screen summarizes the most relevant information of the role.  For the school role it shows University Announcements and the list of classes.  For the work role, it shows general announcements and the two projects “Circuit project” and “Reports” (Figure 8).  For contextual cues, a different visual theme or skin can distinguish each role; this is limited to color in our prototype but can includes fonts, icon style, sound effects etc., to indicate which role is currently being assumed. The subroles belonging to a role appear in the Role Information Panel on the right of the screen and are also shown as folders in a hierarchical browser.  This view also allows users to create traditional folders if needed in the role. The bottom portion of the information panel can provide a summary of roles that are not currently visible.  In Figure 7, it reminds the user that new mail has arrived, which could be found in the Mail view (clicking the reminder would switch to it).Each role allows several tabs as well, but with a larger screen all the information would be visible at once.

 

 

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

The general role is unique because it encompasses messages and contacts from all roles, acting like a regular email application and allows users to transition from non role-based email, and back to it when needed.  The other purpose of the general role is to hold correspondence that does not fit any defined role. 

 

 

 

Figure 8 and  9.  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.

 

 

Several potential problems arise when considering Personal Role Management as a method of organization.  Most importantly, roles are not always mutually exclusive.  To deal with this, a given message or contact can be made visible in any role to which it is possibly related.  In other words, a role acts as a filtered view to see messages, contacts, and events that can be relevant to that role.  This allows for role overlap, such as an email from a friend requesting help on homework while commenting on recent social events.  There is also the question of how the application can determine what messages and contacts fit under which roles.  A potential solution comes from the fact that many students in our surveys used several email addresses (they typically have a university address, an old personal address and a work address).  Those different addresses could easily be used to filter content in different roles.  A less restrictive approach is to assume nothing about an unmarked message until the user assigns it to a role (e.g. by dragging it to the role tab or using a keyboard shortcut).  The new contact is added to the role, and all subsequent correspondence with that person will be assigned to that role unless the thread is marked with another role.  Alternatively if the user initiates the communication from a given role, the recipient is automatically marked to the role.  Adding a role selection option to the email header might catch some mistakes but it is more useful to provide rapid and seamless role switching with shortcuts.  Unassociated messages and contacts remain in the general role which can alternatively show all emails, or “general-only” emails, as well as all people, and all events equally displayed in the calendar.   Not everything can be sorted but even if only 20 to 30% of them are sorted automatically it can represent a significant time saving and reduce the overhead of task switching.  Benefits should increase with the number of unambiguously distinct roles.

 

Another issue is to deliver useful role-specific functionality.  Some functionality can be delivered automatically at the institutional level (e.g. using a semester based calendar for the class role) and adequate user control can further customize the interface for each role.  At the institutional level, a university might define and disseminate default roles to students.  For example signing up for a class would send the student a new role with the class syllabus, book information, exams dates and lists of teachers and classmates.  The newly elected president of the badminton club would receive a new role containing a calendar of deadlines, a specific list of contacts and a budget viewer. Some of the automation could take place by imbedding metadata in an email. 

Using ideas promoted by semantic web researchers [Hendler, Berners-Lee, & Miller, 2002], the email client could provide tools for embedding role associations, news items, event changes, or other meta-information into 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.  Metadata encoding could be implemented as an icon toolbox where users click and drag “forms” into their message.  Once properly filled out, these forms could then offer the recipient to have dates, meetings, contact information, or other data added to his/her role-based email program.   Ideally the past president of the badminton club could email his now ended role to the new president.  

 

For advanced users, personal customization of the roles will increase the benefits of using roles.  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 friends role, where communication is less formal (and students clearly indicated that spell-checking was annoying when talking to friends.)   Different skins could be chosen to match the mood of those different roles.   Search could be automatically limited to the role information by default.  Automatic copies could be turned off in the friends role and archiving on in the work role.   The more the roles are differentiated the more time savings Personal Role Management might generate. 

 

 

3.4    Scenario of use

 

Consider the following scenario of use:  Matt, a typical college student, was just accepted at the University of Maryland.  He has brought his computer to school and is encouraged to download and get familiar with a recommended (role based) email program that has been tailored to University of Maryland students.  When he installs the software, the school calendar is already populated with class registration deadlines, university holidays, games, and the last day of class.  When Matt registers for classes he receives an automated acknowledgment message 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 acknowledges the automatic loading in his calendar); the contact list includes information about the instructor and the teaching assistant; and the syllabus is saved in the class file folder. 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 role tab), or focus on his school role first, then review the other messages.   While he is reading his school role email, he sees in the information panel that the ENEE 430 professor has highlighted the upcoming group project 1st deadline.  In one click he can switch to that class subrole and review the class calendar, which is useful since - as like most undergraduate students – he does not have a 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 recognizes 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 role contact list.  A few months later he already works on two projects so he creates two subroles within his work role. A  month later the company adopts a role-based email system, but  since Matt is graduating and quitting his job, he can pass his role to the fellow student taking his place by emailing him the role information (calendar, contacts, selected important emails, to-do lists, reports) all at once.   Soon he will also archive his entire school role all together. 

 

3.5  Informal user feedback

 

We conducted scenario testing and interview sessions.  Twenty students from the University of Maryland, College Park 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 and concept of role management.  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 “busy”.  These subjects were asked what information they would eliminate, and how well the information was organized.  Several subjects thought that the information panel was not always useful, and thought it should be collapsible.  The calendar’s weekly and daily views seemed too detailed, since many students seldom used calendars to record personal information.  A simplified calendar was thought to be better.  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; a few 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 needed interface features, including the view selection buttons, the information panel, and the contacts hierarchy.  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 the mail view and use the contact list.  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 hierarchy 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 reported 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.  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 automatic changes: 75% wanted to be notified of changes to their schedule and to be asked for their approval. 

 

Feedback from faculty and colleagues was less enthusiastic as more concerns were raised about the capability of the system to correctly sort emails by role.  Faculty and staff typically have a large number of less distinct roles with overlapping sets of colleagues.  Everyone had some roles for which the separation was sufficient to be detected correctly, and some where the separation would be difficult.   For example teaching roles or campus-wide committee member roles are more distinct, but research projects have many overlaps and may have to be grouped into a large role. 

 

4.  Conclusions

 

Our research findings on campus email use have several implications for those designing future email clients: students use email in different ways than the average business user and would benefit from specially designed interfaces. Although school-related email use is heavy, functionality beyond simple messaging is sparsely used and students spend very limited amount of time organizing their emails.

 

Freshmen come to campus ready to start a new life and are likely to adopt software that helps them get organized with their classes.  Customizing the interface to their needs and providing PIM features from the start by creating a program to gather and display university or class schedules is likely to increase use and streamline email and calendar management. Most students keep a significant portion of their incoming mail.  Many would like to have the messages automatically sorted into folders, but don’t seem to know how—or worry that messages will be misplaced.  Personal Role Management may contribute to lessening those problems. 

 

The proposed interface illustrates one way that Personal Role Management might be implemented and initial reactions from students are positive.  We hope others will continue developing the Personal Role Management strategy for email clients.   Developing a fully functional prototype would be the next step in evaluating the practicality of this strategy.

Other user groups may also benefit from role-based interfaces when their roles are sufficiently distinct to allow a adequate level of automatic role detection, or to benefit from customization of the interface for the different roles.  Personal Role Management benefits will be the greatest when users switch to focused and distinct roles, as it would allow them to rapidly focus on the information relevant to that role.   Personal Role Management alone will not solve all the problems of information or email overload but has the potential to organize interface environment in a way that is meaningful to users and mirror the many lives they live.

.

 

 

Acknowledgements

We appreciate partial support from National Science Foundation grant for Information Technology Research (#0086143) Understanding the Social Impact of the Internet: A Multifaceted Multidisciplinary Approach. Additional thanks to Harry Hochheiser and Rina Levy for helping us in the past to refine our understanding of Personal Role Management.

 
 
REFERENCES

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

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

Ducheneaut, N. and Bellotti, V.,  E-mail as habitat: An exploration of embedded personal information management, Interactions, 8, 5, ACM Press, New York (2001), 30-38.
 

Duchenaut, N., Bellotti, V., Howard, M., and Smith, I., Taking email to task: The design and evaluation of a task management centered email tool, Proc. CHI 2003 Conference: Human Factors in Computing Systems, ACM Press, New York (2003), 345-352.

 

Henderson, D., A., Card, S., Rooms: the use of multiple virtual workspaces to reduce space contention in a window-based graphical user interface, ACM Transactions on Graphics, 5, 3, ACM, New York  (1986) 211-243  

 

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

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

 

Freeman, E., Fertig., S., and Gelernter, D., Lifestreams: and alternative to the desktop metaphor,  Companion Proc.  CHI 96 Conference: Human Factors in Computing Systems, ACM, New York (1996), 410-111.

 

Hendler, J., Berners-Lee, T., and Miller, E., Integrating Applications on the Semantic Web (english version), Journal of the Institute of Electrical Engineers of Japan, Vol. 122, 10 (October, 2002), 676-680.

 

Nippert-Eng, C., Home and Work: Negociating Boundaries Through Everyday Life, University of Chicago Press, Chicago (1996).

 

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

 
Kandogan, E. and Shneiderman, B., Elastic Windows: evaluation of multi-window operations, Proc. CHI’97 Conference:  Human Factors in Computing Systems, ACM Press, New York (1997), 250-257.

 

Kaptelinin, V., UMEA: Translating interaction histories into project contexts, Proc. CHI 2003 Conference: Human Factors in Computing Systems, ACM Press, New York (2003), 353-360.
 

Nardi B. and Barreau , D., “Finding and Reminding” revisited: Appropriate metaphors for file organization at the desktop, SIGCHI Bulletin, 29, 1 (1997) 76-78.

 
Plaisant, C. and Shneiderman, B. (1995). Organization overviews and role management: Inspiration for future desktop environments, Proc. IEEE 4th Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises. ACM Press, New York (1995), 14-22.
 

Plaisant, C. and Shneiderman, B., Organization overviews and role management: inspiration for future desktop environments, Video Proc. CHI’95 Conference: Human Factors in Computing Systems, ACM, New York (1995). Also included in the 1994 HCIL Open House video, www.cs.umd.edu/hcil/pubs/video-reports.shtml .

 

Redmiles, David (Editor), Special Issue on Activity Theory and the Practice of Design, Computer Supported Cooperative Work 11, 1-2 (2002).

Robertson , G., van Dantzich , M., Robbins , D., Czerwinski , M., Hinckley , K., Risden , K., Thiel , D., Gorokhovsky, V., The Task Gallery: a 3D window manager, Proc. of the SIGCHI conference on Human Factors in Computing Systems, (2000) 494-501

Roos, L. L. Jr. and Starke, F. A. Organizational roles, in Nystrom, P. C. and Starbuck, W. H. (Editors), Handbook of Organizational Design, Vol. 1: Adapting Organizations to Their Environments, Oxford University Press, Oxford, UK (1981).

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

 

Shneiderman, B. and Plaisant, C., The future of graphic user interfaces: Personal Role Managers, People and Computers IX, Glasgow, Scotland: British Computer Society (1994), 3-8.

 
Sidner, C. and Whittaker, S., Email overload: Exploring personal information management of email, Proc. CHI 1996 Conference: Human Factors in Computing Systems, ACM Press, New York (1996), 276-283.
 
Singh, B. and Rein, G., Role Interaction Nets (RINS): A process description formalism, Microelectronics and Computing Center, Austin, TX, Technical Report CT-083-92 (1992).

 

Venolia, G. D. and Ceustaedter, C., Understanding sequence and reply relationships within email conversations: A mixed-model visualization, Proc. CHI 2003 Conference: Human Factors in Computing Systems, ACM Press, New York (2003), 361-368.

 

 

 

 

 

 

 

Note about the student authors:

 

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 nanotechnology; he is now a graduate student seeking his Ph.D. in the Electrical Engineering department of Pennsylvania State University researching thermal transport in nanowires.

 

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 a recent graduate of 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.


 

 



[1] 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 research, teamwork, communication and leadership skills.  The team included students from Civil Engineering, Biochemistry, Electrical Engineering, Physiology and Neurobiology, German and Computer Science.  Working under the guidance of a mentor (Catherine Plaisant) they met once a week for 3 years. This research was conducted mostly independently by the students, who wrote a final thesis about their work, which is summarized here.

[2]  The idea of subroles was introduced by the students.  The original Personal Role Management proposal specifically avoided subroles because of the added complexity.