current page



Lecture on Oct 14, 2010.

Tutorial by Vadim Ogievetsky.


For anyone interested in the simple projects that was developed during class complete with the browsers dataset you can now get it here: Tutorial (zip), Slides (pptx).



wulabs wrote:

I like this tool - It will get some getting used to, but seemingly the initial learning curve to get started is quite low. I've already played around with the simple graphs but would like to see a more scalable way to plug in data without having to define it in the javascript. Perhaps an ajax JSON call to a REST server so it can pull a lot more data?

emrosenf wrote:

Protovis looks great! I wish I had known about it last time I had to create js charts. I've used highcharts and flot before, but protovis looks pretty promising. Have you thought about commercializing it?

mariasan wrote:

I'm super excited for this tutorial, I've seen so many cool visualizations made in Protovis! @wulabs I actually heard that the learning curve is steep-ish, but then it's great.

msewak wrote:

Protovis is a great tool, I played around with the maps a little ( and it was really fun! Since we can choose our own datasets for assignment three, I wanted to point out

vad wrote:

Hi everyone, I woud like to plug for the ProjectPartners page. If you are looking for group partners then please post your idea there so people can contact you.

@wulabs: Protovis and Ajax JSON calls go together hand in hand.

iofir wrote:

I love how flexible this is. It's like programming without the overhead. cool stuff. btw: since everyone is posting recommendations for datasets (for the project) I thought I'd contribute. check out ( it's a great resource for complex data.

gneokleo wrote:

protovis looks like a very useful tool and i'm excited to learn how to use it. Like the paper says i think it really nails the "expressiveness" part since it offers so much flexibility. I guess I'll have to start using it to judge on the "efficiency" part but I'm assuming it will take some getting used to at the beginning. I used JFreeChart before which was quite expressive but still a bit limited on the types of graphs you can do.

trcarden wrote:

Like most people in the class i am quite exited about working with Protovis. However i was left looking for the documentation. Its just a quick link from the examples :

Also if you were confused with the curried/higher order functions/functions that look like variables .... check cs 242 (programming languages class) lectures on scpd and the class website as it might be helpful (we just covered curried functions and some javascript idiosyncrasies (scoping can be confusing!).

Its a useful class and goes into depth on the constructs of the javascript and haskell programming languages .

yanzhudu wrote:

I need to dig up my Javascript tutorial. Javascript + protovis offer flexibility. I hope there is some sort of visualization library that can make programming easier.

avogel wrote:

As to the learning curve, I used protovis for assignment 1, and found it rather tricky to get it to do exactly what I wanted. For the first assignment, I would have been better off with a tool I was more familiar with, or a combination of protovis and image editing software.

In defense of protovis, though, I haven't done any appreciable web programming or javascript in years, and I was hacking based off some demos with limited time (probably on the order of hours). In addition, the tutorial today filled in some of the gaps that I was otherwise hacking around, so I'm fairly confident that with only a little bit more practice I could express what I wanted in protovis better. Combining the available example code with today's tutorial should result in a dramatically less steep learning curve than one might fear.

Also, as Vadim said, using the debugging capabilities provided by the browser is key - Google Chrome's "Inspect Element" was invaluable.

gdavo wrote:

Are we supposed to comment the tutorial readings/lectures as well? I mean, do you want to read 20 times "Good job! / That looks cool! Yay! / Javascript suxx :(" ?

msavva wrote:

From what I see so far Protovis looks extremely versatile and powerful. There's probably not many visualizations you can think of that are impossible to represent. I wonder how much of this versatility translates over to interactivity (i.e. are there any elements that cannot be interactively controlled?)

In an unrelated note, I recently ran across this extremely interesting "Periodic Table of Visualization Methods". It could be a very useful chart when trying to explore Protovis's capabilities.

rparikh wrote:

Something that we talked about briefly in lecture that might be of interest: you mentioned how JS will append semicolons to the end of your lines if you decide not to type them. This is true. However there are situations where you should be careful about how you choose to ignore semicolons. If for example you decide to write a statement like:

return {

  • stuff


in some browsers the JS interpreter may mess this up. Instead of returning that code block, it may append a semicolon to the end of return (thus terminating that function) and treat that block as an anonymous block. Instead, you should put that curly brace on the same line:

return {

  • stuff


This is very annoying, sure. Also I would recommend not omitting semicolons in general because there's no reason to other than laziness, and it can end up hurting legibility and stuff.

rparikh wrote:

Can't edit for some reason. The above comment should read:



  • stuff


for the first code segment.

acravens wrote:

I share the general enthusiasm about Protovis, but I think what I was drawn to was some conceptual similarities with CSS/markup languages.

I also really like the Visualization Zoo optional link and was curious to what extent folks have been sharing visualizations with colleagues not studying in this area? I have an ongoing discussion with a couple of folks about topics in the class and the Visualization Zoo is a nice link to refer people to. Nice complement to that periodic table of visualizations linked to above.

ankitak wrote:

Probably one of the most powerful features of protovis is that it does not limit the power of JavaScript! The ability to be able to use other libraries and methods make it extremely extensible, portable, and easily maintainable amongst other things!

Also, @msavva, the period table is brilliant. Though one could argue that it might be incorrect to strictly classify visualizations into different categories, it does provide a good insight into various types of visualization methods.

sholbert wrote:

First of all, Vadim is hilarious. Secondly, I love how cleanly protovis works with javascript. I like how concise the notation is where you continue updating the same object that is returned with every call.

The only main shortcoming of Protovis that I noticed was the lack of animation features. It seems that this is the only thing for my use case that Flare offers over Protovis.

abhatta1 wrote:

The inspect element tool seems to be great. Lack of great animation might be a problem and should be included in protovis.@msavva-the periodic table for visualization seems really cool !

selassid wrote:

I like that the nature of making protovisualizations requires you to think "in the right way." That you're given the option at every step to link a dimension or position of a mark to data values, and that the code is mostly just expressing what connections you want to have, not having to specify how to actually draw each of those dimensions. At first when Vadim was making a bar chart and all of the bars were on top of each other because we didn't specify how to place them, I was annoyed that you had to be explicit about such an "obvious" operation, but it was a good learning experience just to realize how many hidden dimensions are in a picture by having to explicitly specify them. Cheesily enough, I now feel like I now know the bar chart better.

rakasaka wrote:

I'm going to try to develop a visualization application for a research project and I was trying to compare Protovis with Flare - it seems like both do their thing well somewhat independently of each other, and I'm excited to try them both out. Makes Google Charts API feel really boring!

felixror wrote:

I think Protovis serves as a very suitable complement of what Tableau is lacking. Tableau is a wonderful tool but doesn't grant user much low level control over creating customized visualizations. I am looking forward to using Provtovis to create more expressive visualization!

amaeda10 wrote:

One suggestion for the tutorial page. I was trying to use Protovis before Vadim gives a talk, and had a problem of using it. (I had some experience of web programming, but not with javascript.) The thing I got stuck was where to put the example code and how I display it. The mistake I made was putting the example code in the protovis code, not in the html file. I know that there are so many documents about how to use javascript, but if I want to spread protovis in the public, then I will put some simple explanations about this kind of really really basic stuff.

Also, I thought that Protovis is some sort of an application at the beginning. But actually this is just a chunk of javascript code. This is also the point people may get confused.

anomikos wrote:

Hmm. Apart from being an interesting framework to visualize stuff Protovis seems to have attracted some good attention so far. I couldn't have thought of a better application for protovis than as a front-end for R. As far as Flare is concerned. Why bother ? Steve Jobs will eradicate Flash by himself !

skairam wrote:

I just wanted to mention that I thought Vadim did a really great job of presenting Protovis, walking us through the code, and pointing out potential pitfalls.

amirg wrote:

Thanks Vadim for the awesome tutorial!

I also want to comment on the language/tool evaluation from the Protovis paper. In general, I think it is hard to evaluate a toolkit and I thought that the paper had a very interesting approach in identifying a set of criteria that makes for a good visualization tool then evaluating Protovis in comparison to Flare and Processing with respect to that criteria. This sort of qualitative evaluation seems to me to be very useful in a number of ways, because it lets you understand the relationship of the different tools to each other. On the other hand, I found the quantitative evaluation (where the number of lines of code necessary to create a particular visualization was computed) not as compelling. One reason for this is that I think the number of lines of code can be, but is not always, a good indicator of quality. For example, it often makes sense to write more lines of code to make things clearer for a human reader of the code. As we saw in the tutorial, each line of Protovis code was quite dense and takes a bit of picking apart before you fully understand what's going on. I'm guessing this would get easier as I get more used to the language, but could also get harder for more complex visualizations. Long story short, I found the metric of number of lines of code to be an intriguing metric, but I guess it can make sense in the context of having an expressive tool for visualization design, while remaining as concise as possible (and Protovis is indeed concise compared to Processing).

jsnation wrote:

I want to thank Vadim as well for the great Protovis primer in class. Not only that, but I think the general javascript tips and pitfalls to avoid will be really useful for those of us that haven't worked with JS before (like me!). I really liked the whole idea that certain items (like the bars or lines) are actually manager type classes to allow you to quickly and easily make those graph types. I also thought the whole Scale class will be really useful for making the graphs look nice.

andreaz wrote:

Thanks so much to Vadim for the awesome lecture on Protovis and his general JS tips. His humor really made the important points stick. The Protovis recreations of the historical visualizations on the Examples page are very engaging and really demonstrate the language's potential. Also thanks so much to everyone who has posted links to dataset resources on this page. I have a few more I'd like to add:

jtamayo wrote:

As mentioned in the Bostock & Heer paper, protovis is an embedded (internal) domain-specific language. For those not familiar with the term, here's a couple of links:

jdudley wrote:
adh15 wrote:

As I worked through the Kosara tutorial, I noticed that when Protovis bars that are not pixel-aligned they become blurred along the edges. For fixed-length data sets, this is easy to solve by using integral values for the size and positioning of each bar, but if you have a fixed visualization size with variable length data (as in the earthquakes example), is there a good way to avoid the blurring? Math.floor() on calculated bar widths and spacings helps, but you can still end up with unused space.

arievans wrote:

Like many others, I was confused about whether we were supposed to comment on this lecture, but it appears that people are so I will throw in my 2 cents.

Javascript is a really powerful language and I'm excited to see such an incredible tool at our disposal to use with it. I'm wondering if there are any sort of established best practices for data. Are there data sets whose sizes may be too large to have reliable performance in the browser?

This question sort of follows up with my questions in class about the use of the data. I guess in general I am impressed by the visualization capabilities enough to believe that what I need is all there already, so I'm focusing more on the data aspect for now till I get my feet wet with the library.

jbastien wrote:

Protovis is definitely powerful and easy to use, but I'm wondering what its downsides are as compared to other JS visualization tools.

ericruth wrote:

In relation to @felixror's comment: I completely agree that Tableau and Protovis seem like very compatible tools. It would be really convenient if there was some way to export Tableau visualizations into Protovis (or other more detailed visualization tools). Seems like it would it be a good way to learn about Protovis by example as well as reduce a lot of the repetitive set-up involved with a more fine grained tool like Protovis. Does anyone know of any tool that does something like this?

ericruth wrote:

In relation to @felixror's comment: I completely agree that Tableau and Protovis seem like very compatible tools. It would be really convenient if there was some way to export Tableau visualizations into Protovis (or other more detailed visualization tools). Seems like it would it be a good way to learn about Protovis by example as well as reduce a lot of the repetitive set-up involved with a more fine grained tool like Protovis. Does anyone know of any tool that does something like this?

ericruth wrote:

In relation to @felixror's comment: I completely agree that Tableau and Protovis seem like very compatible tools. It would be really convenient if there was some way to export Tableau visualizations into Protovis (or other more detailed visualization tools). Seems like it would it be a good way to learn about Protovis by example as well as reduce a lot of the repetitive set-up involved with a more fine grained tool like Protovis. Does anyone know of any tool that does something like this?

brandonh wrote:

@wulabs: yes, ajax JSON works great with protovis. Unfortunately, this is the area where protovis documentation is the most lacking, and could most use some examples.

I've had luck with the jquery and prototype JavaScript libraries, though it took awhile to understand at first that my ajax calls were failing because of the same origin policy; every browser was failing in a slightly different way. Once this was fixed, I found JSON-RPC calls to an Apache server running mod_python to work fine, using the jsonrpc python server libraries from

asindhu wrote:

I think this tutorial was very helpful in giving us a good overview of Protovis, so thank you to Vadim. The one thing that I thought might be missing was an explanation of animations or adding interactivity to the visualization. It seems like Protovis doesn't have too much built-in functionality for animation, so if we are going to be making an interactive visualization using Protovis I suppose the idea is to ask for input through the web page and re-render the visualization using AJAX...or is there a better way?

hyatt4 wrote:

Vadim rocks!

.... is it too late for participation :)

jeffwear wrote:

Bostock and Heer claim that Protovis was not designed "to replace existing systems", but rather to serve as a via media between the philosophies and capabilities of high-level visualization systems and low-level graphical systems. Nevertheless, they describe Protovis as incorporating the best of those systems - the accessibility of charting software and analytical tools, and the expressiveness of low-level toolkits - while avoiding their many faults - their rigidity, weight, and/or use of abstractions. Protovis thus seems to me poised to become the ideal general-purpose visualization framework.

Thus, I'd like to consider how Protovis might appeal to the users of those existing systems. It seems likely that toolkit users will take to Protovis insofar as it is both familiar - they'll still be programming - and simplified relative to their existing tools. They will be able to avoid the abstractions inherent in other toolkits while still having low-level control over the form of their visualizations. Indeed, Bostock and Heer present several examples of positive feedback from programmers such as a toolkit author and Mozilla developers.

But I wonder if the users of charting software might be a little more reluctant to adopt Protovis (at the expense of their existing tools). While much closer in ease of use and rapidity of development to charting software than to the toolkits, Protovis yet does not attempt to emulate the most salient feature of charting software: its automation of visualization design. Bostock and Heer note that "creating a chart ... is more selection than creation". Protovis is a creators' tool.

I think it would greatly aid Protovis' appeal to the users of charting software if Protovis would provide some templates or suggested formats to users (if they chose) based on their data. This can be done without resorting to the black box, hands-off strategies of charting software, simply by providing users with the code of the suggested visualizations to further manipulate. Not only would this ease users into creating their visualizations, but as Bostock and Heer note, this would also support the use of appropriate visual encodings. As they suggest, these "low-level building blocks" can assist users in creating effective visualizations without necessarily limiting possibilities for design. And this would allow users of charting software to gain flexibility without sacrificing their guides.

nchen11 wrote:

I am curious to know if there is any particular reason that Flare was chosen over Processing ( as the second framework to show in class. I mention Processing in particular (as opposed to some other visualization tool) since it was one of the three toolkits that were evaluated for performance comparisons in the Protovis paper (the other two being Protovis and Flare).

Was this an arbitrary choice or something more involved?

esegel wrote:

Jeff's paper evaluates visualization tools on expressiveness ("Can I build it?"), efficiency ("How long will it take?") and accessibility ("Do I know how?"). I want to answer these questions in choosing between ProtoVis and Flare. However, I have no grounds for evaluating the two packages in terms of these questions.

Along the lines of these questions, it seems like there should be an application written for ProtoVis that allows you to quickly and easily produce visualizations based off standardly-formatted datasets. Does this exist? For example, IBM's ManyEyes has a very simple interface for quickly importing data to a few standard displays—something like a "plug and play" model. My guess is that most visualizations use the same basic ingredients, so it seems best to start with a ton of defaults built into an application and then have the user strip them away as needed (e.g. excel) rather than start with a hyper-flexible framework but nothing to show for itself on the onset. Of course though, this will depend on the complexity and uniqueness of what you're trying to achieve with the tool, your level of coding comfort, and how long you have.

nikil wrote:

I think that the protvis is a very interesting way of designing a toolkit, but im not sure how i feel about the style of coding required. If you are familiar with javascript this is not terribly difficult, however if you are new to it, I could see this paradigm as being very confusing. @nchen11 - Prof. Heer made Flare

sklesser wrote:

After working on our final project focusing on interaction with Protovis, I've become supremely impressed with this library. One thing to note for people trying to do a dynamic evaluation of generated Protovis code (for instance a text editor that updates the Protovis code), using the javascript+protovis script is often not an option since nested script tags are not generally supported so you may have to restrict yourself to using javascript script instead of javascript+protovis. This means you have to write out properly formatted functions such as function(d){return d[0];} as opposed to the function(d) d[0] you can do with javascript+protovis (which is used in all the examples on the Protovis web page).

Leave a comment