Position Paper by Chris Weaver, University of Wisconsin—Madison

For the Workshop on "Information Visualization Software Infrastructures" at IEEE 2004 Visualization,
Organized by Katy Börner, Indiana University, USA and Jean-Daniel Fekete, INRIA, France

Part I

I.1) What functionality should a general InfoVis infrastructure provide?

I'll suggest a couple social aspects of infrastructure functionality, anticipating that other participants will address technical aspects. I believe that success of such an infrastructure requires a vibrant, sustained community of people who contribute to:

A locus for frequent communication consisting of project pages (ala sourceforge), community news pages, email digests/newsletters, project and research blogs, commentary/reviewing/metareviewing (ala slashdot)
A centralized index of distributed resources consisting of links to software downloads (modular and unified), data sets (both canonical and unusual), teaching tools (including packaged software and reading lists), and student resources

All of this should be searchable visually, of course!

I.2) What do you see as the main technical challenges for creating a central but flexible and universally useful (information) visualization software infrastructure (as opposed to 100 different ones)?

Infovis research has tended to focus on individual pieces, not the entire puzzle. Lots of work has been done on particular data structures, views, and analysis methods, but there has not been much system-level research, and what has been done tends to be limited to implementations of particular applications. The technical challenge of building an infrastructure that supports development of complete visualization systems probably relates to how difficult it is to achieve modularity and extensibility in various components of such systems:

Data structures and sources are very modular and extensible.
Views are modular and extensible, but numerous variations and versions of basic views would need to be merged.
Algorithms are somewhat modular, but usually coupled with particular data structures and/or views.
Coordinations are not very modular, as they are tied to particular view and data processing implementations, nor very extensible, as they are usually implemented as a small set of high level abstractions.

The main technical challenge may be figuring out how to incorporate various coordination approaches into the infrastructure. It may be necessary to create a multi-level coordination architecture in which user-level coordination abstractions are built upon a unified view-level coordination mechanism.

Two additional technical challenges will be development of general-purpose instrumentation (record/playback for documentation, demos, teaching, testing) and specification of widely-applicable usability protocols.

Social aspects may be more challenging than technical ones. Visualization software is often an important aspect of careers and/or incomes. This situation is understandable, but is probably an impediment to any unified infrastructure. There would need to be a way to allow researchers to contribute software/modules/data/examples/etc. without giving up their ability to be identified as the original/primary/significant source of such contributions.

Part II

Please describe the (information) visualization software infrastructure you are working on.

II.1) Project Name and Web Address

Improvise, http://www.cs.wisc.edu/~weaver/improvise/

II.2) Core Team Members

Sole Developer, Chris Weaver, weaver@cs.wisc.edu

II.3) Project Start Date

April 1999

II.4) Targeted User Group

Improvise has three different levels of functionality: browsing (navigation and selection), building (editing coordinated queries and laying out views in frames), and metavisualization (in situ visualization of coordinations and other interactive structure). Browsing targets normal end-users. Building targets data analysts, at roughly the same level of expertise required to create spreadsheets with moderately complex formulas and layouts. Metavisualization targets advanced visualization designers who wish to incorporate customized graphical annotations into their visualizations, as well as visualization researchers who wish to study coordination structure.

II.5) Supported User Tasks

Improvise is an integrated visualization design environment specialized for interactive, incremental construction of coordinated multiview visualizations of relational data. It supports:

Hierarchical layout of views in frames using a variety of layout managers
Graphical editing of layouts, views, coordinations, and queries
Dynamic creation, deletion, modification, and interconnection of all objects
Saving/loading entire visualizations as XML documents

II.6) Major Features of the System Architecture

Flexible, view-agnostic coordination based on shared objects (Live Properties)
User-customizable data processing/visual encodings (expressions)
User-definable dependencies between visual encodings and coordinations (Coordinated Queries)
Multiple independent selections of the same data
Modular, extensible views and data
Integrated metavisualization (user-definable coordination graphs, etc.)
Self-contained visualization builder and browser

II.7) Algorithms Provided

Views in Improvise evaluate and cache user-definable, expression-based queries on relational data for the purposes of projecting (visual encoding), filtering, sorting, indexing, and grouping data. Expression evaluation is optimized using short-circuiting, scan-constant evaluation, and caching of expensive subexpressions.

Scatterplot views perform tile-based caching of rendered data, optimized for common interaction patterns (pans and zooms). Graph views provide concurrent interactive and energy minimization layout.

II.8) Snapshot of the Interface

Improvise is a self-contained application that displays one or more visualizations, each in its own top-level frame. Each frame contains a multi-page (tabbed) desktop pane in which internal frames can be positioned and sized. Views are leaves layed out in a panel hierarchy inside these internal frames. Editor dialogs allow the user to create, modify, and destroy frames and views and to lay them out using a variety of layouts (roughly equivalent to layout managers in the Java AWT).

The elements that make up coordinations and visual encodings are also created, modified, and destroyed in editor dialogs. Of particular interest is the expression editor, which allows users to construct complicated query expressions in a top-down manner using point-and-click. All views provide popup menus for rapid adjustment of coordinations as well as for setting various view-specific options.

In addition to built-in coordination graphs, Improvise allows users to build custom metavisualizations using the same interface used to build regular visualizations. A metavisualization is a visualization of data that represents the structure of another visualization, and can be used to list views, show coordination graphs, or otherwise reveal visualization structure.

II.9) Development Platform

Platform: Mac OS X and LinuxPPC
Tools: Emacs, Jikes, and tcsh with custom build scripts

II.10) Supported Operating Systems

Any system that supports Java 1.4

II.5) Software Dependencies/Required Libraries

Java 1.4
Xerces (free XML library from Apache.org)

II.5) Current License

None. I have not decided whether to pursue commercialization of the software or to make it available under some free software license (e.g. GPL, BSD). I'm leaning toward the latter. I hope this workshop will help me resolve this issue.

II.5) Number of Users/Downloads

None. I plan to make the software privately available to workshop/conference attendees and other visualization researchers, but will not release it publicly until licensing issues are resolved.

II.5) Pros and Cons

Improvise is a general-purpose visualization builder and browser, and as such trades off performance for flexibility.

Pros:

Provides a coordination and visual encoding architecture that is flexible, expressive, yet fairly high-level
Scales with visualization complexity (number of views, amount of coordination)
Subsumes other coordination/visual encoding architectures (e.g. DEVise)
Is platform-independent (Java)
Coordination graphs and other forms of integrated metavisualization built on top of regular visualization architecture

Cons:

Generally slow performance
Currently supports only tabular data structures and file data sources
Currently provides only basic view types

II.5) Planned Work

Development:

Coordination of views through non-data properties using expressions
Multiple query processing backend compatible with coordination architecture
Automatic lazy expression compilation (requires Java 1.5)
Sensitivities (optimize rendering of rapidly changing data by propagating descriptions of changes)

Implementation:

Finish transition from Java 1.1 to Java 1.4, including Java2D and OpenGL
Non-tabular data structure handling (trees and graphs)
Additional views and rendering modules
Redo node-and-edge graphs views (more scalable, zoomable)
General data format/source import architecture (modular, extensible)
Incorporation of multimedia types

Application:

Metavisualization of other visualization systems
Seamless metavisualization of arbitrary Java applications

Part III

Please describe your main interest in participating in the workshop

Elicit feedback about metavisualization and the possibility of incorporating it into other visualization systems
Discuss role of coordination architectures in visualization infrastructure
Debut Improvise in a more laid-back forum than the symposium
Build an initial user base and solicit usability feedback