I've been doing some thinking about multitouch very seriously since Christmas. (I got an iPod Touch) and I'm starting to crank out some ideas about a new visualization paradigm. It starts with that very premise - that different kinds of data need different kinds of visual paradigms.
Thinking about this in a 'surface computing' UI has unlocked a large number of possibilities and I am developing those ideas now. I will be sharing them from time to time here. It's a bit frightening to do so because I'm not sure how I can keep the ideas to myself. At the same time, I really can't see any other way to develop them strictly in a vacuum, and I think this blog is going to be the best way for me to get in touch with people who can and will help.
At any rate, the basic idea is to make a real desktop - a large translucent horizontal surface for organizing, categorizing and analyzing large amounts of data. Glasstop or tabletop computing is what I'm thinking about, and specifically I am thinking about objects from BI. Not just the presentation objects for end-users but a comprehensive UI which exposes all of the tools that BI architects would use to prepare the data for presentation and that prosumers would use to organize their own or public data sets.
The first rule is that objects will be presented in such a way as to give visual clues to their scale, and the objects may change shape or navigation technique depending on its cardinality.
For example, if I were a marketing manager and I wanted to deal with 1 million customers, and I have and entire six foot by four foot table on which to do so, I would like a tool that allows me to segment them by all of the attributes I have for them. But how do I represent 1 million customers before I perform that kind of segmentation? How might I apply filters and enumerate distinct attributes? These are the kinds of problems I would like my system to solve very easily through multitouch manipulation.
There are a number of interesting analogs that come immediately to mind. Working with a deck of cards or stacks of paper are manual types of sorting paradigms which are familiar. So let's envision one small aspect of dealing with this problem - attribute enumeration. With our 1 million records, we can represent them as a deck of cards. But imagine that there were 100 cards in the deck instead of 52. If we dealt out the deck, each card would represent 10,000 customers. The thing to keep in mind is that we can zoom in to any card and deal with 10,000 or we could zoom back out to the entire deck. We can also change the size of the deck arbitrarily, but for now let's leave it at 100.
Now we know a deck of cards has suits, and each card has a face value. But if we use our imagination we can think of each of these as dimensions or attributes. For the time being let's leave it at the attribute level. Part of the system that is going to help us out tremendously is that it will have visual paradigms for different scalar systems. When I think multitouch in my iPod, it's easy to do flick gestures through say 100 or 200 albums knowing that each album may have 1 to 20 songs each. But I also have contacts in my iPod, for me that's about 7000. It is very inefficient for me to navigate to the Rs, for example, knowing I have 500 people to flick through before I get to Joan Ruzart. I'd probably have to think, go to the Ss and flick backwards. So the cardinality of a flick list should probably not exceed 200. Accelerating flick speed would not be as user friendly as simply adding a shortcut. Therefore I would want a library of shortcuts which are applicable to all of my data sets for quick navigation. And that's where my attribute enumeration comes in.
Obviously if I've already designed the records for my 1 million customers, I know what all the attributes are and what all the fields are. Let's start with something easy. Last name, as I implied above. Instantly and obviously I can split the deck into 26. So let's say I take my pile of 100 x 10k and drag it through a hoop (rather like a lion tamer) with 'ABC' on top. It comes out into 26 stacks. Or alternately it marks those same cards with 26 different letters. For the sake of our example lets say that our hoop only marks the deck.
Only because I used to work at Xerox am I familiar with the terms 'bursting' and 'decollating'. I'll just use the first term. Bursting means taking carbon copies apart. But in our deck example each card represents 10,000 customers. So to burst a card gives us 10,000. We are not bursting our cards as they go through the ABC hoop, we are marking them. So we make 1 million marks in an attribute with a cardinality of 26.
But we could do the same operation with a burst and resize. A burst and resize would take the 100 cards with the random distribution of 10,000 customers each and then sort them into 26 cards with a variable number of customers each. That sounds like a fairly expensive operation. So let's not do it yet.
Instead we will take another attribute and apply it visually to the deck. Let's apply a net revenue per customer metric to the deck. We calculate net revenue per customer and then take a spread of those values. That spread gives us a histogram. Think of it on the x axis from -$500 to $7500. Now I can stack my cards visually along the x axis and instantly eyeball the median. I can squeeze the scale so that I get only three buckets or I can stretch it wider so that I get more buckets. I can grab any stack in any bucket and then expand that out as well. With any stack I can mark or burst and resize the subset and work with another attribute.
Cool huh?
Interesting blog. I've been thinking about touch screen surfaces and infoviz interaction,too.
Posted by: Lynn Marentette | February 16, 2008 at 05:38 PM