Paper Discussion Notes and Author Replies

cs5984: Information Visualization

VISAGE

Dear Dr. Steven Roth, Dr.Peter Lucas & Dr.Carolyn Dunmire,

My name is Priya Shivakumar and I am a Computer Science graduate student at Virginia Tech. As part of the Information Visualization class taught by Dr. Chris North had a presentation and discussion on your paper "VISAGE: A User Interface Environment for Exploring Information". We also went through the Visage sample on the web page (http://www.cs.cmu.edu/~sage/sample.html).

Here are a few thoughts that the students in the class had on the paper.

The general consensus was that the tool was very good as it combines the different visualization techniques and gives the user different views of the data. The fact that any number of visualizations can be integrated using scripts and customized for particular users is also very useful. The students in the class found the built in presentation feature very handy.

One particularly important discussion point was that the tool looked data dependent. For example, in cases where the data does not contain any locations it would be redundant and also a waste of display space to have the map visualization tool as part of visage. Could you offer us some suggestions on
this issue? Another point that came up in class was that the tool does not give a
global view of the data.

The students also felt that the learning curve was high and hence would be difficult to use by users with no prior knowledge. However relative to the amount of functionality the tool provides, we felt it is a justifiable trade off.

Sincerely,

Priya Shivakumar

Dear Dr. Bederson and Dr. Hollan

I am a graduate student in the computer science department at Virginia Tech.. Currently I am taking a course on Information Visualization which is taught by Dr. Chris North (http://vtopus.cs.vt.edu/~north/infoviz/).As a part of Dr. North's class we recently enjoyed discussing about 'Pad++' which is discussed in your paper 'Pad++: A Zooming Graphical Interface for Exploring Alternate Interface Physics '. A presentation was made by one of our classmates and we discussed it critically, analyzing the good features and the possibility of adding new features that might give it a more robust stand.

I take this opportunity to bring to your notice the points that were brought up in the class.

The general consensus favored it as

1) it allowed to zoom the object by just moving the mouse and bring it back to the original size/position by moving it the other way. Thus it is user friendly.

2) it has high frame rate interactions, even if the data space becomes large and complicated.

3) The students also found interesting that the zooming rate is pretty constant even as frame rate changes.

4) Students liked the idea of making links between different objects thus helping in developing the relationship.

5) Different windows can be set up thus showing the path by which the last picture came into existence.

The main point of disconsent was that

1) As we navigate and go deeper and deeper and change positions, it was found that if we try to come back, we land up in a different place and not the one from which we started and this might make a user lost in the data.(this is like going to streets of New York and getting lost)

2)also if we do not know anything about the location of data, then every time we have to zoom in and if data is not found then we got to zoom back and pick up a new object for zooming. This can really make matters worse if the data is very large and finding an object can be really hard.

3) Also when we zoom in, the overview is completely lost and again it gives a feeling that one is getting lost in whole realm of data.

We came up with a few suggestions

1) there should be a 'back' button as in the case of 'windows explorer' so that one can reach the position from which he started.

2) There should be a way to give an overview (possibly like a fish eye) so that the user can know where he is with respect to the starting point.

To sum up, the students really liked the way this 2D interface zooms the objects. It is a unique way of zooming. The students were really curious about the changes that can be made to it to overcome the problems and make it more users friendly.

Though we do not have solutions regarding the problems we have discussed but we would love to have the description of solutions to the problems if any. We appreciate your work. We would like to know if we have overlooked any feature that is worth seeing and also any research that is ongoing on the subject.

Looking forward to hear from you.

Thanks

Regards

Satyajit Singh

Satyajit,

I will add to Jim's comments that another general approach is to support
more application-specific navigation. Rather than having generic manual
zooming where the user does not know where to go, and can get very lost - a
specific application for specific data can lead the user to pockets of
information, and can make it easy to go to specific places while making it
difficult or impossible to go to irrelevant places (i.e., where there is no
information). Most of the new applications we are building are of this
nature, and we leave manual zooming only to advanced users as an option -
but even I find manual zooming to be less and less useful.

- Ben

+--------------------------------------------------------------------+
| Prof. Ben Bederson Director, Human-Computer Interaction Lab |
| bederson@cs.umd.edu Computer Science Department |
| www.cs.umd.edu/~bederson 3171 A.V. Williams Building |
| (301) 405-2764 University of Maryland |
| (301) 405-6707 (FAX) College Park, MD 20742 |
+--------------------------------------------------------------------+

> -----Original Message-----
> From: hollan@cogsci.ucsd.edu [hollan@cogsci.ucsd.edu]
> Sent: Wednesday, March 07, 2001 12:42 PM
> To: sasingh1@vt.edu
> Cc: bederson@cs.umd.edu
> Subject: Re: paper on Pad++
>
>
>
> Satyajit,
>
>
> Navigation in multiscale spaces is interesting. We have
> experimented with a
> variety of options including many of those you suggest such
> as maintaining an
> overview of the whole space with an indication of where you
> are currently
> located. Also we have explored a bookmark facility for
> remembering specific
> window and when you bookmark a location it creates a view onto that
> location. You can then click on one of these views to drive
> the interface back
> to that specific location. We also used a similar bookmark
> facility in our
> Pad Prints application that maintains a history of web pages
> you have visited.
>
> Ben and Geroge Furnas have a nice paper on space-scale
> diagrams that you might
> find interesting.
>
> Jim

## WORLDS WITHIN WORLDS

Dear Drs. Beshers and Feiner,

