Visualization Schemas for Flexible Information Visualization

Chris North, Nathan Conklin, Varun SainiProceedings of IEEE Symposium on InforVis’02

Presented by Mei Huang, Chunyuan Liao

Apr. 21,2005

Outline

Relational Data Schema Motivation Related Work Snap-Together Datacompass Summary & Remarks

Relational Data Schema Structural description of data sets Primitives: attributes, tuples and relations

Motivation

Relational data schema enables flexible database design

No corresponding flexible ways to construct effective UI and visualization-- unique data schema unique

visualization/coordination

-- database keeps changing

-- different views for same data

Mismatch in design capabilities

Relational Databases

Traditional Visualization

Design Goal Data design Visualization design

Design Method Data schema Program code

Designer Data owner Programmer only

Design Change Rapid, dynamic Slow, static

Adaptability Flexible Brittle

Related Work

Single relation visualization APT Sage/SageBrush DEVise

Multiple relation visualization Visage DataSplash/Tioga-2 Rivet/Polaris Sieve

DEVise

http://www.cs.wisc.edu/~devise/devise/quick_intro/index.html

Visage

www-2.cs.cmu.edu/~sage/visage.html

DataSplash/Tioga-2

http://datasplash.cs.berkeley.edu/tour_quick.html

Polaris

http://graphics.stanford.edu/projects/polaris/

Snap-Together -- Overview

A strong analogy between relational database concepts and Snap visualization concepts enables a matching level of design capability.

Demo

Snap-Together -- Theory(1)

Snap Visualization Model Multiple views/Components

Schema primitives

Data-centric coordination and Joins

Snap-Together -- Theory(2) Self Join

eg: TreeView [URLs] Table view

Single Joineg: TreeView [URLs] [HitCounts] Scatterplot

Compound Join

eg: TreeView [URLs] [Hits] [Referrers] TableView

Multiple alternative joineg:

TreeView [URLs] [Hits] [Referrers] TableView

TreeView [URLs] [Links] [Referrers] TableView

url_id

url_id refer_id

url_id

url_id

refer_id

refer_id

Snap-Together -- User Interface

Visualization Schemas

-- represented as a graph and support direct manipulation Nodes

-- represent instantiated visualization components Edges

-- represent coordinations between visualizations

Snap-Together -- System Architecture

Theory UI ArchitectureCoordinated

Muti-views

Visualization Model -Visualization

-Coordination

Relational Model

- Relation

- Association

Data

SourceRelationalDatabase

RelationalDatabase

CoordinationManager

CoordinationGraph

VisualizationSchema

DatabaseSchema

DatabaseManager

Snap server

Event-based coordination Send -> Translate -> Receive

-> selection/navigate Extendable architecture

DataCompass

For novice users or very complex database schemas

One-step construction Interchangeable with

visualization schema Bottom-up approach vs.

Top down approach

Summary-- Snap’s three perspectives

Theory: multi-view visualization, coordinating between data design and visualization design

UI: diagrammatic UI to enable rapid customization of visualization without programming

System Architecture: web-based component architecture to support run-time integration of diverse data sources and visualization tools, and dissemination of custom visualization as web pages.

Remarks Merits:

A cohesive and extensible architecture for coordinating visualization components

Flexible and easy user interface, no programming needed

Shortcoming: No support for visual query No integration between query and visualization

schema Limited support for coordinated data navigation

( pan, zoom … )

Thanks!