Re-architecting visualisations in Java Swing


Published on

hallelujah moment as I realise coding everything from scratch is a waste of time. So I decide to code a toolkit from scratch instead.... well, almost, i extend various Java Swing widgets

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

Re-architecting visualisations in Java Swing

  2. 2. H ISTORY Napier has been developing visualisations for 15 years Perspective Tunnel OO Database Vis (1994) (1997) Rapley & Kennedy Mitchell & Kennedy
  3. 3. H ISTORYMultiple Tree Graph Matrix Vis (2004)(2000) Parallel Coordinates Multiple Tree DAG (2003) (2007)
  4. 4. S PECIFIC 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.
  5. 5. 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
  6. 6. U SE 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
  7. 7. S WING 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
  8. 8. C ASE S TUDY: PARALLEL C OORDINATES 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 Model Interface Controller View (+Controller) implementation. TableMod JTable TableUI el Extended by JParCoor ParCoord d UI
  9. 9. C ASE S TUDY: PARALLEL C OORDINATES LOC: 3,645  2,664 Reusability: Custom App Model  Generic Model
  10. 10. C ASE S TUDY: PARALLEL C OORDINATES By extending the Parallel Coordinate classes, we can also build a Scatter-plot Matrix
  11. 11. C ASE S TUDY: PARALLEL C OORDINATES 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’drop interaction, 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
  12. 12. C ASE S TUDY: PARALLEL C OORDINATES …extends JParCoord and uses a JScatterPlot as a cell renderer in it’s associated UI class Model Interface Controller View (+Controller) TableMode l JTable TableUI JParCoor ParCoord d UI Extended JScatte by rPlot JScatterPl ScatterPlot otMatrix Matrix UI
  13. 13. C ASE S TUDY: G RAPHS /N ETWORKS Re-architecture of previous visualisations of social network and taxonomy data
  14. 14. C ASE S TUDY: G RAPHS /N ETWORKS 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
  15. 15. C ASE S TUDY: G RAPHS /N ETWORKS For the node-link view we built a JGraph class, some associated classes, and a GraphUI class  Fair amount of work
  16. 16. C ASE S TUDY: G RAPHS /N ETWORKS 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)
  17. 17. C ASE S TUDY: G RAPHS /N ETWORKS The graph and table models for the matrix are context-free, they just hold objects and associated renderers decide how to display them
  18. 18. C ASE S TUDY: G RAPHS /N ETWORKS  Graph and matrix views can thus share models  + Shared selection models for highlighting / filtering etcView (+C) Controller Model Controller View (+C) GraphUI JGraph GraphModel Wrapped by instance of TableMod JTable TableUI el JMatrix MatrixUI
  19. 19. I N PROGRESS : M ULTIPLE T REES Re-architecting Multiple Trees to work on top of multiple JTree components
  20. 20. A DVANTAGES OF R E - 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
  21. 21. ! A DVANTAGES OF R E - 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
  22. 22. C URRENTLY 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
  23. 23. C ONCLUSION 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
  24. 24. E ND Thanks Questions / Insults?