My name is Ajay Jampani and I am a graduate student in the Virginia Tech. Computer Science department. As part of Dr.Chris North’s Information Visualization class (http://vtopus.cs.vt.edu/~north/infoviz/), we recently enjoyed discussing the ‘Worlds within worlds’ technique mentioned in your paper “Auto Visual: Rule-based design of interactive multivariate visualizations" in class. Dr. North made a presentation and we had a discussion on the technique. We compared it with other visualization tools and evaluated it's relative strengths and weaknesses in representing data.

I take this opportunity to bring to your notice the points that were brought
up in class:

The points we liked:

(1) Many students liked the way Worlds within worlds represented complex interactive 3D visualizations. They all agreed that it proves to be an effective technique for visualizing multivariate functions and it did not demand much complex math background on part of the user.

(2) We liked the idea of holding a set of variables constant while concentrating on another. Reducing high dimensionality visualizations into those of much lesser order helped find hidden trends effectively.

(3) Most students liked the axes being perpendicular unlike Parallel Coordinates and the concept of nested axes; the dynamics involving surface plots and line graphs were simple and good.

The points that we did not like:

(1) Due to the amount of interaction involved in the manipulation of data (comparisons, looking around to see trends), even an experienced user needs time to get what he wants: that is, most of the times, interaction proves to be a hindrance more than an exploration tool. Is there a way to limit/reduce the degree of interaction?

(2) The idea of ‘slicing off a part of the world’ to reduce the dimensions is not so beneficial as we lose focus and have to keep zooming in and out: This did not appeal to many students.

(3) Getting the overview (for identifying the trends) and detail (for local comparison) at the same time would be a bit difficult when data is dense, because of the presence of a sufficiently large number of worlds.

(4) It suits well for functions but fails when representing data points.

We came up with a few suggestions:

(1) Some students felt this approach is a bit complex and time consuming as it approximates to a two-stage process when one needs to get the values of all the variables associated with a point in the planes. A solution proposed by a student is to group the type of data in each world, so that
comparison between related fields becomes easy and involves less mechanics.

(2) To avoid cluttering in case of dense data, colors can be used to distinguish different data sets; this may encourage exploration further.

On the whole, most of the students were thrilled with the idea of visualizing and thinking in terms of ‘outer’ and ‘inner’ worlds; we agreed this is a unique tool that uses variables and functions to represent high-D data effectively. We are curious how this approach works out when representing
2-D data.

Though we don’t have solutions as such to the problems we mentioned, we feel that there is much scope for improvement. We definitely appreciate your opinion on this. We would also like to know if there are any points that we overlooked and if there is any ongoing research on this technique.

Looking forward to hearing from you with possible improvements,

Sincerely,
Ajay Jampani

## PERSPECTIVE WALL

Dear Drs. Mackinlay, Robertson, Card

We are Gowri Shankar Santhanam and Aejaaz Kamal, pursuing our graduate studies in Computer Science at Virginia Tech, Blacksburg, VA. We have taken up a graduate course titled INFORMATION VISUALIZATION, http://vtopus.cs.vt.edu/~north/infoviz/ this semester. We have discussed the paper PERSPECTIVE WALL: DETAIL AND CONTEXT SMOOTHLY INTEGRATED. http://vtopus.cs.vt.edu/~north/infoviz/perspectivewall.pdf and gone through
the web site: http://www.parc.xerox.com/istl/projects/uir/ in the class. In another class we also discussed the paper DOCUMENT LENS and we came up with
the following views/questions on the two papers:

PERSPECTIVE WALL:

There was a general feeling in the class that the idea of smooth transition from focus to context, was really 'appealing' to the user. Everyone seemed to like the way the 2 dimensional computer screens is exploited to give the user a 3-D perspective. The facility to adjust the ratio of detail to context was really handy to the users.

There was a general apprehension in the class regarding data representation using Perspective Wall. Students were apprehensive over the limit on the apparent "depth" of the context wall, when dealing with very large data. Is there any particular limit on the amount of data that could be displayed using perspective wall?

DOCUMENT LENS:

The class was discussing documents of which sizes can be visualized using the Document Lens. The class felt that the document lens would be a very effective tool to visualize documents somewhere in the range of 30 to 50 pages.

While discussing about the effectiveness of various features of the tool the class felt that the document lens would be excellent tool when one is searching for a specific pattern as the idea of highlighting the query results with red will be very effective to know where are the regions of your interest in the entire whole document.

There was a feeling that this is an excellent tool to view documents which the user did not know much about (compared to an indexed document say for example an FAQ list) in which the user knew pretty much precisely what he was searching for.

The class felt that the tool would scale better compared to the 1-D Perspective Wall since the tool allowed visualizations in 2-Dimensions. It would be possible to view more number of pages using the 2-D Document Lens.

However, the class felt that the tool gave a fairly distorted view of the document. Especially it was felt that the lines "across the edges" of the frustum (in the context area), would be difficult to read. Also images if viewed by this tool would give a fairly distorted view.

Although I guess the size of the reading window was adjustable, the class felt that the reading area looked pretty small. But I guess this is a standard problem in Information Visualization (tradeoff between context and overview).

Another thing the class thought about for both the tools was comparisons of non adjacent pages in the documents. Both the Perspective Wall and the Document Lens were found to be lacking in this aspect.

There was a question raised in the class whether it was possible to view say 50 documents of 2 pages (that is 100 pages from disparate sources) with the Document Lens.

We would really appreciate it if you could give us your views/answers. We
would be eagerly waiting for your views.

Sincerely,

Aejaaz Kamal, Gowri Shankar Santhanam

SEE SOFT

Dear Drs. Steve Eick and Graham Wills,

I am a Computer Science graduate student at Virginia Tech. As a part of the Information Visualization class (http://vtopus.cs.vt.edu/~north/infoviz/ ) taught by Dr. Chris North, we had a discussion on the paper written by you "Seesoft - A tool for visualizing Line Oriented software statistics". I am writing to convey the suggestions, comments and queries of the class on the tool Seesoft.

We felt that this tool is really good in terms of the speed of accessing a particular part of the code as opposed to the traditional methods of browsing through the explorers and clicking on files. It is also very good for understanding statistics about the code. Many of us wanted to use it as a programming environment.

Some suggestions to improve on the tool –

1) We liked the "overview + detail" approach of the tool. We feel that the fisheye approach could be an alternative method to navigate through the details. However, we were wondering if there was a method by which the scale could be increased to include more lines of code.

2) Also, we thought it would be great if one could use this tool at runtime and actually debug the code by walking through the execution points. It would be great if we could have this as a add-on to Visual Studio enabling runtime modification of code and compiling.

3) We felt a need to be able to see the dependency of one part of the code onto another. For example, in case of functions, it would be nice if you could have some arrows in the background that point to all the other parts of the code where this function is called. But since this may get very messy with a large number of function calls, we thought we could have some small icon beside the function calls.

4) Since the tool is tracking all the history and changes, it would be nice if we could use it as version control like the VSS where we can get back to a previous version of the code. It was suggested that a stack of lines could be used to represent each row like a pack of cards, instead of a single line. The topmost line would represent the most recent version of that line and the lines behind it would represent the previous versions. One should be able to go back to the earlier versions and see them.

Some queries regarding the tool –

1) We couldn't figure out one thing in one of the pictures that we saw of the tool. IN the indented mode, we were under the impression that each line of the code would be shown on a black background. But in one case we saw it red lines on a green background with the filename highlighted in green too. We were wondering if that part of the code corresponded to the red color or the green color.

2) We would also like to know if this tool is being actually used and if yes, where and if no, then when and how is it being intended to be used?

3) We were wondering if the tool was being used in applications involving DNA visualizations.

We would appreciate it if you could send us feedback on our suggestions and queries. We would be looking forward for your reply.

Thank you very much for your time.

Regards,

Prasuna

# LIFE LINES

Dear Drs. Plaisant, Rose and Shneiderman,

My name is Margaret Ellis and I am a Virginia Tech student in Dr. Chris North's Information Visualization class (http://vtopus.cs.vt.edu/~north/infoviz/). We recently enjoyed discussing
your paper "LifeLines: Visualizing Personal Histories" as well as the LifeLines demo

One of the major topics of our discussion was the use of space. Some people were determined that more information could be displayed. Others thought that the space actually part of the information. For example, it may be important to see when a person was not having medical problems. What options are you considering for this?

