eagereyes

Various VisWeek Workshops

Robert Kosara — Tue, 27 Jul 2010 16:00:10 +0000

I want to call your attention to three interesting workshops that will be held at VisWeek 2010 in October in Salt Lake City. One is on storytelling in visualization, another on visual analytics in healthcare, and a third one on theory in infovis. The deadlines for two of them are coming up soon.

Telling Stories With Data

If you haven't watched the Hans Rosling video yet, you probably haven't realized that visualization isn't just there for data analysis, it's also a great tool for telling stories. Also, you really need to get out from under that rock.

Anyway, the workshop Telling Stories with Data aims to bring together people who are interested in this topic, and want to discuss ideas, approaches, etc. They also have a facebook page that you can subscribe to to get updates, even if you're only planning on attending without presenting.

The deadline for this workshop is August 4, they want a one-page abstract with bio, and you'll get 20 minutes to present at the workshop.

Visual Analytics in Health Care

While medical applications are huge in scientific visualization, they haven't really made their way into infovis and visual analytics. This workshop on Visual Analytics in Health Care is targeted at researchers working with medical records, on drug discovery, pandemic forecasting, etc.

The deadline is August 27, you can submit a paper with up to eight pages. Accepted submissions will be presented as posters or in oral presentations. Authors of selected papers will also be invited to submit to a special issue of the Information Visualization journal.

The Role of Theory in Information Visualization

Last, but certainly not least, is the important topic of theory in information visualization. The workshop I am organizing together with T.J. Jankun-Kelly and Chris Weaver is titled The Role of Theory in Information Visualization. We want to hear your thoughts on what constitutes theory in infovis, what questions we need to address, and how to do that.

We also stole the idea of setting up a facebook page from the storytelling workshop. Thanks for the idea, guys!

The deadline for submissions for this workshop is August 2, with a limit of two pages for your abstract. We will select a number of submissions for three minute provocations, not full presentations. Selected authors will also be invited to submit to a special issue of a journal later.

These are just the three workshops I know of. Feel free to post pointers to others below.

A Protovis Primer, Part 3

Robert Kosara — Mon, 26 Jul 2010 22:12:09 +0000

After covering some Protovis basics in part 1, and some more advanced techniques plus data loading in part 2, this part is devoted mostly to using what we've already discussed in a more complex example. We'll also look at some basic interaction. While Protovis requires more work to set up charts, it pays off when you want to do something beyond the typical chart types, or when you want to add interaction. You are not limited to any fixed set of charts, but can create any combination you want, or even something entirely new.

In this part of the tutorial, we will create a chart showing the lives and office terms of all U.S. presidents. The chart is a basic life lines "waterfall" chart, with a few small twists. A basic version of the chart can be created in your favorite spreadsheet, but making it look a particular way or being able to interact is a different matter.

Here is a small part of it, showing only the last few presidents. Again, if you are reading this in Internet Explorer or a news reader, you will only see static images and not be able to interact. Go to the tutorial website to get a better idea how it works.

Data Preparation

The data used for this example requires some introduction and a bit of preparation. This is what it looks like:

var presidents = 
[
    {
        "name": "George Washington",
        "born": 2353713,
        "died": 2378480,
        "term_began": 2374600,
        "term_ended": 2377465
    },
    ...
]

The dates are encoded in single numbers, using the Julian Date. This date measures the number of days between January 1st, 4713 BC and the given day. That might seem odd, but it's useful in many applications where a simple way of calculating the number of days between two dates is needed (e.g., in Astronomy). For our purposes, it is useful because it translates the rather unwieldy dates into a simple, linear numerical scale.

A slight complication comes from the presidents who are still around. Their dates of death (and end of office term, for Barack Obama) are set to -1. A function at the top of the program inserts today's date for these dates. You will see below why that makes our lives a lot easier going forward (we won't have to handle special cases).

presidents = presidents.map(function(d) {
    if (d.died < 0)
        d.died = today;

    if (d.term_ended < 0)
        d.term_ended = today;

    return d;
});

The map function is one of those functional programming constructs that JavaScript, being a functional language, has. It applies the function given to it to all elements in the array it is called from, and returns a new array containing the results of calling the function. The resulting array has the same number of elements as the one the function was called with. Here, we're replacing the presidents array with a new one which is tailored to the day when the function was called.

There are two functions in the code that convert from and to the Julian date used. I won't list them here, because they're rather technical, but you can find them in the code. The value for the today variable is generated using one of these functions.

var today = toJulian(new Date());

Setup

For the horizontal lines, we'll have to define a scale so the dates can be mapped to screen locations. We're defining a width of the overall chart, and then use a scale (see part 2) to scale the dates from the first date we might encounter (the birth date of the first president) to the last one (today).

var width = 560;

var dates = pv.Scale.linear(presidents[0].born, today)
    .range(0, width - 10);

As you can see here, I took no chances and actually used the .born field of the first element in the array. That makes it easier to subset the array, as I've done for the images in this article. No matter what part I choose, I don't have to update the scale manually (unless I start cutting at the end, so the end of the chart is not today).

There's also a bit of setup for the vertical part of the chart, but that one's simpler. I'm specifying a variable h for the height (thickness) of the bars, and pad for the padding/spacing in between. The total height of each element is h+pad, and when we multiply that by the number of objects in our array, we get the total height we need for the panel (plus a bit of space for a scale at the bottom).

var h = 3;
var pad = 12;

var height = (h + pad) * presidents.length + 16;

And as before, we'll create a panel to contain the visualization, using these variables to size it according to the content.

var vis = new pv.Panel()
    .width(width).height(height);

Life Lines

The lines representing both the lives and the office terms are fairly simple. I'm using the Bar mark here, but you could also use Rules if you wanted. If you followed the previous two installments, this should be fairly self-explanatory:

vis.add(pv.Bar)
    .data(presidents)
    .left(function(d) dates(d.born))
    .width(function(d) dates(d.died) - dates(d.born))
    .height(h)
    .top(function() ((h + pad) * this.index) + pad)
    .fillStyle("#ddd")

We're telling the bars where the data comes from, and how to map it to its attributes. The .left and .width attributes use the dates scale we defined above to map the Julian dates stored in the data to screen locations. The y axis is handled differently, with an explicit calculation. We're using the this.index variable again, like in the bar charts last time, to create a sequence of objects.

The bars are ordered from the top down, so I'm using the .top attribute instead of .bottom. This not only means that I'm specifying a different point, it also changes the coordinate system: 0 is now at the top, not at the bottom (which it would be if I used .bottom). This makes the definition a bit more elegant, but I could do the same with .bottom by subtracting from height.

You may have noticed that the semicolon at the end is missing. This is because we want to attach a label so we know who's who:

