Authoring Visualizations in Protovis/Flare

From CS 294-10 Visualization Sp10

Jump to: navigation, search

Lecture on Feb 22, 210

Contents

Readings

  • Protovis: A Graphical Toolkit for Visualization. Bostock & Heer. (pdf)
  • Check out the protovis website and read the examples/documentation.
  • Flare tutorial, Heer (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)
  • Software Design Patterns for Information Visualization. Heer & Agrawala. IEEE InfoVis 2006. (html)
  • 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)
  • 2D Graphics Primer (useful for those with little experience in 2D computer graphics)

Demonstrations

DavidZats - Feb 21, 2010 06:45:48 pm

The readings discuss Protovis and Flare, two software tools for creating visualizations. Protovis was designed to strike a balance between the two existing types of tools: high-level tools such as Excel and low-level tools such as Illustrator. As the authors note, the former type of tools is very rigid and is only effective at presenting a predetermined set of chart types. While the latter type is very flexible, the process of using it to create a visualization is very tedious. Given the limitations of each type of software, the authors propose Protovis, which attempts to be flexible enough so as to avoid limiting the user, yet powerful enough so as to avoid being tedious.

Flare, on the other hand, takes the different approach of using a higher-level language. While it does seem that it would take a longer time to learn Flare because of the additional abstractions, it does not seem to be overly restrictive. Additionally, while both of these tools are capable of performing animations, a cursory look seems to indicate that Flare provides a stronger support for them.

Danielle Christianson - Feb 21, 2010 10:25:24 pm

I like Bostock and Heer's framework for thinking about the success of a visualization tool: expressiveness, efficiency, and accessibility. However, I do not think this framework captures what Bostock and Heer consider to be perhaps the most important question: the effect on the creative process. Maybe something like easy of manipulation... Generally, Protovis looks really useful, especially in comparison to Flare. Some of the best aspects in my opinion are that it is open source and has relatively simple grammar. The former is likely the reason for the huge recent growth of R in the ecological community (and others) and thus could rapidly increase occurrences of better visualizations. The latter makes it approachable. Finally the examples on the Protovis website are aesthetically stunning -- I am interested if this is because of Heer's background in visualization or if the software inherently contributes. Bostock and Heer allude to a similar tension in the article -- whether or not users can be encouraged to produce good visualizations with examples and low-level building blocks (pg. 8). For me, this begs more / better visualization education at all levels.

Jeffrey Patzer - Feb 22, 2010 12:51:13 am

So after reading this paper, I can't help but think of Protovis as programmer's version of Tableau. While Tableau allows one to play with the data through direct manipulation, Protovis allows you to play with the data through programming. I think that each system has its pluses and minuses, but that Protovis might have a less steep learning curve. Since Protovis allows you to break down your visualization into component parts and manipulate your data a little more effectively (Tableau only imports from what I saw), I think Protovis might be a good compromise for those wishing to create strong visualizations without having to employ drawing programs.

Mason Smith - Feb 22, 2010 11:55:33 am

