From CS294-10 Visualization Sp11

Jump to: navigation, search

Lecture on Feb 28, 2011



  • Protovis: A Graphical Toolkit for Visualization. Bostock & Heer. (pdf)
  • Check out the protovis website and read the examples/documentation.
  • Software Design Patterns for Information Visualization. Heer & Agrawala. IEEE InfoVis 2006. (html)

Optional Readings

  • prefuse: A Toolkit for Interactive Information Visualization. Heer, Card & Landay. ACM CHI 2005. (pdf)
  • Building Highly-Coordinated Visualizations In Improvise. Chris Weaver. IEEE InfoVis 2004. (pdf)
  • Past, Present, and Future of User Interface Software Tools. Myers, Hudson, & Pausch. ACM TOCHI, March 2000. (pdf)
  • An Operator Interaction Framework for Visualization Systems. Chi and Riedl. In Proceedings of the Symposium on Information Visualization (InfoVis '98), pp. 63--70. IEEE Press, 1998. (pdf)
  • Flare tutorial, Heer (html)
  • 2D Graphics Primer (useful for those with little experience in 2D computer graphics)

Siamak Faridani 00:46, 28 February 2011 (CST)

More than anything I was impressed by how they have used javascript to build protoviz. As a follow up to Jeff Heer's comment about feasibility of building a ggplot2 interpretor in protoviz I contacted Hadley Wickham (the author of ggplot2 and plyr in R) he believed that ggplot2 is so tied to R that is would be easier to start a project in protoviz with a new grammar than to port ggplot2 to protoviz. There are also some efforts online to implement ggplot2 on top of protoviz and they are all bulky tools that are not even close to be completed.

It seems to me that as much as we would like to deny it the choice of underlying language hugely influences the capability of the visualization tool.

Julian Limon - Feb 28, 2011 05:57:40 pm

This is totally unrelated to today's lecture, but I had to share this [infographic of infographics |] that was shared in the I School email list. Like Jessica said, this graphic makes fun of the most common techniques that make visualizations aesthetically pleasant but at the same time make them lie.

Speaking of the lecture, I agree with others who posted. Jeff Heer gave a fantastic lecture of the reasoning behind Protovis and the motivations that his team had. It definitely fills a gap between tools like Excel and Tableau and languages like Processing. Initially, I felt it was a step back to focus on the visualization first--I guess I was used to Tableau's approach that is based in the data. But after the lecture I realized that it gives the designer much more possibilities. Specially when creating dynamic visualizations, the amount of effort that is put into developing a visualization that conveys the information right will pay off.

Saung Li - Feb 28, 2011 07:56:34 pm

After reading the Protovis paper and browsing through the site, I got pretty impressed by the example visualizations shown. Programs like Excel and Tableau are high level enough that it feels like I'm working directly with the data, so they are easy to use. Protovis relies on programming to generate the visualizations, so it may seem like I might be bogged down by the technicalities of the language and not be able to focus on the graphics. However, it does provide more flexibility in visualizations while not being too low level. The chaining of method calls is a useful technique as it works intuitively and looks clean; it would be great if this can be applied to other languages, as I can see it fitting in them. I still think programs like Tableau are more useful overall as it can quickly generate visualizations that are most commonly used. If more options like interaction can be added without requiring much programming, that could greatly increase user productivity.

Dan - Mar 01, 2011 12:23:41 am

Protovis seems like a great tool. Specifically, I like how they aren't trying to replace other visualization software, but instead address needs that are not currently met. The structure of the code seems to provide a lot of flexibility, in particular, the use of marks, anchors, panels, and data transformations. The box model that they use is great because they aren't reinventing the wheel, they are using one of the most popular coordinate systems, the CSS box model. The fact is, Protovis is extremely integrated with the Web and associated technologies, really providing an interface that can be used by thousands if not millions one day.

The main goal of providing a visualization software that is expressive, efficient, and accessible is brilliant. There are so many people in this word with great ideas, but are unable to realize them due to the gap between their technical skills and their ideas. Protovis' goal is to reduce this distance to enable people to actuate their ideas quickly without too much pain.

Javascript is also a great interface for protovis. The inheritance looks great and the feature set is clean and fully-featured.

The Design Patterns paper presented a plethora of design patterns for presenting data visually. The fact is, not one can be applied to all problems, so knowing each as a solution will greatly help any visualization programmer. Figure 14 is a great way of tying all of these models together, and knowing when to use a particular model---a very useful diagram.

Michael Cohen - Feb 28, 2011 10:10:43 pm

Jeff's characterization of protovis as "stylesheets for data, except that the styles can be a function of the data" was helpful. Having done quite a bit of CSS, I think I had somewhat subconsciously picked up on the similarity but it's clearer to me now that it's explicit. Some of the inheritance mechanics that seemed a bit magical to me are clearer now as well.

I've been thinking about Jeff & Mike's goal of finding a middle ground between expressiveness and efficiency, and therefore targeting a group (web developers) that have some familiarity with structured presentation and javascript, but are not full-fledged software engineers. It makes me wonder how much expressiveness we might be able to retain if we put a web application facade in front of protovis and let users assemble visualizations from marks while shielding them from most of the code. I'm picturing something where each mark gets a box on the page where you can specify its properties. Some common options (e.g. "every X pixels" for position) are available in a suggestion area underneath a property as you edit it. If you do type your own expression, you can use your data's field names without having to type the d. and the application would add that in, as well as the function(d) as needed. Perhaps you could drag one mark's box onto another and they would stick together, setting up an inheritance relationship.

Certainly, you'd lose some expressiveness if you don't allow the full range of javascript, but I think you could retain the fundamental flexibility that sets protovis apart from something like Tableau but have it be accessible to non-developers (or have it set up a scaffold that developers could then customize). Might be an interesting final project for someone...

Michael Hsueh - Mar 01, 2011 12:25:41 am

What a fantastic talk today given by Jeff Heer about the Protovis project! One sticking point for me came from Jeff's compelling justifications for going with a declarative nature in the toolkit. I never explicitly considered the importance of being able to produce multiple, rapid examples of different visual styles when thinking about tool kits. It was usually more of a question regarding the feasibility and how easy it is for a given framework to produce a certain style. Protovis facilitates a more data-centric/visual-design way of thinking, which translates roughly into conciseness and much easier experimentation with different visual styles.

Jeff did mention potential limitations in visual expressiveness (though the provided primitives are sufficient for most purposes). I don't find this as much a concern as performance during interactive sessions, whether that is related to rendering or data processing/scalability. Is the toolkit suited for handling large amounts of complex shapes (presumably defined using line primitives) and associated statistical data (I'm thinking visualizations of geographic USGS data)? It is probably a difficult problem in any case, but such challenges have traditionally been best addressed through imperative approaches.

