RE-ARCHITECTING VISUALIZATIONS

TO JAVA SWING

HISTORY

Napier has been developing visualisations for

15 years

OO Database Vis (1994)

Rapley & Kennedy

Perspective Tunnel

(1997)

Mitchell & Kennedy

HISTORY

Multiple Tree Graph

(2000)

Matrix Vis (2004)

Multiple Tree DAG

(2007)

Parallel Coordinates

(2003)

SPECIFIC TOOLS

But each visualisation in turn has been built

specifically for a given context

(databases, taxonomy, microarray data)

Reusability hasn’t been one of the criteria our

projects have been concerned with – build a demo

to show the principles for the problem at hand and

leave it at that

Which makes it hard when other data comes

along…

Those are variable depth

phylogenetic trees mate, you ain’t

getting in.

DRIVER

We wanted to reuse our work to compete for small

projects that last perhaps weeks or months

That sort of timescale doesn’t leave much scope

for development from scratch

A set of general components could be specialised

more easily than trying to fit some specialised

visualisation into a differently-shaped hole

USE A VIS TOOLKIT?

Plenty of visualisation toolkits to use out there

User level suites allow given types of data sets to

be visualised

Programmer level toolkits allow visualisations to

form part of larger applications

The user level toolkits tend to be stand-

alone, more difficult to integrate with other

programs

The programmer level toolkits tend to have their

own new models and syntaxes to learn

SWING

Most of our visualisations were built in Java Swing

but with custom models, components and UIs

Swing itself is a concrete architecture; a fully-

coded implementation of an MVC-patterned GUI

Re-architect our visualisations for Swing – not just

built in Swing but composed on top of Swing’s

existing classes for modelling/viewing Table and

Tree data

Our visualisations can be re-built in a reusable and

general form by extending the existing Swing UI

and Model classes and building necessary new

classes in the Swing style

A Parallel Coordinate display is essentially a table

where data in each column is ordered

independently, so ‘rows’ zig-zag across rather than

read horizontally

By coupling a new UI class with an extended

JTable class (plus a couple of additional sorting

classes) we have a Parallel Coordinates

implementation.

CASE STUDY:

PARALLEL COORDINATES

JParCoor

d

ParCoord

UI

Extended

by

TableMod

elJTable TableUI

Model Interface Controller View (+Controller)

CASE STUDY:

PARALLEL COORDINATES

LOC: 3,645 2,664

Reusability: Custom App Model Generic Model

CASE STUDY:

PARALLEL COORDINATES

By extending the Parallel Coordinate classes, we

can also build a Scatter-plot Matrix

CASE STUDY:

PARALLEL COORDINATES

Easy to adapt Swing-based GUIs to use our components: replace instantiations of JTable(…)with JParCoord(…)

Re: Bederson’s FishEye drop-in replacement for JList(2000)

We now have access to default JTable functionality such as Row filtering, Column drag’n’dropinteraction, direct value editing etc, which we haven’t had to implement ourselves

Two or more JTables or JParCoords can share the same TableModel

A standard JTable in synch with a parallel coordinate plot provides a convenient way to edit data

! Selection models had to be processed differently as selection indexing relates to a table’s view ordering

CASE STUDY:

PARALLEL COORDINATES

…extends JParCoord and uses a JScatterPlot as

a cell renderer in it’s associated UI class

JParCoor

d

ParCoord

UI

Extended

by

TableMode

lJTable TableUI

Model Interface Controller View (+Controller)

JScatterPl

otMatrix

ScatterPlot

Matrix UI

JScatte

rPlot

CASE STUDY:

GRAPHS/NETWORKS

Re-architecture of previous visualisations of social

network and taxonomy data

CASE STUDY:

GRAPHS/NETWORKS

Swing doesn’t have classes that handle general

graph data…

So here we have to build our own graph model

But Swing provides conventions, an architecture, of

Models, Views & Listeners etc that can be followed

For the views, we have two existing views that

show graph data

A node-link graph

A matrix

CASE STUDY:

GRAPHS/NETWORKS

For the node-link view we built a JGraph

class, some associated classes, and a GraphUI

class

Fair amount of work

CASE STUDY:

GRAPHS/NETWORKS

For the matrix though… what’s a graph matrix?

It’s a table, with nodes along axes, edges in the

middle

We build a TableModel instance that sits as a

wrapper around a GraphModel instance

Plug this into a JTable and we have a JMatrix

(extended with extras we’ve put in such as row

headers & sorting)

CASE STUDY:

GRAPHS/NETWORKS

The graph and table models for the matrix are

context-free, they just hold objects and associated

renderers decide how to display them

CASE STUDY:

GRAPHS/NETWORKS

Graph and matrix views can thus share models

+ Shared selection models for highlighting /

filtering etc

TableMod

elJTable TableUI

Wrapped by

instance of

View (+C) Controller Model Controller View (+C)

JMatrix MatrixUI

GraphModelJGraphGraphUI

IN PROGRESS:

MULTIPLE TREES

Re-architecting Multiple Trees to work on top of

multiple JTree components

ADVANTAGES OF RE-ARCH

Java Swing’s model framework is very flexible

Table, Tree and ListModels as interfaces with any

implementation you like underneath that fits

Pluggable Selection models

Pluggable sets of Renderers that display whatever

objects you choose

Access to functionality built in to standard Swing

tree and table widgets

The default Swing widgets include editing

functionality, visualisation components are usually

poor at editing data

! ADVANTAGES OF RE-

ARCH

Swing’s UI classes are pretty monolithic and

inextensible

Mix of private / protected methods that would have

been useful to extend, copy/pasting done at some

point.

They often reference helper classes with restricted

access

Default selection models are limited, mostly yes/no

Have to understand the Swing classes clearly to

incorporate new visualisation effects

i.e. programmatically expanding a column header

fires off events to listeners that can have unwanted

consequences

CURRENTLY

Talks with a couple of firms/existing projects about

visualising their data with the Parallel Coordinate

component

Integrated Parallel Coordinates into an existing

Java-based estate agency prototype

Developed the Scatterplot matrix component with

a health informatics firm in prep for a project bid

CONCLUSION

From our viewpoint, developing this suite of visualisations components that are pluggable directly into Java Swing eases a lot of development headaches

We can adapt existing Java Swing GUIs with our components, for the most part it’s one or two lines of code substitution or an init() method

We can quickly adapt the components themselves for given contexts/data domains

This kind of piggybacking on a commonly-used GUI technology makes it more likely people will incorporate visualisations – and then more people will use them

END

Thanks

Questions / Insults?