When an intermediate view matters: A 2d browser experiment

 C. Plaisant, D. Carr, H. Hasegawa

 

Introduction

The browsing of two dimensional images can be found in a large number of applications such as geographic information systems, word processing, painting or drawing, CAD/CAM systems, process monitoring, medical diagnostic, etc. The images can be relatively small (eg. a screen size drawing) or much larger (e.g. a 100 page document, a 10,000 node link diagram, a city street map). The image may also have to be seen at a very high magnification (e.g. a VLSI circuit diagram or a tissue sample). When the image to be viewed is larger than the screen available, a two dimensional browser (2D browser) has to be provided to allow users to access all parts of the image.

Designers have often relied on a couple of traditional scroll bars or have produced ad-hoc designs for two-dimensional scroll bars. Providing a detailed view coupled to an overview is a classic solution to the problem (eg. a detailed view of the US and a small view showing a world map as an overview, with a mark for the US.) The overview of the entire image space provides context to the detailed view and allows rapid jumps to different parts of the image. But many different tasks are performed with 2D browsers, which probably explains the large number of features found in existing 2D browsers. Little is known about the appropriateness of those features. For example, it is usually accepted that a permanent overview is necessary when the entire image is much larger than the screen. But how much larger? How much of the space is to be dedicated to the overview?

In this work we looked at how well an global overview supports systematic exploration. An overview facilitates large moves (eg. in our map example, users simply click on the world map to look at France) but, if users want to explore the suburbs of Paris the world map becomes of little use. A map of the Paris region is more useful and will allow a more precise exploration. In other words the question is: When does an intermediate view become necessary? And what happens when the intermediate view is not available? We looked at this problem in the context of a practical application: the remote examination of tissue samples under a microscope. The primary task is to browse a large image at different magnifications varying from 25x to 1000x. In order to redesign the user interface for this application we first examined other browsers and looked for previous research on the problem. Next, we decided to keep the original overview and single detailed view browser design. However, we noticed that at high magnification the overview was of very limited use for local navigation. We proposed to offer an intermediate view or local map to assist local navigation at high magnification. But, this addition would require additional hardware and software changes in the commercial system. Therefore, we conducted an experiment to verify the benefits of providing an intermediate view. At higher ratios users performance significantly degrade when no intermediate view is provided. Although, the pathology application is specialized, we believe that these results can be applied to a wide range of applications.

 

PREVIOUS WORK

 Many papers can be found describing 2D browsers [6, 11] or applications using 2D browsers [5, 10]. Maps or overviews have been said to help people keep track of their location [1]. Shneiderman [12] identifies two dimensional browsing as a case of multiple window coordination and three examples of browsers are given. Few studies have compared 2D browsing techniques. Windowing versus scrolling on a visual display terminal as been studied [3], but in the context of large text documents. Leung [8] describes four basic techniques: two screens, split screen, bifocal display and fisheye view. Examples are given and some very rough guidelines for use are suggested. Beard gives many examples of the uses of 2D browsers in radiology applications, hypertext , and other information systems [2]. Then an experiment is described which attempts to evaluate the usefulness of the roaming and zooming techniques compared to scroll bars. The display of the miniature overview of the image was found helpful. Roaming and zooming were found superior to scrolling only.

Despite the fact that geographical information systems come naturally to mind as typical 2D browsers, very little is done in those systems to assist the browsing. Most systems merely allow maps to be generated then printed and browsed on paper, or have open-ending windowing facilities and provide rarely used macro facilities to customize them to a specific application.

 

A Multitude of Tasks and of Browsers

Our exploration of existing systems led us to identify a large number of techniques as well as a wide diversity of tasks being conducted with such browsers. We found that most tasks can be classify among the following categories:

  • Image generation: Users are drawing or painting a large image or diagram. The attention is on a small part of the image, but there is often the need to step back to look at the entire image.

• Open ended exploration: With a surrogate travel program, a museum patron or a tourist can explore a remote city by navigating a map and accessing information on the local attractions. The exploration needs to be easy and the user interface quickly mastered.

