Monthly Archive for October, 2009

Visual Analytics Panel 2009

I’m appearing on a panel at VAST today, talking about the investigation & analysis process in law enforcement & national security.  Here’s what I wrote as a high-level overview:

A common theme across many cases is the discovery of identifiers of interest: names, addresses, phone numbers, email addresses, bank account numbers, amongst others. Patterns of activity are deduced, connections between individuals, the timing and the location of key events like sightings, phone calls, etc., can lead to the generation of hypotheses/lines of inquiry which help drive the direction of the investigation as a whole. Relationship link diagrams, timelines and maps are the three most commonly expressed visualization needs.

Collaboration has been emphasized in recent years. In terms of the typology presented in Illuminating the Path, we find that typically collaboration is asynchronous remote (different time, different place), or synchronous local (same place, same time). In some shift patterns one sees continuous work done by a revolving team (same place, different time), but that is relatively uncommon. Asynchronous remote collaboration is typically achieved by emailing files. This ‘baton-passing’ approach shares a lot with the way that documents are authored in many professions. The key advantage of this approach is that information can be exchanged freely across organizational firewalls: disadvantages are that there is no definitive version of the information and multiple copies of the document can cause confusion.

In the case of (same place, same time) collaboration, this is done using a shared screen at a desk, within meeting rooms equipped with projectors and/or interactive whiteboards, or often done away from the computer entirely in a relatively informal context. In the latter case, printouts of visualizations are often pointed at and scribbled on. Printing is much more important than may be first realized. As cases get complex, it is common to print out the current known state of the case and pin it up on a wall for the investigation team to see and draw on. Evidential and other procedural requirements, especially within the law enforcement domain, mean that visualizations must fit with a ‘paper trail’ of documents.

Analysts have a very strong sense of ownership over the products they produce, and visualizations are no exception. Analysts raise concerns that their visualizations may be misinterpreted when viewed outside of the context of the task at hand. To ameliorate this, and also to facilitate basic reporting needs, visualizations are very commonly embedded as pictures within textual reports. In this state, they lose their interactivity and the consumer cannot ‘drill-down’ on the information represented. Such images are often produced in a separate ‘production’ stage after the analysis has been done. At the reporting stage, it is very common for a visualization to have to fit onto an A4/Letter size piece of paper!  Visual Analytic tools in general tend to neglect the reporting aspects of the job.

For the future, many of the general challenges facing are practical ones. Tool support for versioning, auditing data access, document searching and collaboration could be better. Tools need to be easily deployable by IT staff if they have any hope of adoption. The amount of available data is growing, but perhaps more importantly there are now more and more data sources that need to be checked during an investigation. Any help in getting data saves the analyst valuable time. Lastly improved summarization/aggregation techniques for large data sets would be very welcome.

Visual Analysis Tools: Practical Considerations

So, you’ve spent months working in the lab developing a new visualisation technique or system and you finally got some time with real users. They really like what they’ve seen. You’ve done a good job of writing the paper, it has been accepted and appears on your resume.

But hang on a minute – despite your best intentions and the users’ approval, they aren’t actually using the system right now.  So should you commercialize the idea?  This would mean the ideas are exploited and perhaps could give you some money back for all that hard work.

What are the practical steps you will need to take?

You’ll have to make sure that you actually own the IP on the system too. I’d do that bit first.

Then there are the standard set of business problems like marketing, sales channels, CRM systems, pricing.  And the usual software infrastructure stuff of build systems, installers, change management, testing, documentation.

Installers are a nightmare. ‘But it works on my machine!’ isn’t going to cut it. In real IT environments, the IT manager is a key person you will need on your side. And his/her department will need to test your application for compatibility and other things first.  For desktop applications it isn’t uncommon for deployments to lag from 3 to 5 years behind the current version. That can be very frustrating for you and for your users.

But actually, I’d argue that all those things are a lot easier than the business of really understanding the users needs: that is much harder.  Did the new system really improve their performance? Were they just trying to be helpful and polite when they said they liked it? Or are you seeing well-known experimental biases like the observer-expectancy effect or the Hawthorne effect?

What about the user’s workflow?  How does the tool fit into their existing processes?

If it did increase their performance, could they put a value on that?  And I’m not being theoretical – I’m talking about a real dollar value here. Or some measure of success in terms of the business drivers of the organisation. You will struggle to sell it unless you can talk in business terms that your buyers will use.

In this context one has to question statements like ‘the goal of visualisation is insight, not pictures’. Actually I’d argue that the end goal is action, not insight. The true aim is taking better decisions.

Don’t be disheartened: these issues make a long list, but provided you are providing enough value and provided you think about these up-front you can save yourself a lot of pain for later on. And if you don’t want to think about these things, maybe you could even strike up a licensing deal with someone who does.

Using Javascript for Visualization?

People have been predicting the rise of Javascript visualization implementations for a while now, but is this really going to happen?

First, let’s look at the positive signs:

However, looking about the web, how many examples of visualizations are there? Well, I’ve found some interesting ones like Matt Ryall’s visualizations of wiki data and Social Collider. There are more in the InfoVis research community.

But there aren’t many. So what is preventing it becoming more widespread?

One factor is the stubborness of Microsoft in its reluctance to support standards like Canvas. For commercial purposes IE is impossible to ignore.

Another factor is the language itself:

Javascript books: a cheap dig!

Javascript books: a cheap dig!

For me one of the biggest barriers is the development environment.  I’ve tried a few, the best I’ve found being JSEclipse (now part of Flex).  I must be missing something ;-)

So how is this going to develop?  My guess is that we are still a couple of years away from more mainstream adoption.  But there is no doubt that it is coming.

Update: I chatted with Mike Bostock and Marian Dörk at VisWeek about their Javascript environments. Safari and TextMate seemed to be their preferred environments for writing code…