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:

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.

My experiment compares the effectiveness of the two browsing techniques,
and tries to find if there is a statistically significant difference in
user performance for the two techniques.

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:

When time intervals were compared

When accuracy was compared

When user satisfaction was concerned.

By collecting speed and accuracy data as well as user satisfaction points,
the aim of this experiment was to compare the two browsing techniques and
pinpoint the advantages and disadvantages of the detail-overview pair.

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:

Choice of browsing technique. Treatments:

Zoom-only

Overview-detail pair

Dependant Variables:

Time

Number of Mouse-Clicks

Subjective satisfaction

Subject Selection: From earlier experiments conducted on LifeLines,
it was perceived that a controlled experiment of this stature usually requires
a huge sampling size. From that perspective, an ideal number of subjects
for this experiment should be forty. (However, we had to conduct this experiment
with a sample size of fourteen subjects). The subjects are broken down
into two groups of equal size for each treatment of the independent variable
(browser type). The subjects can be of any background, but should have
prior experience with computers. They should not be visually impaired and
should have no physical handicaps involving hand-eye co-ordination. One
important constraint is that the subjects should not have any prior exposure
to Lifelines. All the subjects are given a verbal description of LifeLines
and the method they would use, for not more than ten minutes. This is followed
by an on-line presentation of LifeLines.

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:

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.

An .lld (Lifelines data) file containing an imaginary medical record served
as the source of data. Perl was used to write the program, which kept track
of the subjects’ responses to the answers, as well as the time and accuracy
of each subject (which served as the CGI script for the server). All of
the tests were run on Windows machines (95 or NT), and used Internet Explorer
4.0 or higher.

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:

Training: A training session was provided to each subject prior
to the experiment which varied from five to ten minutes according to the
confidence level of the subject. The training included pulling up the main
demo version(s) of the two treatments and a brief demonstration of the
capabilities and usage of each version. Any ambiguity or question arising
in the subject’s mind was also answered during this period.

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.

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)

Overview-detail Pair

Zoom-only

Overall Reaction

5.86

5.7

Flexibility

5

5.9

Layout

7

6.3

Navigation

6.7

5.3

Zooming

7.1

6.3

Ease of Operation

7.7

7.1

Feedback

6.1

5.9

Initial Instruction

7.6

7.6

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:

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.

A graph depicting the percentage of mouseclicks recorded on the detail
versus overview window is shown below:

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.

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

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.

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.