• Diagnostic: A special exploration task is the diagnostic task. Most of the time is spent panning the image, looking for patterns, therefore panning speed is crucial. Coverage is also important as skipping part of the image can result in the wrong diagnosis.

• Navigation: Users navigate in a more or less known environment. The typical question in mind is ÒHow do I get there?Ó A global view is necessary to show the current position, provide context, and point at destinations. Zooming and panning occur only occasionally.

• Monitoring: Here users have to Òkeep an eye on everythingÓ and always need the status of the whole system that they are monitoring. They also need a way to view several problems in detail at once.

It is harder to classify the many different 2D browsers found in research or commercial systems. The most common techniques are:

  • One window with zoom and replace: An overview is presented so that the entire image is viewable. The user then marks a rectangular area and that area is magnified and replaces the window. To continue browsing the user must zoom out to the overview and zoom in again (eg common in CAD programs).

• Coupled detailed view and overview: Many 2D browsers provide an overview of the whole image as well as a local magnified view of part of the image. The most common screen layout reserves a small part of the screen for the overview (eg. for painting program, road navigation, hypertext network browsers, and hierarchy browsing) but, in some cases it is the overview which occupies most of the screen (eg. monitoring of a network). Sometimes both windows are of equal size or the ratio between the two windows can be adjusted. The small window is usually placed to overlap the large window; therefore, hiding part of the large image. The small window has to be moveable to allow access to all parts of the image.

• Free zoom and multiple overlap: This is the typical option chosen by systems running on fast platforms with large screens. Users are free (and required) to specify, move, reshape and delete every window. This is a very flexible environment but, managing the display takes a significant amount of time and windows are constantly obscuring each other.

• Fisheye view: A more rarely used alternative is the fisheye view [6, 11] . The image is distorted so that the center of interest is displayed at high magnification while the image is progressively compressed at other places. It uses a single view so no zooming or scrolling is required but distortion can be very severe, which is a problem with geographic information, CAD/CAM drawings, or any image where an object's shape is of importance.

This is far from an exhaustive list of the possible 2D browsers but shows the diversity of possibilities. There exist 2D browsers which don't even allow panning while others swamp users with a multitude of options. Others provide automated placement of windows following complex strategies[5]. We are currently working on a taxonomy of 2D browsers including aspects such as static and dynamic viewing characteristics, number of views, recursivity, zoom ratio specification, window placement strategies, automated features such as searches, and trails or scans. Our hope is that a careful analysis of the existing designs and the tasks they are used for will help us understand what features of 2D browsers are required when a given task has to be performed. For example, it seems more appropriate to use a small overview for an image generation task. However, a large overview might be better for a monitoring task because a lot of attention needs to be given to overall status. Research is still needed to show the benefits and drawbacks of 2D browser features.

 

Our Practical Application

 We investigated the use of intermediate views in the context of a telepathology workstation [13,14]. Telemedicine is the practice of medicine over communication links. The physician being consulted and the patient are in two different locations. A telepathology system has been developed and commercialized by Corabi Telemetrics Inc. [figure 1]. It allows a pathologist to render a diagnosis by examining tissue samples or body fluids under a remotely located microscope. We worked closely with Corabi to develop an improved user interface for the system.

 

Figure 1: Simplified diagram of a telepathology system.

 

 It has been shown that telepathology was possible and that diagnoses can be rendered from remote sites using a video monitor. Design efforts are now aimed at optimizing the workstation to ensure its successful integration in the organizational and social context of pathology services. The telepathology workstation is a very rich practical environment offering many interesting research problems nested in the practical limitations of a "real world" application.

Specimens are very high definition 3-D color objects that take too long to digitize and have impractical storage requirements [14]. Therefore, it is currently not practical to digitize the entire specimen at the highest magnification. Instead the specimen is viewed under the microscope and the analog image is sent in real time to the diagnostic workstation. One of the main challenges has been to accommodate for time delays in the system [7, 4, 9]. The delays are introduced by the communication channels and the mechanical devices being operated (eg. the slow motorized microscope).