Everyone agreed that LifeLines gives a good overview of information. We noticed that it does not have multiple foci for comparison. The class determined that it scaled up better than perspective wall.

Considering the limitations mentioned in the paper, we critiqued the demo. The control panel is a particularly useful feature because it allows individual users to pick the colors which mean something to them. We noticed that to view the mouse over information the user must first interact with the scroll bar of the display window. Students were happy to see there was a text search but couldn't find a means to undo the search and were frustrated that it was case sensitive. We are unsure about how the lines or icons are grouped and what determines the loss of a label.

One bias we noticed is that it visually emphasizes conditions that occur over long periods of time. For example, fatigue seems more important than knee surgery. One issue we considered was that in the demo the icons for discrete events just look like very short lines. In the paper the icons
were diamonds, we are curious about the reasoning behind this modification. We are also wondering about linking events and aspects that are not related by time, such as treatment for a preexisting condition.

Interestingly, only some members of our class felt strongly that they would prefer seeing a doctor who used this tool. We acknowledged that there are certainly privacy issues. There was more than one mention of using this tool to relate multiple records. One suggestion was for statistical analysis. Another suggestion was to not only compare school, psychological and juvenile justice records for an individual but to study general behavioral patterns.

Sincerely,

Margaret ElliS

## STAR COORDINATES

Dear Mr. Kandogan,

I am a graduate student in Computer Science Department at Virginia Tech. I am taking the course Information Visualization (http://www.cs.vt.edu/~north/infoviz/) taught by Dr. Chris North. We
discussed your paper "Star Coordinates: A Multi-dimensional Visualization Technique with uniform Treatment of Dimensions" in class recently.

At beginning of the discussion, a presentation about this paper is made by a student. He introduced the basic idea of star coordinate and demonstrated how to use the system by showing an example about cars. He made a conclusion that this approach provides users with an initial interpretation of data and is particularly useful for identifying clustering of data based on user
defined queries. He also pointed out some drawbacks of the system. One is that detail description of data sometimes obscured by data points. The other is that it will take some time to learn the operation.

The following is the discussion among the class. Students talked a lot about its advantages. It's good for interaction by scaling and rotation. Relationships between any numbers of variables can be found easily. Marked data points are painted in different color making them easier to follow.
Students also talked about its disadvantages. Users need to get familiar with the system before they can do transformation and selection operations for a query. It might be not good in printed form. The data points are so close together as the number of data points and the number of dimensions increase. It's not easy to locate a specific data point. A student suggested negative axis should be added for each dimension. Some disagreed with it because more axis give more confusion.

Finally, we compared star coordinate with parallel coordinate. Much more students voted for star coordinate. The main reasons of voting for star coordinate are that relationships are easily found and it is better for large data set. The main reasons of voting for parallel coordinate are that data are not compacted and more attributes can be conveyed. we decided the star coordinates seems to scale up for one thousand (???) of data items better than the other approaches we looked at.

Class discussion also revealed that we thought it would take a lot of time for the user to discover relationships in the data because of amount of interaction required. Do you have any plans to improve it?

This paper brought fresh perspective to our study in multi-dimensional visualization. We are grateful to your research discovery. It inspired our thinking and discussion. We are looking forward to your reply.

Thank you!

Sincerely Yours,

Fanye Cui

## SUNBURST

I am a student in a graduate level information visualization class at Virginia Tech that is taught by Dr. Chris North. We reviewed the papers on Sunburst and the comparison of Sunburst to Treemaps.

We were very impressed with the Sunburst tool and thought it was the best visualization tool we saw for visualizing hierarchies. We thought it was better than Treemaps, especially because Sunburst avoids the slice-and-dice problem that Treemaps has and it also better visualizes the structure of the hierarchy. Sunburst also scales up well with large amounts of data since it can be compact, much better than the node-link-approaches like hyperbolic trees. One other aspect we appreciated was the use of animation because it helps keep the user oriented as to where in the hierarchy they are.

Of the three general techniques, our class preferred the detail outside method. We came to this conclusion because this method was more space efficient than the angular method and more intuitive than detail inside. The angular method did receive some praise because it allowed for multiple foci.

We also reviewed the comparison paper of Sunburst vs. Treemaps. Since there are different types of hierarchies and it is unknown whether these results apply to all of them, we suggest make users perform only one type of task, but over many hierarchies, and with more samples.

One other issue was with the presentation of the data. It was not easy to figure out the conclusions from looking at the content of the tables. Since this was an experiment evaluating visualization designs, we suggested presenting the results in a more visual manner. In a show of hands, the class also preferred Sunburst over Treemaps, which was consistent with your results.

We would also like to know if there has been any new work done on Sunburst and where it's development stands. We would also like to know if there is a downloadable demo to play with.

We enjoyed looking at Sunburst and thought it was very innovative. Thank you

Marty Einstein

Hi Marty,
Thanks for the interesting feedback. I think that you're being kind saying SB is better than TM. :^) I think that each has some advantages and both should be useful in a number of situations. I'd have to agree with some of your comments about the empir study paper.
We just had oodles of data in that study and it was hard to tease it all out and come up with clear conclusions. Those kind of experiments are really tough to run too.

I found it interesting that you all preferred the detail outside method of those 3. I do think that animation/zooming techniques like those can make these kinds of visualizations even more effective.

As for demo able versions, I'm afraid that I don't have too much that would work. What kind of machines do you use? I do have a version that's pretty solid (basic SB) for Solaris on Sun workstations. I could probably bundle that up to give to you. I also have an alternate java version that a student wrote for me. It's OK, a little buggy and doesn't quite work the way I like, but it's not too bad. The animated/zooming version runs on Windows and has lots of hitches and problems so I don't really have anything solid there to give out.

Have you tried the new sequoia view tree map system from the folks in the Netherlands? Very nice.

--John

## FISH EYE VS. OVER VIEW + DETAIL

Dear Drs. Hornbæk and FrØkjær,

My name is Shumei and I am a graduate student of Information Visualization instructed by Dr. Chris North at the Virginia Tech Computer Science department. (http://vtopus.cs.vt.edu/~north/infoviz/). Approaching the end of the semester, we have already been through the studies and discussion of quite some InfoViz new techniques and concepts, we studied your paper “Reading of Electronic Documents: The Usability of Linear, Fisheye, and Overview + Detail Interfaces” as the finalizing part our course, and we came up with some ideas and also questions regarding the debate and experiment described in your paper. I have this opportunity to bring to your notice the points that were brought up in class:

Among which the Fisheye is the focus students showed interests in:

1) In technical paper format, the first and last part of the paper may be of more importance, but its not always the case, while we all preferred the way of computing the importance of a paragraph semantically.

2) As Fisheye interface intends to shorten the time of navigation, by helping and letting the user choosing the less important part to be skipped over, but in the initial orientation takes longer time than the other interfaces, like what we prefer above, if the important words of those less important paragraph are left outstanding with viewable size, users can get some idea of the content at glance in stead of having to expanded it.

