Snap-together visualization: can users construct and ...infovis.cs.vt.edu/oldsite/papers/IJHCS-snap.pdfSnap-together visualization (Snap) is a conceptual model, user interface, software

Int. J. Human-Computer Studies (2000) 53, 715}739doi:10.1006/ijhc.2000.0418Available online at http://www.idealibrary.com on

Snap-together visualization: can users construct andoperate coordinated visualizations?

CHRIS NORTH- AND BEN SHNEIDERMAN

Human-Computer Interaction Lab & Department of Computer Science,University of Maryland, College Park, MD 20742, USA.email: [email protected], [email protected]: www.cs.umd.edu/hcil/snap/

(Received 2 February 2000, and accepted in revised form 31 May 2000)

Multiple coordinated visualizations enable users to rapidly explore complex information.However, users often need unforeseen combinations of coordinated visualizations. Snap-together visualization (Snap) enables users to rapidly and dynamically construct coor-dinated}visualization interfaces, customized for their data, without programming. Usersload data into desired visualizations, then construct coordinations between them forbrushing and linking, overview and detail view, drill down, etc. Snap formalizes a concep-tual model of visualization coordination based on the relational data model. Visualizationdevelopers can easily Snap-enable their independent visualizations using a simple API.

Empirical evaluation reveals bene"ts, cognitive issues and usability concerns withcoordination concepts and Snap. Two user studies explore coordination constructionand operation. Data-savvy users successfully, enthusiastically and rapidly constructedpowerful coordinated}visualization interfaces of their own. Operating an overview-and-detail coordination reliably improved user performance by 30}80% over detail-only anduncoordinated interfaces for most tasks.

( 2000 Academic Press

1. Introduction

In the "eld of information visualization, researchers and developers have created manytypes of visualizations or visual depictions of information (Card, Mackinlay & Shneider-man, 1999). For example, to display hierarchical information, one can choose fromoutliners, hyperbolic trees (Lamping & Rao, 1996), treemaps (Shneiderman, 1992),"sh-eye views (Furnas, 1986), etc. Each visualization has di!erent strengths. For example,hyperbolic trees may be appropriate for deep unbalanced hierarchies, whereas treemapsare helpful when nodes have numerical attributes.

User-interface designers often coordinate multiple visualizations, taking advantage ofthe strengths of each, to create even more powerful information exploration environ-ments (Shneiderman, 1998; Baldonado, Woodru!& Kuchinsky, 2000). This technique isparticularly potent when the information is su$ciently complex to require di!erent typesof visualizations for di!erent aspects or layers. A simple example interface is Microsoft's

-Now a$liated with the Department of Computer Science, Virginia Tech, Blacksburg, VA 24061, USA

1071-5819/00/110715#25 $35.00/0 ( 2000 Academic Press

IJHCS=20000418=Ravi=Venkatachala=BG

716 C. NORTH AND B. SHNEIDERMAN

Windows Explorer, which employs three visualizations to browse hierarchical "lesystems: an outliner visualization of the folders, a tabular visualization of the "les in theselected folder and a textual visualization of the details of the selected "le includinga miniature quick-view.

We de"ne a coordinated}visualization user interface as a set of visualizations and a setof coordinations between them. Some common types of coordinations (North& Shneiderman, 1997) used in information}exploration interfaces are as follows.

f Brushing and linking: an exploratory data analysis (EDA) technique used when dis-playing a set of data items in multiple visualizations. When users select items in onevisualization, those items are automatically highlighted in all the visualizations.A common example is brushing scatterplots (Becker & Cleveland, 1987).

f Overview and detail view: selecting an item in the overview navigates the detail view tothe corresponding details. Items are represented visually smaller in the overview. Thisprovides context and allows direct access to details. For example, web designers oftenadd a table-of-contents frame to a large document. Users can then select a section titleto scroll the main frame immediately to that section.

f Drill down: allows users to navigate down successive layers of a hierarchical database.Selecting a parent item in one visualization loads children items into another visualiz-ation, as in Windows Explorer. This enables exploring very large-scale data, bydisplaying aggregates in one visualization and the contents of a selected aggregate inanother visualization (Fredrikson, North, Plaisant & Shneiderman, 1999).

f Synchronized scrolling: users can conveniently scroll through multiple correspondingdata sets. Examples are alternate translations, music and information with summariesor annotations.

In the literature, the phrase &&multiple views'' is sometimes used to refer to only thebrushing-and-linking coordination. Hence, we use &&coordinated visualizations'' to referto the more general de"nition above.

While many coordinated}visualization interfaces have been implemented, two con-founding problems arise. Firstly, the set of visualizations and coordinations needed inany given situation depends greatly on the following.

f Data: di!erent data sets have di!erent features and structure.f ¹asks: what does the user want to accomplish with the data?f ;sers: there is tremendous variation between users in individual user preferences,

experience levels, etc.

For example, while Windows Explorer is helpful for some users and tasks, systemadministrators may need di!erent visualizations. Replacing the outliner visualization offolders with a scatterplot of the folders would enable administrators to quickly spot largeold folders for archival (see Figure 1).

Secondly, the implemented visualization tools are typically not programmed tocoordinate together. Hence, these alternate combinations usually require custom devel-opment. Researchers in our lab stumble over this problem often, and must constantlyre-implement coordinations between new unforeseen combinations of visualizations.Unfortunately, this is a poor solution to the problem. Even with good component-baseddesign, these hard-coded combinations are in#exible and di$cult to construct.

IJHCS=20000418=Ravi=VVC

FIGURE 1. A coordinated}visualization interface, quickly constructed with Snap, for system administratorsbrowsing "le}folder structures. The scatterplot and hyperbolic tree display the folders, enabling users toexamine size and date trends as well as hierarchical structure. Selecting a folder displays details of its "les in the

tabular visualization. Selecting a "le displays it in the quickview.

SNAP-TOGETHER VISUALIZATION 717

Clearly, the number of needed combinations of visualizations and coordinationsexplodes exponentially, and implementation becomes intractable. Hence, the control ofthe choice of coordinated}visualization interface needs to be in the hands of the users.A lightweight mechanism is needed to allow end-users to easily &&snap'' individualvisualizations together into custom combinations. This must not be a toolkit thatrequires programming, but a user interface.

Snap-together visualization (Snap) is a conceptual model, user interface, softwarearchitecture and implemented system developed to meet these needs. Snap enables datausers to rapidly and dynamically mix and match visualizations and coordinations toconstruct custom exploration interfaces without programming. Snap is #exible in data,visualizations and coordinations. Snap focuses on (1) interconnecting the visualizationtools created by researchers and developers in the "eld to (2) construct coordinated}vis-ualization interfaces for rapid exploration and navigation of data and relationships.