.anchor("left").add(pv.Label)
    .textAlign("left")
    .textBaseline("bottom")
    .text(function(d) d.name)
    .textStyle("#333");

Since the anchored label is passed the same data item the original object uses, we have to extract the name attribute. Everything else is just for proper alignment and styling.

In addition to the lives, we care about the presidents' office terms. This works essentially the same way, it just uses a darker shade of gray and doesn't involve a label.

vis.add(pv.Bar)
    .data(presidents)
    .left(function(d) dates(d.term_began))
    .width(function(d) dates(d.term_ended)
                        - dates(d.term_began))
    .height(3)
    .top(function() ((h + pad) * this.index) + pad)
    .fillStyle("#ddd");

So far, we've handled them all the same way, no matter if they are still alive or not. That works because we earlier set the values so that none of them was past today, so none of the bars can go off the right edge. Now, let's add a little indicator to show which ones are still around. This is a thin line that we're adding to the right end of the life line. In the original version, I had a little triangle there that turned the bars into arrows, but that doesn't work very well with these thinner bars.

The line is another bar, this one only a single pixel high. Other than that, the mapping is fairly straight-forward. The only thing to note is that we need a .visible attribute to only show it for those few people who are still around. Also, the .fillStyle has to be different for the president who is still in office. Since the office bar is darker, it only makes sense to also make the extension darker in this case. I will explain the ? operator a little further down, because we'll also use it for the interaction, but basically it's a conditional expression: if the first part is true, it returns the part right after the ?, otherwise it returns the part after the :.

vis.add(pv.Bar)
    .data(presidents)
    .visible(function(d) d.died == today)
    .left(function(d) dates(d.died))
    .top(function() ((h + pad) * this.index) + pad + 1)
    .height(1)
    .width(10)
    .fillStyle(function() (this.index == presidents.length-1)
                                    ? "#333": "#ddd");

So let's look at what we have so far:

Interaction Setup

There are several ways to create interactivity in Protovis. The general way so far has been to put a transparent object over the entire panel (or at least the parts that you want to interact with), catch mouse events, and figure out what to do with them. Protovis 3.2 introduces behaviors, which are much more elegant and specific, but also have their own pitfalls.

The interaction we're going to build is a simple mouse-over that will show some lines to better compare different life lines, and a label showing actual dates. To do this, we'll need to capture mouse events when the mouse pointer is over an object. This is done by specifying a behavior for the entire panel:

var vis = new pv.Panel()
    .width(width).height(height)
    .event("mousemove",
        pv.Behavior.point(Infinity).collapse("x"));

