Considerable work has been done in the past in regards to the presentation and operation of 2D browsing techniques. A great diversity in the design of 2D browsing techniques has been identified and some common examples include detail-only, single window with zoom and replace, tiled multi-level, free zoom and multiple overlap, bifocal view and fish-eye view. Task taxonomy exclusively for applications using browsing techniques have also been established which consists of image generation, open-ended exploration, diagnostic, navigation and monitoring. An exhaustive study in this respect was done by Plaisant, Carr and Shneiderman (Image Browser Taxonomy and Guidelines for Designers, 1995). However, in this experiment we focus primarily on two browsing techniques namely Zoom-only and Overview-detail pair as applied to LifeLines, an information architecture for viewing personal histories.

Single view browsers dedicate all the screen space to a single view. They offer advantages when users' work can be confined to parts of the image that fit on the screen, however they are not so productive when users are required to work simultaneously with distant parts of an image. The zoom-only technique is a variation of the single view browser. This is an excellent tool when the increase in size between the entire image and the detailed view leads to difficulties in navigation. The single browser flavor of LifeLines offers panning capabilities apart from letting users zoom-in and zoom-out using left and right-mouse clicks respectively.

The detail-overview browsing technique (or single coordinated pair, as it is often called) of Lifelines uses the concept o_coordination for its browsing application. Coordination is a task concept that describes how information objects change based on user actions. The detail-overview pair in Lifelines is a variation on the two-dimensional hierarchical scheme using a tightly-coupled windowing architecture. A tight coupling is maintained between the overview and the detail window, such that a field-of-view-box on the overview can be manipulated to update the detail view. Additionally, users in this scheme have a choice to use the detail view as a separate window for zoom and replace, and the tight coupling ensures that when the detail view is panned, the field-of-view-box in the overview is also resized. The layout adopted for the detail-view pair is a side-by-side placement, since it allows users to have a look at the big picture as well as the detail view at the same time.

LifeLines offers a unique way of visualizing personal histories. The application uses dynamic color-coding with multiple – zoom support to embed large volume of information about a person’s historical data in some particular arena (e.g. medical history) on a single viewable page. The data-view itself can be manipulated using either compact, chronological, advanced compact or normal viewing techniques. Dynamic labeling techniques like Infotip and Excentric enhance the overall presentation of data and gives useful feedback to the user in this vast multitude of information which otherwise would have taken several spreadsheets screens. An important feature of the application is its zooming technique, which can go several layers deep and allows for a richer visualization attribute in the representation of data. Moreover, the application, written in JAVA as an applet, is web-compliant and ensures accessibility from virtually anyplace in the world. The flexibility of the software also makes allowances for several types of browser support, and it is here where our experiment comes into focus. Since a sizable portion of the operation deals with zooming, it is extremely important that the design of the browser should not introduce disorientation or confusion among the user population while zooming, and the information representation should be consistent and intuitive. The main contenders in this case are:

• Zoom-only (or Single Window with Zoom and Replace) This technique presents a global view of the entire image. Traditionally, the user marks a rectangular area, which is magnified and replaces the entire image. This technique is slightly modified in LifeLines, as the essence is on a single dimension (the timeline) and hence the user just clicks on a portion of the graphical history record and the image gets magnified in the x-direction. However the technique is recursive, as clicking on the zoomed image would produce further zooming in the x-direction, and it is possible in this way to embed a huge amount of data within a single page. Right clicking on the screen would produce an effect in the opposite direction, as the image gets gradually zoomed out in the same number of steps. The zooming factor (or zooming ratio) is an important consideration here as too much or too little might have a detrimental effect on the user satisfaction. Also the smoothness of zooming can be a key factor in determining user-satisfaction.
• Overview-detail (or Single Coordinated Pair) This is the most commonly used theme in many 2D browsers. This browser combines displays of the overview and a local magnified view. In Lifelines, the version using the coordinated pair has 2 identical graphical history displays to begin with. Both displays consist of the overview initially. The display on the left is static and would not change for the life of the application. The display on the right magnifies the area marked on the left display by a control resembling a cross-hair. Since user manipulations on one window produce the desired effect on another, the selection of the zooming factor is absolutely vital as a non-optimal magnification factor would give the wrong signal to users, that they have no control over the application.

The experiment examines two formats for visualizing information within a browsing framework. Subjects were made to use one of the two browsing techniques and asked to answer questions based on the information given. It was predicted that participants using the detail-overview pair would do better:

• When time intervals were compared
• When accuracy was compared
• When user satisfaction was concerned.