Snap also provides a platform on which to study the use of coordinated visualizationsin general. Do users understand coordination between visualizations? Can they con-struct their own coordinated}visualization user interfaces to support their tasks? Canthey use coordination to their bene"t? If there is a bene"t, why and what are the keyaspects of the coordinated visualizations that causes improvement?



In general, user-interface design requires signi"cant expertise, but Snap puts somedesign capability in the hands of users. Can users essentially design their own userinterfaces for information exploration by snapping together appropriate components?

This paper presents the Snap user interface and basic conceptual model and thenreports on two studies on constructing and operating coordinated visualizations.

2. Related work

Coordinated}visualization systems for information visualization can be classi"ed bytheir level of #exibility in data, visualizations and coordinations.

(1) Data: users can load their own di!erent data sets into the visualizations.(2) <isualizations: users can choose di!erent sets of visualizations as appropriate for the

data.(3) Coordinations: users can choose di!erent types of coordinations between pairs of

visualizations as needed for exploring or navigating relationships in the data.

Level 0 systems are not intended for #exibility. For example, Windows Exploreralways displays the same data set (the hard-drive "le structure), with the same visualiz-ations and coordinations.

Most systems are level 1, #exible for data but not visualizations or coordinations.Users can load their own data, but are always presented with the same interface.

Level 2 systems include #exibility in choice of visualizations. EDA systems, such asDatadesk (Velleman, 1988), SAS JMP, EDV (Eick & Wills, 1995), and Spot"re (Ahlberg& Wistrand, 1995), display a data table in many di!erent types of visualizations of users'choosing such as scatter plots or bar charts. All the visualizations are coordinated forbrushing-and-linking, allowing users to relate data points across visualizations. Indatabases, Visage (Roth et al., 1996) extends the brushing coordination to multiple tablesby brushing across relational joins. However, users cannot establish a di!erent type ofcoordination between two visualizations with these systems.

Level 3 systems include #exibility in the coordinations between visualizations. Some ofthese provide only one type of coordination but let users choose which visualizations tocoordinate. The Apple Dylan programming environment (Duman & Parsons, 1995) letsusers browse hierarchical object-oriented programs by splitting and linking frames sothat selecting a folder in one frame displays its contents in the other frame (e.g.generalized Windows Explorer). Spreadsheet visualization (Chi, Barry, Riedl & Konstan,1997) arranges many small 3D visualizations as cells in a 2D grid. Then, users can selecta whole row or column of visualizations to synchronize their 3D navigation. DEVise(Livny et al., 1997) allows users to select some di!erent types of coordinations betweenvisualizations. Users can synchronize panning and zooming of plots with common axes,and establish set operations between visualizations so that data in one visualization canbe combined with data in another.

In scienti"c visualization, data-#ow systems such as ConMan (Haeberli, 1988), AVSand IBM Data Explorer, and "lter-#ow systems such as Linkwinds (Jakobson, Berkin& Orton, 1994) also employ a form of dynamic linking, but for a di!erent purpose. Userslink a variety of modules to create custom data processing and viewing pipelines, muchlike pipes on the Unix command line. Snap coordinations transmit interaction rather



than data, and coordinations are bi-directional like constraints rather than pipes.Constraint-based tools such as ThingLab (Borning, 1986) are intended for speci"cationof more complex interaction within a view.

Snap builds on these systems, borrowing Visage's information-centric approach mak-ing individual information objects the basis of coordination rather than 2D informa-tion-space axes as in DEVise. Snap uses a drag-and-drop action similar to Apple Dylanto select visualizations to coordinate. However, Snap's coordination model, speci"cationinterface and ultimate purpose are unique. Snap allows users to construct a variety ofcommon coordinations quickly and easily.

2.1. EVALUATION

Little work has been done to study and evaluate the use of coordinated visualizations.Several empirical studies have compared speci"c coordinated}visualization interfaces toother approaches such as "sh-eye and detail-only visualizations for browsing hierarchies(Chimera & Shneiderman, 1994; Shneiderman, Shafer, Simon & Weldon, 1986) and large2D spaces (Beard & Walker, 1990). In general, these studies indicate an advantage ofcoordinated visualizations over single detail-only visualizations. However, the studiesdid not determine why or what aspect of the coordinated visualizations caused improvedperformance. Was it the additional information displayed in the multiple visualizationsor the interactive coordination between them?

Even less is known about users ability to construct such coordinated}visualizationenvironments. Usability work on Apple Dylan (Dumas & Parson, 1995) indicates thatonce users were shown how to split and link its frames, they were able to remember it.While users were successful with Dylan's single type of data, visualization and coordina-tion, will that carry over to a general coordinated}visualization environment? Can usersgrasp the notion of establishing di!erent types of coordinations between di!erent typesof visualizations? Can users construct appropriate interfaces for themselves this way?Clearly, a deeper level of understanding about users and coordination is needed.

3. Snap-together visualization

3.1. USER INTERFACE

Snap is based on the relational data model. To explore a database, users "rst load anddisplay relations (tables or query results) in visualizations. Then they coordinate thevisualizations by specifying actions to tightly couple between the visualizations.

3.1.1. Scenario: xle}folders. We "rst demonstrate step-by-step how Snap is used toconstruct the "le}folder browser for system administrators as described in the example inthe introduction (Figure 1). First, a database containing the folder and "le information isopened with Snap. The Snap Menu window [Figure 2(a)] displays the list of data tablesand queries in the database (left), as well as a list of available visualization tools (right).

To view the folders in a scatterplot, the data table containing folder information isdragged from the list and dropped onto the scatterplot button. A scatterplot windowopens, loads and displays the folders as data points (using Spot"re (Ahlberg & Wistrand,



1995), a commercial scatterplot package) as on the left of Figure 2(d). Choosing folder's&&creation date'' attribute for the X-axis and &&size'' attribute for the>-axis establishes thedesired view. Now it is easy to spot any large old folders in the upper left of thescatterplot.

Of course, users need to see the "les contained in the folders. In the Snap Menuwindow again, a query that extracts information about the "les within a given folder isdragged from the list and dropped onto the tabular visualization button. This opensa tabular visualization window as on the right of Figure 2(d).

Now, the two visualizations can be coordinated for behavior similar to WindowsExplorer. Snap automatically adorns each visualization window with a Snap button

FIGURE 2(b) Each visualization window is adorned with a Snap button. Dragging the Snap button from thescatterplot window to the tabular window constructs a coordination between the visualizations and displays

