It's by pure chance that Jeffrey Heer came to my CS376 class this week to speak to us about visualization technology. (Either that, or design education at this school is a conspiracy). I was both surprised and gladdened that Dr. Heer arrived; until then, visualization at Stanford wasn't very high-profile for me.
So it comes as another pleasant shock to be reviewing Dr. Heer's work this week. Protovis provides a declarative markup for articulating visualizations for the web. As someone on a start-up dev-team, that's a highly desirable good -- the alternative frameworks for a comparable solution range from the design-impoverished (Google Visualization API) to the beautifully inexact (Adobe Illustrator). Web designers have a palpable hunger for the next generation of tools, ones that will let them manipulate pixels with all the fluidity of CSS.
Granted, this need is only ten-or-so years old: research used to be quite satisfied with R graphics, and the business world seems fattened on Excel bar charts (and that nouveau-Ariel typeface, Calibri). But with the data deluge [link] on its way, there will be a growing ecology of some data visualization language on the web. When news organizations, bloggers, and web developers all turn to tame this data, they will eventually wrestle out a standard for this mode of expression, as they did for markup (HTML) and video (Flash).
And this brings me to the part I liked the most about the reading. When users are all empowered to share their visualizations & data, everybody wins. (You can even save a government $3.2 billion USD [link]). If there is a pervasive, open-sourced standard that allows us to harness the Twitters, the SMS gateways, the Youtube hits -- we might have something flexible enough to show us where we're headed. Or, failing that, we'll all at least be looking at the same sort of map. Standardized, simple toolkits FTW.
(the links only work on my page -- click through above to visit!)
That was a well-written paper–it made me want to try out Protovis!
Since this week's focus will be on visualization of data, though not necessarily Protovis in particular, I've listed some ways in which design thinking applies to visualization:
• Creating tools (e.g. Protovis, etc.) for making visualizations
• Creating visualizations
• Introducing interactivity into visualization
• Facilitating iteration on the visualizations of self and others
• Considering the intended audience of a visualization
I'm looking forward to the 547 talk. I think there will be much more to discuss after that.
Protovis is interesting - what I found most compelling was that, in certain ways, it took something that a lot of graphics programs do anyways (let you control a basic set of properties of an object) and allows users to link those properties to data sets, instead of fixed numbers. The interesting thing, though, as much as Heer claims to want versatility, Protovis seems to be optimized for a certain number of visualizations (pie charts, etc).
I think visualization shows a unique opportunity in the field of graphic design for human centered designers to add real value. While graphic design sometimes borders on art, there's a real chance to think about what sorts of data is worth (in want of) visualizing, how this data will effect the user, and lastly, how best to strikingly display it (both for visual impact and understanding). Now that data is available not just on the level of organizations and masses of people, but individual people, how can we use that data for change? If this is of interest to people, this talk by Robert Fabricant is cool: http://vimeo.com/3730382?pg=embed&sec=.
@Andrew: I agree about ProtoViz's intersection between design and data viz. as a tool for making visualizations. How do you feel about using it as a prototyping tool?
This question stems from my more general fascination with the notion of finding the right tools when rapidly prototyping. In my experience, prototyping usually entails paper, foam core, cardboard, etc. More concrete implementation - building, coding - don't come until later.
Ted brought up the failure of inventor's kits because they assume a specific set of tools and, therefore, indirectly impose limitations. Could paper prototyping do the same thing? As a disclaimer, I will admit that I am not aware of the emphasis on paper prototyping in industry-level design. But, it seems as though rapid prototyping should be done with whatever tool would be able to best express the underlying design concept. This also relates to Rob's comments on web design prototyping - should we just jump straight into html and css because we'll have to end up prototyping in that space anyways.
@Brie: Great question. Is Protovis a prototyping tool? Or more generally, what makes a good prototyping tool? Where do trade offs surface, in terms of tool expressiveness, learning curves, speed of production, ability/willingness to change directions, etc?
@Steven -- I mean, if your own research is taken as a hint, then a good prototyping tool is one which enables successful prototypes.
Once we ask that question -- "[what makes] what makes great prototypes?" -- then we can begin to relate the fundamentals from your recent work. If parallel prototyping is a best practice, then our tools demand massive expression space (for maximally divergent designs). In terms of learning curve, we ask for tools that enable the same sort of rapid prototyping as the egg-drop -- that is to say, minimally difficult to learn. Et cetera.
What I mean to say is: there's a good case to be made for evaluating a tool by the ecology it affords. A poor worker might blame his tools.
@ Nina - I agree with your point about the making visualizations a powerful communication and behavioural change tool and this is mainly accomplished through human centered designing of these visual representations and promoting engagement through interactivity. A lot of the discussion in our class I feel tends to focus on how helpful a certain concept would be to "designers" - But I feel that designers - just like communicators - or many other professions are mere conduits or channels that could create something valuable for an end-user base. (check Rob's notes on the need for creative tools etc.. etc.. ) But lets just ask ourselves - the tools available for visualizations may have improved tremendously over the past decade, but has the end-user experience or the value of visualizations to users actually increased at the same rate?
If not what are we doing wrong? How can that be improved?
1) I like protovis's point on Facilitating iteration on the visualizations of self and others - Personalization adds to the ability of an individual to "relate to" and understand a visualization and also increases its communicative power - (or its ability to encourage some form of action or behavioural change)
2) Introducing interactivity into visualization - Promoting engagement helps sustain interest.
3) Ethics of representation - this was an issue that has been omitted by Protovis but was touched on by Prof. Heer briefly in his presentation - In many situations data can be manipulated and represented in ways to promote a certain perspective. As designers do we only think of the aesthetic / artistic appeal of a visualisation? Or are we also concerned about not just the accuracy but also the objectivity and "sense of balance" in a visualisation that allows the end-user to obtain a more rounded / holistic view on an issue?
Brie, Protovis seems like it would be a great prototyping tool, except for the fact that there still seems to be a significant investment required before the first iteration with data appears. However, Jeff Heer argued that with visualization you almost have to go to code earlier than in other design disciplines because it's hard to predict how the data will look before actually seeing it. That said, once the initial investment in setting up the code for a visualization is in place, Protovis makes it easy to change properties and tweak parameters. In fact, it even seems well suited to trying out new kinds of visualizations as long as the designer has the abilities required to define them mathematically and precisely. Testing your new vis is as easy as refreshing a web page.
You don't have permission to comment on this page.
Comments (8)
Rob Ryan said
at 11:48 pm on May 13, 2010
It's by pure chance that Jeffrey Heer came to my CS376 class this week to speak to us about visualization technology. (Either that, or design education at this school is a conspiracy). I was both surprised and gladdened that Dr. Heer arrived; until then, visualization at Stanford wasn't very high-profile for me.
So it comes as another pleasant shock to be reviewing Dr. Heer's work this week. Protovis provides a declarative markup for articulating visualizations for the web. As someone on a start-up dev-team, that's a highly desirable good -- the alternative frameworks for a comparable solution range from the design-impoverished (Google Visualization API) to the beautifully inexact (Adobe Illustrator). Web designers have a palpable hunger for the next generation of tools, ones that will let them manipulate pixels with all the fluidity of CSS.
Granted, this need is only ten-or-so years old: research used to be quite satisfied with R graphics, and the business world seems fattened on Excel bar charts (and that nouveau-Ariel typeface, Calibri). But with the data deluge [link] on its way, there will be a growing ecology of some data visualization language on the web. When news organizations, bloggers, and web developers all turn to tame this data, they will eventually wrestle out a standard for this mode of expression, as they did for markup (HTML) and video (Flash).
And this brings me to the part I liked the most about the reading. When users are all empowered to share their visualizations & data, everybody wins. (You can even save a government $3.2 billion USD [link]). If there is a pervasive, open-sourced standard that allows us to harness the Twitters, the SMS gateways, the Youtube hits -- we might have something flexible enough to show us where we're headed. Or, failing that, we'll all at least be looking at the same sort of map. Standardized, simple toolkits FTW.
(the links only work on my page -- click through above to visit!)
Andrew Hershberger said
at 11:28 am on May 14, 2010
That was a well-written paper–it made me want to try out Protovis!
Since this week's focus will be on visualization of data, though not necessarily Protovis in particular, I've listed some ways in which design thinking applies to visualization:
• Creating tools (e.g. Protovis, etc.) for making visualizations
• Creating visualizations
• Introducing interactivity into visualization
• Facilitating iteration on the visualizations of self and others
• Considering the intended audience of a visualization
I'm looking forward to the 547 talk. I think there will be much more to discuss after that.
Nina Khosla said
at 12:09 pm on May 14, 2010
Protovis is interesting - what I found most compelling was that, in certain ways, it took something that a lot of graphics programs do anyways (let you control a basic set of properties of an object) and allows users to link those properties to data sets, instead of fixed numbers. The interesting thing, though, as much as Heer claims to want versatility, Protovis seems to be optimized for a certain number of visualizations (pie charts, etc).
I think visualization shows a unique opportunity in the field of graphic design for human centered designers to add real value. While graphic design sometimes borders on art, there's a real chance to think about what sorts of data is worth (in want of) visualizing, how this data will effect the user, and lastly, how best to strikingly display it (both for visual impact and understanding). Now that data is available not just on the level of organizations and masses of people, but individual people, how can we use that data for change? If this is of interest to people, this talk by Robert Fabricant is cool: http://vimeo.com/3730382?pg=embed&sec=.
Brie Bunge said
at 5:36 pm on May 16, 2010
@Andrew: I agree about ProtoViz's intersection between design and data viz. as a tool for making visualizations. How do you feel about using it as a prototyping tool?
This question stems from my more general fascination with the notion of finding the right tools when rapidly prototyping. In my experience, prototyping usually entails paper, foam core, cardboard, etc. More concrete implementation - building, coding - don't come until later.
Ted brought up the failure of inventor's kits because they assume a specific set of tools and, therefore, indirectly impose limitations. Could paper prototyping do the same thing? As a disclaimer, I will admit that I am not aware of the emphasis on paper prototyping in industry-level design. But, it seems as though rapid prototyping should be done with whatever tool would be able to best express the underlying design concept. This also relates to Rob's comments on web design prototyping - should we just jump straight into html and css because we'll have to end up prototyping in that space anyways.
Steven Dow said
at 10:29 am on May 20, 2010
@Brie: Great question. Is Protovis a prototyping tool? Or more generally, what makes a good prototyping tool? Where do trade offs surface, in terms of tool expressiveness, learning curves, speed of production, ability/willingness to change directions, etc?
Rob Ryan said
at 3:55 am on May 21, 2010
@Steven -- I mean, if your own research is taken as a hint, then a good prototyping tool is one which enables successful prototypes.
Once we ask that question -- "[what makes] what makes great prototypes?" -- then we can begin to relate the fundamentals from your recent work. If parallel prototyping is a best practice, then our tools demand massive expression space (for maximally divergent designs). In terms of learning curve, we ask for tools that enable the same sort of rapid prototyping as the egg-drop -- that is to say, minimally difficult to learn. Et cetera.
What I mean to say is: there's a good case to be made for evaluating a tool by the ecology it affords. A poor worker might blame his tools.
Poornimaw said
at 7:21 am on May 21, 2010
@ Nina - I agree with your point about the making visualizations a powerful communication and behavioural change tool and this is mainly accomplished through human centered designing of these visual representations and promoting engagement through interactivity. A lot of the discussion in our class I feel tends to focus on how helpful a certain concept would be to "designers" - But I feel that designers - just like communicators - or many other professions are mere conduits or channels that could create something valuable for an end-user base. (check Rob's notes on the need for creative tools etc.. etc.. ) But lets just ask ourselves - the tools available for visualizations may have improved tremendously over the past decade, but has the end-user experience or the value of visualizations to users actually increased at the same rate?
If not what are we doing wrong? How can that be improved?
1) I like protovis's point on Facilitating iteration on the visualizations of self and others - Personalization adds to the ability of an individual to "relate to" and understand a visualization and also increases its communicative power - (or its ability to encourage some form of action or behavioural change)
2) Introducing interactivity into visualization - Promoting engagement helps sustain interest.
3) Ethics of representation - this was an issue that has been omitted by Protovis but was touched on by Prof. Heer briefly in his presentation - In many situations data can be manipulated and represented in ways to promote a certain perspective. As designers do we only think of the aesthetic / artistic appeal of a visualisation? Or are we also concerned about not just the accuracy but also the objectivity and "sense of balance" in a visualisation that allows the end-user to obtain a more rounded / holistic view on an issue?
Andrew Hershberger said
at 11:35 am on May 21, 2010
Brie, Protovis seems like it would be a great prototyping tool, except for the fact that there still seems to be a significant investment required before the first iteration with data appears. However, Jeff Heer argued that with visualization you almost have to go to code earlier than in other design disciplines because it's hard to predict how the data will look before actually seeing it. That said, once the initial investment in setting up the code for a visualization is in place, Protovis makes it easy to change properties and tweak parameters. In fact, it even seems well suited to trying out new kinds of visualizations as long as the designer has the abilities required to define them mathematically and precisely. Testing your new vis is as easy as refreshing a web page.
You don't have permission to comment on this page.