What types of display techniques can be used effectively in the periphery? Graphics can encode large amounts of information in a small space. Auditory cues can inform the user without occupying any screen space. Animation can cycle through information, informing the user without requiring physical interactions.
What types of tasks are best suited for this type of peripheral display? Various tools support awareness and monitoring, though the ever increasing amount of information on the Web presents a new domain to test their effectiveness. Peripheral displays could provide a quick way to perform browsing, searching, and reading tasks without having to raise a window specifically for the task. However, the problem remains of matching display techniques to tasks in a manner that people enjoy using and can use effectively.
This chapter presents Irwin, a peripheral tool that employs the communication mechanisms described above in a peripheral display. A case study examined how Irwin users made use of the tool, and the relative merits of peripheral displays for a variety of tasks are discussed.
Irwin [51] monitors Internet information resources and alerts the user of updates and modifications. Irwin consists of a set of hypertools-small reusable programs that can run simultaneously and share information. The central tool in Irwin handles the visualization and user interactions, while the remaining tools process the information from each resource and update the visualization tool when important changes occur.
The information resources monitored by Irwin can include email folders, Usenet newsgroups, Web pages, and weather data. The email and newsgroup hypertools monitor the messages in a folder or group, alerting the user when new messages arrive. The Web tool summarizes headers, lists, and hypertext links on a Web page, allowing the user to monitor news wires and hotlists. The weather tool monitors the weather conditions and forecast for a given city. Each results in a list of information that is then displayed by a variety of communication techniques.
Irwin uses multiple communication techniques to convey an overview of each resource as well as details about a selected resource: a set of animated icons, an auditory cue, a navigation bar, and several textual views. In the set of icons, the state of each resource is given by an icon. As the resource changes, the appearance of the icon changes and an auditory cue is played. If user selects an icon, the other views are updated to show information about the corresponding resource. A navigation bar shows a syntactic encoding of the resource contents and can be used like a scrollbar to scroll through the messages displayed in the textual views. Users can configure the orientation and placement of the icons with respect to the other views and can even choose to hide the other views until some event happens, e.g. an icon is clicked. Figure 1 shows the Irwin interface; the remainder of this section describes each communication technique that it uses.
Figure 1:
The Irwin user interface.
The resources (email, a Web page, a Usenet newsgroup, and the local weather)
are represented by selectable icons in the icon bar at the far left.
Next to the icon bar, the navigation bar provides a graphical overview
and navigation tool for the selected resource.
The header list and message view
support textual browsing and reading capabilities for the resource.
Audio updates add a non-visual cue that alert the user
when a change occurs.
Icons are used in interfaces because they provide a universal representation in a small amount of space. In windows-based environments, they can both provide information and invite the user to click to obtain more information. Studies have shown that changing the appearance of icons can convey additional information about their use; for example, animated icons [4] convey more information about the functionality of tools in a tool palette than a static image.
Irwin uses a 16-by-16 pixel animated icon that changes color and appearance based on the state of and changes to the contents of the information resources they represent. In addition, for some types of information the bitmap itself changes based on the state of the resource. The expectation is that changes to the icons will draw attention and convey information about the status of the resource. Figure 2 further explains how the animation occurs.
Figure 2:
A time-lapse series of shots of the Irwin email icon.
When new email arrives, the icon changes color,
then gradually fades toward the original color.
It does not completely return to the original color
until the user reads the new message or
clicks on icon to acknowledge that it was received.
Other icons behave similarly when updates occur,
and some change their appearance based on
the nature of the contents.
Auditory cues provide an additional mechanism for alerting users that a change has occurred. They may be the only way the user knows about the change if the display is obscured or if the user is not looking at the screen. Auditory cues have proven useful in both enhancing and replacing visual cues in user interfaces [8, 7].
Based on these previous results, I felt it would be useful to allow users to combine an auditory cue with the visual icon change. I selected sounds that are distinctive but are not distracting and, most importantly, are short. Each is less than two seconds in duration, which I expected would be long enough to be noticed but not too long to become an annoyance. In the initial configuration, I tried to select sounds that were indicative of the resource; for example, a dog bark for mail (dogs always bark at the mail carrier) and a splat for news (similar to a newspaper hitting a front porch). Of course, the user can select any desired sound; Irwin provides a list of twenty.
Since screen space is at a premium in Irwin, use the space occupied by a scrollbar not only is used for navigating the list but also for providing an overview of the contents of the list. To accomplish this, several graphical methods were developed for encoding useful information about a line or word of text into a small area.
One way to representing large amounts of textual information in a small space is to reduce the size so that text appears as a few graphical pixels. Fisheye views, read wear and edit wear, and the SeeSoft and RunView packages all use this type of encoding [26, 33, 20, 49]. Irwin uses a similar representation that combines this type of information encoding with the power of a scrollbar in a device called a navigation bar. Each line of text in a list is represented by a line of pixels, and the lines are colored and positioned to convey information about the items in a list.
The navigation bar supports both semantic and syntactic encoding of information. Semantic encodings are used when the user wants to highlight specific items such as sender names for email, subject for news, or topics on Web pages. The semantic encoding requires the identification of a word or phrase to encode by analyzing the structure of the sentence using various information retrieval techniques [24]. The semantic encodings require user specification of color mappings or require a legend to explain to the user the meanings for each color. Since a legend takes up a lot of space and space is at a premium, a syntactic encoding was used instead.
The syntactic encodings encode words or phrases from a list graphically, where a 4-by-4 block of pixels represents each character in the word. To differentiate between words of equal length, the blocks are colored that correspond to vowels such that `a' is red, `e' is orange, `i' is yellow, `o' is green, and `u' is blue. Since syntactic encodings remain consistent between sessions, users can learn and remember encodings between sessions. Also, unlike semantic encodings, syntactic encodings do not require the user to select item characteristics of interest and thus have a lower startup cost.
Users interact with the navigation bar to control the portion of the information list that is visible in the text view. The black box surrounding a series of messages indicates that they are visible in the textual list. A grey highlighting line indicates the pattern for the currently selected message. Figure 3 shows the navigation bar and textual views displaying information for an email folder.
Figure 3:
Irwin's display of an email folder.
Note that many of the visual structures found in a scrollbar
are present in the navigation bar. They function in a
similar manner.
The message encodings are contained in the trough
of the navigation bar and contain a set of coded lines
representing each email message.
The encodings are indented proportional to the time at which
the message was received to group them visually by arrival time.
Since not all message representations can fit in the navigation bar
at a time, the indicator line reflects the position and percentage
of message representations that are visible.
The text views to the right provide detailed information
about the selected messages.
The time at which the message was stamped is encoded by indenting the message according to the hour; for example, messages received at 3 PM will be indented three blocks. This is intended to group messages by arrival time, thus facilitating searches and browsing. If users knows the time at which a message arrived, they can identify the range of messages in which it must fall using the navigation bar.
I conducted a study to examine the effectiveness of navigation bars. The study showed that users are able use navigation bars to perform various searching and browsing tasks more effectively than with a traditional scrollbar [50].
Graphics alone might not show all the information necessary to understand a message -- at some point a textual view will likely help. Irwin incorporates two textual views: a header list and a message view. Irwin constructs lists of headers for each resource, the senders for email and Usenet news, abbreviated headers for Web pages, and days of the week for the weather forecast. If the user selects an item from the list, the message view shows a more informative summary of the original message. The user can click on the message view to jump to a browser to see the full message.
Irwin was designed with four potential tasks in mind, browsing, searching, monitoring, and awareness.
In the case study, I wanted to learn how people use technology to increase information awareness. What tasks do users want to do with an awareness tool? Do icons that change appearance provide useful information? Do auditory cues increase awareness in a positive way, or will they become intrusive or annoying over time? Are syntactic encodings usable and learnable? By offering Irwin to users and observing how they use it, I hoped to answer some of these questions.
Nine people attended a presentation and demonstration explaining how to set up and use Irwin. Seven people tried Irwin at least once, and four of those continued to use it regularly.
I asked those who did not use Irwin why they chose not to. Most simply did not feel that they needed such a tool. One person noted that she didn't receive much email and only rarely browsed the Web: ``I'm an example of a fish who doesn't want a bicycle for Christmas - I just don't have much use for it!'' One user wanted a less passive visualization tool. He reported the he felt he did not have enough control over when the resources were checked. ``At times I want to tell it to go get information about a newsgroup or Web page. I don't want to just wait for the regular time interval checks.''
Five months after the presentation I visited with the four frequent users individually for about an hour to discover how they used Irwin, and in particular which features were most and least useful. Many of the questions were open-ended, allowing the users to expand upon issues of interest. I also asked them to discuss other possible uses for awareness and monitoring tools. Their responses are summarized in the next section.
The four participants in this study were all members of the Georgia Tech Graphics, Visualization, and Usability Center. This allowed me to assume a certain level of sophistication with email, Usenet news, the Web, and interfaces in general. Alan was a faculty member with a private office and his own Sun workstation, while the other three were graduate students who used X-terminals in cubicles and workstations in a shared laboratory.
The participants' real names have been changed to preserve their anonymity, and none of the participants were required to use Irwin or to answer any questions about it. I hoped these assurances helped to generate a realistic experience.
Alan used Irwin to monitor his email, the Golf Magazine GolfOnline Web site, ESPN television's ESPNET Web sports news wire, and the local Atlanta weather. He placed Irwin in the lower right corner of the screen with all views generally visible.
Alan used a different auditory cue for each resource. ``I chose nice short sounds that are moderately loud - long ones get old.'' Alan relied primarily on the auditory cues to inform him of changes; he infrequently looked to see if the icon appearances had changed and sometimes even had the icon view partially covered with other windows at times.
Alan received around sixty email messages a day, and he always left his email tool running. When he received new mail, he almost always turned to his email tool rather than to Irwin. Alan mainly used Irwin for passive browsing of Web sites that he normally would not have visited very often. Since Web sites change at irregular intervals, Irwin alerted Alan of changes without requiring him to check the site himself. Alan typically looked only at the currently displayed message when it popped up and rarely clicks on the icons or the navigation bar to view other resources or earlier messages. Sometimes he browsed through the textual list and selected messages to view on the message display. When he saw a particularly interesting message, he used Irwin to pull up the full article in his Netscape Web browser.
Since Alan did not use Irwin to browse old email or Web summaries, he doubted he would use any navigation tool, whether it be a syntactic or semantic encoding or even a regular scrollbar. The only desired feature would be a thread display for email that would highlight threads of related messages, a feature not present in his mail reader. This added value might be useful, but as it was he preferred to pull up his mail reader when he needed to do any searching or browsing.
Alan wanted Irwin to monitor other information resources, in particular Unix commands for checking the status of shared hardware resources. Sometimes when printing a large document, he needed a tool to monitor the print queue and to alert him when the job is done. Alan noted that monitoring the status of processes might be useful to see if they become defunct or exit abruptly. He stated that he would be willing to do a one-time configuration if it were then easy to start and stop these type of monitors. In addition, there were certain Web sites with images that Alan would like to monitor; for example, traffic report maps and weather radar pictures. He reported that he would like for Irwin to display a miniaturized version of these images.
Bert used Irwin to monitor the local weather and six different email folders. Since Bert filtered his email, he needed a tool like Irwin to help keep track of changes in each folder. Bert configured Irwin so that only the icons are visible unless the cursor was inside the Irwin window. Bert placed his Irwin at the upper left corner of his screen above his clock and system load monitor.
Bert had the same auditory cue (a beep) for all of his email folders. When he heard it, he looked at the Irwin animated icons to see which folder received email. ``It's less trouble just to look at Irwin than to remember lots of different sounds.'' Bert liked the fact that animated icons fade over time because it reminded him that there was email that he had been neglecting. He liked the changing weather icon but was unsure about having other icons change appearance. ``Just so it's simple and makes sense.''
Bert used Irwin primarily to alert him when new email arrives. He liked the quick access to information that Irwin provided. ``It's much quicker than starting email, so I use only Irwin when possible.'' Bert pulled up his mail reader when he needed to read long messages or to reply to a message, functions that are beyond the scope of Irwin. Often times he knew from the message summary that he could ignore the email until a more convenient time.
Bert generally did not look at the navigation bar, though sometimes frequently repeated patterns would catch his eye. He never tried to do any searching or browsing with Irwin, opting instead to use his email reader and Web browser for such tasks. He reported that he might use the navigation bar more if the information provided were more useful, like perhaps showing the importance of the message in some way. He actually found the weather navigation bar's encoding of the day of week more useful than the syntactic encoding.
Bert reported that he would like to configure Irwin to monitor people's activities, in particular to see if they are available. At the time, he had to run the Unix finger command repeatedly to see when people were at their machines. This type of repetitive task would be well-suited for a tool like Irwin. Bert also wanted his clock and system load monitoring tools integrated into Irwin to save room on his desktop. He noted that some operating systems provide these types of toolbars, but often they are not very configurable.
Carl used Irwin to monitor his email, a Usenet newsgroup, the ESPNET news wire, and the local weather. He placed Irwin at the top of the screen next to his clock, and he always left all of the Irwin views visible.
The only sound Carl configured in Irwin was a beep for email. He listened to a few of the sounds but decided against using them. ``They would drive me up the wall.'' Carl even complained that some of the longer and louder sounds from other people's Irwins disturbed him.
Instead of sounds, Carl relied on the icons for information about new messages. He particularly liked the weather icon and wished that other icons changed appearance as well. Since he often used an X-terminal with a black-and-white monitor, neither the change in color of the icons nor the syntactic encoding of keywords were of much help. He would have liked to associate icons with different events so that when the event occurred the corresponding icon would be visible.
Carl tended to use Irwin for browsing more than the other users. However, he said he only recognized two patterns in the navigation bar (one being his own encoded login name). Occasionally Carl would notice repeated patterns in some newsgroup representation; generally this meant a knowledgeable person was replying to a number of messages at once, which made for interesting reading.
Carl liked to read the Irwin textual message summaries for news articles because it was quicker than starting a news reader. However, he was frustrated that articles were truncated after a limited number of words. Usually he wanted to see the entire message without having to jump to his news reader. Similarly for Web pages, he did not want the slow-loading graphical view used by most browsers and preferred a quick view of the text only. For Carl, the big advantage of Irwin was the speed at which he could obtain information.
Carl believed that a variety of views in the navigation bar would be more useful. At times he would have preferred a site-of-origin view where the bars are colored by the site at which the message originated, and other times he wanted a message threads view. ``It should be easy to configure to see alternate views.'' In addition, Carl wanted to be able to zoom in and out of the representation, or perhaps even have a fisheye view of the resource. He was concerned that he could not see the entire resource at once.
Dora used Irwin to monitor her email, USA Today's Washington DC news wire, the local weather, and two Usenet newsgroups. She placed Irwin at the bottom of the screen between her system performance and desktop management tools.
Dora associated a different sound for each category of resources; for example, Irwin barked when new email arrives and beeped for any new news. She would have preferred to combine related resources into a single icon. Then she would have known at a single glance whether a resource of immediate interest had experienced changes. ``At busy times I might check my email but not my newsgroups. It would be helpful to only have to check a single icon.''
Dora was the only participant who used semantic highlighting. She created three lists of names for her email: one for coworkers, a second for family members, and a third for her PhD committee members. Each list of names had a different highlight color, so when she looked at the navigation bar she could tell who had been sending her email. ``When I see a lot of red, that generally means I'm in trouble with somebody.'' Dora still left the syntactic encoding on as well so she could distinguish between other messages. However, she did not recognize any names, though she sometimes noticed repeated patterns resulting from several messages from the same person.
Since she generally worked in a lab or cubicle without windows, Dora enjoyed the changing icon of the weather display. ``It serves as a reminder of what's going on in the real world.'' She would have liked to see something similar for other resources because it could have provided easily accessible information - a user would only have to look at Irwin to learn about the state of the resources.
Based on the observations of Irwin users, a number of issues emerged which should help in the future development of information awareness tools.
In general, users were willing to sacrifice a little bit of screen space to increase their awareness of the contents information resources. Even those who did not use Irwin cited reasons other than space limitations. Most users wanted to be able to integrate other monitoring tools into Irwin as well to facilitate smooth transition between the monitoring and awareness tasks performed with with Irwin and the reading and browsing tasks performed with other programs.
Some of the users stated that they would notice repeated patterns in the syntactic encodings when browsing resources. However, none of the users could associate more than a few encodings with the corresponding word or name, and none tried to do any searches using the encodings. Users did not take the time to look at the patterns because they were comfortable using other tools for browsing and searching. Both of these tasks benefit from a large amount of screen space and are not practical in small peripheral tools like Irwin. The main reason people used Irwin for tasks involving a significant amount of reading was to avoid application startup, download, and display delays.
When using Irwin, the primary task performed by the users was to maintain a general awareness of breaking information. Occasionally users took advantage of the auditory cues and icon animation to know when to check a resource. The most significant informational gain from Irwin came from the hands-off textual views.
Unlike with traditional biffs and similar tools, Irwin users can see textual information about new email and news articles, and unlike with traditional readers and browsers, Irwin users can obtain information without mouse or keyboard input. The hands-off, peripheral nature of Irwin provides users with the additional information necessary to make smarter decisions about whether to interrupt their current task to attend to email or other informational tasks.
The research described in this chapter has examined different communication mechanisms and different usage approaches for peripheral displays. Perhaps the most important advance gained in building and evaluating the Irwin system is the understanding of the possibilities for peripheral displays.
Users seemed most successful at using Irwin for monitoring and awareness, but as soon as browsing, searching, or reading became their focus, other tools that can make full use of the screen seemed more suitable. The tasks differ in that browsing and searching are active tasks that dominate users' attention (and should dominate their screen space), while awareness and monitoring are much more passive tasks that must be accomplished with relatively little effort. When performing monitoring or awareness tasks, users do not want to follow the overview, zoom and filter, details on demand model that Shneiderman touts as the mantra for visual information seeking [69]. Instead, they want details that are constantly available without any effort in zooming and filtering.
A related concern is to consider the effectiveness of various communication mechanisms in supporting monitoring and awareness. Graphical encoding techniques have proven useful in the display of static information, but its potential in staying aware of dynamic information seems less clear. Audio is useful for drawing attention to status and informational changes, but it can be annoying and intrusive and seems better suited in complementing other techniques. The animated icons provide a lasting reminder of the type and nature of changes to an information resource, yet the amount of information they can provide is somewhat limited. The textual displays naturally provide an easy method for displaying the significant amount of textual information that is generated, but text can take up a large amount of space and the static nature of the textual displays necessitated user interaction in reading the information.
The approach in this thesis is to augment textual displays with animated effects in an effort to raise awareness of a large amount of information in a hands-off manner.
Animation has been used in a variety of situations, including tickering and changing information on television stations, fading sports and news data on Web pages, and animated images in Web and billboard advertisements. Often it is looked upon as more of a distraction than a benefit, but the potential upside makes it worth considering.
The use of animation has several potential advantages:
Several potential disadvantages must be considered as well.
Gradual and repetitive animation shows potential in creating useful and usable information awareness applications. By animating large amounts of information in a small space, the remaining space can be used for other applications. Changes to the information can be integrated gradually into the display in the next iteration, minimizing the disturbance to the user. Constantly cycling through the entire information space lessens the number of physical interactions required to obtain the information - rather than having to press a series of buttons or keys to get information, the user need only wait for it to cycle through.
The next chapter examines the effectiveness of various types of animated textual effects in maintaining awareness.