3) What if we combine the Overview+Detail and Fisheye together especially for question-answering task, would that increase the efficiency by adding the advantages of two? That is, the left side provides access to content and right side facilitates fast navigating through.

4) As graph tells the content more intuitive and better than text, we feel that leaving the graphs out larger when diminishing the text by 75% is very efficient.

Some question about the experiment design:

5) The Fisheye interface takes less time in essay task does make sense to us, but in the question answering task, depending on how difficult the questions, suppose it was deep (as in the previous task, subjects were asked some literally obvious questions, I assume here should be some tough ones) user may need a good understanding the document’s structure and needs to find and go back to the content where faster scrolling is not of much importance to pace this process. Based on the higher grading of O+D and nature of each method, we feel that O+D could excel in this case.

6) As the choice of subjects, although they are averagely in computer science for 6.5 years, they may not have evenly experience with those three interfaces, especially relatively new one, and besides they are all currently in the same working environment. With O+D and linear interface, people may already have quite some experience and some personal strategy of using it , while with Fisheye, which inferior much in grading index , people may get to know how to use it pretty soon, but not strategically.

7) Saying that Overview is distracting or leading users to unnecessary exploration is not fair because user can ignore it if he didn’t want it, and using Fisheye doesn’t reduce the time needed for exploration unless all the question happens to falls into the couple of paragraphs, which were expanded already.

In general, we all like the idea of Fisheye more than the experiment grading. Hope to get your response regarding our ideas and confusions.

Sincerely,
Shumei

## HYPERBOLIC TREES

Dear Dr.John Lamping and Dr. Ramana Rao,

My name is Maulik Shukla and I am a graduate student in computer science department, Virginia tech. As part of Dr. Chris north’s information visualization class (http://vtopus.cs.vt.edu/~north/infoviz/), we recently enjoyed discussing your paper “the hyperbolic browser: a focus + context technique for visualizing large hierarchies” as well as the hyperbolic tree demo

(http://www.inxight.com/products_sp/ht_sdk/ht_sdk_demos.html).

I take this opportunity to bring to your notice the points that were brought up in the class.

The points class liked:

1.Hyperbolic geometry provides an elegant solution to the problem of visualizing large tree structure.

2.Continuously graded fish eye view mapping from the hyperbolic plane provides good focus + context view.

3.Easy to navigate through the hierarchy.

4.“Stretch map / shrink map” and “change map orientation” tools help in making the display more clear and also in making effective utilization of the display space.

5.“+ / -“ Signs provided on the nodes help to know whether that node contains more information or not. It also allows eliminating the portion of the tree, which we are not interested in.

6.Coloring of nodes really helps to distinguish nodes from different families.

The points class did not like:

1.It can display only 3-4 levels of the hierarchy at a given time and never gives the overview of the entire tree structure at any time.

2.The large number of links on near the periphery helps to understand the structure of the tree. But at the same time it does not convey any useful information about the nodes.

3.Slight transition of the parent node causes great change in the orientation of its children nodes near the periphery.

4.When a node has very large number of children, the display shows only “fan of links”, without giving any useful information about the structure of the tree or the attributes of the individual nodes.

Suggestion:

Overall the concept of hyperbolic tree is very effective to visualize “simple tree structures”. Can we use the same concept to visualize “Intertwined / complex tree structures” (cross functional hierarchies, in which a node may have more than one parent)??

Please let us know if you are working in this direction. Also inform us if we missed any important point during our discussion or about the recent development in the hyperbolic tree concept.

Thanking you,

Maulik Shukla

Maulik,

>My name is Manlike Shukla and I am a graduate student in Computer Science
>Department, Virginia Tech. As part of Dr. Chris North's Information
>Visualization Class (http://vtopus.cs.vt.edu/~north/infoviz/), we recently
>enjoyed discussing your paper "The Hyperbolic Browser: A Focus + Context
>Technique for Visualizing Large Hierarchies" as well as the Hyperbolic Tree
>Demo (http://www.inxight.com/products_sp/ht_sdk/ht_sdk_demos.html).

>The points class did not like:
>
>1.It can display only 3-4 levels of the hierarchy at a given time and never
>gives the overview of the entire tree structure at any time.

This would require a very different approach, I think. Suppose that the
tree has a branching factor of 5, and you want to see 5 levels of the
hierarchy. The top 5 levels of the hierarchy have (5^5 - 1)/4 = 781 nodes.
It will be very difficult to make a visualization that shows all those
nodes at once. So you would have to have some sort of selective
visualization of the parts of the hierarchy of interest, rather than the
uniform kind of visualization that the hyperbolic tree provides.

We had experimented with a "binocular view", where two nodes are in focus,
one at each "eye" of a binocular shaped field of view. It looked cool,
but we never came up with an intuitive way for the user to control it.

>2.The large number of links on near the periphery helps to understand the
>structure of the tree. But at the same time it does not convey any useful

Guilty as charged. One idea that we had considered was putting some sort
of indication, like color or brightness, in the few pixels just outside
circle to give a sense, for example, of how much mass of tree lies below
visible resolution in that direction.

>3.Slight transition of the parent node in the causes great change in the
>orientation of its children nodes near the periphery.

This might be helped by some different kind of mapping.

>4.When a node has very large number of children, the display shows only “fan
>of links”, without giving any useful information about the structure of the
>tree or the attributes of the individual nodes.

The hyperbolic tree really shows off the hierarchy structure. When there
isn't much structure to the hierarchy, i.e., when it is bushy, when one node
has lots of children, you have more of a list than a tree, in a sense.
Maybe you could transition to some sort of list view for those cases.

>Suggestion:
>
>Overall the concept of hyperbolic tree is very effective to visualize
“Simple
>Tree Structures”. Can we use the same concept to visualize “Intertwined /
>Complex Tree Structures” (cross functional hierarchies, in which a node may
>have more than one parents)??

This is something we have often wished we could do. What makes it hard is
that, while the hyperbolic plane has a very different metric structure from
the Euclidean plane, it has the same topological structure. Much of the
complexity of cross functional hierarchies stems from their complex
topological structure, for which hyperbolic geometry doesn't seem to
provide a lot of help.

Inxight has implement some support for DAGs, where you show a complete copy
of a node and all its descendants below each of its parents, exploiting the
large amount of room given by the metric structure of the hyperbolic plane.
Alternatively, you show a complete copy of the descendants below only one
of its parents, but the user can make any of the ones be the one that is
expanded, and the system shows which other nodes are unexpanded versions.
I don't know if this has been used very much.

Personally, I find hierarchies to be a very limiting way of organizing
data. But I have learned the hard way that when you go beyond hierarchies,
things can easily get terribly complicated. This hasn't discouraged me
from trying to get beyond hierarchies, but it has made me expect to have to
work very hard and very carefully every time I try to do it.

>Please let us know if you are working in this direction. Also inform us if
we
>missed any important point during our discussion or about the recent
>development in the hyperbolic tree concept.

I think two of the most important features of the hyperbolic tree are
1. It is instantly understandable ... no training required.
2. It looks cool.
I didn't appreciate either of these initially, but I think that they are
major reasons for the interest people have shown in it.

I assume that you know about the three dimensional hyperbolic viewers.
There are also some papers out of Microsoft Research and PARC showing that
the hyperbolic tree doesn't speed up user performance in search tasks. (It
is much more suited to showing information about a hierarchy you are
somewhat familiar with than to blind navigation.) I am sure that Inxight
is working on more improvements.

Personally, I joined a start up, Purple Yogi, www.purpleyogi.com, about a
year ago. While I think I am a researcher at heart, I'm finding this to be
a very good "sabbatical" to recharge my intuitions. I've been working on
our automatic ontology creation, automatically organizing unstructured data
into a hierarchy. And we do get substantial leverage from breaking the
hierarchy rules in limited ways.

John

Maulik,

For the most part, you seem to have understood everything quite well. You
have identified both pluses and minuses to Hyperbolic Tree that are
accurate. We have been quite successful at getting a number of software
OEMs to include the technology in their software applications. And more
recently, more and more companies have been using it on their web sites and
in their internal applications.

I would say the biggest design limit for HT is the wide fan-out problem that
you have detected. We can make this work a bit better than it does
currently, but I think in the end this problem cannot really be resolved
on-widget, so to speak. Nor should it necessarily be solved. The goal
isn't to have only one mother of all widgets for the entire user interface.
It would be better to link multiple conventional views and wide widgets.
For example, one could show another pane with a list of children for the
focus node, so you can quickly read through them.

Commercially the issue of showing 3-4 levels hasn't really been a big
problem, because it is so much better than anything else out there right
now. Also because you can jump 3 or 4 levels with a quick click and jump
back, you can really get a sense of the top 7-10 levels pretty quickly. You
can definitely tell quite well whether the say 7**7 node top segment of the
tree is well-organized, what all range of stuff it covers, whether it might
be worth your time, etc. in say 10 seconds or less.

The changing orientation at the periphery is inherent to using hyperbolic
geometry. It was a design decision to "tame" hyperbolic geometry to
preserve any spatial orientation at all. In particular, we decided that in
radial layout to ensure that when a node was at center, the vector between
it and the root would be have same direction as between the node and the
root when the root was at center. After that constraint there is pretty
much no more freedom in the geometry on what to do with all the other nodes.

Inherently Hyperbolic Tree is Tree visualization. We have had luck in
using it in cases where various kinds of graphs are really best navigated or
viewed as a tree with cross-links e.g. Yahoo. We have some improvements
coming down the pike in this area.

Thanks for you thoughts. Meanwhile some other comments on trying out our
products:

1) Hyperbolic Tree has been renamed Star Tree. I'll leave it as an exercise
for your class to figure out why :-)

2) You can download a free viewer that has many example Star Trees bundled
in. Go to startree.inxight.com. Tell all your classmates and friends that
you think will find this interesting.

