FP-MichaelCohen-ThomasSchluchter

From CS294-10 Visualization Sp11

Jump to: navigation, search

Contents

A Code-Minimizing Front End for Creating Flexible Visualizations

Group Members

  • Michael Cohen
  • Thomas Schluchter

Description

Domian-specific visualization toolkits such as protovis enable users with pre-existing programming experience to create data-driven visualizations concisely and quickly. In Jeff Heer's lecture, he specifically mentioned that in designing protovis, he was seeking a middle ground between expressive but low-level graphics libraries and simple-to-use but highly constrained charting tools like Excel. While we believe that protovis succeeds admirably for designers with javascript experience, we think its elegant mark-based architecture opens the door to further simplification that would allow a designer to access much of the flexibility of the system while minimizing the amount of programming knowledge required to a level approximately equivalent to that required to write formulas in Excel. To situate the proposed tool in the space of current visualization options, we believe that protovis can provide the substrate for a web-based tool with a learning curve comparable to Tableau, but with greater expressive flexibility. This tool will allow non-programmers to access much of the power of protovis, while also facilitating quicker, interactive "scaffolding" of new visualizations by programmers. The research value will be in pushing the quality and complexity of data visualizations that can be expected from non-programmers to new levels, without resorting to expensive hand-rendered art (e.g., with Illustrator).

Given the timeline of this project, it is not feasible to implement a front end that allows access to all of the facilities of protovis. However, at a minimum, users of the system should be able to replicate all of the protovis examples in the "conventional" category and a significant fraction of the "custom" ones. Interaction will be out of scope since it requires customized javascript for most practical uses. Hierarchies and networks will probably also be out of scope for the first cut due to time limitations, although unlike interaction we don't see any conceptual reason why they couldn't be added.

Initial Problem Presentation

Project presentation 04/05/2011 (PDF format)

Final Deliverables

Work breakdown for final project

  • Michael
    • Originated the ProtoWiz concept
    • Created the underlying mark-and-property architecture and hierarchy
      • Set up content of property HTML forms (drop-downs, etc.)
      • Implemented Protovis code generation for each property
      • Implemented updating of property forms based on available scales and data fields, etc.
    • Implemented code expansion (e.g. automatic addition of "function(d)" when "d." is referenced)
    • Integrated with Protovis to parse generated code and render the canvas (with status display)
    • Integrated simpleCombo and jscolor
  • Thomas
    • Created initial designs
    • Coded interactivity of mark list elements (sortable, accordion)
    • Implemented reordering of layers
    • Contributed to visual design

We contributed equally to the evaluation process

Brandon Liu - Apr 06, 2011 03:44:58 pm

Nice that you mentioned Scratch, I think a fundamental idea in Scratch that could be applied is the little puzzle pieces on each object that indicate what kind and how many arguments each part takes. Since Protovis methods have well defined input/output, find some way to leverage this in the interface to make the editing easier.

Jvoytek - Apr 06, 2011 03:30:17 pm