I agree that the main body of mainstream visualization media work will depend on tools that occupy the midway point between low-level and madlib-like frameworks. Protovis occupies this part of the spectrum nicely, along with other rapid prototyping tools such as Processing, which has a slightly lower-level approach (but is of course supported by visualization plugins).

I thought the paper on visualization design patterns was important. We don't want to constantly reinvent the wheel, and a survey of widely used patterns helps in this regard. Many of the patterns are familiar to me (camera, reference model) due to prior exposure to graphics APIs or other frameworks. Some others were new and interesting to me, such as the relational graph. I'm sure I've encountered it academically at some point, but lacked familiarity with it in practical contexts -- that is, until learning about visualization software.

Jvoytek - Mar 01, 2011 12:31:37 pm

Julian, love the graphic (although I think it obviously oversimplifies the challenges in infovis for comedic effect). I think the point is, it's easy to make a visualization that looks good but the challenge is making it look good, and mean something. It's interesting that the designer decided not to address some of the topics Tufte covers like color choice, and data-ink ratio.

Matthew Can - Mar 01, 2011 01:48:39 pm

I agree with Michael Hsueh's point about the performance of Protovis. I'd also like to know how well it scales because I noticed some lag with the interactive visualizations on the demo page. As Michael suggests, imperative approaches can address this, but I think that trades off the system's accessibility. Another approach, one that is transparent to the designer, is to run an optimizer after the user has declaratively specified the visualization. However, I'm not sure how feasible this approach is.

Regarding the design patterns for information visualization, I liked how Heer and Agrawala's work extended the design patterns of others and situated them all in context. It's given a lot of structure to my understanding of info vis design, much the same way software engineering design patterns have.

I'm also glad Heer talked about the Wrangler data transformation system. It's a great demonstration of how HCI approaches to a problem can get us closer to a solution when machine learning just isn't good enough. And finally, I like that Heer closed his talk by situating Wrangler and Protovis in the greater context of the data life cycle, how these systems address parts of a bigger problem that spans HCI, visualization, databases, and data mining (and probably other fields I'm forgetting right now).