3) I think you might be playing with Table Lens as well. Be sure to check
out all the examples at TableLens.com.

4) If you and all of your classmates and Chris would like free copies of
Eureka, the windows desktop application based on Table Lens, we can provide
them to you through our Eureka Seed Program. Just provide me a table of
<First Name, Last Name, Email Address> for each person, and we'll enter them
into the ESP program (Our web app generates an email invitation, people

Thanks,

Ramana

## ENVISION

Dear Drs.Lucy Nowell, Robert France, Deborah Hix, Lenwood Heath and Edward Fox:

My name is Ravikiran Vatrapu and I am a Computer Science graduate student at Virginia Tech.I am doing a course in Information Visualization, being taught by Dr.Chris North (http//vtopus.cs.vt.edu/~north/infoviz). In the study of visualization techniques for document collections, we recently discussed "Envision". We were impressed by the distinctive 'matrix of icons' approach to visualizing the search results.

The discussion brought forward some interesting observations, critiques and ideas.

1. The matrix of icons visualization technique is very helpful to view a range of document characteristics and properties. What appealed to us most was the fact that apart from the standard visualization of the relevance rank and the estimated relevance of each document, the ability to view and also customize the various characteristics like document type, experimental version, publication years etc in a easy way.

2. The division of the screen into three interactive windows seems to represent the similar stages in the mental model of the user during the task. Giving the user direct control over the layout semantics in the Graphic View is a feature that will allow the users to make changes based on their task requirements. Redundant cues emphasize the characteristic of the document(s). The ability to mark the interested documents as useful with the option to use them, as basis for feedback search, to print or to save is very useful. The cluster icon was not all that easy to understand at first but once we knew about the labeling there was no difficulty.

3. We liked the configurations that enabled to view the entire search results without scrolling. User customized metaphors are certainly desired. Consistent labeling does away with any possible confusion.

4. There seems to be a lot of space that is not utilized when there are few results or when the search results overlap. Can the scaling on the axes be changed so that more and more documents are displayed? Like shrinking the years that have fewer documents and using that space to show more documents from the cluster icon?

5. How far will envision be scalable with the implementation of the zoom feature?

6. We are interested in knowing about the presentation of multi-sets mentioned in the

Apper.

Looking forward to hear from you on the above thoughts and know of any further developments to "Envision".

Sincerely,

Ravikiran Vatrapu.

From: Robert France [france@vt.edu]
Sent: Thursday, April 19, 2001 10:40 AM
To: rvatrapu@vt.edu
Cc: fox@cs.vt.edu; heath@cs.vt.edu; hix@cs.vt.edu; nowell@vt.edu; Chris
North
Subject: Re: Discussion Notes on Envision

unusually refreshing -- to see the results of discussions like that.
Current work on Envision has focused on pragmatic issues -- translating
it into Java, speeding up the rendering of the graphic window, and
better integrating it into the MARIAN system -- but once we have a
stable Java version we do intend to pursue the zoom issue that you
mentioned. We would also like to address the sparse-display problem by
giving the user the ability to either suppress certain rows and columns
or restrict the display to only certain rows and columns. And as you
noticed, multisets are a significant issue.

All the research issues require a strong HCI focus -- even zoom, which
seems fairly straightforward until you get into it; -}. The Envision
design is the result of extensive user-centered design and usability
testing, and I personally don't want to see it compromised by new
functionality that makes sense to nobody but the programmer. If there
is anybody in your group that would be interested in making a project of
this I would be happy to talk to him or her.

Again, thanks for the feedback,

Robert France

Hello Mr. George Robertson

My name is Dilshad Akhter and I am a graduate student in the Department of Computer Science, at Virginia Tech. Currently I am taking a course in Information visualization (http://www.cs.vt.edu/~north/infoviz) with Dr Chris North (http://www.cs.vt.edu/~north). In the study and analysis of visualization of workspace, we recently discussed "Task Gallery". We were pretty impressed with this approach of task management using gallery metaphor.

The discussion brought about some interesting critiques and ideas:

1. This provides quick task switching which is very important, when working on quite a large number of tasks at the same time.

2. One neat thing about this is that it allows grouping all the applications related to a task and placing them on a certain background to form the task. This background helps the user to remember the task. The user can also specifies the place to put the task, which in turn help him to remember the whereabouts of the task.

3. In the task gallery, all the applications of a certain task are placed on a stack. This is a huge improvement over the small icons in the task bar in ordinary 2D desktop interface. It also lets us change the ordering of the applications, which is not possible in case of icons at the task bar. This helps the user in finding a application very quickly.

4. It has simple navigation technique using only 1 (DOF) degree of freedom. So, there is no chance of getting lost. But when moving along the corridor, we loose the overview. To get the entire overview, we have to move all the way down to the end of the corridor. Another observation is that it does not show any kind of hierarchy between the applications and/or documents.

5. In terms of scaling, it is a huge improvement over the traditional 2D system. We also liked the way an application moves through the palette on the left hand.

6. During discussion, we couldn't figure out, "where are the other applications?" i.e. the applications that are not open. We could not figure out how to open a new application.

7. So far, it doesn't support to display the same applications in different task. There is no way to share the same window between different tasks. But, in many cases, it is very crucial.

We'd be glad to hear from you on the above thoughts and comments, and know of any further developments to "Task Gallery"!

Thank you!

Sincerely,

## LIFE STREAMS

Dear Scott Fertig, Eric Freeman and David Gelernter,

My name is Luhui Hu and I am a graduate student in the Department of Computer Science, Virginia Tech. I am doing a course in Information Visualization, being taught by Dr North (http://vtopus.cs.vt.edu/~north/infoviz). In the study and analysis of visualization of workspace, we recently discussed Lifestreams. We were impressed with this unique approach to visualizing and organizing lifestreams using a simple metaphor.

The discussion brought about some interesting critiques and ideas:

1. Through a time-ordered steam of documents and stream filters (sub streams), Lifestreams provides convenient and explicit ways to organize, locate, summarize and monitor incoming information. This made Lifestreams to move beyond brick-and-mortar files and directories and traditional hierarchical models of information management.

2. By mouse selecting documents, and color and animation indicating important document features, Lifestreams made users to pick up and catch desirable and urgent documents and information conveniently and promptly.

3. Lifestreams anchored a "Find" text box to let users search and select specific documents. If the string, "Find", is replaced by a button with a string "Find" on it, the users should feel more comfortable and have another choice by using the mouse instead of only the keyboard.

4. Through finding and searching documents by keywords, Lifestreams will form a sub stream containing these keywords and then let users further select. In most situations, users would like to find some particular kinds of documents quickly. For example, users would like to view their incoming or existed emails in an inbox directly, and they would not like to search them firstly and then can view them in detail. Therefore, if Lifestreams also supports the category order for some special cases, users would be happier.

5. The documents' stream is placed in the diagonal of the window; its purpose is so obvious that the window can display documents as many as possible. However, not only does the height of each document waste too much space of the window, but also it seems too empty except the diagonal.

We'd be delighted to hear from you on the above thoughts, and know of any further developments to "Lifestreams"!

Luhui

## CHIME

Dear Roger Sayle and E. James Milner-White,

My name is Matt Clement and I am a graduate student in the Department of Computer Science, Virginia Tech. I am doing a course in Information Visualization, being taught by Dr North (http://vtopus.cs.vt.edu/~north/infoviz). In the study and analysis of visualization of hierarchies, we recently discussed CHIME. We were impressed with this unique approach to visualizing molecular structures.

The discussion brought about some interesting critiques and ideas:

1. The myriad of viewing options and techniques provided many useful ways to view the molecules. By allowing the objects to spin we were able to see varying structural features on all sides of the object. This facilitated a better understanding of the structure while allowing users to form a more accurate mental model of the three dimensional structure and its components.

2. By coloring component parts of the molecule differently, we were able to recognize differences in the structures very easily. This was especially salient after applying the "space fill" filter and surface calculation function to the view.

3. Synchronization proved extremely helpful when comparing molecules. however, we wondered why zooming was not also synchronized between windowed views? We felt, by synchronizing the zooming function between two windows, users would be better able to compare detailed features of two molecules' structure at identical zoom levels

4. We also noted that the zoom function did not seem to provide any additional detail to the area in question--only a larger view. One possibility would be to provide greater levels of detail upon zooming on an area of the molecule. For proteins in particular, this would provide an excellent opportunity to add detail concerning amino acid sequencing
(provided sufficient zooming for this option of course :).

5. While we found the spinning to be 'pivotal' to comparison and interpretation of differences, it seemed to unnecessarily restrict motion to two degrees of freedom (not including the zoom feature). An additional third degree might provide more in-depth comparisons and more intuitive user manipulation.

We'd be delighted to hear from you on the above thoughts, and know of any further developments to CHIME!

Matt.

## CHEOPS

Dear Luc Beaudoin, Marc-Antoine Parent and Louis C. Vroomen,

My name is Sumithra Bhakthavatsalam and I am a graduate student in the Department of Computer Science, Virginia Tech. I am doing a course in Information Visualization, being taught by Dr North (http://vtopus.cs.vt.edu/~north/infoviz). In the study and analysis of visualization of hierarchies, we recently discussed "CHEOPS". We were impressed with this unique approach to visualizing large tree structures, since it makes efficient use of screen real estate and conserves pixels.

The discussion brought about some interesting critiques and ideas:

1. Overloading, which is the key idea behind CHEOPS, was highly appreciated since it helps save space. The idea of showing overloaded nodes distinctly was also liked by the class. One suggestion offered as the next step to this was the idea of indicating the extent of overloading as well, by using gray scales.

2. On seeing the CHEOPS demo (visualization of the de Virtual family tree), we observed that the exploration of the hierarchy had to strictly be top-down, constraining the user from tracing through levels upward. We thought it would be great to also provide bottom-up tracing so that a user could, for instance get to know the parent of a certain person by clicking on the appropriate node. This feature could be incorporated perhaps by letting the user switch to a bottom-up mode and selecting a node at a certain level, upon which the associated ancestors can be identified.

3. CHEOPS provides a good visualization of structure, but not attributes of the nodes. The class agreed on the fact that it would be good to incorporate this as well, to make the visualization complete.

4. Search tasks are hard to perform since the tool does not directly support searching for a node in one go. This can be achieved only through exploration.

5. We noticed that the visualization did not display any text / identifiers associated with the nodes. It was felt that indicating as much information as possible on a node would be a better idea than showing details of a node only on user's selection of the node.

6. In relation to the above point, one idea that came up was to use rectangles instead of triangles to be able to accommodate more text. This would lead to rectangles of varying sizes at different levels but would, on the whole, help to convey more information.

We'd be delighted to hear from you on the above thoughts, and know of any further developments to CHEOPS!

Sumithra.

Thanks a lot for your interest in the Cheops technique and various kind

First, I should tell you that none of us work at CRIM, or on Cheops
anymore, although Luc Beaudoin is pursuing research in visualization.
I include him in our correspondence, as he may have comments to add to
my own.
We had pushed the technique a lot further than what you saw in the
demonstration, but that is unfortunately not available anymore since
CRIM restructured their site.
Louis Vroomen still has a lot of the design documents, but he's been to
busy to put them back on the web, and I am afraid I do not have a valid
e-mail address for him at the moment.

> Dear Luc Beaudoin, Marc-Antoine Parent and Louis C. Vroomen,
>
> My name is Sumithra Bhakthavatsalam and I am a graduate student in the
> Department of Computer Science, Virginia Tech. I am doing a course in
> Information Visualization, being taught by Dr North
> (http://vtopus.cs.vt.edu/~north/infoviz). In the study and analysis of
> visualization of hierarchies, we recently discussed "CHEOPS".
> We were impressed with this unique approach to visualizing large tree
> structures, since it makes efficient use of screen real estate and
> conserves
> pixels.
>
> The discussion brought about some interesting critiques and ideas:
>
> 1. Overloading, which is the key idea behind CHEOPS, was highly
> appreciated
> since it helps save space. The idea of showing overloaded nodes
> distinctly was
> also liked by the class. One suggestion offered as the next step to
> this was
> the idea of indicating the extent of overloading as well, by using gray
> scales.

Or color scale as it were. We have thought about using the color scales
for other things, esp. search result quality.
Making it a general principle as you suggest is certainly in line with
the general principles behind Cheops, but the effect would have to be
subtle, since it is important that a sharp divide be kept between the
nodes that are overloaded and those that are not. Still, a good idea.

> 2. On seeing the CHEOPS demo (visualization of the de Verteuil family
> tree),
> we observed that the exploration of the hierarchy had to strictly be
> top-down,
> constraining the user from tracing through levels upward. We thought it
> would
> be great to also provide bottom-up tracing so that a user could, for
> instance
> get to know the parent of a certain person by clicking on the
> appropriate
> node. This feature could be incorporated perhaps by letting the user
> switch to
> a bottom-up mode and selecting a node at a certain level, upon which the
> associated ancestors can be identified.

This is graph exploration! We have extended the millipede (see below, 6)
to handle graphs.

> 3. CHEOPS provides a good visualization of structure, but not
> attributes of
> the nodes. The class agreed on the fact that it would be good to
> incorporate
> this as well, to make the visualization complete.

We could have changed the information panel upon pre-selection, and
indeed did so at one point, but performance was a bit of an issue.

> 4. Search tasks are hard to perform since the tool does not directly
> support
> searching for a node in one go. This can be achieved only through
> exploration.

We implemented a filtering mode, where all nodes turned to gray except
those that matched the filter, which were magenta, with shades for

> 5. We noticed that the visualization did not display any text /
> identifiers
> associated with the nodes. It was felt that indicating as much
> information as
> possible on a node would be a better idea than showing details of a
> node only
> on user's selection of the node.

This is difficult because of

> 6. In relation to the above point, one idea that came up was to use
> rectangles instead of triangles to be able to accommodate more text.
> This
> would lead to rectangles of varying sizes at different levels but
> would, on

Yes. We had an extension of Cheops called the Millipede, where each row
became one rectangle, that could host the node name, and a row of small
selection rectangles above it.
It gives a bit of a rolodex impression, I suppose. Here is a crude text
rendition:

_____________
|_|_|_|_|_| |_|_|_|
|_Node name__|

_____________
|_|_|_|_|_| |_|_|_|
|_Node name__|

Mouse-over on the "legs" changes the name, allowing for really fast

As for graph exploration, we implemented it with another layer of extra
legs, above the main row, that would light up if there were multiple
ancestors for the selected node.
I wish I could show you; this is worthless without a picture!

I still have a working prototype somewhere, but setting it up to show it
through the net would take some time to arrange, I'm afraid.

> We'd be delighted to hear from you on the above thoughts, and know of
> any
> further developments to CHEOPS!
>
> Thank you for your time!
>

Thanking you again for your interest, we'd be delighted if these few
words can spark more ideas.
Information visualization is a rich field indeed.

> Sumithra.
>

Phir milenge
Marc-Antoine Parent

## TILE BAR

Dear Marti,

My name is Ashwini Pande and I am a Virginia Tech student in Dr. North's Information Visualization class (http://vtopus.cs.vt.edu/~north/infoviz/). As a part of the course, we recently had the discussion about your paper "Tile bars: Visualization of Term distribution Information in Full Text Information Access" as well as the demo of the same (http://elib.cs.berkeley.edu/tilebars/)

Here is the summery of our discussion:

Over all everybody agreed on the fact that Tile bars is a very good tool for representing the relation between the keywords and to get the overview of the document. Moreover using the subsection method user can directly reach any part of the document, which is of interest to the user. The usability of the tool is also very good. The buttons on top of the demo were useful in retrieving the documents with different combinations of the keywords, which is a very good functionality.

But at the same time here are some of the questions/suggestions raised about the functionality of the tool:

1) Students were not sure about the difference between the 'X' and the two while blocks one below the other. We understood that the 'X' represents the area that don’t have anything relevant to the query but we also thought that the white block also represents the same situation. SO we couldn't get the exact difference between the two. Can you brief us about that?

2) We liked the concept of the arrow to browse through the document, but it took us a little while to understand their purpose. in short we didn't find the arrows very intuitive. There was one suggestion in this regard- why not make the squares little small so that we can fit in more information from the document. This might eliminate the need for the arrows for some documents.

3) The numbers that you show on buttons on the top of the demo show only the count for the documents that are currently shown out of all the retrieved ones. Why not show the count of the entire search result? This will give the exact picture as to how many documents out of the retrieved set fit in that particular criteria.

4) Many people thought that it would be good if you could highlight the keywords after we zoom into the contents of the document. That might help them to go to the most relevant part of that subsection.

5) Tile bars only gives the over all view of the document but looking at that we are not able to know the titles of the document. This will be useful if a user is looking for a particular document from the document collection. If you could display the titles also then he can directly go to the most relevant subsection of that document with the help of the block presentation.

We hope that you will get back to us soon with answers to above questions.

Thank you,

Sincerely,
Ashwini Pande.

Hello Ashwini, and thanks for writing.

Please bear in mind that the version of TileBars that you see at that
URL is an implementation done by someone else (Tom Phelps) based on my
papers. I personally dislike those X's and don't think they are a
good idea. I also think the titles should be shown.

http://www.sims.berkeley.edu/~hearst/tb-overview.html

Can you folks get a hold of one of the videos that shows versions of
TileBars that I implemented? Or read one of the papers I wrote? That
shows them the way I envisioned them. Here are the two videos:

Hearst, M. and Pedersen, J., Revealing Collection Structure through
Information Access Interfaces,'' Video track in the {\it
Proceedings of the International Joint Conference on Artificial
Intelligence} (IJCAI), Montreal, Canada, Volume II, 2047-2048, 1995.

Hearst, M. and Pedersen, J.,  Visualizing Information Retrieval
Results: A Demonstration of the TileBar Interface,'' Video track
in the {\it Proceedings of the ACM SIGCHI Conference on
Human Factors in Computing Systems (CHI)}, May 1996. Derived from
video of IJCAI 95.

Marti Hearst

---
Marti Hearst UC Berkeley (SIMS)
Assistant Professor School of Information Management & Systems
510-642-8016 Office 102 South Hall
510-642-5814 Fax Berkeley, CA 94720-4600
hearst@sims.berkeley.edu http://www.sims.berkeley.edu/~hearst

Dear Dr. Abello

My name is Yuying Tian, a graduate student in Computer Science Department, Virginia Tech. I am currently taking a class - Information Visualization being taught by Dr. Chris North (http//vtopus.cs.vt.edu/~north/infoviz). We have recently discussed your paper "Visualizing Massive Multi-Digraphs".

We are very interested in the visualization techniques described in your paper. You showed several ways with different visualization to look at the huge amount of graph data. We specifically like the star-map, which associate the data with geographic information. This map shows data in a clear way because the graph shows only the start and the end of data instead of many lines clusters in between. We also noticed that data representations are very dense for the Multi-comb view and the Multi-Wedge view. This is very good because we want to visualize trends of data and compare them.

After discussing the paper, we came up several questions and suggestions that we hope to get response.

1. We found it difficult to see details of data by viewing the star-map. There is no label for star segments. When we see a very long star segment in a star, we have no idea which state is that segment. Actually, we have the same problem with the Multi-Comb view. It is easy to see that several states make a lot of calls. However, what are theses states?

Suggestions: For Star-map, our suggestion is to put a small USA map into each state. And using color to show the amount of calls instead of star segments. For example, darker color means higher amount of calls. By using these small maps, we would have an overall idea about the calling relationship between states. How about if the state is too small? No problem! The picture of states can be enlarged when the mouse points to it. Or we can even open a new window to show this picture for each state. For the Multi-Comb view, we can label each state around the edges of the comb. And it would be much efficient if the comb can be rotated, so that states at the back of the comb can come to the front and the name of those states can show up.

2. How is the needle grid view different from the Multi-Comb view? And why the Multi-Comb view is especially useful to provide animations of data set evolution? It seems that both views have the same purpose: viewing the trends of data by computing rows and columns of data vectors. We feel that the grid map offers more information on trends of data. The Multi-Comb view is good for finding extreme data sets.

Thank you very much for your consideration. We are looking forward to hearing

from you soon.

Sincerely,

Yuying Tian

## THEME SCAPE

Dear Dr. Thomas,

My name is Christopher Roach and I am attending Virginia Tech as a graduate student in computer Science where I am currently taking a class in Information Visualization being taught by Dr. Chris North (http://vtopus.cs.vt.edu/~north/infoviz).  We have recently gone into a discussion of text visualization and analysis and have looked into themescapes as an example of this type of technology.

My classmates and I were quite impressed with the ability of the themescapes tool to take such a large assortment of unstructured textual documents and place them into a three-dimensional landscape that allows an individual to quickly scan the image and get an overview of where the most important sources of information are located and how these sources are related to one another within the image.  The scale of the software was also something that we believed was quite impressive as the software states that it is useful for visualizing collections of more than 20,000 documents.  We believe that this is a very novel concept and one that seems to be extremely useful (especially to those of us doing research work).

After discussing your software concept in class we came up with a few questions on the themescapes visualization tool that we were hoping to get answered.  These are:

1) Something we noticed about the software was that it seemed to rely more on the tools provided in order to focus in on the desired outcome rather than directly manipulating the landscape to further focus in and find the information needed.  Are there plans in the future to make the three-dimensional landscape even more interactive, thus limiting the amount of tool use in which the user must engage?

2) When studying the map we found that we were unable to find out whether a peak was comprised of a large number of diluted documents or a small number of subject intensive documents.  Is there a way of concluding this information by nothing more than a glance at the image?

3) If the answer to the above question is no then one suggestion we had was using color to represent the number of documents and keeping the height of a peak as the subject concentration within each document.

