Ross’ PhD Blog Memex

• Currently Listening to: Albert Niland — Wuthering Heights

Say hello to my little friends.

I got word in April that my first paper, the alluringly-titled “Collaborating in Context: Immersive Visualisation Environments” which I submitted in March to the Context in Advanced Interfaces workshop at AVI06, had been accepted. So, Mark, Mike and I headed off to Venice for the week to watch presentations, ride around on boats and eat octopuses.

The paper concerns the design and development of our unique visualization lab here in UCD. My presentation at the workshop went fairly well, considering I had completed a cross-city dash minutes before starting (Venice is a big place!). My slides are available with the others at the workshop’s results page. My paper has been published in the ACM digital library.

AVI 06 proper was an excellent conference, with plenty of interesting work going on, and people to meet. My trip report is available:

Trip Report: AVI 2006 May 23–26, Venice Italy

Our own photos are online, and you can also check out the very lovely Geoffrey Ellis’ AVI photos (spot the goons!).

• Currently Listening to: Kate Bush — Cloudbusting

As part of the new structured PhD program in operation in CSI, we all have to give a talk on something relevant to our research.

I chose/it was suggested to me to present “fisheye” visualizations, a technique described by George Furnas in his seminal paper “Generalised Fisheye Views”, and the 20 years on review paper, “A Fisheye Follow-up: Further Reflections on Focus + Context”. This is a really interesting data filtering approach (and not a visual technique as the name might imply).

The talk seems to have gone down well, which is nice, as I have some workshop talks coming up later this month. Creating this presentation, the first I’ve given since I left IBM last September, has proven to be very good practise for preparing a talk, and then — erk! — fielding questions. My slides are linked below.

Talk: Information Visualization
Using View & Data Distortion

And here are some of the things I learned from my presentation:

1. Never, ever try and say “specificity” out loud in front of other people. That is all.

• Currently Listening to: Modest Mouse — Float On

This paper describes visualising the process of looking after a medical patient, using multiple, simultaneous, tightly-coupled views.

@inproceedings{1019226,
 author = {Wolfgang Aigner and Silvia Miksch},
 title = {Supporting Protocol-Based Care in Medicine
   via Multiple Coordinated Views},
 booktitle = {CMV '04: Proceedings of the Second International
   Conference on Coordinated \& Multiple Views in Exploratory
   Visualization (CMV'04)},
 year = {2004},
 isbn = {0-7695-2179-7},
 pages = {118--129},
 doi = {http://dx.doi.org/10.1109/CMV.2004.19},
 publisher = {IEEE Computer Society},
 address = {Washington, DC, USA},
}

Though the middle sections of this paper do not have much specifically to do with my own field of visualisation, they do contain a lot of good passages on visualisation techniques. Visualising time-orientated data is particularly interesting. They refer to the somewhat misleadingly named “fisheye view”, in which the focused element is enlarged and centred, and all other elements are distorted by shrinking and moving them outwards, which is a nice way to better make use of display space.

There is also a good introduction to using multiple simultaneous views, each focusing on different aspects of the data. They go about this by splitting the display area into a Logical View and a Temporal View. This approach could also be used to visualise sensor data — in effect explicitly denoting the scientific and information visualisation aspects.

There is also a section on setting up a user study to ascertain the needs, general practices and expectations of seasoned medical professionals. This is relevant as I may well have to set up some testing time with domain experts to test if our new visualisation environment is indeed more useful for collaboration than the way things are currently done.

The characteristics that the doctors and other staff identified as being important in such a system were non-surprising: intuitive interactions, a clean interface and flexibility were all mentioned. Designing for domain experts also raises a new point: the system will have to include a means for data input, which is a part of the UI that I hadn’t given much thought before.

We are preparing to install IBM’s Deep Computing Visualization software on a computer in the new Visualisation lab that’s hooked up to the DiamondTouch. This will allow us to both:

* “Explore the styles of interaction possible across different devices and a heterogeneous computing environment”
* Support simultaneous multi-user interactions across different displays

I am expecting to demo my simulation on the multiple displays in the Viz lab in the months ahead, so this will be a good introduction to the technology.

From the fact sheet (PDF):

High-end graphical images can be viewed in two visualization modes — SVN (Scalable Visual Networking) to increase screen resolution and multiplicity of physical displays; and RVN (Remote Visual Networking) to allow remote use of the application.

These two modes reflect two of the challenges in my PhD research: creating a visualisation of a large dataset across many displays, and to allow parts of the visualisation to migrate across devices.

• Currently Listening to: Ampop - My Delusions

After my initial foray into predicting the future was met with puzzlement, I’ve been thinking back over the idea of, as Aaron put it, “marrying the Scientific Visualisation with the Information Visualisation”. This seemed like the logical way to go, but right now it doesn’t look like what’s actually required or even desired for this project. Nonetheless, I want to write down the reasons I originally started thinking along this track.

Spatial Representation

First of all, because an autonomic system is made up of a large and fluctuating number of sensors and actuators, it made sense to have some form of spatial representation of where the sensors are located. This allows such actions as the person watching the visualisation saying “show me activity for the sensors at the rear of the car”, or for those clustered in the engine, for example. This would surely be a useful UI for interacting with the simulation.

Sensor Grouping

Beyond these ‘logical groupings’, they could also simply drag a box around the sensors they were interested in, and use the usual Shift-click/Ctrl-click interaction to add or remove sensors from their selection, and then generate the visualisation from this selection. Splitting the sensors driving the visualisation into groups like this would simplify the task of focusing on certain parts of the simulation, or moving parts of it onto other display devices (particularly low-power devices, with not enough processing power to generate the entire visualisation).

Using a 3D Camera

When sensors fail, as they are wont to do, the camera in the 3D environment can be positioned to show the location of the failure. This would allow the user to select nearby sensors and get realtime data from just those sensors surrounding the problematic one.

At this early stage in my PhD, it would be instructive to look ahead and take a wild, naïve guess as to what kind of deliverable simulation I may end up producing at the end. If only to look back and laugh later on.

First of all; the challenge, as I understand it at this time:

To model an autonomic system, specifically one inside an automotive machine, most likely a car. A modern car will have a wide array of sensors and actuators, and the system designer needs to be able to see how they are performing, in real time.

At the moment I’m envisioning a car, modelled in 3D, driving out onto a classic Tufte-ian grid.

A car that I’ll never be able to model.

The best guess at the moment on what kind of 3D I’m going to use would be some modification of the “Source” engine, which powered Half Life 2. The SDK comes with the game and I’ve played around with it. It’s very powerful.

Once the car comes to a stop, the outer paneling flies off, exposing a simplified version of the car’s innards. Thus begins the simulation, with (hopefully live) data being fed into the system and the display showing various activities on the screen.

Statistics like network activity and CPU usage will be on-screen at all times, in the form of pie-graphs and “sparklines” to show trends over time. Atomic events such as sensors being activated and sensors failing will be shown as alerts, possibly through a picture-in-picture system that shows a zoomed-in version of the full model at the point where the incident occurred. Clicking on this PiP box will then focus the main view on this area, through a camera movement. This device was used in the household simulation game, “The Sims”, to announce events like burglaries and housefires.

So, that’s what I’ve got so far. Of course, I’m leaving out all the bits about multiple displays and pulling elements from the main screen down onto a PDA or something crazy. It’s early days yet though, so this could still go in any direction.