Brandon Liu - Mar 01, 2011 06:51:16 pm

I really enjoyed Jeff Heer's talk on Protovis, especially how it presented each of the design decisions as evolving towards making a more expressive and concise visualization toolkit. The paper mentioned creating a development/prototyping environment for Protovis sketches, kind of like processing. I think this would go a long way towards bridging the gap between web developers and Protovis, especially since debugging JavaScript isn't the easiest. Someone mentioned adapting Protovis to work with R; i would be interested in working on that project.

The paper on Protovis also introduced me to the Cognitive Dimensions of Notation method for evaluation. I found a walkthrough here:

Also, I was really impressed by the DataWrangler project and its potential to replace tools used by both individuals fiddling with data, and organizations who use commercial ETL tools. Some limitations for DataWrangler in practice are to build a sufficient library of operations, and to generate fast scripts to crunch lots of data.

Sally Ahn - Mar 01, 2011 10:04:54 pm

I also greatly enjoyed Jeff Heer's lecture about Protovis. The many examples presented in the paper as well as its website shows the toolkit's impressive breadth and depth of applicability to numerous datasets. As mentioned in the paper, the type of visualization are often picked on how easy it is to produce with the available tool, rather than how appropriate it is for presenting the data, and I think Protovis makes an important contribution by addressing this problem with a user-friendly and complete visualization toolkit. I was also impressed by the Data Wrangler we saw at the end of lecture. Manipulating noisy data is definitely a tedious task, and I really liked how the interface tries to automate the task safely by providing suggestions of the interpreted pattern to the user rather than making dangerous assumptions.

The design patterns paper was a great overview of the technical details behind implementing visualization tools. The authors' make an astute observation that "research literature often place more emphasis on novel features than on recurring design patterns," and I think they pressent a valuable information resource to facilitate future work in visualization.

Thomas Schluchter - Mar 01, 2011 10:32:14 pm

I agree with everyone: That was a fantastic lecture, and about very impressive work at that. I found the "graphical" approach to visualization much easier to understand when Jeff talked about it compared to reading about Protovis on the website. The idea of decomposing a visualization into its visual properties and then constructing the code to generate them is very interesting. The reason why I think this complements software like Tableau so well is that it allows (forces?) the author of the visualization to consider whether his or her design choices make sense. Protovis assumes that one is familiar enough with the data to make decisions about visualization techniques, and it makes the process of selecting these techniques more deliberate than just spitting out a standard bar chart. Therefore, it makes a lot of sense to say that Protovis is for visualization "designers". (That does raise the question how data-savvy one needs to be to make visualizations...)

Total aside: As Jeff discussed the similarity of Protovis and stylesheets, I remembered all these times when I wished CSS would accept lambdas with access to the DOM as input :)

David Wong - Mar 02, 2011 01:17:11 am

I enjoyed the talk from Jeff about the nature of visualization systems and how Protovis filled a specific gap in that area. It really help put the spectrum of visualization systems in perspective, which helps inform judgements on what is or isn't a valuable contribution to the literature. I found it particularly inspiring to hear about the design of Flare versus the design of Protovis. Having used Flare, I very much understand the motivation to design a system like Protovis. Also, I found the inheritance and SVG components in the design of Protovis to be particularly elegant. Jeff was saying that his future work included adding a GUI on top of Protovis. I think that a system with a Protovis-like declarative language under the hood and easy to manipulate graphical objects that represent the marks could cater to less computer science savvy users.

Michael Porath - Mar 02, 2011 12:19:03 pm

Having played around with Protovis for some time, Jeff's talk proved me that I was missing the fundamental principles of Protovis. His quick walkthrough made clear to me how the framework is best used and what the design goals were. Specifically, three points stood out that weren't clear to me working through the examples: (i) the hierarchical inheritance of properties, (ii) that every further parameter that is being passed to a function argument refers to one element further up in the hierarchy, (iii) Seeing the .add methods as factories.

Karl He - Mar 02, 2011 08:06:25 pm

While using Protovis is by no means a trivial feat, the design of Protovis is excellent. It recognizes its domain very well, making a language that is easy to place in a webpage as well as having a language that is easy to understand for web developers. The comparison to other toolkits illustrated the difference quite well, especially when compared to Processing which is chock full of for-loops, and a lot of pre-processing before calling the graphing function.

[add comment]
Personal tools