Hypothesis:

Task Questions

We predicted that subjects using the detail-overview pair would perform with fewer errors and a faster overall response for all the questions. Also, we predicted that subjects using the zoom-only treatment would have a marginally better performance in terms of number of errors.

Subjective Satisfaction

We predicted that subjects using detail-overview pair will have a higher level of user-satisfaction than those using zoom-only treatment.

  Independent Variable:

• Zoom-only
• Overview-detail pair

• Time
• Number of Mouse-Clicks
• Subjective satisfaction

Control for Resources: There can be reasons other than the ones under discussion that might be responsible for large variation in performance. The most common factor in this case is the allocation of resources. A large monitor with better resolution might introduce performance improvements than those using monitors with lesser dimensions. The same might be said for different machine speeds. So control has to be exercised in this case, and the recommended combination is a 17-inch monitor using a Pentium machine with a speed between 200-266 MHz.

Task Selection: Considerable amount of effort was expended in developing a task structure for the experiment. Jia Li, a PhD student in the Computer Science department in the University of Maryland recently conducted an experiment on Evaluation of Three Temporal Data Layout Strategies [4]. Jia's contributions were very useful in implementing a task structure for this experiment. I have tried to include a taxonomy that encompasses a balanced mix of various types of application-usage. This include tasks that include location of events by time duration, location of events by name and ranking of events by time-duration and name.
 
 

Participants: Fourteen individuals belonging to various technical backgrounds took part in this experiment. Out of the fourteen, thirteen were students and one individual was a professional. Among the students, there were two undergraduate students (from the Computer Science department) and the rest were either students pursuing their Master’s or PhD degree. Selection of subjects was based mainly on randomization, however we saw to it that the subjects came from different disciplines and had different levels of exposure to computer and the internet (see Appendix for details).

Design: A between groups experiment was performed and each group had an equal number of subjects, that is, seven. A paired t-test was performed to look at the differences in terms of the dependent variable mean task time for each subject, a graphical representation was to depict the differences in the mean number of mouseclicks used by the two groups, and an error count kept track of the mean number of answers that were incorrect for each group. For the subjective satisfaction results, the mean score for each of the question on the questionnaire was posted in a table format relative to each group.

Materials: Both the versions of Lifelines were created using Java and using JDK 1.1 as the development environment. Both were run as applets in a web browser instead of having them run as standalone applications. This had two-fold advantages:

• It was a way of testing the robustness of the application, as future versions are more likely to run on the web than as standalone versions.
• Since it was running on the web, it provided a foolproof method of tracking the time and the accuracy of the subjects’ tests without looking over their shoulder. A webserver was running in the background which made tracking a very easy and accurate proposition.

All the tests were run at the Human Computer Interaction Laboratory at University of Maryland. The hardware requirements included a minimum CPU speed of 200 MHz and a minimum memory requirement of 32MB ram. There was no other place in the campus, which came close to meeting these requirements. Most of the participants used a 17-inch monitor and a 200+ MHz Pentium/PentiumII processor for their experiment. The memory used in most cases was 64 MB ram. Participants were scheduled one at a time except for two occasions when there were two participants running the experiment simultaneously at two individual machines. Each subject took between 20 to 35 minutes to complete the experiment including filling up the background survey and the subjective satisfaction questionnaire. Details of the experiment can be found at these three websites:

• http://www.cs.umd.edu/hcil/lifelines/expt/expt_intro1.html for the zoom-only treatment.
• http://www.cs.umd.edu/hcil/lifelines/expt/expt_intro2.html for the single coordinated pair (detail-overview) treatment.
• http://www.cs.umd.edu/hcil/lifelines/expt/manual.html: This has the location-guide to all the files and the documents used in this experiment. Should there be some individual who wishes to improvise on this experiment, this is the place where he should look first.

Background Survey: The experiment started with the subjects filling up an on-line background survey. The time to fill up the survey were not included as part of the time for calculating the mean time of the task for each subject. The survey outputted the surveys to a file which provided us with the requisite background information of the subjects. (See Appendix)

Task Completion: Submitting the background information took the subject to the actual experiment site which consisted of a two-frame page. The dominant frame had the applet running on about 80% of the screen space while the minor frame had the questions and the answer choices on the right-hand side. The minor frame was a perl-generated html frame that continued on to the next question once the question was answered and the "Submit" button was pressed. The answer was of the multiple-choice checkbox variety with three or more options. The applet was unaffected by the manipulations on the right-hand frame and mouse-clicks which corresponded to the applet were the only ones that were collected.
 
 