the Snap speci"cation dialog.

FIGURE 2(a). Snap's Menu window displays the list of tables and queries in the database (left), and theavailable visualization tools (right). Dragging the folders table onto the scatterplot button opens a scatterplot

visualization of the folders [as in Figure 2(d), left].


FIGURE 2(c) With the Snap speci"cation dialog, users choose the actions to tightly couple between thevisualizations. Here, selecting a folder in the spot"re scatterplot should load the contents of the folder into the

table visualization.

FIGURE 2(d) Construction of the coordinated}visualization interface is complete. Now, users can browseby simply selecting folders in the scatterplot to view their "les in the tabular visualization, like Windows

Explorer.




. To coordinate the visualizations, the Snap button is dragged from the

scatterplot to the tabular visualization [Figure 2(b)]. The Snap Speci"cation dialog[Figure 2(c)] then displays the available actions in each visualization that can be tightlycoupled. Choosing the &&select'' action for the scatterplot and the &&load'' action for thetabular visualization speci"es that selecting a folder in the plot should load and displaythe "les in that folder into the tabular visualization.

Now, construction of the coordinated}visualization interface is complete [Figure2(d)]. Users can browse by simply selecting folders in the plot to view their contents inthe tabular visualization.

Additional visualizations could be added to further improve the interface (Figure 1).For example, if the context of the folders in the hierarchical structure is important, thenusers might load the folders into PARC's Hyperbolic Tree (Figure 1, lower left). Theycould snap this to the scatterplot so that selecting a folder in either visualization wouldalso select and highlight it in the other. To examine the contents of many "les, users couldsnap a "le viewer (Figure 1, lower right) onto the tabular visualization.

3.1.2. Scenario: census data. Snap is in use at the Census Bureau to construct visualiz-ation environments for analysts and to prototype interface variations for CD-ROMproducts. Census analysts have found the capability to relate data between maps andplots extremely helpful. As an example, Figure 3 is an interface constructed with Snap forexploring Census population data of US states (left) and counties (right). Users canexplore from nominal, geographic and numeric perspectives using the textual lists, mapsand scatterplots. Selecting Maryland reveals that it ranks very high in terms of incomeper capita and percent college graduates. Apparently, Maryland has two counties thatare outliers with very high percentage of college graduates. Selecting the outlier countywith the highest per capita income reveals that it borders Washington, DC.

3.2. MODEL OF VISUALIZATION COORDINATION

Snap's conceptual model of visualization coordination is based on the relational datamodel. To explore a database, users can construct interfaces composed of coordinatedvisualizations based on the data schema. Snap establishes a direct correspondencebetween relational data concepts and user-interface concepts.

Relational data model ;ser InterfaceRelation P VisualizationTuple P Item in a visualizationPrimary key P Item IDJoin P Coordination

In Snap, a visualization displays a relation (a table or query result) from the database.Coordination between two visualizations is based on the join relationship between theirrelations (see Figure 4). This is somewhat similar to RMM (Isakowitz, Stohr & Balasub-ramanian, 1995), which generates hyperlinks based on database relationships.

3.2.1. Relations into visualizations. When using Snap, users "rst load relations intovisualizations (Figure 5). Generally, each tuple in the relation is depicted as an individual


FIGURE 3. A coordinated}visualization interface for exploring Census data of US states and counties, dynam-ically constructed using Snap. Users can drill down from states (on the left) to their counties (on the right).Brushing-and-linking between the nominal, geographic and numeric perspectives enables users to relate the

visualizations.

FIGURE 4. Snap's model maps relational data concepts to user-interface concepts. This illustrates the"le}folder example in Figure 2.


item in the visualization. For example, a scatter plot displays each tuple as a dot usingtwo of its attributes as the coordinates. The relation must have a primary-key attribute touniquely identify individual tuples. We assume that queries inherits a primary-keyattribute from a base table.


FIGURE 5. Components of Snap. Users "rst load queries into visualizations, then snap them together.Coordinations tightly couple actions between visualizations.


Each visualization supports a set of actions that can be performed on individualtuples. These actions allow users to indicate interest in a tuple. They can also be invokedby the system, using primary-key values to identify the tuple to act on. Each visualizationtool publishes the set of actions it supports to Snap. Example actions include thefollowing.

f Select: selecting a tuple to visually highlight it. For example, clicking on a dot ina scatter plot might color the dot bright yellow.

f Scroll, zoom, etc: navigating to a tuple to bring it to the center of view. For example,scrolling a list to bring an item to the top of the window.

When initially loading a query into a visualization, users may employ a parameterizedselection query. The parameter value is used as selection criteria in the query. Di!erentparameter values can be plugged in to select di!erent subsets of a table. In this case, thevisualization also has a Load action. Invoking this action and supplying a parametervalue re-executes the query and loads the new results into the visualization. This enablesa visualization to be used to display di!erent portions of a large data table based onexternal input.

3.2.2. Coordinating visualizations. After loading relations into visualizations, users canthen establish coordinations between the visualizations (&&snap them together''). A Snapcoordination tightly couples an action on items in one visualization to an action on itemsin another visualization. Then, when the user invokes the former, Snap automaticallyinvokes the latter and vice versa. To establish a coordination between a pair ofvisualizations, users choose the actions in each visualization to tightly couple (Figure 5).Users are guided by the type of the join relationship between the relations in the twovisualizations: one-to-one or one-to-many.

1. One-to-one: this relationship is often the result of displaying di!erent projections ofthe same table in multiple visualizations. Examples of the common coordinationsdescribed in the introduction that are one-to-one are as follows.

f Brushing-and-linking:Join relationship: one-to-one


FIGURE 6. The user interface for Exercise 1 of the "rst study and also for the second study. A pair of textualvisualizations with overview and detail-view coordination for browsing detailed census data of the US states.


Coordinated actions: select in visualization1 and select in visualization2. This links theprimary-key value of the select action in visualization1 to the primary-key value of theselect action in visualization2.Operation: selecting an item in one visualization also selects (highlights) the corre-sponding item in the other visualization. For example, in Figure 1, selecting a folder inthe Hyperbolic Tree highlights that folder in the scatter plot.

f Overview and detail view:Join relationship: one-to-oneCoordinated actions: select in overview and scroll in detail view.Operation: selecting an item in the overview scrolls (or more generally navigates) thedetail view to the details of that item. Likewise, scrolling the detail view selects thecurrently viewed item in the overview. For example, in Figure 6, selecting a state fromthe list on the left jumps the scrolling detail view to the section about that state.



