Zoom-Only Vs Overview-Detail pair: A Study in Browsing Techniques as Applied to Patient Histories

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:

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:

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: Dependant Variables: 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:

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.
 
 

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)

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:

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.
 

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

  Tables

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.