High-level Concepts of Interactive and Web Graphics
Duncan Temple Lang
University of California at Davis
Department of Statistics
4 | Goals of the session are
5 |
to introduce you to a variety of tools that you can use immediately to create interesting displays, dashboards, etc.
to explain the architecture involved so that you can go further than simple use of the tools
6 |
7 | These tools provide "instant" gratification (once you learn the basics).
8 | However, it is very important that you focus on using the tools to present the data clearly
9 | and offer insight for the viewer. It is easy to produce bad displays, and to focus on the "glossy", "moving"
10 | things.
11 |
12 | Interactive displays are very different from static plots.
13 | When we create a static plot, we make decisions about what is in the plot
14 | or not, what to emphasize. We are in charge of what the viewer sees.
15 | For an interactive plot, we still get to make many decisions
16 | that limit what the viewer can see. However, when the viewer
17 | sees the display, she can change it via the user controls we provide.
18 | We are providing the viewer with a process for exploring the information
19 | in the plot in her own way.
20 |
21 | Interactive plots are verging on software, and many are full-fledged
22 | pieces of software. Therefore, we need to incorporate best practices
23 | and considerations for both user interface (UI) and user experience
24 | (UX). We have seen best practices and considerations for static
25 | plots. These also (generally) apply to interactive plots, and we also
26 | have to consider dynamic, interactive best practices.
27 |
28 | We need to
29 |
consider what the viewer may want to do,
handle errors
provide feedback and suggestions
use clear interfaces with documentation. Often they will not be intuitive to everyone.
30 |
31 | There are many ways to create interactive plots. It is somewhat of a
32 | wild-west out there. Things are converging and approaches are being
33 | integrated. There are still a lot of tradeoffs. While many of you
34 | will want to quickly create standard plots, others will want to create
35 | non-standard plots and will have to work harder as there may not be
36 | existing functions to create those plots. Regardless, it is helpful,
37 | if not very important, to understand the fundamentals of the
38 | mechanisms that make all of this possible and to be able to go below
39 | the high-level interfaces.
40 |
<aside>
41 | I'm a big believer in minimizing the discontinuity in programming when dealing with problems.
42 | In other words, I don't want to have a situation where it is easy
43 | to do one thing, but a slight variation in that means an entirely different approach and
44 | having to learn a new software system or computational model.
45 | For this reason, I like to know how things work and be able to use the primitives
46 | when we need to do something slightly outside of the norm.
47 | </aside>
48 | There are (at least) three differerent styles of interactive plots:
49 | 1) stand-alone displays that contain all the information for their own interactivity (e.g. tooltips, animation in SVG)
50 | 2) displays that have client-side (JavaScript) code which updates the plot at viewing time
51 | 3) displays that need computations to be done at viewing time that can't be done in the client's browser, e.g. need to come back to R.
52 |
53 | When we are on our own machine, we don't need to care much about these distinctions.
54 | When we publish displays for other people to view, we have to consider some issues.
55 |
56 | If we are displaying data that cannot be explicitly shared in totality with viewers (for confidentiality reason or simply size of the
57 | data), but we can show summary plots, then we have to have any computations that update the display done on a server, not in each client's browser.
58 |
59 |
60 | The server does not run arbitrary code, but there are security issues that we need to be aware of.
61 | Running R on a server requires some care to ensure that people cannot inject code to expose information
62 | on the server, or delete files, or simply keeps the server busy so that other requests cannot be processed.
63 | If you build something popular, the demands on the server may be many.
64 | For personal use, or internally within an institution, this is probably not an issue.
65 |
66 | The more we can do in the client's browser, the lower the latency/delay waiting for results.
67 | Perhaps, the initial display of the page is delayed however.
68 | Ideally, display the initial page rapidly and asynchronously download additional elements
69 | we need (e.g. data for further plots).
70 |
71 | We're going to look under the hood so that you can learn how
72 | you can go further than the basics.
73 |
74 | Different Architectures for Interactive Plots
75 |
Use an R graphics device with locator() or setGraphicsEventHandlers()
PNG/JPEG files and image maps (very old)
Create plots in R to, e.g., SVG, with annotations to provide event handlers, animations.
76 |
RSVGTipsDevice
svg() graphics device and then post-process the SVG content to add tooltips, animations, event handlers - SVGAnnotation
Add SVG content to R objects in grid plot and generate SVG - gridSVG
77 |
Within R, create JavaScript, HTML code that will create the plot in the Web browser when loaded
Create HTML document whose sub-contents will be updated at
78 |
79 | Creating object-based pots where the elements in the plot is quite different
80 | from the R style of graphics.
81 | We can change the characteristics of an element and it will be immediately updated.
82 |
83 | Object-based displays are problematic as the number of elements grows.
84 | This is true of vectorized plots also.
85 | Instead of having a fixed number of pixels based on the dimensions
86 | of the raster image, object-based plots have as many elements as
87 | there are observations (or more).
88 |
89 | If you know R, it may be easier to create HTML, JavaScript code, etc. in R.
90 | Programmatically generating content is a good idea when it removes repetition
91 | (e.g. creating checkboxes for 100 senators) or we want to reproduce this in different ways.
92 | However, it adds an additional layer between the output we create and the input that creates it.
93 | This can make it difficult to create the final document we actually want.
94 | Furthermore, it often complicates debugging both the page generation and also
95 | the run-time behavior of the page. This is because we have to fully understand
96 | how and what the layer is generating.
97 |
98 | Client-server code is hard to debug since there are two agents involved.
99 | We can run the R shiny server interactively and catch errors.
100 |
101 |
102 | http://timelyportfolio.github.io/gridSVG_intro/
103 |
104 |
105 | Linked plots
106 | Brushing
107 |
108 |
109 | animation
110 | Simple sequence of images
111 | Object-based animation.
112 |
113 |
114 |
115 | Basics of Stand-alone
116 | tooltips
117 | highlight (e.g. a point, a line)
118 |
119 |
120 | Off-The-Shelf Approaches
121 |
122 | googleVis
123 | https://developers.google.com/chart/
124 |
125 |
126 |
127 |
128 | Maps
129 | chloropleth maps. Good choice of colors vital.
130 |
131 | Google Earth
132 | allows the viewer to add/remove other elements/layers, control time window,
133 |
134 | RgoogleMaps
135 | ggmap
136 |
137 | rworldmap, rworldxtra
138 |
139 | par(mar = c(0, 0, 0, 0))
140 | plot(getMap("li"))
141 |
142 |
143 | plotKML package
144 |
145 |
146 | Linked maps
147 | file:///Users/duncan/Projects/NSFWorkshops/Visualization/maps/DistributionsMap.html
148 |
149 |
150 |
151 |
152 |
153 | HTML, CSS, JavaScript
154 | www.w3schools.com
155 |
156 |
157 |
158 | ExcitedRW: Click on a boxplot of timings, show code corresponding to that implementation.
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 | D3
167 | /Users/duncan/Projects/Visualization
168 |
169 |
2 | This is content that we write in a separate file.
3 | It is regular HTML
4 | with links and images 
.
5 |
6 |
7 | 