f Synchronized scrolling:Join relationship: one-to-oneCoordinated actions: scroll in visualization1 and scroll in visualization2.Operation: scrolling through a list of tuples in one visualization also scrolls tocorresponding items in another visualization.

2. One-to-many: this relationship indicates a hierarchical structure between the rela-tions. Each parent tuple in the "rst relation has many child tuples in the second relation.A common coordination for this relationship type is as follows.

f Drill-down:Join relationship: one-to-manyCoordinated actions: select in parent visualization (one) and load in child visualization(many). The query in the child visualization is parameterized to select only those childtuples that are related to the parent tuple whose primary-key value is given as theargument. The primary-key value of the select action in the parent visualization islinked to the argument of the child query.Operation: selecting an item in the parent visualization loads related items into thechild visualization. For example, in Figure 1, selecting a folder in the scatterplotdisplays the "les related to that folder in the tabular visualization. There is a one-to-many relationship in the database between folders and "les. The &&Files of a Folder''query loaded into the tabular visualization is essentially: &&SELECT * FROM FilesWHERE Files.ParentFolder"?''. Selecting a folder in the scatterplot binds its pri-mary-key value to the &&?'' parameter and re-executes the query.

Snap coordinations are bi-directional, so that either action triggers the other. Userscan also chain coordinations end-to-end. For example, users can establish brushing-and-linking across three visualizations. In Figure 1, selecting a folder in the HyperbolicTree also selects it in the scatterplot, which in turn loads "les into the tabular visualiz-ation. After construction, users can save a set of coordinated visualizations as a group forlater re-use or sharing.

3.3. SOFTWARE ARCHITECTURE

The Snap system acts as intermediary between visualization tools and handles alldatabase access. Snap uses a very simple application programming interface (API) tocommunicate with visualization tools. Hence, researchers and developers can easilysnap-enable their independent visualization tools. We propose this API as a standard,analogous to APIs for cut-and-paste capabilities in modern window systems, that wouldbroadly enable this advanced functionality and greatly increase the applicability of manyvisualization tools.

Tools that have been enabled include a tabular visualization, a variety of textual listvisualizations, an outliner, Spot"re scatterplots, Treemaps, Hyperbolic Trees, InternetExplorer, ArcView maps, image thumbnail browser, etc. Snap has been used withMicrosoft Access and Oracle databases. Snap is implemented on the Windows platform,using COM to communicate with visualizations and ODBC for database access. When



using Microsoft Access databases, Snap uses Access's GUI to enable users to create andedit queries and manipulate the data schema.

For more details about the Snap system, see (North, 2000).

3.4. ADVANTAGES AND DISADVANTAGES

When constructing a coordinated}visualization interface, Snap has advantages (#) anddisadvantages (!) over programming the interface by hand (hard coding the desiredcoordinations between visualizations):

Snap Programming

#Non-programmers !Programmers only(for enabled visualizations)

#Quick and easy !Time consuming and di$cult

#Can make throw-away solutions for temporary !Short-term needs go unmetor short-term needs

#Interfaces are changeable on the #y !Static, in#exible, slow turn-around

#Can prototype many options !Prototypes typically non-functional

#Robust coordination model !Prone to mistakes, inconsistencies

#Guided by Snap model !Design from scratch

#Once enabled, visualizations are reusable in !Visualizations hard-coded each timemany di!erent interfaces

!Potentially disparate visualizations #Package in custom user interface

!Bounded functionality #Custom functionality as needed

The Snap architecture is designed to use independent visualization tools. An alternateapproach would be to fully integrate visualizations by custom implementing them withinthe context of the coordination system [as in Visage, DEVise, Spot"re, etc.]. Eachapproach has corresponding advantages (#) and disadvantages (!):

Independent visualizations Integrated visualizations

#Open system, others can easily add !Closed system, only system developervisualizations can add visualizations

#Reuses existing visualizations from the "eld !Popular visualizations must be re-implemented within the system


#Visualization development una!ected !Visualizations must use designatedstructures

#Visualizations can be used outside the system !Visualizations only work within thesystem

#Clean component-based design, visualizations !Potential inter-dependencyinsulated via API complexities

#Consistent coordination model !Potential coordination inconsistencies

!Use only existing functionality of visualizations #Can add new functionality tovisualizations

!Visualization user-interface inconsistencies #All visualizations implemented withsame look and feel

!Potential performance hit #Potential performance boost fromshared data structures, etc.

!Static coordination model #Can add advanced customfunctionality for coordinatingdynamic data, edits, etc.


4. Empirical evaluation

Studying the use of Snap is important for the following two reasons.

f To evaluate the usability and bene"t of the Snap system itself and discover potentialuser-interface improvements.

f To gain a deeper level of understanding about users' ability to understand, constructand use coordinated}visualization strategies in general. These are critically importantissues for visualization researchers and user-interface designers.

The Introduction section of this paper concludes that users should be provided withthe capability to construct coordinations between visualizations. This conclusion is validonly if the capability is both (1) usable and (2) bene"cial. Hence, two separate studieswere undertaken to evaluate these two distinct aspects of coordination:

(1) Construction: can users successfully construct their own coordinated}visualizationinterfaces?

(2) Operation: can users then operate the constructed coordinated}visualization interfa-ces to explore information bene"cially?

4.1. EVALUATION OF COORDINATION CONSTRUCTION

The "rst study uses Snap to examine the construction phase of coordination. The goal ofthis study is to determine if users can learn to construct coordinated}visualizationinterfaces and how di$cult it is for users to construct them, in terms of success rate andtime to completion and to identify cognitive trouble-spots in the construction process.



Can users grasp the concept of coordinating two independent visualizations together toform a uni"ed browsing tool? What cognitive issues are involved, how much training isrequired, how do users' backgrounds a!ect performance and can relatively novice usersconstruct powerful exploration environments in a short time? This study also revealspotential Snap user-interface improvements.

4.1.1. Procedure. We worked with six subjects on a one-on-one basis. Four of thesubjects were employees of the US Bureau of the Census, three of whom were dataanalysts or statisticians, and one a programmer. The other two subjects were computerscience students on campus.

First, background information was obtained from each subject concerning theiroccupation and experience with census data, computers, databases, Microsoft Access,visualization tools and programming.

Then, each subject was trained on Snap. The training program consisted of thefollowing.

(1) A quick demonstration of Snap by the administrator to give the subject an overviewand motivation.

(2) Review of relational database concepts including: tables, records, "elds, primarykeys, foreign keys; database query concepts including: projection, selection, sort, join;and Snap model concepts.