Subjective Questionnaire: Pressing the "Submit" button on the last task took the subjects to the subjective questionnaire page. The questionnaire consisted of a rating system for different attributes of the system. The range for the rating varied from 1 (worst-case) to 9 (best-case). Subjects were required to rate the system according to the layout, navigation, zooming, exploration, operation, feedback, initial instruction and overall reaction to the system. Provision was also made so that subjects were allowed to make any suggestions or additional comments which might not have been covered by the questionnaire.
 
 

The results indicated that the detail-overview pair had nearly significant better results in terms of mean time for all-task completion. Given a significant level of difference to be 0.05, the t-tests yielded a t-distribution probability of 0.052 with a tstat value of 2.42. No t-tests were conducted on the number of mouseclicks since one of the applications used clicking on the background as its principle for zooming while the other used clicking and dragging as its mode of operation for zooming. The detail-overview pair also seemed to soar over the zoom-only treatment in terms of number of correct answers, however no conclusive tests could be run on those results.
 
 

Results: The result closely approaches a statistically significant difference between the two treatments with respect to the dependent variable, mean task time for completing all the tasks.
 
 

The results for the mean number of mouseclicks for the two treatments is shown in the following table:
 
 

The following table shows the correctness of answers for the two treatments. Since this is a more subjective issue, and also depends on the person’s interpretation of the question, we decided that we did not have enough controls to conduct a test on it. However, the results are tabulated below. Although the majority of the answers were correct the results seem to indicate that the detail-overview pair has a slight edge in this respect.
 
 

The following table shows the subjective satisfaction results for the two treatments.
 
 

For most of the results, there is little to distinguish the between two treatments. However, according to the subjects’ responses, the zoom-only treatment offers more flexibility, but the converse is true for zooming and ease of operation. Both the treatments got low scores in flexibility, suggesting that we should give more importance to this issue in future.
 
 

The aim of the experiment was to determine how well the overview-detail pair treatment fared against the zoom-only treatment as applied to LifeLines.

Our experiment results confirmed our hypotheses to an extent as we found that the overview-detail treatment had nearly statistically significant better results in terms of time to complete all the tasks. The mean number of mouseclicks was also lower for the detail-overview treatment and all areas except Flexibility registered higher subjective satisfaction scores than the zoom-only treatment. However, in our hypotheses, we had predicted that the number of errors is going to be lower the zoom-only version. But our experiment results showed that it is actually the other way around. But as I mentioned before, it is a very subjective issue and should not be used as a yardstick in this case for judging overall performance.

The success of the detail-overview pair in this case can be attributed to the fact that although the zoom-only (or zoom-and-replace) view givers the users maximum screen space, it does not give them the chance to see the position of the detailed view relative to the global view. Also, every time the user has to switch to a new view he has to zoom out first by right-clicking, and if he has used too much zooming in the previous case, it only means he has to zoom out more to restore the record to the global view. Excessive repetitive action may be a cause for losing user-interest in this case. The detail-overview pair removes all these difficulties. The tight coupling between the two windows ensures that users have time to think about what spot they are going to choose, and then they have to click and drag only once over an area which is determined by the level of magnification they wish to achieve. Despite using up time to frame their strategy, users are still able to complete their tasks in a relatively low timespan. With the zoom-only (or zoom-and-replace) treatment, however, users have to rely more on his instinct than on strategy when they set about completing a task. Another potential problem with the zoom-only method is that the choice of zooming factor might be crucial. Although in the experiment mentioned above, the zooming factor was constant for the zoom-only treatment, in actual applications, it might very well depend on the nature of the task. This brings to the forefront the concept of an optimal zooming factor, which might be a tricky issue to agree upon. The detail-overview pair, in this regard, is more flexible as the zooming factor is dynamic and depends on the user himself, or rather the dimensions of the field-of-view-box that he is creating by clicking and dragging. The short-time-memory load is also higher in the zoom-only case, as users, upon perceiving that they have zoomed in a slightly different position than that they have wished, have to remember with a fair degree of accuracy the positioning of their event of interest in the global scheme of things, so that they can go back and try zooming in on that area. However, the zoom-only method is voted more flexible by the users which can be attributed to its more intuitive design. Also, it is to be conceded that the detail-overview pair works progressively better with larger screens and more resolution, and might be virtually impossible to work with a screen of the order of 15 inches diagonal size.