Tasks and constraints

The typical pathology 2D browser task is a diagnostic task: most the time is spend panning the image, looking for patterns, then zooming in for more details. Speed is very important (pathologists are paid by the case), and overlooking part of the image can result in serious problems for the patient (and the pathologist!). Ease of navigation is essential as well as knowing where you are and where you have been.

The simulator

Because of the considerable cost and complexity of the real system we used a simulator to explore alternative interfaces. This simulator consists of 2 PC's linked together via a serial line. It uses images made of color rectangles instead of tissue samples. This substitution was made in order to simplify the real-time animation in the simulator. For this experiment we disabled many of the features or variations (e.g. the delays were set to a constant 2.5 seconds and focusing and illumination were always adjusted properly.)

The browsing interface

Our initial 2D browser design corresponds to the traditional "coupled overview plus detailed view" browser [figure 2 & 3]. The overview of the entire slide is created by digitizing the slide under a separate camera available for taking views of gross specimens. This was originally the only access to a digitized image. It is monochrome and has to remain of relatively poor quality to prevent pathologists from conducting the diagnostic from an image other than the very-high-definition, diagnostic-quality image. The overview of the slide is approximately five times larger than the specimen (5x). So, the detail-to-overview ratio is 20:1 when the sample is viewed at 100x under the microscope, 40:1 at 200x and up to 200:1 at 1000x. A red rectangle on the overview shows the location of the microscope field-of-view (or stage) which can be directly manipulated. A trackball is used to move the stage of the microscope.

When the trackball movement is small a cursor visible on the detailed view [figure 3] indicates the final destination of the motorized stage. When the move is larger the cursor disappears from the detailed view (leaving a direction mark on the side) and users have to rely on the overview to see and set the final destination of the stage. But, at 200x the stage indicator has become very small and at 400x it is only an X. A pixel move of the 400x cursor corresponds to several screens worth movement of the detailed view.

The questions

In one of our earlier experiments we showed that dragging the overview was helpful to novice users for large moves[4]. But at high magnification the stage indicator becomes so tiny that it cannot be controlled precisely for small movements of the stage. In such cases the proposed solution was to replace the overview by an intermediate view (similar to a map of Paris region in our beginning example). Our questions were: When does the overview becomes useless for exploring the sample at high magnification? What is the effect on the diagnostic? And what is the detail-to-overview ratio for which an intermediate view of the slide becomes necessary?

A double motivation

In addition to our research goal of providing general guidelines to 2D Browser designers we also had the more practical need to justify the "expense" of the intermediate views. Providing intermediate views implied two changes:

  • For the hardware: adding a digitizing board to the system to get usable views (since simply zooming on the existing overview would not provide usable intermediate views over 100x)

 

• For the user interface: adding complexity to handle intermediate view requests, mechanism and rules to allow the return to the whole overview, and the listing and managing the existing intermediate views.

Therefore, giving users access to intermediate views would be considered only if necessary.

 

THE EXPERIMENT

We conducted an experiment to evaluate the effectiveness of the intermediate view for 3 magnifications (100x, 200x, 400x) corresponding to a 20:1, 40:1, and 80:1 ratios between the overview of the slide and the magnified view to explore. Our hypothesis was that at 20:1 the intermediate view would not be necessary while at higher ratios the subjects using the intermediate view would perform significantly better.

We recruited 24 subjects with an advertisement posted on campus and in downtown College Park. Half the subjects were instructed to use the "local map" feature of the browser while this feature was disabled for the other group. Subjects were paid $10 for participation. To encourage speed and accuracy, an additional $10 bonus was given to the subject who performed the tasks without errors in the shortest time.

The Tasks

