1. Visualization Schemas for Flexible Information Visualization Chris North, Nathan Conklin, Varun Saini Proceedings of IEEE Symposium on InforVis’02 Presented by Mei Huang, Chunyuan Liao Apr. 21,2005

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

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

4. 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

5. Mismatch in design capabilities Relational Databases Traditional Visualization Design GoalData designVisualization design Design MethodData schemaProgram code DesignerData ownerProgrammer only Design ChangeRapid, dynamicSlow, static AdaptabilityFlexibleBrittle

6. Related Work Single relation visualization APT Sage/SageBrush DEVise Multiple relation visualization Visage DataSplash/Tioga-2 Rivet/Polaris Sieve

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

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

9. DataSplash/Tioga-2 http://datasplash.cs.berkeley.edu/tour_quick.html

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

11. Snap-Together -- Overview A strong analogy between relational database concepts and Snap visualization concepts enables a matching level of design capability. Demo

12. Snap-Together-- Theory(1) Snap Visualization Model Multiple views/Components Schema primitives Data-centric coordination and Joins

13. Snap-Together-- Theory(2) Self Join eg: TreeView  [URLs]  Table view Single Join eg: TreeView  [URLs]  [HitCounts]  Scatterplot Compound Join eg: TreeView  [URLs]  [Hits]  [Referrers]  TableView Multiple alternative join eg: TreeView  [URLs]  [Hits]  [Referrers]  TableView TreeView  [URLs]  [Links]  [Referrers]  TableView url_id refer_id url_id refer_id

14. Snap-Together -- User Interface Visualization Schemas -- represented as a graph and support direct manipulation Nodes -- represent instantiated visualization components Edges -- represent coordinations between visualizations

15. Snap-Together -- System Architecture TheoryUIArchitecture Coordinated Muti-views Visualization Model -Visualization -Coordination Relational Model - Relation - Association Data Source Relational Database Relational Database Coordination Manager Coordination Graph Visualization Schema Database Schema Database Manager

16. Snap server Event-based coordination Send -> Translate -> Receive -> selection/navigate Extendable architecture

17. DataCompass For novice users or very complex database schemas One-step construction Interchangeable with visualization schema Bottom-up approach vs. Top down approach

18. 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.

19. 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 … )

20. Thanks!