4) If a subject is related to more than one mountain is that topic placed within both of these mountains or is it placed somewhere between the two mountains?

We look forward to hearing from you on the above questions and suggestions,

Thank you,

Christopher Roach

## NICHE WORK

Dear Dr.Graham J Wills

I am Aarthi Sundararajan, a graduate student in Computer Science at Virginia Tech and a Student in the class "Information Visualization" which is being handled by Dr.Chris North (http://vtopus.cs.vt.edu/~north/infoviz) . As a part of the course, we recently discussed the paper "NicheWorks – Interactive Visualization of Very Large Graphs” which was presented by one of our classmates.

The discussion brought up a few interesting points:

1) The Option given to the user for selecting the desired Layout and incremental algorithm according to the data set under his consideration.

2) The Visualization of Graphs that have lots of nodes and edges is very difficult which has been handled through a very novel approach in Niche works.

3) The Option given to the user for pruning down the data by the selection of the attributes.

4) The concept of Brushing.

5) The Use of interactive linked view environments.

1) How is the Root Node determined when a Tree Layout is used as the initial Layout?

2) We were not sure about the color scheme that was used for the different nodes and links in the "Chicago Tribune" example.

3) The class felt that the visualization might become cluttered if the graph under consideration is a highly connected graph, which might have lots of links.

