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 (http://vtopus.cs.vt.edu/~north/infoviz/ ),
we 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.
We are looking forward to your reply. Thank you for your time.
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,
>
> Thanks for your note.
>
> 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
> locations and easily return to them. This facility pops up
> another Pad++
> 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
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,
Thanking you for your time,
Sincerely,
Ajay Jampani
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.
Thanks for your precious time.
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
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
( http://www.cs.umd.edu/hcil/lifelines/latestdemo/chi.html).
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.
We are looking forward to your reply. Thank you for your time.
Sincerely,
Margaret ElliS
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
Mr. John Stasko,
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
for your time,
Marty Einstein
SUNBURST - REPLY
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
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
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.
We are looking forward to your reply.
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).
Thank you for your note.
>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
>information about the nodes.
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.
I'm glad you enjoyed the paper. Thank you for your feedback.
John
Maulik,
Thanks for sharing the observations and comments of your class discussion.
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
login based on the triple, and download a free copy.)
Thanks,
Ramana
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".
Thank you for your time,
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
Thank you for your insightful comments. Its very helpful -- and
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,
Dilshad Akhter
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"!
Thank you for your time!
Looking forward to your reply,
Luhui
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
instantaneously without further adjustment.
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!
Thank you for your time!
Looking forward to your reply,
Matt.
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!
Thank you for your time! Looking forward to your reply,
Sumithra.
CHEOPS - REPLY
Namaskar, Sumithra
Bhakthavatsalam!
Thanks a lot for your interest in the Cheops technique and various kind
comments and suggestions.
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.
Let me still answer your comments as I may
> 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
overloading again.
> 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
a) Overloading
b) The nodes are already quite information-laden.
> 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.
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
navigation.
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.
> Looking forward to your reply,
> Sumithra.
>
Phir milenge
Marc-Antoine Parent
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.
This URL has a more information on TileBars.
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.
Thanks again for your interest.
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
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
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.
We also had a few Questions about the paper:
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
readers
> can themselves play around with the data and visualizations instead of
getting
> bored of tabular data.
>
> #9- Are you still working on the tool to incorporate further advanced
features?
Yes, entire via group here still uses and enhances the new library.
-Audris