A scholarly paper by:
Partha Ghosh, 2nd year MSSE student, University of Maryland
Advisor : Dr. Ben Shneiderman, Director, Human Computer Interaction Laboratory, University of Maryland, College Park
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.
Fig1: Sample Screen shots from the two treatments: Overview-Detail Pair (left) and Zoom-only version (right)
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:
THE EXPERIMENT
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:
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:
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.
Fig2: A sample of the tasks used in the experiment
METHOD
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:
PROCEDURE
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:
Fig 3: On-line background survey form that the subjects were required to fill at the start of the experiment
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.
Fig 4: Sample screen-shot while task completion is in progress (Overview-detail pair)
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.
Fig 5: Screen shot of the subjective satisfaction questionnaire
RESULTS
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.
Table1: Task Time for completing all the tasks (in seconds)
Overview-detail pair | Zoom-only treatment | |
Mean | 41.44 | 53.10 |
Standard Deviation | 13.76 | 15.15 |
Median | 46.14 | 50.20 |
P(t<T) | 0.052 | |
tstat | 2.42 |
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.
Fig 6: Graphical Representation of Mean Task Times
The graphs show the mean task times according to the two treatments.
Fig 7a: A graphical representation of Mean Task Time per
subject (Zoom-only)
Fig 7b: A graphical representation of Mean Task Time per subject (Overview-Detail pair)
The results for the mean number of mouseclicks for the two treatments
is shown in the following table:
Table 2: Number of mouseclicks for completing all the tasks
Overview-detail Pair | Zoom-only treatment | |
Mean | 73 | 150.71 |
Standard Deviation | 32 | 126 |
Median | 58 | 90 |
Fig 8: Graph showing the comparison by number of mouseclicks
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.
Table3: Number of errors encountered while completing all the tasks
Overview-detail Pair | Zoom-only | |
Mean | 2.43 | 4 |
Standard Deviation | 1.28 | 1.41 |
Median | 2 | 4 |
The following table shows the subjective satisfaction results for the
two treatments.
Table 4: Mean subjective satisfaction score (out of a maximum of 10)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
DISCUSSION
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:
Fig 9: Graph showing the percentage of mouseclicks on
each window of the overview-detail pair
The last item in our discussion is the comparison of complexity of tasks
with respect to the treatments. The graph below depicts the scenario:
Fig 10: Graph showing the mean user time per task for the two treatments
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.
CONCLUSIONS
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, 3rd 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
APPENDIX
Lists of Figures and tables
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)
Zoom-only Treatment : User Profiles and comments
===============================================================
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.
Detail-overview (Single Coordinated) pair: User Profiles and Comments
===============================================================
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.