-
Notifications
You must be signed in to change notification settings - Fork 31
Animated interactive plots (animint)
Animint is an R package for making interactive animated data visualizations on the web, using ggplot syntax and 2 new keywords:
- showSelected=variable means that only the subset of the data that corresponds to the selected value of variable will be shown.
- clickSelects=variable means that clicking a plot element will change the currently selected value of variable.
Toby Dylan Hocking initiated the project in 2013, and Susan VanderPlas (2013), Carson Sievert (2014), Tony Tsai (2015), Kevin Ferris (2015), and Faizan Khan (2016) have provided important contributions during previous GSOC projects.
Standard R graphics are based on the pen and paper model, which makes animations and interactivity difficult to accomplish. Some existing packages that provide interactivity and/or animation are
- Non-interactive animations can be accomplished with the animation package (animint provides interactions other than moving forward/back in time).
- Some interactions with non-animated linked plots can be done with the qtbase, qtpaint, and cranvas packages (animint provides animation and showSelected).
- Linked plots in the web are possible using SVGAnnotation or gridSVG but using these to create such a visualization requires knowledge of Javascript (animint designers write only R/ggplot2 code).
- The svgmaps package defines interactivity (hrefs, tooltips) in R code using igeoms, and exports SVG plots using gridSVG, but does not support showing/hiding data subsets (animint does).
- The ggvis package defines a grammar of interactive graphics that relies on shiny’s reactivity model for most of its interactive capabilities (animint does not need a shiny server).
- Vega can be used for describing plots in Javascript, but does not implement clickSelects/showSelected (animint does).
- RIGHT and DC implement interactive plots for some specific plot types (animint uses the multi-layered grammar of graphics so is not limited to pre-defined plot types).
For even more related work see the Graphics and Web technologies task views on CRAN, and Visualization design resources from the UBC InfoVis Group.
The most important project that would result in animint being easier to maintain would be a fork (animint2 package) that changes the API, and no longer depends on ggplot2. Animint currently works with ggplot2 version 2.1 (faizan-khan-itt/ggplot2@validate-params fork). However, in recent experience, it has proven too much hassle to depend on ggplot2; its API has changed several times in the past few years, and we are only able to update animint months later. Also, it seems that the most common issue that animint users have is that they do not have the correct version of ggplot2 installed. Furthermore, there are several issues which render the newest version of ggplot2 fundamentally incompatible with animint, e.g. it is impossible to disable warnings. Thus, it would be best to rewrite the package entirely as animint2:
- copy basic geom code from ggplot2 to animint2, remove dependency on ggplot2.
- new animint2::ggplot_build function which is aware of animint’s interactive capabilities, and can be called once to produce the info we need for rendering (in contrast, the existing ggplot2::ggplot_build function is called multiple times in our code).
- object-oriented animint2 internals — replace current if(geom==”point”) with methods inside of geom definitions. The code specific to
geom_point
would go insideGeomPoint
methods, whereas code that works on all geoms (e.g. saving tsv files to disk) would go insideGeom
. - remove clickSelects/showSelected/etc aesthetics, and instead use params: currently we write
geom_point(aes(xVar, yVar,
clickSelects=clickVar,
showSelected=showVar, showSelected2=showVar2,
showSelected.variable=selector.name,
showSelected.value=selector.value,
))
and in the new version we would write
geom_point(aes(xVar, yVar),
clickSelects="clickVar",
showSelected=c("showVar", "showVar2", selector.name="selector.value"))
- keep all test cases, but re-write them to work with the new syntax.
- introduce dependency on data.table, so that data visualizations with large data sets can be compiled faster.
- try to maintain syntax compatibility with existing ggplot2 as much as possible, so users can transition easily to animint2. Keep
geom_point
or introduce newgeom_point_animint
or just useanimint::geom_point
?
An ideal student project also will implement several new features to Animint, and also write some tests and documentation (vignette, web page, blog). Some important items from the TODO list:
- Upgrade to d3.js version 4, which makes data join easier. The new
merge
function allows combining the ENTER and UPDATE selections, which reduces duplication and can make animint.js code easier to understand, as explained in this article. - htmlwidgets/crosstalk support – see how Carson did this with plotly.
- New aesthetics that only make sense on the web/SVG (not in ggplot2), for example an aesthetic for stroke-opacity and fill-opacity.
- Support for multiple clickSelects aesthetics per geom.
- Currently, selected items in Animint are shown with a black border outline stroke for rectangles, and with 0.5 more alpha transparency for all other geoms. This should be configurable using new aesthetics such as selected.color, selected.alpha, etc.
- New hoverSelects aesthetic which updates the selection just by hovering the mouse over an element, including tests that simulate mouseover/mouseout events.
- Last year Faizan implemented updating of axes/legends after changing the currently displayed data subset. Currently the computations are done in the compiler but there are some limitations (ask @faizan-khan-iit), so it would be preferable to move the computations to the renderer.
- Compute stats based on the current subset, e.g. total homicides, maybe animint syntax like this.
Any other ideas for improving Animint are welcome as well!
Animint already provides useRs with some unique features for interactive data visualization. At the end of GSOC, the animint package will have even more features, more unit tests, more documentation, and perhaps be more portable (work without dependency on ggplot2).
YES. If you don’t know JavaScript then I suggest you read some tutorials, e.g. Mozilla JavaScript basics, W3Schools, mbostock’s blocks examples.
Please get in touch with Toby Dylan Hocking <tdhock5@gmail.com> and Carson Sievert <cpsievert1@gmail.com> after completing at least one of the tests below.
NOTE: we already have found a very good student, Faizan Khan, who we expect to apply for this GSOC project. Please be aware that there is usually only 1 student per project in R-GSOC. However we definitely could make an exception if we find a student who can provide amazing results for the following tests.
Do one or several — doing more hard tests makes you more likely to be selected.
- Easy: use Animint to visualize some data from your domain of
expertise, and upload your visualization to the web using
animint2gist
. - Medium: translate an examples of the animation package into an Animint. Do not do one of the examples that has already been ported. Post a link to your result on the Ports of animation examples page on the Animint wiki.
- look at source code of one of the animation package functions e.g. grad.desc() for a demonstration of the gradient descent algorithm. Translate the for loops and plot() calls into code that generates data.frames. In the grad.desc() example, there should be one data.frame for the contour lines, one for the arrows, and one for the values of the objective/gradient at each iteration.
- Use the data.frames to make some ggplots. In the grad.desc()
example, there should be one ggplot with a
geom_contour
and ageom_path
, and another ggplot with ageom_line
that shows objective or gradient value versus iteration, and ageom_tallrect
in the background for selecting the iteration number. - Make a list of ggplots and pass that to animint2dir. For the grad.desc() example the plot list should be something like list(contour=ggplot(), objective=ggplot(), time=list(variable=”iteration”, ms=2000)).
- Medium-Hard: write a testthat unit test based on one of your Animint visualizations. Fork animint and add a renderer test (using animint2HTML) to tests/testthat/test-renderer3-YOUR-TEST.R, then send us a Pull Request.
- Hard: show us your level of JavaScript coding skills. Fork the animint source code on github, then implement one of the RENDER items on the TODO list, then send us a pull request.
- Students, please post a link to your test results here.