(3) Detailed instruction on the use of Snap and Microsoft Access (Access is used toconstruct queries). The subjects walked through the construction of a few variationsof coordinated}visualization interfaces for exploring census data. This demonstratedhow to construct common types of coordinations.

Then, when con"dent to continue, each subject began the testing phase. Subjects weregiven a database of census data for the US states and counties. Testing consisted of threeexercises in which subjects were asked to construct a coordinated}visualization userinterface according to a provided speci"cation.

Exercise 1: The "rst speci"cation consisted of a printed screenshot of the desired userinterface (Figure 6). This trial was designed to be fairly easy, to be similar to thoseconstructed in the training, and to build con"dence.

Exercise 2: The second speci"cation was also a screenshot (Figure 7), but moredi$cult. It involved a one-to-many join relationship, so that selecting a state woulddisplay data for that state's counties.

Exercise 3: The "nal speci"cation consisted of a textual description of the browsingtask that the constructed interface should support: &&Please create a user interface thatwill support users in e$ciently performing the following task: to be able to quicklydiscover which states have high population and high Per Capita Income, and examinetheir counties with the most employees.'' This trial was designed to test if subjects couldthink abstractly about coordination, and if they could think in terms of task-orienteduser-interface design. It was also designed to allow for potential creativity and variationin subjects' solutions.

Finally, subjects were given the opportunity to freely explore the system, describeproblems with the Snap user interface and o!er suggestions for improvement.


FIGURE 7. The user-interface speci"cation for Exercise 2 of the "rst study. It uses a textual list, scatterplot andtabular visualization to explore census data for states and counties.


The following variables were measured.

f Subjects' background information.f Learning time.f Success (yes/no or how close to success).f Time to completion.

This study also observed the following.

f Cognitive trouble spots (in training and test trials).f Snap user-interface problems.

4.1.2. Results. From the background survey, none of the subjects except the Censusprogrammer had experience with Access or SQL, and little exposure to relationaldatabase concepts. The Census analysts had signi"cant experience with census data, butgenerally used #at "les or spreadsheets. Each had experience with only basic visualiz-ation tools (e.g. Excel charts).

All the subjects completed the training phase in 30}45 min. They all were able tocomplete all three exercises, with occasional help from the administrators in using



Access's visual query editor. They accomplished Exercise 1 in 2}5 min, and Exercise 2 in8}12 min. They spent 10}15 min on Exercise 3 until they were satis"ed with theirsolution.

In general, the subjects were quick to learn the concepts and usage, and were verycapable to construct their own coordinated}visualization interfaces. Several stated thatthey had a sense of satisfaction and power in being able to both (1) so quickly snappowerful exploration environments together and (2) with just a single-click e!ect explo-ration across several visualizations and see the many parts operate as a whole. Theyreported that it made exploration seem &&e!ortless'', especially in comparison to thestandard tools they are used to. As to the subjects' general reaction to Snap, they clearlyshowed enthusiasm. There may have been social pressure to respond positively, since thesubjects knew that the administrator of the experiment was also the developer of theSnap system.

There was an interesting di!erence between the reaction of the data analysts andprogrammers (census programmer and computer science students). The programmerscommented enthusiastically about the component-based programming approach andthe ability to rapidly construct new interfaces. Whereas, the data analysts commentedabout being able to explore the data thoroughly and e$ciently. They did not see it asconstruction, but as exploration.

In fact, the data analysts performed better than the programmers. They learned thedatabase concepts quicker, completed the exercises quicker and constructed creativeinteresting new interfaces. Perhaps they were more motivated by the use of examplesinvolving Census data. Even during the training, they were already trying variations ofcoordinations and exploring the data. Two pointed out various anomalies in the data.After "nishing the exercises, these subjects each voluntarily stayed for an additional hourto discuss and try other examples. All four Census subjects expressed desire to use Snapin their work. In fact, a collaborative e!ort has since been undertaken.

An important result was the creativity and variation evident in the subjects' solutionsto Exercise 3. Subjects were able to design user interfaces that made cognitive sense totheir own perspective on the data. They used a mixture of visualizations including tables,scatterplots, lists and outliners. For example, while the expected design was two scatter-plots with a drill-down coordination (one-to-many, select to load), one of the dataanalyst subjects augmented this design with a pair of lists for the state and county names(similar to Figure 3). The subject stated that this would help to see which state andcounty was currently selected in the scatterplots, and also allow for accessing states byname which would be di$cult with a scatterplot alone. Another subject who preferred tosee numeric values placed the counties in a table sorted by number of employees. Onehad even constructed an interface using the treemap visualization, which is generallyconsidered a more advanced visualization di$cult for novices. In addition to variation inuser interfaces, subjects made use of the transitive property of coordination to coordinatevisualizations in di!erent pairings.

Overall, subjects did not have problems grasping the cognitive concept of co-ordinating visualizations. They were able to generate designs by visual duplication andby abstract task description. Results from Exercise 3 demonstrated that these users wereable to design appropriate coordinated}visualization interfaces. These encouragingresults indicate that users can handle a mid-level of design in which they piece together



pre-designed components to construct a larger design. Snap apparently "nds a middleground between usage (the realm of end-users) and design (the realm of experienced HCIpractitioners) appropriate for these data-savvy users. This validates the primary bene"tof the Snap capability, its #exibility.

The problems subjects did have were in manipulating the Snap and Access userinterfaces. Creating queries was by far the most di$cult part of the construction processfor the subjects. Learning to use Access and its query editor is a challenge in such a shorttime.

4.1.3. User-interface issues. Understanding the basic underlying model of Snap wascritical. However, the current Snap user interface and the form "ll-in style of the Snapspeci"cation dialog does not re#ect this model well. This study identi"ed four majortrouble spots in the interface.

(1) The terminology of the snap-able actions &&select'' and &&load'' caused some con-fusion. It was not clear enough that these represented user-interface actions. Appar-ently, some subjects were confusing &&select'' with the database query sense ofselection.

(2) Constructing a drill-down coordination (one-to-many, select-to-load) was verylaborious, and subjects sometimes got lost in the three-step process: writing theparameterized query, opening the query in a visualization and specifying the coord-ination.

(3) When constructing interfaces of three or more visualizations, subjects sometimesforgot what coordinations they had constructed between visualizations. They had torecheck them individually.

(4) When subjects were not quite sure what coordinations they should construct, theywould often &&just try stu! '' and see how it behaves. A coordination debugging modeis needed to help them see how the tight-couplings propagate between the visualiz-ations.

