From CS294-10 Visualization Fa08
Lecture on Sep 22, 2008
- Visual information seeking: Tight coupling of dynamic query filters with starfield displays, Ahlberg & Shneiderman. (html)
- Visual exploration of time-series data, Hochheiser & Schneiderman. (html) (pdf)
- Postmortem of an example, Bertin (pdf)
- The visual design and control of the trellis display. Becker, Cleveland and Shyu. (ps) (pdf)
- Table lens, Rao and Card, (acm)
- Human guided search: Survey and recent results, Klau, Lesch, Marks & Mitzenmacher. (pdf)
- Design and evaluation of incremental data structures and algorithms for dynamic query interfaces. Tanin, Beigel & Schneiderman (citeseer)
Maxwell Pretzlav - Sep 21, 2008 03:41:21 pm
The Becker, Cleveland and Shyu paper above is in reverse order (not uncommon for postscript files meant for printing). I've uploaded a reversed PDF for easy reading (say, in Preview.app) here.
Ketrina Yim - Sep 22, 2008 08:02:25 pm
I found the color coding aspect of the Attribute Explorer quite fascinating. Even when there are no exact matches for queries involving multiple attributes, the color coding tells which data comes the closest to satisfying them. It's particularly useful for users who are just as interested in close matches as they are in exact ones.
But this leads to a question: why isn't this feature seen in today's interactive visualizations and visualization tools? Apparently, IBM had been working on the idea, but seeing as the page is from 2001, they probably moved on to other things. Could it be that it was pushed to obscurity by newer, fancier methods of interaction? If so, it really ought to be picked up and reconsidered, so that someday it can find its way into product query sites, such as the MyPhoneFinder.
On a slightly different note, Newcars.com has a something similar to MyPhonefinder for their Car Chooser, except you can also directly compare the details of up to four cars.
Ljuba - Sep 23, 2008 12:17:03 am
It seems that once we start dealing with interactive visualizations, we step into the realm of user interface design with all its complexities. Tufte's edicts of eliminating chartjunk and maximizing data-ink seem to only apply to the visualization once it's been made static, but say nothing about how to manipulate an interactive visualization system to explore multiple views.
There are, however, guiding principles for software UI design that can help us here. One of my favorites is that no action should take more steps (clicks, mouse drags, keystrokes, etc.) than necessary. A good example of poor UI design vis-a-vis this rule is the alpha-slider for movie titles used in the FilmFinder application we read about and talked about in class. Let's consider what a user might want to do with a list of movie titles.
1. Browse movies in alphabetical order.
2. Search for a particular movie by title.
3. Find a movie given only part of the title.
The alpha-slider is poorly suited for these tasks. Scrubbing through the movies alphabetically is what the slider is good for, but actually browsing the collection one title at a time by performing minute mouse movements, continuously holding the mouse button down, is tedious and unnecessary. The same actions are required to find a movie whose title you know the beginning of. Finding a movie by only part of the title is nearly impossible with an alpha slider.
A far better solution would be to implement a dynamic search field like the one in iTunes. As the user types any part of the film title, matches would appear immediately below the search field in a drop-down menu. The user could then either click on the correct title or complete the search until only one item remains and hit enter. This implementation makes finding movies really easy using any known part of the title. Almost no mouse interaction is even necessary and it is much quicker. Now, alphabetical browsing is not ideally suited to this kind of UI widget either, but if need be, a list of movies could be implemented as a scrollable drop-down menu from the search field when no query is supplied.
I love sliders. It think they serve the purpose of dynamically filtering data in visualizations beautifully. But they're very poorly suited for finding a particular visual element or browsing elements one by one because of the continuous user interaction required to operate them. So, when you're looking for something, stick with a search field.
Scott Murray - Sep 23, 2008 03:31:16 pm
Ljuba, I agree with your comments above. During the demonstrations of early software, I try to remind myself that we're studying these applications' visual representations of data, not their kludgey UI elements. Even Ben Fry's Zip Decode, which I think is the most elegant of the bunch, uses an unfamiliar UI (although it may be appropriate for the specific use, in this case).
I also have a comment on Bertin's "Postmortem of an example." I've pulled out here what I found to be his two most valuable insights in the piece:
- In decision-making the useful information is drawn from the overall relationship of the entire set.
We've come to understand this implicitly, during our early discussions of why to create visualizations at all, but it helped me to see the thought articulated so clearly. For those visualizations intended to inform a decision (which isn't all of them), it is important for the designer to realize that the process of visualization is not merely representing the original data set, but adding new "data": the visual forms from which patterns may be perceived, and upon which judgements may be made.
- ...the use of a single table indicates that the problem is well defined.
I found this to be an interesting rule of thumb by which to consider one's data. Start by framing your question, then adapt the data to a structure simple enough to provide you with an answer.
NickDoty - Sep 24, 2008 12:51:06 am
I was really blown away by Ben Fry's zipdecode visualization.
I wonder if the same thing could be done with telephone area codes or even Social Security Numbers, both of which have initial numbers organized geographically. Although neither of those examples has quite the strict hierarchy that makes this example so great, I think it would actually be more interesting to see the dispersion of telephone numbers and Social Security Numbers through the country than to see static geographical data like zipcodes.
On reflection though, is this really the most effective visualization? It's certainly dramatic to show the numbers lighting up piece by piece, but it's also more difficult to see the boundaries between numbers (I had to switch back and forth between 5, 6 and 8 multiple times, for example) than if the hierarchy were displayed without asking the user for a single portion to highlight.
Ketrina Yim - Sep 24, 2008 08:59:08 pm
@NickDoty: It would lose some degree of interactivity if the hierarchy were displayed in advance. Having the numbers light up as the ZIP is typed in would help draw the user's eye to the highlighted area (it's also what made it so amazing!).
As for area codes, it's entirely possible to make a visualization similar to zipdecode. Social Security Numbers might be somewhat more complicated, as they are attached to a person, and people often move residences from state to state.
Maxwell Pretzlav - Sep 25, 2008 07:43:07 pm
I had the same reaction as Scott to the Bertin reading. I was impressed with how Bertin pulled out things which we sort of implicitly know as data viewers but as designers it is very useful to see written down in concise terms. I like how Bertin understood and explained the usefulness of directly interacting with data visualizations before any of today's modern interactive interface came into place.
I was also particularly impressed with ggobi's brushing technique. Is this used in other data visualization software? It seems it would be incredibly useful in finding patterns in (or just understanding) many types of complex multivariate data.
James Hamlin - Sep 25, 2008 11:05:03 pm
The concept of 'tight coupling' is key. When each component of an interactive visualization's interface updates in concert, maintaining logical coherence, a user will more quickly and easily grasp the metaphor the visualization presents. I would imagine that something like preattentive causal 'reasoning' is leveraged to solidify the user's model of the presentation. 'Loose' coupling wouldn't exhibit this causal behavior and thus the visualization wouldn't be understood as a coherent, unified system. This is in addition to, probably the reason for, the points the article makes, that tight coupling reveals software state and helps users avoid unnecessary or erroneous input. It would be an interesting exercise to explore implementation-level details and design patterns that can make developing and extending software with tightly coupled UI/visualization components simple, efficient, and elegant.
Nicholas Kong - Sep 27, 2008 06:20:33 pm
I was just wondering if anybody else found the "strip labels" in the trellis diagrams distracting. While they do seem useful when there are overlapping intervals, for me it was not clear what they were meant to represent and did not add anything to the readability of the charts. The entire trellis concept seemed to be a formalization of Bertin's rearrangement dictum.
I would have to agree with all the above statements about Bertin. His ability to distill vague notions into concrete statements is quite astounding.
Matt Gedigian - Sep 28, 2008 07:41:34 pm
@Ljuba I have to say, I didn't really understand what they were using the Alphaslider for. This paper from 1993 describes using Alphasliders for things like a VCR control panel where you don't have a keyboard, mouse, or very much space. That makes more sense -- I will definitely look for this feature the next time I purchase a VCR.
The theme of the paper was tight coupling - in that context I suppose the main benefit of the Alphaslider is that it serves as both an input control and an output display. So the thumb could be positioned based on other selections by the user. I don't see the benefit of that in this case since I don't see why you'd want to start browsing from that location. But maybe in a non-movie application it would be handy.
The benefit that Maneesh mentioned in class had to do with conveying information about the entire dataset. The marks on the slider indicate how many movie titles start with the letter A, for instance. I'm not sure that's crucial for selecting movies, but Google's Chrome browser uses the scrollbar to indicate the location of search results. In the comments, people mention other programs that take advantage of the scrollbar to convey information. This paper from CHI 92 also discusses various designs (pdf).
Razvan Carbunescu - Sep 28, 2008 09:27:22 pm
One thing that I did find very useful though from the filmfinder application was the way they use tight coupling between the detail on demand to allow for selection(highlighting) of a particular actor/director in order to allow for a new search. I do think thought that the filmfinder suffers from a bit of confusion because of the color coding of the movies; while it provides some information I think that the rainbow effect that it creates seems overwhelming. I think that what should be done is for the colors to change interactively with the search also with only 4 colors being displayed based on the appropriate movie results 3 colors for the first 3 most common movie types and a 4th other color for the rest.
Chris - Sep 29, 2008 01:41:23 am
The data discussed in Filmfinder seems suspiciously static. In particular, the data for each film discussed were properties such as lead actor, rating, genre. This sort of information has little bearing on whether or not I will be interested in a given film.
For the Flimfinder example and many others, a more important (and often more difficult) question than "how should the data be presented?" is "what data should be presented?" If one doesn't have the right answer to the latter, the former is irrelevant. There has been a shift (since the mid-90s, when this paper was published) in the way in which data is organized. Rather than presenting users with records (film name, year, actor, etc), more significant emphasis is placed on properties data such as user feedback and interaction (e.g, user provides ratings, etc) and interconnections between data (ege, pagerank or the intersection between movie casts). Consider, for example, the now-ubiquitous "people who watched/downloaded/bought/liked this also watched/download/bought/liked the following" panels found whenever you perform a transaction online. This sort of non-obvious, non-static data is often far more valuable to the user than records and statistics.
I think that this message has been taken to heart these days. It is interesting to compare Filmfinder with its modern successful equivalents (NetFlix, iTunes).
David Poll - Sep 29, 2008 02:00:38 am
Zipdecode reminded me of a UI pattern I find particularly important that is becoming more and more common in modern applications. While I think Zipdecode's overall UI isn't wonderful (they shunned the use of common UI controls like textboxes), it does an excellent job of associating user interactions with appropriate visualizations. The pattern I'm talking about that's becoming more and more common is the "live filter". Gone are the days of "create a query and hit submit". Life is so much easier when you get immediate feedback. Today, you see this pattern in desktop/instant search (one of my favorite UI forward-leaps in Vista), web search (e.g. google suggest), and even e-mail filtering (in Outlook, for example). All of these applications are very close if not identical to the brushing/linking techniques we discussed, and they make for a much more coherent interface than in "classic" software. Remember the search dog in old versions of Windows? He seems so primitive by comparison! :)
Witton Chou - Sep 29, 2008 02:52:41 am
I really like the tight coupling strategy from the Ahlberg and Shneiderman piece. It is definitely a strategy worth employing in our visualization project. By verifying that only the pertinent filters and pieces of the visualization are available when certain other contraints are asserted, we can reduce the possibility for errors and facilitate the users understanding of what certain filters may have altered in the data set. The filmfinder/homefinder examples are great in that the user can instantly see changes in the data as the filters are quickly being altered through the sliders. Although there are some problems with the sliders themselves, the idea behind using these sliders is worth exploring.
I really enjoyed the TimeSearcher examples. I found that being able to select a group of trend lines through a region of the graph and select trend lines matching a particular pattern are very useful in areas such as market research. Being able to interactively explore the trend data graphically and efficiently through this clean interface is quite amazing.
Jeff Bowman - Sep 29, 2008 12:53:23 pm
As Christopher mentioned, with the FilmFinder, I immediately became curious about how static the data was; however, I also was curious about the chosen dimensions. They claimed they interviewed film clerks and film aficionados, but the data dimensions that resulted seemed to be pretty complex.
Interestingly, Ahlberg and Shneiderman focused on the starfield display as their key method of presenting this information. I would contest that, as the starfield display is notable for the number of data dimensions it can show, but in some ways the 2D collage output from the Cell Phone Finder is equally good at displaying and focusing information. I would be curious about whether the interactive querying and interaction that the starfield display presents could be distilled into numbers (e.g. result counts and field StDevs) to select data quickly without displaying all of it, for searches involving such things as image data or long records.
I would also point everyone at HousingMaps.com, a modern Craigslist+GoogleMaps mashup for apartment searches. Not only is it reminiscent of HomeFinder, but it's also pretty useful if you happen to be moving in the near future.
Michael So - Sep 29, 2008 01:19:50 pm
In the Visual Information Seeking reading, I like the aspect of tight coupling that applies to components of a query facility. When a user forms a query, it is very helpful to see the impact of each selection made in the query. This is good because it puts constraints on other components of the query. The example given about finding a film before 1935 is a good illustration of this aspect of tight coupling. If someone wants a film before 1935, there should only be a select number of actors and directors. This is helpful for someone who does not know much about movies, or in general about the data set, because it helps prevent errors and inconsistencies.
I also want to say that the zipdecode visualization example is a good demonstration of this tight coupling aspect. With each number you type, you get an immediate response showing the results of your input. Typing 9 as your first number "pops out" West coast area and there is no mistaking that zip codes starting with 9 apply to only West coast. Therefore if someone didn't want to find a zip code in the west, then from typing 9, the visualization immediately suggests the user to reformulate their query.
Sarah Van Wart - Sep 29, 2008 02:10:21 pm
I found the Hochheiser & Schneiderman article (Visual Queries for Finding Patterns in Time Series Data) very interesting. It was yet another way in which to explore, query, and refine large quantities of data in an intuitive way. Just an anecdote on the power of interactive software: while reading the article itself and trying to make sense of the stock lines and how the "time box" interacted with the lines, I couldn't quite grasp how the time boxes (especially the second time box) was used to filter data. However, as soon as it was demonstrated in class, it was instantly clear how (1) drawing a box around cheap stocks at an earlier point in time, and (2) drawing a second box around more expensive stocks at a later point in time could help a user to quickly filter data. The way in which the particular visualization helped to sift through time series data was extremely useful.
With the FilmFinder, I immediately was interested in the effect of visualization. But, I thought some functions were not needed or did not make sense. Because, plotted data chosen by dimensions resulted in pretty complex or bit seemingly meaningless. Maybe, this is because hardness of question selection. For example, everyday we Google something and have the reply. I think everyone almost is caring about a query i.e. question If our question is not thrown properly, the answer replying to us will be significant or meaningful and vice versa. Also, tn "Graphics and Graphic Information-Processing, author says "Information is the reply to a question" . I think when we take advantage of dynamic query as interaction, we should choose the query carefully before making visualization,
Seth Horrigan - Sep 29, 2008 03:10:57 pm
I have seen demonstrations of HomeFinder and FilmFinder a few times now, and I agree that they were both novel and innovative methods for interacting with a static data set. At the time they were created, they represented a huge leap in interactive visualization, and their research ideas have since been incorporated into systems that we encounter daily. However, two things strike me every time I see the tools demonstrated.
- The systems are ugly.
- The systems are hard to use.
Granted, in the mid-90s, Windows 95 was a dominant operating system and in some ways the interfaces followed the thematic GUI design of that OS. Granted, aesthetics were not central at all to the purpose of the paper. Even so, it is a fairly ugly system. The fonts are blocky, the graphics distracting, the grays and black of the buttons and background are displeasing to my eye, and the cacophony of color used to encode data in little rectangles is no better. I am not complaining - as I said, the aesthetics were peripheral. Even so, that is the first thing I notice every time I see the interfaces. I wonder how they would look if someone tried to redesign them in a visually pleasing manner.
The difficulty of use also strikes me, and I have to wonder if this bothered Schneiderman as well. In the FilmFinder, the mapping between the (only partially aligned) buttons and the colors is difficult (color in a little box above the button needs to be mapped to the text, representing the genre, listed on the button). No matter the number of items on the screen, each is a tiny little rectangle that is exceedingly difficult to click on (especially using interfaces like a touchpad mouse). That problem is even worse with the tiny diamonds on HomeFinder. When the number of movies increases, the problem is exacerbated as movie titles disappear and the precision required to find details on a specific movie increases dramatically. Also, the box describing the movie then obscures part of the visualization. Again, the visualization was still revolutionary, but these things bother me every time I see it demonstrated.
Simon Tan - Oct 01, 2008 03:33:21 am
I recognize the Gulf of Evaluation/Execution material from a User Interfaces course, and I'm sure it can be found in any course where user interaction is involved in any way. Donald Norman's basic conceptualization of how humans interact with foreign systems (I suppose this could include other humans as well!) are a clear, succint way of pointing out what needs to be considered in the designs of such systems. The goals of minimizing those two gulfs underlie all that is considered 'good' in interaction design.
I have seen Dynamic Queries used in many web applications (any application with a live slider qualifies), but I rarely find Brushing and Linking used. That is a shame, since I really enjoyed seeing it in action and felt that it was a natural extension of what your hands do on a monitor screen when faced with a complex visualization of data, like a scatterplot with too many points - that is, many of us will point at one piece of data with one hand while comparing it to a related data plot on another graph marked by another hand. If these two data points referred to the same thing, it would be so much easier to have the software highlight them together, as we do with our hands floating across the monitor.
Calvin Ardi - Oct 07, 2008 04:27:38 pm
@Seth I share the same sentiment; HomeFinder presented new techniques and interactions at the time, yet the interface is a bit cumbersome to use. Even so, for an application that was made in 1992, we've come a long ways in terms of the actual graphical ability to display things with more colors and in a lot more aesthetically pleasing matter (and consumers/users certainly demand it). It would be interesting to know if such a product was developed any further (during that time) and used for actual home finding, or if it was more of a conceptual piece than anything.
As Jeff mentioned, HousingMaps is akin to HomeFinder; I've used it a few times myself when looking for available apartments. It does the best it can with respects to the data given, but sometimes a few housing opportunities are missed as the craigslist poster doesn't include all the necessary information (street intersections as opposed to the actual address, or just blatantly not including any information). It would be interesting to see if it could gather data from the various apartment owner's websites as opposed to just craigslist (off-hand, an RSS feed wouldn't be a bad idea, either).
Bertin's Postmortem of an Example was great in showing the process from start to finish. A data table with useful information contained within transformed, step by step, to a chart that's easily readable. It was rather clever that all the rows were on individual cards of paper and could be manipulated in different ways (...the mobility of the image). This, if not already implemented, would be a neat feature to have in the visualization software used in assignment 2. Perhaps even a "shuffle" button would allow for a random arrangement of the different rows to pick out sets or patterns.