Notice the second line that binds a pv.Behavior to the mousemove event. The definition of the behavior says that we are interested in pointing, and that we do not care if the closest object is too far away (i.e., we're specifying a circle with radius infinity to capture objects). Also, we do not care about the x position, only y, so we'll tell Protovis to ignore that part when looking for the closest match.

This definition passes the events on to individual objects in the panel, which now have to handle them. In this case, because we are specifying a point behavior, the events that our objects receive are called point and unpoint. We'll add a little function to our basic life lines bars that looks like this:

var activePresident = 0;

vis.add(pv.Bar)
    [definition like first one above]
    .event("point", function() {activePresident = this.index;
                                return vis;})

The activePresiedent variable contains the number of the president the user is pointing at. When the object receives a point event, it calls the function we specify, which updates that variable. Whatever that function returns is then repainted. Since we don't want to worry about precise repainting here, we'll just return the entire panel to be updated. With more complex visualizations, it can make sense to only update parts that have changed.

To keep this simple, we do not handle the unpoint event. That means that there is always one active president, making things easier further down.

Reacting to Interaction

Now that we know which president's timeline the user is pointing at, we can do something to highlight it and add some information. This is what we'll do with the label to highlight it: use a darker color, so it stands out more. The only thing that differs from the definition above is the last line.

.anchor("left").add(pv.Label)
    .textAlign("left")
    .textBaseline("bottom")
    .text(function(d) d.name)
    .textStyle(function() (activePresident == this.index)
                            ? "#333" : "#ddd");

Because we are specifying a function, it gets re-evaluated every time the panel is redrawn. So whenever the point event is triggered, it will check whether the label is for the "active" president or not.

The operator used here is a shorter version of an if statement. We could also write the last line above like this:

.textStyle(function() {
    if (activePresident == this.index)
        return "#333";
    else
        return "#ddd";
    });

The first version is obviously more compact, and "more functional" (i.e., closer to the way if works in some functional languages). If used sparingly, this syntax can actually make code more readable. But it easily gets overused, especially when you start nesting expressions; so use with caution.

In addition to highlighting, we also want to have add some vertical lines that help the user compare the lives and office terms of different presidents. To do this, we'll add some Rules.

vis.add(pv.Rule)
    .left(function() dates(presidents[activePresident].born))
    .bottom(0)
    .strokeStyle("#aaa");

This very simply maps the current president's birth date to the x position using the dates scale, and it is also updated every time the panel is redrawn. We'll also add one for the ascension, end of office term, and date of death. Only with the latter two, we want to be careful for those special cases. So we add a simple rule to hide the lines when they are not needed:

.visible(function() presidents[activePresident].term_ended
                                                < today);

The same is done for the .died field. That means that we won't show the lines for those presidents still alive or in office.

Text Label

Now this is all good and well, but what about exact dates and such? Because the interaction essentially centers around one variable, it's very easy to add more things that react without creating additional dependencies. Adding a label that displays the active president's name is as easy as this:

vis.add(pv.Label)
    .text(function() presidents[activePresident].name)
    .left(0)
    .bottom(52)
    .font("bold 12pt sans-serif");

Same idea as above, and the rest is styling. That's not yet terribly useful though, because we're already seeing the name on the life line. But we can just as easily add the life and office terms:

vis.add(pv.Label)
    .text(function(d) {
        var s = "Life: "+dateFormat.format(
            toJSDate(presidents[activePresident].born))+" - ";
        if (presidents[activePresident].died < today)
            s += dateFormat.format(
                toJSDate(presidents[activePresident].died));
        return s;
    })
    .left(0)
    .bottom(40);

The date here is printed using a date format function that is included in Protovis. To use that, we have to convert the date (which is a Julian date, remember) into a JavaScript object. The function toJSDate() does that. If you want to see the specifics of the date format or the function, check out the source code.

But since we are using the Julian date, there is one thing we can do very easily: figure out the age at the time of ascension.

vis.add(pv.Label)
    .text(function(d) "Ascension Age: "+
        Math.floor((presidents[activePresident].term_began-
            presidents[activePresident].born)/365.25))
    .left(0)
    .bottom(20);

The difference between the term_began and born fields is the number of days between them. By dividing by 365.25, we convert to years and even consider leap years (though it's unlikely to make a difference). Finally the value is rounded down to the next smaller integer using the Math.floor() function.

Here is the complete plot including the labels:

And that's it! Interactive visualization in the browser! If you want to see the entire dataset, there is a version of it here in a little virtual pop-up. Also check out the code on github, or download a ZIP file containing the full code and data file.

Multi-touch Brushing for Parallel Coordinates

Robert Kosara — Wed, 21 Jul 2010 01:49:55 +0000

Interaction in visualization is incredibly important, but often more tedious than it needs to be. I have developed a new way of brushing in parallel coordinates that uses the multi-touch trackpads on Apple's MacBook and MacBook Pro laptops for faster interaction. The video below demonstrates the technique, and the source code is available.

This is a little experiment that has gotten out of hand a bit. I recently submitted a paper to a conference that doesn't let me attach additional materials, so I figured I'd put the video up on vimeo and link to it in the paper. I also posted a link on my secondary blog, which got posted on Twitter, and which ended up being blogged by some other people.

If you've used a MacBook or MacBook Pro, you know how simple and intuitive the two-finger scrolling is. Similarly, there are some interactions on the iPhone that are so obvious (like the pinch for zooming) that it's tough to remember how we did things before touch screens. I wanted to create a similar experience for brushing in parallel coordinates.

The idea is to map the axes to locations on the trackpad, and use several fingers to indicate different kinds of brushing. A single finger selects an axis, two fingers let you brush on a single axis. With four fingers, you can brush on two axes at the same time, either on adjacent ones or ones that have other axes in between them. There is also a somewhat unusual brushing method called _angular brushing_, which is very tedious to use with a mouse. Using three fingers, it's very quick and intuitive, and great for finding outliers in the data. You can also flip and rearrange axes.

There are a few details that make this a bit more complicated, because it's hard to maintain the horizontal position during interaction. So there is a certain "stickiness" to the first axis, which keeps it selected even when the fingers move somewhere else. The right mix of stability and flexibility is not easy to find, but I think I'm getting close.

The trackpad is not just a good fit because it's a lot more common than large touch screens (also on some non-Apple laptops), but because it solves an interesting problem you have when interacting with stuff on a touch screen: your fingers get in the way. That isn't always a problem, but in the case of brushing, it is. You don't want to have to change the brush, lift your hands, look at it, put down the hands, adjust, lift again, etc. With the interaction happening on a different surface (and in a convenient location), you can focus on the program's response to what your hands are doing.

The video below demonstrates the technique. It's still quite a different thing to actually try it out yourself, though. It allows for very fast exploration of data, unlike any interaction technique I'm aware of. Using your fingers is not very precise, but that's not the goal here, anyway: it's about getting a feeling for a new dataset.

You can watch the video in HD on the vimeo site. The inset in the lower right is meant as a guide to show what the fingers are doing, not as a part of the actual user interface. People have suggested showing the location of the fingers as an overlay, but when you watch the video you will see why this would be a bad idea: the fingers don't have to line up with the axes, plus the floating dots would be distracting.

I have also posted the source code and there's an executable under the downloads tab if you want to play with it. Be advised, though, that this is a pure research prototype that demonstrates the technique but doesn't do anything useful. The data is hardcoded and the program only lets you brush and rearrange axes, nothing else. The program requires Mac OS X 10.6 "Snow Leopard" and a recent MacBook or MacBook Pro.

Workshop: The Role of Theory in Information Visualization

Robert Kosara — Thu, 15 Jul 2010 03:51:21 +0000

Information visualization is a very applied field that prides itself on its practical applications and real-world scenarios. Ignoring the theoretical side is dangerous, however, because it limits our ability to distill useful information about the foundations of the field from the practical work being done, and limits our understanding of how and why our own creations work. The goal of this workshop at VisWeek 2010 is to bring together researchers interested in the theoretical aspects of visualization, define the field, discuss ideas and approaches, and get the word out about the importance of theoretical research in information visualization.

Topics

There are many different views of and approaches to theory in visualization. We want to discuss them and come to an understanding of what encompasses theory. Topics that the organizers currently consider theory include:

Perceptual research
Design studies
Ways of systematically exploring the visualization design space
Methodological work: how do we do our work, and how can we improve our processes?
Representation, structure, metaphors: how and why do we attach meaning to visual shapes?
Reference datasets and tasks

Also, how do we make it easier to publish this kind of work? What makes for a good theory paper? Can a theory paper stand on its own, without an application or immediate use? Etc.

Structure

The workshop will be based mostly on discussions. We invite speakers to submit short (2-page) position statements. A small number of these will be invited to give very brief (3-minute) presentations at the workshop. The goal is not to present large bodies of work, but to have the presentations spark discussions.

We are also planning a mini-panel, in which the panelists will give short (5-minute) presentations, with an extensive question-and-answer period afterwards.

As an extension of the workshop, we are planning a special issue of a journal devoted to theoretical work in information visualization. More details on this will be coming soon.

Deadlines

Submission: August 2, 2010
Notification: August 6, 2010

Participation

Everybody at VisWeek 2010 will be welcome to participate in the discussions.

We are sending out invitations to people in the field who we consider to be interested in theoretical work. But we want to especially encourage people who may not be well known yet, or who have had an interest in theoretical work but have not published in this area yet, to participate and submit statements.

Date and Time

The conference schedule is not available yet, but the workshop will take place some time during the conference week of October 24 to 29, 2010.

Format, Submission

Submissions have to be in the summary format (same as for posters) and no longer than two pages. We are not looking for expositions of research results, but rather interesting and provocative ideas, position statements, and thoughts about the scope of theory in infovis.

Accepted position papers will be made available online and be included in the VisWeek electronic proceedings.

Submit your paper by emailing a PDF file to the following address:

infovistheoryws@me.com

Feel free to post comments below if you have questions, or use the contact form

Organizers

Robert Kosara, UNC Charlotte
T.J. Jankun-Kelly, Mississippi State University
Chris Weaver, University of Oklahoma

InfoVis Discovery Exhibition 2010

Robert Kosara — Fri, 02 Jul 2010 03:06:15 +0000

Showing the impact of visualization work is not something we as a community are particularly good at. The Discovery Exhibition at the Information Visualization conferences is a great venue for doing just that. If you have a tool that's used by real users for real work, submit a brief description by July 19. We (three readers of this website, my student Caroline Ziemkiewicz, and I) submitted an entry on Parallel Sets, and won the Best Presentation Award. Petra Isenberg is writing a series of postings over at infosthetics on last year's entries, starting with ours.

This year, they've extended the limit for the abstracts to four pages, which makes writing things up a lot easier. Squeezing three short case studies, a brief description of the tool, an abstract, and a few screenshots into two pages was a bit of a challenge last year.

Writing for the discovery exhibition is different than a paper or poster. You want to introduce your tool, but especially show that it has made a real impact. Perhaps the most effective way for this are case studies: show what real users have done with it. Doing this can be a challenge because many companies don't want to share their data or what they do with it. But there are ways to still do it, with sanitized data, cleaned-up screenshots, and general descriptions of what has been done.

The point is that there needs to be some kind of evidence that the tool is actually useful to real people. Collecting that kind of data is very helpful for showing the value of visualization (beyond academia). So if you have done something useful, submit it!

Yes, more installments of the Protovis Primer are coming. Stay tuned.

The End of Verifiable.com

Robert Kosara — Mon, 21 Jun 2010 02:26:22 +0000

On August 1, 2010, the visualization website Verifiable.com will close. If you don't know Verifiable, I recommend checking them out despite this, it's an interesting site that has explored an important niche of the online visualization (visualization-as-a-service, if you will) world. Its demise can teach us a lot about how visualization for the masses works, and what we need to do to actually make it happen. Verifiable let you upload data and create visualizations. The interface was similar to Tableau, though certainly not as powerful. But it provided a lot of ways of creating interesting visualizations, and was more analytical than Many Eyes.

What I liked best about Verifiable, and what all other visualization websites I know are still missing, was that you did not have to pick the type of visualization first. Just like in Tableau, you could switch data dimensions and visual mappings around to figure out what would work best for your data.

Like most online services, this one had a free tier, where your data and visualizations were public. With a paid account, everything was private, unless you chose to share it. It's kind of a typical setup where they tried to establish a popular service to get people interested, and convert some fraction of them into paying users.

Lessons Learned the Hard Way

Stuart Roseman, Verifiable's "soon to be Ex-President," presents his thoughts on what went wrong and what their main stumbling blocks were. These are valuable lessons worth discussing a bit further. According to Roseman, any startup must:

serve a need actual people have RIGHT NOW
implement in such a way so that users don't have to do ANY work or expend ANY energy except for paying
avoid user interfaces like the plague.
be able to field something really quickly: not years, not months, but weeks.
get the product into users hands quickly and iterate on their daily needs often

As much as I hate to admit it, I think all visualization websites fail on point one. People don't feel a need to visualize data, we have to make them aware that visualization even exists, and that it can do something for them. The vast number of pretty but useless pictures on the web that are all called visualizations doesn't exactly help.

The few people who do want to visualize their data and are looking for this kind of service are most likely not interested in visualization web sites the way they exist today. Those people are mostly dealing with very valuable proprietary data that they don't want to (or aren't allowed to, per corporate policy) upload to a third party's web service.

The second point, I'm not sure I agree with. It may be true that casual users will abandon a site where they have to do work pretty quickly; but those corporate users I'm thinking of are very eager to play with their data.

More general users are a different question, and I wonder if it even makes sense to mix the two. That may sound like a good idea to get lots of users that you can convert to paying customers, to raise awareness, etc. But ultimately, I think it makes it harder to focus on the power users that you'll make money from and eats up resources.

Point number three, avoiding user interfaces, is an interesting one. Since Verifiable was quite similar to Tableau, a comparison is perhaps in order. While Tableau has one of the most effective user interfaces once you know it, it's by no means obvious. I use Tableau in my Visual Analytics class, and I get complaints from students every year about how much time it takes them to figure out how to work with the program. It seems obvious when you see somebody else do it, but when you're working with it yourself for the first time, you easily get lost.

The thing about Tableau, and what makes it so powerful, is that the user interface is not primarily about visualization, but about data. What you are seeing is a visualization that you're building, but you mostly control the data. That is a virtue, but it also creates a disconnect that users need to get over before they're able to use it effectively (and without frustration).

Users who care about their data and what they can learn about it accept this very quickly, and actually appreciate it. But users who want to play with visualization settings don't like it, and will look for a different program. It may be that the same thing happened with Verifiable.com.

The last two points (get the thing out the door quickly and iterate often) are typical agile development kinds of ideas. Those work with a focused user base that you can ask questions and get concrete ideas from, but not with casual users who want to play with baseball stats and global poverty data. For those users, you have to drive the tool forward, because you're presenting something new to them that they didn't realize was even possible. Power users will not (and shouldn't) tell you what to create, but at least they'll have a clear idea what they want to achieve with your tool.

Key Obstacles

Roseman also discusses some key issues that stood in the way of becoming a more successful website:

how many edge cases there are in any complex user interface
how little patience users have for complex user interfaces
how hard it is to find clean data and upload it
how little interest people have in finding clean data and uploading it
how much time and skill it requires to find clean data and upload it
how much time and skill it requires to make a decent, thoughtful chart from that data
how impossible it is to test complex user interfaces (we even convinced the funfx guy to help out and we still failed to develop a decent overall easy to run test framework)
how fragile a complex flex based user interface is. fix one thing break another.

While the technical issues are certainly big practical problems, they equally apply to many other kinds of web services. The interesting point here, and the key idea behind Verifiable, is the difficulty of finding good, "clean" data that is also of interest to people. Despite the considerable amount of stuff now available on data.gov and similar sites, there is no commensurate surge in web sites, visualizations, etc. Sure, there are exceptions, and some data makes big waves. But most of the data is probably never even looked at.

The truth is that most data is just not very interesting. Digging through all this data is difficult, and visualization doesn't necessarily help. Are you going to spend an hour or two playing with some financial dataset, only to find out that there's nothing interesting in it? And if you've done that once, how many more times are you going to do it?

Visualization for the Masses – Done Right

I think the idea of visualization for the masses is a good one, but not if it's also done by the masses. This kind of effort has to be curated, there has to be an editor who has the instinct to look for and find interesting data, knows how to analyze it, and uses visual tools to present it. That model is not really different from journalism, all the talk about "citizen journalism" notwithstanding.

I think that what Verifiable's demise is showing is that visualization is too hard a sell right now to a public that has no idea what to do with it. A better way of making people see visualization's benefits is by presenting well-constructed, interesting examples that give people actual information. Over time, this will show them how visualization is more than just pretty pictures, and perhaps inspire them to try those tools themselves.

We tend to forget that all those things that now get a "citizen" prefix (journalism, science, etc.) first had to be figured out and developed by people who spent their entire lives doing them. Only through the commoditization of this knowledge, and the tools that are needed, has it become possible for people outside that realm to try their hands on those same things. Visualization tools may be readily available (though not all are created equal), but the knowledge how to use them well is not. In fact, a large part of that does not even exist yet. Before we have experts who really know what they are doing when it comes to visualization (and can point to evidence that they do), there won't be effective visualization by the masses.

Verifiable.com was the right idea, but it simply came too early. Give it another five to ten years, and the world will be ready for it.

Beautiful Visualization

Robert Kosara — Wed, 16 Jun 2010 03:51:39 +0000

Beautiful Visualization is a collection of essays on a wide range of topics in visualization. Don't let the title mislead you: while it has its share of artistic visualization, there is also quite a bit of technical information in there. One of the chapters was written by yours truly. The chapters cover topics like Wordle, the New York Times News API, the use of color, visualizing Wikipedia, etc. Among the authors are people like Martin Wattenberg and Fernanda Viégas, Moritz Stefaner, Danyel Fisher, etc. All chapters are in the 10-25 page range, which makes for nice bite-sized chunks that can be read one after the other or as you find the time for them.

Julie Steele and Noah Iliinsky, the editors, have done a great job to make the chapters read well and be easy to digest. Even the more in-depth stuff is illustrated nicely with figures and described in ways that provide enough detail without getting too technical.

My chapter, Turning a Table into a Tree: Growing Parallel Sets into a Purposeful Project, talks about some of the thinking behind the Parallel Sets redesign I did about two years ago. It goes into a bit of technical detail how Parallel Sets work internally, but also describes how thinking about the data model lead to a visual redesign, which in turn prompted more technical changes and a better understanding of our own technique. I also use my little soapbox to complain about the quality of academic prototypes and the lack of an open-source culture in visualization.

O'Reilly offers the book in a physical version and as an ebook (as a completely annoyance-free PDF, and there's also epub and a few other formats). The chapters have also been released under a creative commons license, so you can find most of them posted on the web somewhere. If you buy the book, the proceeds go to charity.

A Protovis Primer, Part 2

Robert Kosara — Thu, 10 Jun 2010 12:57:52 +0000

The second installment of the Protovis tutorial introduces some more of its JavaScript-specific features like scales, shows how to anchor marks on other marks, and how to use rules. We also start using real data, and learn how to load that data from a remote source. Visualization is pointless if it doesn't represent interesting data. For this part of the tutorial, I have prepared a data file that contains all earthquakes of magnitude 1 or above over the last 24 hours. This data file is created by downloading a CSV file from U.S. Geological Survey (USGS) and converting it to the JSON format. The data file (at this URL) is updated once every hour, so if you have a Protovis-capable browser, you are seeing current data in the examples below.

Data in Protovis

There are many ways to get data into Protovis, and several ways of organizing it. The easiest way is to load a file in the JSON (JavaScript Object Notation) format, which is essentially JavaScript syntax for expressing arrays/lists and objects/dictionaries. This is what the earthquake data looks like in the file:

[
    {
        "Src": "ci",
         "Region": "Southern California",
         "Lon": "-116.8408",
         "Datetime": "Thursday, June 10, 2010 01:35:03 UTC",
         "Depth": "4.10",
         "Version": "1",
         "Lat": "34.3186",
         "Eqid": "14740876",
         "Magnitude": "2.0",
         "NST": "79"
    },
    ...
]

The outer square brackets denote an array, which can contain any type of object (including other arrays, numbers, etc.). Curly braces delimit an object, which in other languages would be called a hash table or dictionary. An object maps keys, which have to be strings, to values, which can be of any type.

The example here shows only strings, but that is the result of the conversion not caring about data types. The numbers could also be represented without quotation marks. JavaScript automatically converts strings to numbers as needed, so in practice it makes practically no difference how they are encoded.

JSON data can be retrieved from many sources, instead of or in addition to XML. JSON has the advantage of being smaller than XML, easier to parse, and mapping directly to an object hierarchy in most programming languages. It is also possible to create JSON from CSV and other tabular data with the help of CSV to JSON converters.

There are two ways to get this data into your Protovis visualization. One is like in the Protovis examples, where the data is part of a variable declaration that is read in as a source file. That is fine for examples, but is a bad idea when getting data from remote sources: somebody could alter the file to contain any functionality to hijack your application, spread malware, etc.

So the following way of loading data is more complicated, but also much more secure. It uses the jQuery library to load the data, and the browser's own JSON parser to securely parse the JSON data into a variable we call earthquakes.

var dataURL = "http://data.eagereyes.org/pv/earthquakes.json";

var JSONdata = $.ajax({ type: "GET", url: dataURL,
        async: false }).responseText;
var earthquakes = JSON.parse(JSONdata);

There are a lot more things jQuery can do, including asynchronous downloads of the data, etc., but this is all we'll use for now. Our earthquakes variable now contains the array of earthquakes, with each entry in the array being an object that has fields such as Magnitude.

To access this data, we need to set the variable as the data property of the visualization we're building, and provide a function that accesses the data. The following code is very similar to what we ended up with in the first part, with a few modifications. First, it defines a few variables for convenience, then it creates a simple bar chart from the magnitudes of the earthquakes.

var width = 560;
var height = 245;

var barWidth = width/earthquakes.length;
var gap = 2;

new pv.Panel().width(width).height(height+5)
    .add(pv.Bar)
        .data(earthquakes)
        .bottom(0)
        .width(barWidth-gap)
        .height(function(d) d.Magnitude * (height/9))
        .left(function() this.index * barWidth)
    .root.render();

A little detail that will save us some work later on is the definition of the height. Notice that the panel is five pixels higher than the height variable specifies. This gives us a little bit of headroom for later to add things close to the top without cutting them off. You can ignore this for now, though.

The barWidth variable adapts the visualization to the number of earthquakes to show. This number varies, since there can be more or fewer quakes over the course of a day, so we don't want to assume a particular number. An earthquake's magnitude is measured on the Richter scale, which does not have an upper limit. For practical reasons, we'll limit the maximum to 9 here, which fortunately is rather uncommon.

The key points for data access here are the following two lines. The first one tells Protovis to use our earthquakes variable as the data source.

        .data(earthquakes)

Protovis does not care what the variable contains, as long as it is an array. It simply walks through all the elements in the array and hands them back to functions we define. One such function determines the height of the bars in our bar chart.

        .height(function(d) d.Magnitude * (height/9))

This does two things: it accesses the Magnitude field inside an object and scales that value to fit the height of the visualization. Since the value will be different for each bar, we have to define a function here. The function gets a single parameter, which we call d. Since we've specified the data to be the earthquakes variable, we know that the function will be passed one of the earthquake objects. So inside the function, we know that d has all the fields shown in the JSON code snippet above. One of them is the earthquake's magnitude, in a field called Magnitude. The expression d.Magnitude accesses the value of that field.

The rest of the function scales the value from that field by multiplying it with one-ninth of the height of the panel. That means that if the bar will be the height of the panel if the magnitude is equal to 9, and smaller if it is less than that.

And voilà, the earthquakes of the last 24 hours.

Anchors

Of course, this doesn't yet tell us a whole lot. How strong were those earthquakes? Were any of them serious? We can do this by attaching labels to the bars that tell us the actual numbers. In Protovis, this can be done in a very elegant fashion. At the end of the pv.Bar definition, before the line that says .root.render(), we add these lines:

.anchor("top").add(pv.Label)
    .text(function(d) d.Magnitude)
    .textBaseline("bottom")

What that does is attach one label to each bar, anchored at the top of the bar. The data is the same as what is used for the bar, which is one of our earthquake objects. So we need to again define a data accessor function that extracts the magnitude from the earthquake object (same as for the bar above). The additional textBaseline definition is used to move the label up, otherwise it would overlap the bar. Labels can be aligned in a number of different ways, to be attached to different sides of objects without getting in the way.

Labeling all the bars gives us this new variation of the chart.

Hiding Marks

That's a start, but it's also very cluttered. Since higher magnitudes are less common, they stand out and are still readable, anyway. But it's clearly a better idea to get rid of all the clutter, and this is very easy:

    .visible(function(d) d.Magnitude >= 4)

The visible attribute determines whether a mark will show up or not. As before, we need to define a function here, because the value of the expression will change for each array entry. The rule here is to show the value for earthquakes of magnitude 4 and higher (i.e., earthquakes stronger than "minor"). The function works in a very similar way to the text and height definitions above, only its type is a boolean value: true or false. If the value is greater than or equal to four, the expression will evaluate to true, and the label will be visible. If the magnitude is less than four, the result is false, and the label is not shown.

There is no guarantee that there won't be overlaps, but they are a lot less likely now. Also, it makes more sense to label the stronger earthquakes, because those are obviously of more interest.

Rules

Now in addition to numbers, let's also add a more visible scale. The mark to use for this is called a rule. Rules are lines that are either horizontal or vertical, depending on what data is specified. By defining a bottom function, we tell Protovis that we want horizontal lines. Rules are added directly to the panel, so let's call the panel we're creating eq.

Just like with bars and other marks, rules need data to be drawn. To do that at regular intervals, we could specify an array that contains the values from 0 to 9, for example. But we can also use a Protovis utility function called range() that creates that array for us. If you are familiar with the range function in languages like Python, this will look familiar: you can specify just the upper limit (which is not included in the array), or add the starting point and step size as well. Since we're starting at 0 and want a step size of 1 (which are the defaults), we can just specify the upper limit.

Finally, the values need to be scaled just like for the bar height. So the formula for that looks exactly like above, only here we are directly getting the numerical values, rather than looking at an earthquake object.

eq.add(pv.Rule)
    .data(pv.range(9))
    .bottom(function(d) d * (height/9))
    .strokeStyle("lightgray");

The result looks like this. Defining this before the bars means that the bars will be painted on top of the lines. Since the bars are quite thin, it looks like the lines are in front, but they are not.

Labeled Rules

Anchoring also works for rules, and it's extremely useful to label them. This specifies that we want to attach labels to all the rules, but we'll hide the one at 0. This is simply to avoid the 0 being cut off, which it would be given its location. There are other ways of doing this, like moving the baseline, but we'll keep this simple for now.

.anchor("left").add(pv.Label)
    .visible(function(d) d > 0);

Notice that we do not even have to specify the text property here. Protovis automatically assumes that the label should show the numbers from the parent object if nothing is specified, and that is what we want here. (This, BTW, is where specifying the panel height as a bit higher than the chart comes in handy: the top-most label would otherwise be cut off. Having a bit of space around the panel is often a good idea, but makes examples a bit more confusing to read, so I'm keeping it to a minimum here.)

As it is, the lines still start at the left edge of the panel, so the labels are actually pushed of the side. We need to move them over to the right a bit, like this:

eq.add(pv.Rule)
    .data(pv.range(10))
    .bottom(function(d) d * (height/9))
    .strokeStyle("lightgray")
    .left(10)
    .width(width-10)
.anchor("left").add(pv.Label)
    .visible(function(d) d > 0);

Also, the bars need to be moved so they don't overlap with the labels. This is done by changing the barWidth definition slightly.

var barWidth = (width-10)/earthquakes.length;

Where that is used to specify the location of the bars, we also need to add the same amount so that the gap is to the left (if we don't add anything, the thinner bars will simply end up being shorter, with a gap on the right).

    .left(function() 10 + this.index * barWidth)

That gives us a better view of the data, with a grid and labels.

Scales

Using the same function for the scale in the background is kind of ugly, especially if that means we need to copy code. That is why Protovis has a mechanism for reusable scales that are defined once and then used in several places. This not only makes the code more compact and elegant, it also makes it much easier to change it without running the risk of inconsistencies between the different marks.

To define a scale, we use the pv.Scale class, which has a number of convenience functions. Using the familiar function chaining style, it lets us create two scales, one for the x coordinate and one for the height.

var xScale = pv.Scale.linear(0, earthquakes.length)
                .range(10, width);
var magnitude = pv.Scale.linear(0, 9).range(0, height);

The code should be fairly self-explanatory: we are defining linear scales from 0 to the number of earthquakes, or from 0 to the maximum magnitude we want to show, respectively. The range() function specifies what the output range will be, in our case it's simply the width or height of the panel.

Now remember that this is Protovis, and it will not surprise you that scales are not objects, but functions. That means that you can call xScale() and magnitude() as functions to convert a number from the data domain to the screen domain. The way this is used is shown in the following, which specifies the height and location of the bars.

        .height(function(d) magnitude(d.Magnitude))
        .left(function() xScale(this.index))

If we had a simple array of numbers, we could even just pass it the function, but since we need to access a field for the height, and the index for the x coordinate, we need to define another function. But the rules are more straight-forward.

eq.add(pv.Rule)
    .data(magnitude.ticks())
    .bottom(magnitude)
    .strokeStyle("lightgray");

Notice the definition for bottom, which simply passes the magnitude function in without any modifications. Another trick here is using the ticks() function on the scale, which creates equally-spaced numbers that are suited well for a scale (the exact numbers depend on the range of the scale and the optionally specified number of ticks). This actually means we're calling a function on a function! JavaScript is weird like that.

The result of this looks no different, which is good. But it's now much more elegant and easier to change.

Color Scales

Scales can also be used to interpolate colors. Let's say we wanted to change the color of the bars depending on their value, we could create a color scale like this.

var colors = pv.Scale.linear(1, 9).range("lightgray", "red");

This assigns a light gray to a magnitude of 1, and turns the bar more and more red the closer we get to 9. In the definition of the bar, we can now use the new scale to specify the fill color.

.fillStyle(function(d) colors(d.Magnitude));

At this point, this is a redundant mapping, because the magnitude is already shown as the height of the bar. So let's look at another attribute, like Depth – perhaps there is some correlation between the depth at which a quake happens and its magnitude. To do this, we'll define a new scale, similar to the one above.

var depthColors = pv.Scale.linear(0, 150)
                    .range("lightgray", "blue");

And then use that one instead in the definition of the bars.

    .fillStyle(function(d) depthColors(d.Depth));

Done.

Putting It All Together

Here is the entire code for this, including the data loading part. This is also available as a file from the github repository and in a ZIP file together with sample data.

var dataURL = "http://data.eagereyes.org/pv/earthquakes.json";

var JSONdata = $.ajax({ type: "GET", url: dataURL, async: false }).responseText;
var earthquakes = JSON.parse(JSONdata);

var width = 560;
var height = 245;

var barWidth = (width-10)/earthquakes.length;
var gap = 2;

var xScale = pv.Scale.linear(0, earthquakes.length).range(10, width);
var magnitude = pv.Scale.linear(0, 9).range(0, height);

var depthColors = pv.Scale.linear(0, 150).range("lightgray", "blue");

var eq = new pv.Panel().width(width).height(height+5);

eq.add(pv.Rule)
    .data(magnitude.ticks())
    .bottom(magnitude)
    .strokeStyle("lightgray")
    .left(10)
    .width(width-10)
.anchor("left").add(pv.Label)
    .visible(function(d) d > 0);

eq.add(pv.Bar)
    .data(earthquakes)
    .bottom(0)
    .width(barWidth-gap)
    .height(function(d) magnitude(d.Magnitude))
    .left(function() xScale(this.index))
    .fillStyle(function(d) depthColors(d.Depth))
.anchor("top").add(pv.Label)
    .text(function(d) d.Magnitude)
    .visible(function(d) d.Magnitude >= 4)
    .textBaseline("bottom");

eq.render();

Previous: A Protovis Primer, Part 1 Next: A Protovis Primer, Part 3

Conference Acceptance Rates

Robert Kosara — Sun, 06 Jun 2010 21:20:04 +0000

Acceptance rates are one of the key ways of measuring the quality of conferences. I think it's time we collect that data for conferences relevant to visualization. I have put together a page for this, and have found some of that data. But I need your help to fill in the gaps and suggest other conferences that would be of interest. I originally only wanted to include the VisWeek conferences, but then I figured it would make sense to extend the list a little bit. So currently, there is InfoVis, Vis, VAST, EuroVis, AVI, UIST, and CHI. I am open to suggestions for further conferences to include, but I want to keep focusing on visualization. So even though CHI and UIST are included, I don't want to expand into HCI much more.

There is also missing data. Especially for InfoVis, IEEE Xplore doesn't have the prefaces for conferences before 2005. Some of the early Vis conferences and a few others are also missing. Please take a look at the list and if you have access to proceedings for years where numbers are missing, send them to me or leave a comment below.

Given that this is about visualization conferences, I figured it would make sense to also visualize the data. The first visualization shows acceptance rates from 1990 to 2010. Not all of the missing lines are actually missing data, because the different conferences started at different times.

The following shows numbers of submissions. CHI's increase in submissions is impressive; even more impressive is that they kept their acceptance rate nearly constant through this enormous growth.

The next task is to look into impact factors for visualization journals. That information seems to be much harder to come by though, unfortunately. But it would be very worthwhile.

Follow this link to the acceptance rates data. The data is also available in CSV and JSON formats in a repository on github.

A Protovis Primer, Part 1

Robert Kosara — Thu, 03 Jun 2010 04:43:08 +0000

Protovis is a very powerful visualization toolkit. Part of what makes it special is that it is written in JavaScript and runs in the browser without the need for any plugins. Its clever use of JavaScript's language features makes it very elegant, but it can also be confusing to people who are not familiar with functional programming concepts and the finer points of JavaScript. This multi-part tutorial shows how to create a visualization (my interactive Presidents Chart) in Protovis, and explains the concepts that are involved along the way. This introduction is based on my experiences with using Protovis in my Visualization and Visual Communication class earlier this spring. While the concepts involved are really not that difficult, they are rather foreign to students who have not been exposed to functional programming. And since that is also the case for a lot of hobbyists and people wanting to do visualization who do not have a computer science background, I imagine they run into the same problems.

This has grown from being a single article into several parts (and is still expanding). Let me know if there are things that you don't understand or that you think need to be covered in more detail, so I can tailor the next parts accordingly.

Protovis requires a modern browser, which means any recent version of Safari, Chrome, FireFox, or Opera. Internet Explorer does not work, because it does not support the HTML5 Canvas element. The visualizations in this article are all Protovis drawings (check out the source code!), with a fall-back to images for RSS readers and IE users. There is no real difference at this point, but once we get to interaction, you will want to read this in a supported browser.

A Simple Example

Let's start with a simple example, taken almost verbatim from the Protovis paper presented at InfoVis 2009 (PDF).

The following code creates this chart:

var vis = new pv.Panel().width(150).height(140)
    .add(pv.Bar)
        .data([1, 1.2, 1.7, 1.5, .7, .2])
        .bottom(0).width(20)
        .height(function(d) d * 80)
        .left(function() this.index * 25)
    .root.render();

Let's look at this line by line. The first line defines a new Panel, the base element for any Protovis chart. The panel is the canvas on which everything is drawn (in fact, it becomes an actual canvas element in the webpage). This line also defines its size by calling two functions that set its width and height.

Function Chaining

This brings us to the first bit of magic: Almost all functions in Protovis return the object they are called on. That makes it possible to chain function calls instead of having to repeat the variable name over and over. While this leads to more elegant, simpler code, it can make it a bit terse and more challenging to read. But consider the alternative:

var vis = new pv.Panel();
vis.width(150);
vis.height(140);
var bar = vis.add(pv.Bar)
etc ...

Function chaining lets you treat functions like statements: I want a panel, and I want its width to be 150 and its height to be 140; this translates very directly into function calls. While this is not all there is to what Bostock and Heer call a "declarative style of programming," it certainly is a big part of it.

Marks

But back to our example. The second line adds something to the panel by calling the add() function. What is added is called a mark, a graphical element that can represent data. Let's briefly skip over the details of that and look at the last line: here, we need to call the render function of the panel to tell it to create the necessary infrastructure and start rendering. Since at this point, the functions being called are called on the bar mark that was added in the second line, we need a way to go back to the panel. This could be done by assigning the panel to a variable vis and calling vis.render(). The way it is done here is using the special variable root, which exists in all marks. It returns the panel that the mark sits on, so we can add other marks to it or call its functions.

The following code snippet is identical to the above. I just showed the other one first because it is the style that the Protovis examples are written in, so it makes sense to get familiar with it.

var vis = new pv.Panel().width(150).height(140);
vis.add(pv.Bar)
    .data([1, 1.2, 1.7, 1.5, .7, .2])
    .bottom(0).width(20)
    .height(function(d) d * 80)
    .left(function() this.index * 25);
vis.render();

Using variables is a good idea in general, especially when creating more complex visualizations. But the clever design of Protovis' functions makes it possible to all but eliminate them in many cases (at least as far as Protovis objects are concerned).

Mark Properties

Now let's look at the definition of the bars, which is the same between both alternatives. The first statement defines an array of numbers, which are the data to be shown on the chart. We will later see data in variables and arrays of objects, not just numbers. But this kind of inline definition of the data is also possible. The square brackets delimit an array in JavaScript (and lots of other programming languages), numbers are listed with commas in between.

The line after the data statement specifies two important but constant parts of the layout. Since we're using bars, we have to specify at least their position (x and y), their width, and height. For a bar chart, it makes sense to have all the bars have the same width, so it is set to a number here. And since we want all bars to sit on the same baseline, we specify their y position as 0. The terminology here, bottom, has to do with the way locations and sizes can be specified in Protovis. I'll cover more of that later.

More Fun With Functions

The next two lines is where it gets really interesting, and where a lot of confusion comes from. Remember that we are creating a bar chart here, but there is no loop to draw each of the bars. We specified the entire data array two lines earlier. Now how do we get Protovis to draw something?

The way Protovis works is that a definition like this tells it to iterate over the array of data it is given, instantiate a mark for each entry in the array, and evaluate all the information it is given about what to do with the mark. In the case of the width and bottom attributes, this is simple: we specified constants, so it just uses these same numbers for all of the bars it creates.

But we want the bars to represent the data by varying their height, how do we do that? The answer here is a function. Instead of specifying a number or variable, we assign a function to the height property. For every entry in the array, Protovis will call this function with the value, and use the result of the function as the height of the bar. The beauty of this approach is that JavaScript, unlike Java and most of the more common imperative languages, can use a function like a variable: you can pass it to another function, store it in a variable, and evaluate it by calling it.

As with the function chaining before, the particular style in which this is done in Protovis makes this a bit more difficult to understand. Here is the definition of the height again:

.height(function(d) d * 80)

And here is the same definition in a more verbose style that is actually correct JavaScript (Protovis does some magic with function parsing that allows the sloppy but more compact style above):

.height(function(d) {
    return d * 80;
})

Both statements do the exact same thing: they specify a function without a name (called an anonymous function) that takes one argument called d. The function returns the result of a simple computation, multiplying the value of that argument by 80. The unit here is pixels, which means that our highest bar will be 1.7 * 80 pixels high (1.7 is the maximum value in the data array).

Functions used in property definitions can do a lot more complex things. You can also assign functions to variables and reuse them in different definitions. But many functions used in visualization definitions in Protovis perform fairly straight-forward calculations or access data in more complex data structures (we'll get to that, too).

The last line in the bar definition works the same way as the height definition, with a small difference. We want our bars to be next to each other, not drawn on top of each other. Even though the mark is called bar, it is really more a general-purpose rectangle: it doesn't know anything about being a bar in a bar chart. That makes it very flexible and powerful, but it also means that you need to do a lot of things by hand that might seem obvious.

Bar Layout

To move the bars, we specify their left property, which together with the bottom means we're specifying the lower left corner. Since this value will have to be different between the bars, we need to again specify a function. We are specifying everything at once, so there is no obvious way to order the bars and use that order to space them. Protovis therefore has a special variable that is available when it evaluates functions, which is called this.index. That variable's value is the index of the current value in the array, starting at 0 and going all the way to the size of the array minus 1.

.left(function() this.index * 25);

Remember that we set the width of the bars to 20. Putting the bars at multiples of 25 means that we're leaving five pixels of space between them. You can easily tweak any of these numbers to change spacing, scaling, etc. Just remember that when you increase the scale factor, you will have to also change the size of the panel, or your bars will be cut off!

Adding A Variable

The last step in this first part of this tutorial is simply to move the data into a variable. This is a simple but important step. To do this, we will define new variable numbers that contains the exact same numbers as above. The only other thing that changes is the data() function call that now uses the variable.

var numbers = [1, 1.2, 1.7, 1.5, .7, .2];

new pv.Panel().width(150).height(140)
    .add(pv.Bar)
        .data(numbers)
        .bottom(0).width(20)
        .height(function(d) d * 80)
        .left(function() this.index * 25)
    .root.render();

Running this does not actually make any difference, which is what we intended. But it opens the doors to some more flexibility. What if we wanted the bars to change size depending on how much data there is? Let's define another variable for the panel, panelWidth, and calculate the width of the bars, barWidth, from the size of the array.

var panelWidth = 150;

var barWidth = panelWidth/numbers.length;

The barWidth is the total space a bar takes up, including its spacing to the next bar. If we simply use this for our definition:

new pv.Panel().width(panelWidth).height(140)
    .add(pv.Bar)
        .data(numbers)
        .bottom(0).width(barWidth)
        .height(function(d) d * 80)
        .left(function() this.index * barWidth)
    .root.render();

We end up with something slightly unexpected:

We need to add some space between the bars again. Remember that we set the width to 20 earlier, but multiplied the index by 25. We need something similar here, so we'll introduce another variable, barSpacing. This will be subtracted from the barWidth in the width definition, so the bar does not use the entire width it got assigned.

var barSpacing = 5;

new pv.Panel().width(panelWidth).height(140)
    .add(pv.Bar)
        .data(numbers)
        .bottom(0).width(barWidth-barSpacing)
        .height(function(d) d * 80)
        .left(function() this.index * barWidth)
    .root.render();

The result is a readable chart that looks like before:

This may not look very exciting, but it gives us a lot of flexibility. Now we can change the width of the chart by simply changing the panelWidth, let's say to 250:

As you can see, the bars have adapted to the new width. The spacing looks a bit odd because barSpacing is still a constant, but that would be easy to change, too. But what happens if we add more data to our numbers array?

var numbers = [1, 1.2, 1.7, 1.5, .7, .2, .5, .9];

The bars adapt to the number of values, because the barWidth depends on the number of values in the numbers array, numbers.length. This only works to a certain point, because our spacing is still constant; but it's a start.

This concludes the first part of this tutorial. The next parts will cover more complex layouts, Protovis scales, other mark types, reading of complex data, labels, etc.

Start Playing!

If you want to play with Protovis, I am providing a ZIP file with two simple HTML files: one is the basic bar chart, the other one uses variables for the data and the widths.

I have also started a repository on github for people familiar with git.