Redesigning the Snap user interface around an overview diagram would solve theseproblems. A node and link diagram could represent the visualizations as nodes andcoordinations as links between them. This overview could become the primary userinterface for constructing, editing, examining and debugging coordinations. Such a visualrepresentation with direct-manipulation interaction would closely re#ect the conceptualSnap model (a &&visualization schema'' analogous to the data schema). Hence, this wouldlikely reduce users' training time as well.

In addition, while the ability to create queries with Access enables more complexscenarios, it is a burden for common simple coordinations. Basing the Snap speci"cationdialog on the database schema diagram would more closely match users' mental modelof the data. This would simplify constructing drill-down coordinations since Snap couldgenerate the parameterized selection queries automatically. For projection queries,expanding the Snap Menu window to include attribute names would allow users todirectly select desired attributes to load into visualizations. Together, these modi"cationswould obviate the need to use Access to manually create queries in common cases. Thiscould further reduce training time to almost nothing.



Also, window management is a serious problem. Subjects spent considerable amountsof time rearranging visualization windows on the screen into nicely tiled layouts. Othershave proposed solutions to this general problem (see Kandogan & Shneiderman, 1997for a review).

4.2. EVALUATION OF COORDINATION OPERATION

The second study uses Snap to examine the operation phase of coordination. The goal ofthis study is to measure the bene"t of coordinating visualizations as compared to simplyusing single or multiple uncoordinated visualizations. The visual feedback across coor-dinated visualizations could be distracting or disorienting for users. But if there isa bene"t, what is its magnitude in terms of user task times and subjective satisfaction forbrowsing large information spaces?

While there are many possibilities, this study examines the overview-and-detail coord-ination. This coordination has two enhancements over the traditional single-visualiz-ation detail-only display.

(1) Overview: a display enhancement that depicts the full breadth of the data in a com-pact form, like a table of contents.

(2) Coordination: an interaction enhancement that allows users to select an item in theoverview to scroll the detail to that item. Likewise, directly scrolling the detailhighlights the current item in the overview.

Chimera's results (Chimera & Shneiderman, 1994) seem to indicate thatoverview-and-detail should perform better than detail-only. But, if so, which enhance-ment is the important factor that causes improved user performance? Is it (1) theinformation displayed in the overview or (2) the coordination between the overview anddetail?

Hence, the purpose of this study is not to compare a coordinated user interface withthe best alternative (see Section 2.1 for such studies). Instead, the purpose is to furtherunderstand coordination and its users. Speci"cally, why and how much does thecapability to coordinate an overview improve over using the detail only, in the context ofa single popular type of navigation (one-dimensional scrolling) for browsing tasks? Whatis the value or detriment of multiple visualizations that are not coordinated? What areusers' reactions to these interfaces?

4.2.1. Independent variables. ;ser interface. A simple textual user interface, construc-ted with Snap, for browsing population statistics of 45 of the US states from the CensusBureau's 1990 census. Subjects did not need to use the Snap user interface, but usedinstances of a simple textual visualization tool that were coordinated by Snap a priori tobrowse the data. The three treatments (see Figure 6) are as follows.

(1) Detail-only: a single scrolling textual report of the states, in alphabetical order, andtheir data (Figure 6, right-most window).

(2) No-coordination: the same visualization as detail-only, with the addition of a secondtextual visualization tiled on the left. The second visualization displays only the



names of the states as an overview. The visualizations are not coordinated (forexample, as if generated by Access).

(3) Coordination: the same visualizations as no-coordination, with the addition of anoverview-and-detail coordination between them. In Snap, this tightly couples theoverview's select action to detail's scroll action.

The no-coordination interface treatment is included for two important reasons. First,no-coordination will reveal which aspect of the coordinated}visualization interfaceapproach is most critical: the multiple visualizations or the coordination. Second,no-coordination mimics many common systems such as Access, Excel, web browsers andother #exibility level 2 or below systems, which do not allow users to construct customcoordinations between their visualizations. No-coordination also occurs when usingmultiple visualization tools that were not originally developed to work together. With-out Snap, users cannot coordinate them.

¹ask. A variety of browsing tasks, using a question and answer approach. The ninetreatments are as follows.

(1) Coverage-yes: &&does the information include statistics about the state of Ohio?''where Ohio is included in the data.

(2) Coverage-no: same as coverage-yes, but where the state is not included in the data.(3) Overview patterns: &&how many states in the list begin with the letter M?''(4) <isual lookup: &&what is the population of the sixth state from the bottom of the list?''(5) Nominal lookup: &&what is the population of Georgia?''(6) Compare-2: &&which of the following states has higher median family income: Califor-

nia or Washington?''(7) Compare-5: &&which of the following "ve states has higher median household income:

Florida, Texas, Louisiana, Alaska or Oregon?''(8) Search for target value: &&which state has average commute time of 31?''(9) Scan all: &&which state has the highest college degree %?''

The tasks are listed here in order from easy to di$cult based on the experiment results.The actual order they were administered was: 5, 1, 6, 8, 3, 7, 2, 9, 4.

4.2.2. Dependent variables. ;ser performance time: time to correctly complete each task,not including reading the task question.;ser subjective satisfaction: subjects rated their satisfaction with each interface on

a scale of 1}9 on four categories (with scales): comprehensibility (confusing to clear), easeof use (di$cult to easy), speed of use (slow to fast), overall satisfaction (terrible towonderful).

4.2.3. Procedure. The 18 subjects were students and sta! from campus, and were paid$10 to participate. A within-subjects design was used. Each subject used all threeinterfaces to perform all nine tasks. To avoid repetition, three di!erent but similar sets oftask questions were used. To counterbalance for potential order e!ects, all six possiblepermutations of interface order were each assigned 3 times. The three task sets were notpermuted.



For each interface, subjects were "rst trained in its use and performed several practicetasks before beginning the timed trials. After "nishing all three interface treatments,subjects then completed the subjective satisfaction questionnaire.

4.2.4. Results. Analysis of the data reveals a strong and interesting result. Figure 8shows the mean user-performance times for each task and interface. A 3]9 within-subjects ANOVA reveals that the user interface e!ect, task e!ect and interaction e!ectare all statistically signi"cant at p(0.001. Nine one-way ANOVAs reveal that userinterface is signi"cant for all nine tasks at p(0.001.

Finally, individual t-tests between each pair of user interfaces within each taskdetermine performance advantages. For tasks 1}3, the coordination and no-coordina-tion interfaces are both signi"cantly faster than the detail-only interface at p(0.001, butnot proven di!erent from each other. Whereas, in tasks 5}9, coordination is signi"cantlyfaster than both no-coordination and detail-only at p(0.001, and the latter are notproven di!erent from each other. However, while task 4 (Visual lookup) could beincluded in the second group of tasks, it may classify as an in-between case. For this task,coordination is signi"cantly faster than the other two user interfaces at p(0.005, butno-coordination is marginally signi"cant over detail-only at the p(0.07 level.

First, coordination results in major improvement in user performance time overdetail-only for all tasks. On average, coordination achieves an 80% speedup overdetail-only for easy tasks and 50% for di$cult tasks. The least improvement, about 33%,is in task 6 (compare-2). This task had the lowest interaction}time to thinking}time ratio.