For each task the instruction sheet gave the approximate location of a special yellow rectangle (representing a "bad" cell). Subjects had to find this target at low magnification (25x), increase the magnification to a specified level (100x, 200x, or 400x), and search within the yellow rectangle for additional small yellow rectangles that were visible only at high magnification. Half the subjects where instructed to make an intermediate view by touching the "LOCAL MAP" button on the control screen. The current image viewed on the detailed view would replace the slide overview on the control screen [figure 4]. After completing each task the subjects reported the number of small yellow rectangles that they had found and rated their confidence in their answer on a scale of 1 (unsure) to 7 (certain). Although pathologists rarely scan rectangular areas, they do systematically scan small areas of interest. We used rectangles because it was a simple area that all subjects could scan with a simple strategy.

After a demonstration, three practice tasks allowed subjects to become comfortable with the equipment and the tasks. Then, each subject performed three tasks at each magnification. The order of the three magnifications was counterbalanced. All subjects where encouraged to use the same zig-zag scanning strategy. They were told that speed and accuracy were important and reminded of the bonus. During the experiment subjects were not informed of their errors. About 30 minutes was necessary for training and 45 minutes to complete the 9 tasks. In addition to the confidence levels, we measured the time to complete the tasks and the number of errors. An error was counted each time an incorrect number of small rectangles was reported.

 

Results and discussion

Student t-tests were computed between groups for each of the dependent variables (no comparison was made across magnifications).

As expected there were no significant differences at 100x in either the number of errors or completion times [table 1]. However, users having the intermediate view were significantly more confident about their answers.

 

100 x 1:20

With Int. view

No Int. view

t value

Errors

(per 3 tasks)

.58

(.64)

.92

(1.04)

0.91

Time (in sec.)

for 3 tasks

394.67

(62.56)

477.00

(128.94)

1.91

Confidence

(1 to 7=high)

6.56

(.39)

5.92

(.93)

2.09*

Table 1 -- Means and standard deviations for 100x (20:1) [*significant at =.05]

At 200x both groups worked at about the same speed and with the same high confidence level but the users not having the intermediate view made significantly more errors [table 2]. We observed that they tried to use the overview to keep track of their movements, but they had problems navigating and overlapped their trail or left strips of the image unexplored. This indicates that overview was already insufficient for a detail-to-overview ratio of 40:1.

 

200 x 1:40

With Int. view

No Int. view

t value

Errors

(per 3 tasks)

.25

(.60)

.92

(.76)

2.29*

Time (in sec.)

for 3 tasks

749.91

(191.41)

804.00

(246.52)

0.56

Confidence

(1 to 7=high)

6.28

(.52)

5.94

(.83)

1.13

Table 2 -- Means and standard deviations for 200x (40:1) [*significant at =.05]

 

 

400 x 1:80

With Int. view

No Int. view

t value

Errors

(per 3 tasks)

.25

(.60)

.83

(.99)

1.68

Time (in sec.)

for 3 tasks

364.33

(95.57)

493.50

140.31

2.52*

Confidence

(1 to 7=high)

6.56

(.46)

5.92

(.82)

2.26*

Table 3 -- Means and standard deviations for 400x (80:1) [*significant at =.05]

 

The delays in system response may have emphasized cost in time of making navigation errors. However, we do not believe that it played an important role and many other systems have delays due to computational complexity when they generate and animate high resolution images.

We had anticipated finding an advantage in time at 200x and were surprised not to find differences in time at 200x. We think this can be explained by the fact that the rectangles to scan at 200x were larger and required more planning and more care executing the zig-zag strategy which seemed difficult for some subjects. Several subjects scanned the rectangle twice to be certain of their answer. But for any application involving some diagnostic task the number of errors is far more important. More errors were made at 200x but the subjects did not seem to realize that they were making them. Their confidence did not change from the other magnifications.

Conclusions

Despite our improvements, exploration of the specimen remains long and difficult. Some partial automation of the process would be very helpful. For example users could draw a trail that can be followed automatically, with the possibility to stop, explore locally and resume following the trail. Also, an area can be marked on the slide overview to be scanned automatically. The areas already scanned can be shown to allow users to verify that all important parts of the slide have been seen.