It would be really cool if you could move from the GUI to code and back again. For example, you create a simple line graph, export the code then modify the code outside of the system (maybe the system doesn't allow for this type of modification in the GUI), then import it again and make other modifications using the GUI. Very cool idea.

Dan - Apr 06, 2011 03:33:36 pm

ProtoWiz seems very cool! I like the inheritance ideas and how you can tie different marks together. Were the images you showed part of the prototype, or mock-ups? Very good so far. The graphical (or layer) approach seems very logical, I agree, and I don’t think protovis supports that very well right now, at least there is no GUI for it. Your storyboards were really well thought out. The prototype you have is great! Very cool idea for emulating the code in a form.

David Wong - Apr 06, 2011 03:53:32 pm

I think that this is a very interesting and promising idea. I like the idea of layering visualizations as it is intuitively conveying the modular aspect of protovis. Given the feedback from others in the class, it'd be interesting to see any other related systems (eg the one for Google Charts) and see where your system is making key contributions. Also, another good thing to do is to make a list of what protovis functions are supported by your system and what are not supported. I also think that ProtoWiz could be a helpful learning tool for the language so examples of code in relation to the functions of the system would be very helpful.

Siamak Faridani - Apr 06, 2011 03:52:42 pm

I liked the demo and I believe it will be a great tool in people's toolbox. I personally look forward too seeing this tool completed. As I mentioned in class a similar tool for ggplot2 that may give you some inspiration too. I personally like the terminal/code window at the bottom and I have used it extensively to correct my R visualization and I highly recommend it to those who may do visualization in ggplot.

Web interface for ggplot2

Matthew Can - Apr 06, 2011 05:28:36 pm

This would be quite a useful tool. Aside from the layering, how are you planning to supported nested marks and their relationship to nested data? For example, I think the way Protoviz works is that if your data is an array of arrays, and you feed that into a panel, each mark in the panel gets an array. The interface for this should be easy for users to understand.

Julian Limon - Apr 06, 2011 07:33:47 pm

This looks like a great project. I think it'd be a great way to reduce the barrier to entry for those Protovis users who aren't as tech-savvy. One thing you might want to explore is to visually display the concept of inheritance in Protovis. I don't know if you guys are planning on introducing any inheritance on your layer model. I personally feel that Illustrator layers seem all at the same level. I wonder what visual cues you could explore to graphically display the Protovis hierarchy (which I for me was one of the hardest concepts to grasp).

All in all, this could be a great way to take the best of the Excel model (intuitively selecting visual elements first) and combine it with the potential of Protovis.

Krishna - Apr 06, 2011 08:20:31 pm

Very nice project ! Would it be possible to place marks on different regions of the screen towards generating small multiples ? Also, I am curious to know how marks can be reused across the visualization.

Saung Li - Apr 07, 2011 12:46:35 am

This is a great problem to tackle. It would indeed be nice to close the gap between something like Protovis, which is more technical and flexible, and Microsoft Excel, which is less technical and less flexible. What comes to my mind is Adobe Flex, where there are many common built-in widgets that people can use and then modify code underneath/around them to use them flexibly. Perhaps ProtoWiz can do something like this where users can select common features like in Excel and then have the option to modify them.

Sally Ahn - Apr 07, 2011 01:46:33 am

I agree with the many comments that this could be a very useful tool. How much flexibility/control would the users have over their data? For example, if they want to filter the data by some attribute, they may need to view or modify the JSON data. This may not be much of an issue if you limit the scope to static visualizations.

Michael Porath - Apr 07, 2011 04:21:42 pm

Ooh, I'm so looking forward to using that :) Some of the comments in class mentioned that it would be helpful to create the first rough draft of a visualization with the tool and then refine programmatically. I would argue that the other way round would make as much sense, if not more. Imagine one could upload an existing visualization script, and then change the parameters on existing marks. From my experience, lots of time goes into the visual polish and the fidelity of the graph. The constant back and forth between source code and visualization is tedious, and your tool could speed up that process and allow for more experimentation.

Michael Hsueh - Apr 08, 2011 02:06:10 am

A cool and very useful project! I really like the idea of dropping the learning curve for generating visualizations while still supporting the most common / useful visualization options. As for supporting interaction, a similar approach of providing useful "templates" might work. For example, any given element/layer might have a checkbox for being "selectable." Selectable elements might naturally have a standard type of hover-over pop up display that shows information (what exact information can, again, be templatized). This tooltip might be enabled for elements via another checkbox. Perhaps another standard interactive template that can be applied is dragging, which might be more complicated as it presumably involves altering the runtime dataset, but might still be do-able.

Karl He - Apr 08, 2011 11:22:34 pm

I think it would help a lot to work on the layer-input form to be more natural, to make this a tool that an average person could use. The relationship between layers would likely be hard to hold in your head without having to worry too much about how exactly to implement a layer.



[add comment]
Personal tools