Upload
martinjgraham
View
612
Download
1
Tags:
Embed Size (px)
Citation preview
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?