The no-coordination interface results in a nearly binary pattern, and is likely thesource of the interaction e!ect between task and interface (see Figure 9). For tasks 1}3,no-coordination performs faster than detail-only, and its averages are similar tocoordination. In these tasks, subjects only needed the information in the overview toaccomplish the task. Whereas, in tasks 5}9 the coordination interface is faster thanno-coordination and the averages for no-coordination are similar to detail-only. In these

FIGURE 8. Average user-performance time for tasks in the second study. The coordinated interface hassigni"cantly faster performance in most cases: coordination; no-cordination; detail-only.


Tasks

1}3 4}9

Slower group Detail-only Detail-onlyNo-coordination

Faster group No-coordinationCoordination Coordination

FIGURE 9. User-interface treatments in the second study, grouped by user performance in tasks. The fastergroups are signi"cantly faster than the slower groups at p(0.005. The no-coordination interface results in

a binary e!ect.


tasks, subjects needed to access the details of the data. Observing subjects' behavior asthey performed these tasks revealed that when using no-coordination they tended toignore the overview. The lack of signi"cant di!erence between no-coordination anddetail-only in these cases does not imply that they are necessarily the same. It isconjectured that they are the same due to the observation of the users. In any case,coordination is signi"cantly faster than no-coordination for these tasks. Hence, in taskswhere access to details is important, undoubtedly a majority in common applications,coordination is absolutely critical.

Task 4 (Visual lookup) might classify as an in-between case. With no-coordination,many subjects determined the name of the target state from the overview, then scrolled toit in the detail view. With detail-only, they scrolled to the bottom, then scrolled back upwhile counting, and sometimes lost track. Apparently, this is a case where simply havingthe contextual information of the overview was somewhat advantageous. Coordinationwas still a major improvement over both.

In fact, an important result is that coordination performance times for lookup tasks(4 and 5) are in the same extremely fast range as overview tasks 1}3. Whereas, no-coordination times drop to detail-only level performance. When looking up details,perhaps the most common task, coordination especially excels.

In general, overview-and-detail coordination greatly improved performance overdetail-only scrolling. Clearly, a major advantage of the coordination is the ability todirectly select a target in the overview to immediately locate its details. Whereas, thescrolling interfaces require careful searching while dragging the scroll bar thumb.Observing the subjects as they performed the tasks revealed that they were more likely toexplore when using coordination. For example, in the Compare-2 and Compare-5 tasks,subjects were more willing to recheck their answers with coordination. With detail-onlyand no-coordination subjects spent extra e!ort to mentally alphabetize the "ve states tocompare so as to minimize their scrolling e!ort. Several subjects reported verbally andon the questionnaire that scrolling was di$cult. This is surprising since scrolling isa fundamental component of current GUI systems and perhaps the most commonnavigational method. The coordination interface could be considered an improved scrollbar that facilitates exploration.

4.2.5. Subjective satisfaction. With the satisfaction data (Figure 10), a 3]4 within-subjects ANOVA indicates that user interface, subjective satisfaction category, andinteraction e!ect are all signi"cant at p(0.001. One-way ANOVAs for each category


FIGURE 10. Average user subjective satisfaction in the second study. The coordinated interface rates signi"-cantly higher in all four categories: coordination; no-cordination; detail-only.


indicate that comprehensibility, ease of use, speed of use and overall satisfaction are allsigni"cant at p(0.001 level.

Analysing each pair of interface treatments within each category reveals that all pairsare signi"cant at p(0.001 except: detail-only and no-coordination in ease of use aresigni"cant at p(0.05 and the same pair in comprehensibility are not proven di!erent.

Coordination is a clear winner, gaining nearly twice the rankings of detail-only andno-coordination in ease, speed, and overall. On average, subjects ranked no-coordina-tion 1}2 points higher than detail-only, except in comprehensibility they ranked aboutthe same. While completing the survey, several subjects stated that no-coordination wasonly useful for the overview tasks.

4.2.6. Answers. Returning to the research questions: which factor is more critical, theoverview information or the coordination? The answer is nearly binary. If only theoverview information is needed, then naturally coordination is not necessary. But for theimportant cases where access to details is needed, then coordination is critical. What isthe magnitude of the bene"t? For the three most di$cult tasks, the coordinated versioncut tasks time in half. This study also reveals the importance of good overview design toenable common questions to be answered directly from the overview.

When "rst presented with the no-coordination interface, many subjects immediatelyattempted to click in the overview expecting the detail view to change, even when theyhad not yet seen the coordination interface. Hence, subjects were not distracted by thiscoordination, but rather they desired and expected it. They were visibly distraught whenthe interface did not behave as they hoped. They were clearly more satis"ed with thecoordination interface, as the subjective satisfaction data indicates. Subjects verballyexpressed appreciation for the interactive coordination that sped their tasks.

4.3. COMBINED ANALYSIS

Combining the results from these two studies may indicate the breakpoint at which timesavings during coordination operation surpass coordination construction time. In



Exercise 1 of the "rst study, subjects constructed the same user interface as was used in thesecond study for browsing tasks. The time cost of constructing the coordinated interfacewas about 2}5 min, while it saved about 0.6}1.5 min over the standard detail-only interfacefor the more di$cult tasks. Hence, after just a few tasks, users are already reaping savingswhen constructing their own coordinated interface. Of course, it is di$cult to factor inlearning time and e!ects of sharing saved interfaces. Nevertheless, this simple analysisreveals that customized information visualization is within the grasp of data users.

5. Conclusions and future work

This paper validates the capability for data users to construct their own customizedcoordinated visualization environments for exploring data. The Snap conceptual modeland software architecture demonstrate that such a capability is technologically feasible.The Snap user interface and two studies demonstrate that such a capability is bothusable and bene"cial.