Looking forward to hear from you,

Thanks,

Aarthi

Joy,
Sorry for the delay, but I could not answer all the questions shortly, so it
took a
while to find free time

> #1- Firstly, the demo that we had with us did not quite work as wanted .
Quite
> a few features were not working and it was rather slow to respond at times.
I am not sure exactly what demo you currently have. I suspect it is based on
the
early version of our new library (mmvz), rather than the version used in the
paper.
If you'd like, I can send you the demo with the version described in the paper
(it has
the functionality described in the paper). The key question is what
description you have
and
what demo you have, because the system went over a several evolutionary steps.

> #2- The Static and Dynamic stuff was really great.
>
> #3- The idea of a dynamic presentation that involved the odions/reader was
> indeed very interesting and praiseworthy.
>
> #4- The concept of selecting any tuple by clicking on a link or typing a query
> ("SELECT 9 WINS") was also appreciated.
>
> #5- We thought that if we could have some other kinds of plots apart from a
> scatter plot, then it would be good for viewing different kinds of data
> including multidimensional ones.
The library allows for the creation of other types of plots.

> #6- If the attributes on each of the axes of the scatter plot could be
> changed, the dynamism of the document may be further enhanced.
I am not sure I understand what attributes you have in mind?

> #7- we would like to know what kind of a tool/language/script you have used to
> create the web page. How have you integrated the visualizations and text on
> the final page so that their interaction etc. have been maintained.

This is one of the main points of the approach. As long as the data sets are

common the links between views are automatically maintained. Methods to
construct/script views have changed over time.

> #8- The idea can enforce truth and help avoid falsification since the