The results of this experiment apply to other domains such as browsing maps, schematics, or any large graphic. Our questions were: When does an intermediate view become necessary? And what happens when the intermediate view is not available? Our experience shows that an intermediate view should be introduced when the ratio of images is above 20:1. Certainly, by the time the ratio reaches 40:1 users have serious difficulties and the global overview is more of a hindrance than a help.

General guidelines for designers of 2D browsers need to be developed. An important challenge remains to find the best match between features and the tasks to be performed. We have begun to look at 2D browsers with the goal of producing design guidelines supported by empirical studies of users.

We believe that our experience is also a good example of a real world application for which added features and added hardware need to be justified. The product developers heard our initial suggestions, but the prototypes and the experimental results[4] had much more influence when decisions were made about future versions of the system.

Acknowledgments

We want to thank all the members of HCIL for their helpful discussions. Funding for this project was provided in part by the State of Maryland (MIPS), Corabi Telemetrics International . and the System Research Center of the University of Maryland.

References

[1] Baird, J. C., Studies of the cognitive representation of spatial relations, Journal of experimental psychology, 108, 90-106 (1979) 

[2] Beard, D., and Walker II, J., Navigational techniques to improve the display of large two-dimensional spaces. Behaviour and Information Technology, 1990, Vol.9, no.6, 451-466

[3] Bury, K. F., Boyle, J. M., Evey, R. J., and Neal, A. S., Windowing versus scrolling on a visual display terminal, Human Factors 24, 4, (1982), 385-394.

[4] Carr, D., Hasegawa, H., Lemmon, D., Plaisant, C. (March 1992), The effects of time delays on a telepathology user interface, Technical Report CAR-TR-616, To appear in Proc. of AMIA 16th Annual Symposium on Computer Applications in Medical Care, Baltimore, Nov.10th 1992.

[5] Funke, D., Neal , J. and Paul,, R., An approach to intelligent automated window management Calspan Corp. Technical. Report , Buffalo [to appear ]

[6] Furnas, G., Generalized fisheyes views. Proceedings of CHI’86, Human Factors in Computing Systems, ACM, 1986, pp 16-23.

[7] Keil-Slawik, R., C. Plaisant, and B. Shneiderman; "Remote Direct Manipulation: A Case Study of a Telemedicine Workstation"; Aspects in Computing: Design and Use of Interactive Systems and Information Management, Bullinger H.-J. Ed., (Proc. of the 4th Int. Conf. on HCI, Stuttgart, Sept. 91). Elsevier, Amsterdam, 1006-1011.

[8] Leung, Y. K., Human-computer interface techniques for map based diagrams, in Salvendy, G. and Smith, M., Eds., Designing and Using Human-Computer Interfaces and Knowledge Based Systems, 361-368, Elsevier, Amsterdam, 1989.

[9] Plaisant, C., Carr, D. and Hasegawa, H., Exploring remote images: a telepathology workstation. To appear in Siggraph Video Review - Issue on INTERCHI '93

[10] Rein, G. L. and Ellis, C. A. rIBIS: a real time group hypertext system, Int. Journal of Man-Machine Studies, 34(3) 349-368 (1991)

[11] Sarkar, M. & Brown, M., Graphical fisheyes views of graphs, Proceedings of CHI’92, Human Factors in Computing Systems, ACM, pp 83-92

[12] Shneiderman, B., Designing the User Interface, Addison-Wesley, 1992.

[13] Weinstein, R., K. Bloom, & S. Rozek; Telepathology, Long Distance Diagnosis; American Journal of Clinical Pathology, 91 (Suppl 1) (1989) S39-S42.

[14] Weinstein, R., K. Bloom, & S. Rozek; Telepathology, Static and Dynamic Imaging in Pathology IEEE Proceedings Image Management and Communications, Vol. 1 pp. 77-85, 1990.