One of the issues that need to be looked upon in the future is the concept of "runaway zooming". This is equally valid for the single window of the zoom-only treatment as well as the "detail" window of the detail-overview pair (which, in fact, has all the properties of a zoom-only window in itself). Since the application is written in Java and is invoked from the web, the loading of the applet onto the local machine might take up considerable time depending on the network load and the processing power, and there is nothing to indicate when the loading is complete. In three instances, we had users complaining that while they had clicked away a good number of times the application has remained completely static, and then all of a sudden it started zooming away beyond the user’s control.

One of the interesting issues we observed during the course of this experiment is the users’ apparent lack of interest to use the detail screen in the detail-overview pair as an individual single window with zoom-only attributes. There can be three explanations for this behavior:

• The initial instruction/training was inadequate to impart this information to the user that the detail window can be used in that manner.
• The user was unsure about the results of using the detail window, and/or was not confident of exploring further possibilities.
• The user preferred to use the field-of-view-box for navigating within the system.

On the whole, the task graph follows a similar pattern in both cases. The mean time for the first task is the highest indicating that users took up time to come to terms with the system. But once they are past the first task, the pace picks up and this is especially true for the zoom-only treatment, where the learning curve appears to be steeper.
 
 

Although the experiment was conducted as planned, there were certain limitations which perhaps needs to be taken into consideration when conducting an experiment of a similar standing. The most noteworthy among the limitations is the sample size. In reality, it would be advisable to conduct the experiment with as many as forty subjects. The speed of the machine was another factor, which requires considerable attention. Although 200+ MHz Pentium machines were enough to run the experiment, the question is how much appreciable change would a 300 MHz or say, a 500 MHz machine would have on the experiment. For example, the problem with "runaway zooming" can be minimized to a great degree with a faster processor. Also there are still some modifications to be done to the system, especially in the zoom-only version where perhaps it would not be a bad idea to have a "reset" button which lets the user go back to the intial state of the system (might also be used to curb "runaway zooming").

The experiment indicates that for the given set of tasks, detail-overview pair elicits a better performance from users than single window with zoom-only treatment. I say "for the given set of tasks" because task complexity is something that is not accounted for in the experiment, and it would be interesting if somebody compares the same treatments in light of task complexity in future. For the moment, however the message seems to come across loudly that multi-level browsing technique has a brighter future when applied to a dynamic visualization tool like LifeLines.
 

List of References:

1. Shneiderman, B., Plaisant, C. and Carr, D. Image Browser Taxonomy and Guidelines for Users, IEEE SOFTWARE, March 1995

2. Shneiderman, B., Designing the User Interface: Strategies for Effective Human-Computer Interaction, 3^rd Edition, Addison-Wesley.

3. Lindwarm, D., Rose, A., Plaisant, C., and Norman, K., Viewing personal history records: a comparison of tabular format and graphical presentation using LifeLines, Behaviour & Information Technology, 1998, VOL. 17, NO. 5, 249-262

4. Li, J., Au, W. and Lau, F., Evaluation of Three Temporal Data Layout Strategies, URL: http://www.cs.umd.edu/users/jiali/shore

5.Plaisant, C., Mushlin, R., Snyder, A., Li, J., Heller, D. and Shneiderman, B., LifeLines: Using Visualization to Enhance Navigation and Analysis of Patient Records

6.Plaisant, C. and Shneiderman, B., An Information Architecture to Support Visualization of Personal Histories, University of Maryland CS-TR-3855, UMIACS-TR-9787. A short version of this report appeared as a poster summary in 1996 American Medical Information Association Annual Fall Symposium (Washington, D.C., Oct. 26-30, 1996), 884, AMIA, Bethesda, MD

7. Plaisant, C., Milash, B., Rose, A., Widoff, S., and Shneiderman, B., LifeLines: Visualizing personal histories. Proc. of CHI ‘96, ACM, New York, (1996), 221-227.

8. Milash, B., Plaisant, C., and Rose, A., Exploring LifeLines to visualize patient records, video in CHI’96 video program (Vancouver, B.C., Canada, April 13-18, 1996), ACM, New York
 
 

Figures

Figure 1: Sample Screen shots from the two treatments: Overview-Detail Pair (left) and Zoom-only version (right)

Figure 2: A sample of the tasks used in the experiment

Figure 3: On-line background survey form that the subjects were supposed to fill at the start of the experiment.

Figure 4: Sample screen shot while task completion is in progress (Overview-detail pair)

Figure 5: Screen shot of the subjective satisfaction questionnaire

Figure 6: Graphical representation of Mean Task Times