The overview-and-detail coordination o!ered a 30}80% speedup over detail-onlyscrolling for all nine user tasks. While the uncoordinated overview was su$cient foroverview only tasks, coordination was critical when accessing details. Data-savvy userssuccessfully and enthusiastically designed and constructed coordinated interfaces of theirown, showing creativity and variation. Users readily grasped coordination based onrelational data schemas, although querying was problematic. These users are clearlyready for and strongly desire signi"cantly more advanced tools than standard detail-only, uncoordinated or hard-wired systems. While these cognitive issues were examinedwithin the Snap platform, we believe that these results will apply to similar coordinationsand #exibility in other systems.

The implications for practitioners are as follows.

f User-interface designers should employ coordination strategies, such as overview-and-detail, in their designs to improve user performance and satisfaction.

f Designers of systems that display multiple visualizations (uncoordinated or #exibilitylevel 2 and below) can implement Snap-like coordination construction concepts intothem, advancing them to #exibility level 3.

f Developers of independent visualization tools and operating systems can integrateSnap APIs and architectures to enable universal coordination capabilities. Forexample, Snap concepts could be integrated into a data standard such as ODBC.

The design of each coordination is critical, and others need to be evaluated. Ofparticular interest are the drill-down and brushing-and-linking coordinations. In addi-tion, these studies have identi"ed major improvements to the Snap user interface forcoordination construction based on cognitive issues. Additional work is needed todiscover if user training requirements can be eliminated by basing the interface on dataschema diagrams. Continued research is needed to explore coordination overviews,coordination guidelines, automated coordination suggestion and more.

This research was partially supported by funding from West Group and the US Bureau of theCensus. Thanks to Kent Norman for advice on the second study. Thanks also to Ben Bederson,Dave Mount, Adam Porter and Allan Kuchinsky for comments.



References

AHLBERG, C. & WISTRAND, E. (1995). IVEE: an information visualization and explorationenvironment. Proceedings of the IEEE Information <isualization Conference +95, pp. 66}73.

BALDONADO, M., WOODRUFF, A. & KUCHINSKY, A. (2000). Guidelines for using multiple views ininformation visualization. Proceedings of the Advanced <isual Interfaces Conference 2000.

BEARD, D. & WALKER, J. (1990). Navigational techniques to improve the display of large two-dimensional spaces. Behaviour & Information ¹echnology, 9, 451}466.

BECKER, R. & CLEVELAND, W. (1987). Brushing scatterplots. ¹echnometrics, 29, 127}142.BORNING, A. (1986). Constraint-based tools for building user interfaces. ACM ¹ransactions on

Graphics, 5, 345}374.CARD, S., MACKINLAY, J. & SHNEIDERMAN, B. (Eds). Readings in Information <isualization:;sing<ision to ¹hink. Los Altos, CA: Morgan Kaufmann.

CHI, E. H., BARRY, P., RIEDL, J. & KONSTAN, J. (1997). A spreadsheet approach to informationvisualization. Proceedings of the IEEE Information <isualization Conference *97, pp. 17}24.

CHIMERA, R. & SHNEIDERMAN, B. (1994). An exploratory evaluation of three interfaces forbrowsing large hierarchical tables of contents. ACM ¹ransactions on Information Systems, 12,383}406.

DUMAS, J. & PARSONS, P. (1995). Discovering the way programmers think about new program-ming environments. Communications of the ACM, 38, 45}56.

EICK, S. & WILLS, G. (1995). High interaction graphics. European Journal of Operations Research,81, 445}459.

FREDRIKSON, A., NORTH, C., PLAISANT, C. & SHNEIDERMAN, B. (1999). Temporal, geographicaland categorical aggregations viewed through coordinated displays: a case study with highwayincident data. Proceedings of the ACM CIKM +99=orkshop on New Paradigms in Information<isualization and Manipulation, pp. 26}34.

FURNAS, G. (1986). Genralized "sheye views. Proceedings ACM CHI Conference +86, pp. 16}23.HAEBERLI, P. (1988). ConMan: a visual programming language for interactive graphics. Proceed-

ings of the ACM SigGraph Conference +88, pp. 103}111.ISAKOWITZ, T., STOHR, E. & BALASUBRAMANIAN, P. (1995). RMM: a methodology for structured

hypermedia design. Communications of the ACM, 38, 34}44.JACOBSON, A., BERKIN, A. & ORTON, M. (1994). LinkWinds: interactive scienti"c data analysis and

visualization. Communications of the ACM, 37, 43}52.KANDOGAN, E. & SHNEIDERMAN, B. (1997). Elastic windows: evaluation of multi-window opera-

tions. Proceedings of the ACM CHI Conference +97, pp. 250}257.LAMPING, J. & RAO, R. (1996). The hyperbolic browser: a focus#context technique for visualizing

large hierarchies. Journal of <isual ¸anguages and Computing, 7, 33}55.LIVNY, M., RAMAKRISHNAN, R., BEYER, K., CHEN, G., DONJERKOVIC, D., LAWANDE, S.,

MYLLYMAKI, J. & WENGER, K. (1997). DEVise: integrated querying and visual exploration oflarge datasets. Proceedings of the ACM SIGMOD Conference +97, pp. 301}312.

NORTH, C. (2000). A user interface for coordinating visualizations based on relational schemata:snap-together visualization. Doctoral Dissertation, University of Maryland, Computer ScienceDepartment. http://www.cs.umd.edu/hcil/snap/ (May 2000).

NORTH, C. & SHNEIDERMAN, B. (1997). A taxonomy of multiple window coordinations. TechnicalReport dCS-TR-3854. University of Maryland, College Park, Dept of Computer Science.

ROTH, S., LUCAS, P., SENN, J., GOMBERG, C., BURKS, M., STROFFOLINO, P., KOLOJEJCHICK, J.& DUNMIRE, C. (1996). Visage: a user interface environment for exploring information.Proceedings of the Information <isualization Conference, IEEE, pp. 3}12.

SHNEIDERMAN, B. (1992). Tree visualization with treemaps: a 2-d space-"lling approach. ACM¹ransactions on Graphics, 11, 92}99.

SHNEIDERMAN, B. (1998). Designing the ;ser Interface: Strategies for E+ective Human-ComputerInteraction (3rd Edn.). Reading, MA: Addison-Wesley.

SHNEIDERMAN, B., SHAFER, P., SIMON, R. & WELDON, L. (1986). Display strategies for programbrowsing: concepts and an experiment. IEEE Software, 3, 7}15.

VELLEMAN, P.(1988). ¹he Datadesk Handbook, Odesta Corporation.


Documents

Snap-together visualization: can users construct and ...infovis.cs.vt.edu/oldsite/papers/IJHCS-snap.pdfSnap-together visualization (Snap) is a conceptual model, user interface, software