Though I really liked the idea of Protovis (and can't wait to use it at some point), I was unconvinced by the case studies and comparisons present in the paper. Processing, Protovis, and Flare all seem to be at sufficiently different levels of abstraction (as opposed to merely different *types*) that comparing them is apples-to-orange(-to-bananas). A quick Google search suggests much better tools to compare Protovis to.

Jon Barron - Feb 23, 2010 04:12:24 pm

I really like the idea of Protovis, but I can't help but feel that my demographic (people who are already familiar with programming languages that have visualization capabilities) is not really addressed in this paper. Packages like Matlab seem to have just as much capability as Protovis. Protovis may be slightly more terse and therefore requires less effort in implementation, but there's certainly a substantial learning curve that I'm not very keen on. Especially unappealing is the fact that Protovis's capabilities are nearly guaranteed to be a subset of Matlabs, which can be bothersome when attempting to do non-trivial mathematical transformations of the data while visualizing it. I would greatly prefer is Protovis was produced as a package within some other fully-featured programming language, such at Matlab or Python.

Akshay Kannan - Feb 23, 2010 09:12:41 pm

Having used Flare in the past to implement graph visualization for database schemas, I can personally attest to the ease of use and power of this framework. Rather than traditional visualization methods in Matlab or PyGraphViz, the scripting web-based interface for tools such as Flare and Protovis give it a huge potential for viewing live data or allowing users to dynamically interact with graphics. An example I found particularly intriguing was the integration with the Google Maps API for Oakland Crimespotting: http://vis.stanford.edu/protovis/ex/oakland.html By combining with existing web API's and other resources, Protovis provides a whole new level of empowerment for visualizers. To make a database analogy, these API mashups are effectively a "join" across different resources that can allow users to synthesize new information.

Zev Winkelman - Feb 24, 2010 01:00:22 am

I'd like to echo John's comment about the demographic. Though the toolkits have evolved to serve various balances of fine grained control vs. higher level abstractions, and in so doing allowing for various levels of flexibility and productivity, I personally have a hard time embracing them instead of the low level languages I already know.

One interesting case where this might not continue to hold for me personally is in the area of 3D graphics, which I have yet to establish much fluency. Toolkits that allow me to ramp up in that area might be easier for me to resolve myself to learning.

Another interesting case, discussed in the papers, is the evolving nature of human computer interaction. As we move beyond the desktop platform standard of the last few decades, and start to deal with new interfaces and input methods, solid toolkits enabling use of these inputs and methods, before they become standardized might be helpful. Though, assuming that there will be another convergence or standardization around these new methods and inputs, I'm likely to return to the low level languages and program them directly when/if they expand to allow me to do so.

Finally, and this relates to a question I had in class about having to copy large amounts of data, and dealing with high volume streaming data, I worry about the performance overhead of these toolkits. In theory any unexpected bottlenecks could be debugged by an end user, but if that ends up being frequently necessary, then many folks, again, in certain demographics, might return to rolling there own implementations.

Arpad Kovacs - Feb 24, 2010 01:16:50 am

Responding to Jon and Zev's comments: Programmers who feel comfortable programming in Matlab have no need for Protovis, since they already possess the tools needed to create almost any visualization imaginable with relatively little effort. Instead, Protovis is intended for use by designers who want to quickly and easily create visualizations that go beyond the constraints imposed by Tableau/Excel, but have little/no programming experience. The fact that Protovis is a declarative language reveals its target user group: nonprogrammers who want to describe what they want, and don't care how it happens. In contrast, an experienced programmer would probably be annoyed to find that he cannot customize the control flow of his application, and might prefer an imperative language such as C++ / Java instead.

This is where Flare, Processing, and other toolkits come in: like Protovis, they offer visualization-specific abstractions that decrease development time, while simultaneously offering the power of the underlying programming language. Even if you really like low-level languages, I seriously doubt that you want to reinvent the wheel by writing code to put evenly-spaced tics on each axis and legends for each data series on your chart. There is probably a library somewhere that will do this for you semi-automatically, and the efficiency overhead probably isn't too bad either (sure, there's more bloat, but there's also more people optimizing the code for performance).

So in summary, I see Protovis as an introductory stepping-stone to more powerful languages such as Matlab, Java/Processing, and Actionscript/Flare that allow you to save time while gaining more flexibility. If you are familiar with Adobe's Flash, think of it as the difference between Flash CS4 (WYSIWYG for newbie users) and Flex (MSXML for pros): both let you build flash animations, but they each use a different approach for doing so.

Ryangreenberg - Feb 24, 2010 12:00:42 pm

The first reading I looked at was the overview of Protovis and I skipped to the code samples. Compared with JavaScript charting libraries, like [Flot] its syntax seemed relatively complex to create the same result. After reading the paper explaining the design methodology of Protovis, I appreciated the complexity and realized I was comparing apples and oranges. Protovis is a visualization library--it isn't intended to be a charting library with predefined types a la Excel, ManyEyes, etc. Having expressiveness as a design goal for Protovis was well supported, I thought, by the example that Heer gave in class. Starting with classic, drawn-on-paper visualizations sets a much higher bar for should be possible than limiting your scope to the kinds of visualizations people create when constrained by pre-defined tools.

To Arpad's point above, I'm not sure that a declarative language in general are designed for non-programmers. After all, specifying the problem ("what they want") in a domain-specific language is often a large part of the challenge in creating any program.

Timothy Wheeler - Feb 24, 2010 11:36:25 am

As an engineer, I would personally benefit more from a visualization toolkit that was written in Matlab or Python. But, I must admit that the engineering visualizations I create will most likely end up in the massive databases of harshly compressed PDFs where relatively few people will ever see them. The real market for visualizations is the web, and I think that by targeting web platforms, Heer et al. are on to something. Although the JavaScript+DOM platform has its idiosyncrasies, Protovis puts powerful visualization tools in the hands of the interdisciplinary web development teams that currently have everyone's attention.

Jonyen - Feb 24, 2010 03:11:06 pm

I liked the appeal of ProtoVis for its appearance and the seemingly simple use of the language. I've used Flare before, which I also think has been very nicely done and has a lot of features available. I feel that the bigger challenge isn't so much in information visualization as it is with the manipulation of information. It's difficult to extract data and then be able to play around with it, and there's the whole issue of direct manipulation when it comes to information visualization. ProtoVis and Flare provide some level of power in manipulating the data, but it's not easy to produce a visualization if you're a non-programmer. Similarly, Tableau has a whole set of issues when it comes to producing visualizations, for both programmers and non-programmers alike. For now, I feel comfortable with Microsoft Excel or Adobe Illustrator for basic visualizations, but there's still so much that needs to be done to make it more powerful and more easy to use. I think ProtoVis and Flare are good, but there needs to be a shift away from the language and more into the interaction with the data.

Boaz Avital - Feb 26, 2010 05:48:55 pm

Protovis seems to be a great tool and beautifully implemented. It found a need in the visualization market and filled it, so now people don't have to know about low-level graphics and drawing in order to accurately express their designs. What's especially good about it is that it's easy to build upon. If you want to create one or two fairly simple visualizations, you can use protovis by itself. But if you want to create a whole class of related yet varying visualizations, it's easy to build a layer on top of protovis that simplifies your task and shortens the semantic distance to your goal.

I was really amused at the recreation of classic visualizations in Protovis and think it serves to illustrate its power well.

The ability that Flare has in complex animations is pretty important. Right now, from what I can see, most of the animations are transitional, which is still nice as it helps the user change contexts more easily. However, the possibility for animations to help improve visualizations in other ways is huge, and Flare can, if perhaps not now then easily in the future, take advantage of this.

Ebby Amirebrahimi - Mar 01, 2010 12:29:36 am

I think toolkits like Protovis and Flare are useful bridges between basic data view applications and powerful data processors like Matlab. At the same time, I think it has a very specific target audience. As a programmer, I don't exactly want to learn a new language or give up the power that I can access using Matlab or Java (through Processing). At the same time, Protovis and Flare do emphasize visual appeal and good presentation, which is very important when it comes to creating a front-facing user interface. I think it would be nice if these toolkits were extended to support more mainstream programming languages, not just languages used by front-end engineers. Nonetheless, I'm sure users on the other end of the spectrum appreciate using simpler languages for these tools.

Stephen Chu - Mar 01, 2010 03:17:52 am

I've never programmed visualizations, but I'm excited to try Protovis. I haven't used Prefuse or Matlab, so I can't compare the tools yet. But I agree with the points above that using Javascript for Protovis has important advantages. Sharing visualizations is much quicker as well as more accessible through the browser. I think Protovis does meet its goal of providing a fast tool that can be used by non-programmers, shared quickly to a broad audience, and still remain powerful and expressive. One blog commented on the lack of simple example tutorials. Although some beginner-level examples were provided, I tried searching for more step-by-step tutorials, too. I think more documentation would be very valuable and help attract a larger audience.

Kerstin Keller - Mar 01, 2010 12:39:26 pm

I really enjoyed the lecture that Jeff Heer gave.

I am also very excited to try out Flare for our next assignment, it seems that you can do powerful animations within a reasonable amount of time.

Shimul Sachdeva - Mar 01, 2010 02:37:22 pm

Protovis creates rather appealing visualizations. The lecture showed some pretty cool examples, including the Job Voyager. One area I feel was not touched well was data manipulation. The assignments we've had so far in class seem to suggest that a large part of creating a good visualization is manipulating the data effectively. This requires an easily accessible and manipulative database. Hence, I would expect visualization tools to focus also on data gathering and manipulation techniques.

The documentation on Flex/Flash reminded me immensely of Silverlight. It seems that both have a similar approach towards creating web based applications, i.e., a clear demarcation between frontend/XML and backend/scripts. Although I have never used Flex, I reckon it would be similar in concept to Silverlight. I look forward to working with Flex.

Prahalika Reddy - Mar 02, 2010 05:42:26 am

Protovis software is quite interesting, especially the many different ways data can be visualized. I agree with the claims made in the Protovis paper, about how most chart making software is very restrictive in how the data must be formatted in order to use the software itself. It's definitely true that they are very easy to use, with almost no learning curve, but they aren't very powerful and don't offer much variety.

I looked through many of the examples on the Protovis website, and while many of them are very creative, I feel like they are hard to understand. For example, the visualization, "Burtin's Antibiotics", is very hard to even read. I don't see what purpose the circular form of the chart serves; it could have been done more effectively as a regular grouped bar chart.

However, many of the others are great visualizations. I especially liked the "Polar Clock" because it was very effective in showing the time moving, and captured the essence of a clock.

Jaeyoung Choi - Mar 02, 2010 03:18:21 pm

So far, I've been using tools residing on the opposite extremes, high-level chart type(MS Excel, Tableau) and low-level vector drawing(Illustrator). As I've never used Matlab or other tools residing in the middle of these extremes, Protovis does appeal to me in terms of its efficiency, expressiveness, and accessibility at creating visualization. Examples along with source codes are sufficient to give me notion of what can be done easily.

Priyanka Reddy - Mar 10, 2010 08:10:00 am

I enjoyed Jeff Heer's lecture and seeing all the visualization tools that are available to me. I hadn't known about many of these before and didn't realize they existed. I think the websites for the various tools show some great examples of visualizations, but what I'd really like to know is when to use each one. Each has different strengths and weaknesses and knowing what each is good for and not so good for would really make choosing one much simpler. Another major problem with visualizations is formatting the data appropriately for each tool, a problem that Shimul also mentioned above. None of the visualization tools talk about what's the best way to format the data for that program. In fact, gathering and formatting data seems to be the least talked about when it comes to the topic of visualization, but from my experience so far, is the most time-consuming and frustrating part of making visualizations.



[add comment]
Personal tools