Comparison of SequoiaView and Grokker for InfoVis HW4, Assignments of Computer Science

An analysis of two information visualization tools, sequoiaview and grokker, used for completing infovis hw4. The author evaluates the applications' features, such as viewing options, color coding, navigation, and task performance, and discusses their strengths and weaknesses.

Typology: Assignments

Pre 2010

Uploaded on 08/05/2009

koofers-user-agj
koofers-user-agj 🇺🇸

10 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Marleigh Norton
2/24/04
InfoVis HW4
1 General Analysis
1.1 SequoiaView
SequoiaView seems to have very limited application. All one can do is visualize a hard
drive, and since I’m running these applications on Virtual PC on a Mac, the parts of my
hard drive that can be accessed and visualized are limited.
Of the various viewing options, the best seemed to be the Squarified Cushion Treemap,
chiefly because it made sure the elements were large enough to click upon. The other
views sometimes became too narrow to select easily. The disadvantage of the square
view, which was less of an issue with the other views, was easily seeing how things were
grouped. While elements of the same directory were grouped in rectangles, it was often
hard to distinguish precisely where the rectangle began or ended, for example, whether a
given column of elements belonged to the directory to its left or its right. The
highlighting option for showing the entire path helped a great deal with this, though it
still required mousing over a particular element, which made it less useful for an
overview.
A major complaint was the choppy navigation. When clicking on an element, rather than
smoothly animating the zooming motion, the zoomed in view was simply displayed.
This would not have been so disorienting except the element clicked upon also moved
relative to the cursor. The user gets lost and must search for the element she was
interested in, difficult, since they all look very similar. This is illustrated in Figure 1.
One thing I did like about SequoiaView was the color coding by file type. When one
uses this program, one immediately sees the size of each element, which is often what I
want to know about a file. By enabling color-coding by file type, it’s easy to search out
particular types of file. This made SequoiaView an excellent choice to perform Task 2
(see §2.2.1).
pf3
pf4
pf5

Partial preview of the text

Download Comparison of SequoiaView and Grokker for InfoVis HW4 and more Assignments Computer Science in PDF only on Docsity!

Marleigh Norton 2/24/ InfoVis HW

1 General Analysis

1.1 SequoiaView

SequoiaView seems to have very limited application. All one can do is visualize a hard drive, and since I’m running these applications on Virtual PC on a Mac, the parts of my hard drive that can be accessed and visualized are limited. Of the various viewing options, the best seemed to be the Squarified Cushion Treemap, chiefly because it made sure the elements were large enough to click upon. The other views sometimes became too narrow to select easily. The disadvantage of the square view, which was less of an issue with the other views, was easily seeing how things were grouped. While elements of the same directory were grouped in rectangles, it was often hard to distinguish precisely where the rectangle began or ended, for example, whether a given column of elements belonged to the directory to its left or its right. The highlighting option for showing the entire path helped a great deal with this, though it still required mousing over a particular element, which made it less useful for an overview. A major complaint was the choppy navigation. When clicking on an element, rather than smoothly animating the zooming motion, the zoomed in view was simply displayed. This would not have been so disorienting except the element clicked upon also moved relative to the cursor. The user gets lost and must search for the element she was interested in, difficult, since they all look very similar. This is illustrated in Figure 1. One thing I did like about SequoiaView was the color coding by file type. When one uses this program, one immediately sees the size of each element, which is often what I want to know about a file. By enabling color-coding by file type, it’s easy to search out particular types of file. This made SequoiaView an excellent choice to perform Task 2 (see §2.2.1).

InfoVis HW Page 2 of 5 Figure 1: In the first picture, the user selected the red box, shown by the red arrow. In the second zoomed in picture, the desired file bounced over to the right side of the screen, while the user’s cursor, shown by the white arrow, stayed in place.

InfoVis HW Page 4 of 5 The visualization of the web pages was cute, but in my opinion, not particularly useful. This was due less to the visualization technique and more to the search results and presentation method. When searching for “Marleigh Norton”, the results were grouped into categories. Some of these categories made sense, such as “MIT” (my undergraduate school). Some of the others did not, such as “Four”. Having googled for the phrase before, I have a good idea of what the search results for that string should be, yet it took me quite a while to even find my home page, which is one of the first search results returned by Google, because it was buried inside an oddly named node. The way I wanted this feature to work was to type in a page or URL and have Grokker map out the entire site for me, as well as links. If Grokker supports that capability, I was unable to find it. My Amazon search worked much better. I was able to locate a favorite graphic novel series in fairly short order. I expect the clearly defined Amazon category structure helped a great deal in this. One suggestion, however, is that since one can navigate while a site is being grokked, the node being viewed should be processed first. For example, while Amazon was grokking the title of my book, I clicked on the Books node and zoomed into it. Rather than filling in the Books node next, Grokker continued mapping out the Videos and Music nodes, even though that was clearly not a high priority for me.

2 Tasks

These were the tasks selected to compare SequoiaView with Grokker. Tasks:

  1. Overview: How many directories is my C drive divided into?
  2. Identify files to be deleted to free up space (size and type important).
  3. Navigate to a particular file

2.1 Overview: How many directories is my C drive divided into?

Answer: Not Found

2.1.1 SequoiaView

SequoiaView could show this information. I would have found the answer by mousing over various elements until all base directories were accounted for and tallying up the answer myself. This would be tedious.

2.1.2 Grokker

Grokker also requires tallying up the number of directories, though unlike SequoiaView, no mouseovers are necessary. Unfortunately, I was unable to discover how to visualize my entire C: drive. The highest I could get to was C:\ Documents And Settings\Marleigh Norton.

InfoVis HW Page 5 of 5

2.2 Identify files to be deleted to free up space

2.2.1 SequoiaView

SequoiaView performed this task quite well. In making a decision about what to delete when I decide to purge my system, I most often want to look at the file size and the type. Large image files and movie files are the first to go. With SequoiaView, looking for large red squares helps identify these candidates quickly.

2.2.2 Grokker

Grokker was not as good at this task as SequoiaView. The size of the nodes in Grokker correspond to the number of elements, not the file size. One could filter on files size, which did help a great deal. However, there was no filter for file type, which would have helped as well. There is a “Last updated” filter, which helps identify unused files, but since I often archive files on my computer, this was not helpful for me.

2.3 Navigate to a particular file

2.3.1 SequoiaView

SequoiaView bombed at this task. Not only were the navigational transitions choppy, as pointed out in the overview, but it was exceedingly difficult to identify a particular file. Directories were unlabeled. The best thing to do was to mouseover everything in a hunt- and-peck style until you found something promising. Then you clicked on it and did the same thing again in the next view.

2.3.2 Grokker

Navigation using Grokker was fairly nice. The transitions were smooth and clicking on nodes to descend a directory tree was fairly simple. One major complaint, however was with the folder panel on the right. When visualizing the hard drive, the panel on the right displays the file system in typical Windows icons. It seems logical that one should be able to navigate the visualization this way. Wrong! While one can click around in the file system, the visualization does not update accordingly. Also, the file system panel doesn’t have a button to ascend one directory, and if you modify the text box with the path, Grokker tries to turn the path into a URL to load. If Grokker is going to display information in the style of a Windows folder, it should have the functionality and behavior of a Windows folder.