Figure 7a: A graphical representation of Mean Task Time per subject (Zoom-only)

Figure 7b: A graphical representation of Mean Task Time per subject (Overview-detail pair)

Figure 8: Graph showing the comparison by number of mouseclicks

Figure 9: Graph showing the percentage of mouseclicks on each window of the Overview-detail pair.

Figure 10: Graph showing the mean user time per task for the two treatments

Table 1: Task Time for completing all the tasks (in seconds)

Table 2: Number of mouseclicks for completing all the tasks

Table 3: Number of errors encountered while completing all the tasks

Table 4: Mean subjective satisfaction score (out of a maximum of 10)
 
 

NAME Krishna Ganti

SEX Male

AGE 18plus

EDUCATION Masters

MAJOR Computer Science

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET More than 15 hours

==============================================================================================================================

NAME Bryan Pizzillo

SEX Male

AGE 18plus

EDUCATION Undergraduate

MAJOR Computer Science

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET 10-15 hours

==============================================================================================================================

NAME priya nagarajan

SEX Female

AGE 25plus

EDUCATION Graduate

MAJOR biochemistry

USED A ZUI BEFORE? no

PREFERRED BROWSER netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET 5-10 hours

==============================================================================================================================

NAME Prashanth Acharya

SEX Male

AGE 25plus

EDUCATION Graduate

MAJOR Materials Engg

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE no

HOURS A WEEK ON THE INTERNET More than 15 hours

==============================================================================================================================

NAME Barbara Bour

SEX Female

AGE 25plus

EDUCATION PhD

MAJOR Molecular Biology

USED A ZUI BEFORE? yes

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET 0-5 hours

==============================================================================================================================

NAME Arul Joseph

SEX Male

AGE

EDUCATION PhD

MAJOR Chemistry

USED A ZUI BEFORE? yes

PREFERRED BROWSER netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET 0-5 hours

==============================================================================================================================

NAME Swaminathan Narayanaswamy

SEX Male

AGE 18plus

EDUCATION Masters

MAJOR Computer Engineering

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET More than 15 hours

==============================================================================================================================

NAME COMMENT

Ganti

Pizzillo There should have been an auto maximize/minimize button, or at least a "home" type button that would bring it back to the original view. Maybe a double click on a line would maximize the line, that way you do not have to deal with the scroll bar at the bottem (which is annoying).

nagarajan

Acharya Not sure if it was on purpose, but some of the questions

seemed to refer to stuff which was not in the data.

Bour

Joseph

Narayanaswamy It took me a while to figure out how to navigate. After that, it was a lot easier.
 
 

NAME M Chakravarti

SEX Female

AGE 25plus

EDUCATION Graduate

MAJOR Molecular genetics

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET 0-5 hours

==============================================================================================================================

NAME Manoj Sharma

SEX Male

AGE 18plus

EDUCATION Graduate

MAJOR Computer Science

USED A ZUI BEFORE? yes

PREFERRED BROWSER IE

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET More than 15 hours

==============================================================================================================================

NAME Yancy Davis

SEX Male

AGE 18plus

EDUCATION Undergraduate

MAJOR Computer Science

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET More than 15 hours

==============================================================================================================================

NAME Arunava Chakravarti

SEX Male

AGE 25plus

EDUCATION Graduate

MAJOR Engineering

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET 0-5 hours

==============================================================================================================================

NAME Venkatesh

SEX Male

AGE 18plus

EDUCATION Masters

MAJOR EE

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape Nav

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET More than 15 hours

==============================================================================================================================

NAME Vasudevan

SEX Male

AGE 18plus

EDUCATION Masters

MAJOR Computer Engg

USED A ZUI BEFORE? yes

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET 5-10 hours

==============================================================================================================================

NAME kumar Anupam

SEX Male

AGE 18plus

EDUCATION Undergraduate

MAJOR Computer Sciences

USED A ZUI BEFORE? no

PREFERRED BROWSER Netscape

FAMILIARITY WITH IE yes

HOURS A WEEK ON THE INTERNET 5-10 hours

===============================================================

NAME COMMENT

Chakravarti

Sharma Give labels to all the markings, so that it is visible without zooming. Some questions were wrongly stated. What do you mean by exploration being risky or safe?

Davis

Chakravarti

Balasubramanian Would be nice if there were markers to identify dates faster.

Vasudevan

Anupam Its seems really nice interface, except for the fonts, a pop up screen on the mouse being there would make it look a little less clustered on. It just seemed like too much information on one page.
 
 

Web Accessibility