14  Interactivity, whole communications

To what use — if any — should we make of interactivity? One use, is when a static graphic does not “reveal all the relationships constituted by the interplay of the data” (Bertin 1981) relevant to our intended message. Indeed, this is frequently the case when exploring high-dimensional data. For that, consider Tufte’s advice on a design solution:

At the heart of quantitative reasoning is a single question: Compared to what? Small multiple designs, multivariate and data bountiful, answer directly by visually enforcing comparisons of changes, of the differences among objects, of the scope of alternatives. For a wide range of problems in data presentation, small multiples are the best design solution (Tufte 1990).

We’ve already discussed small multiples, reviewed an example with the Citi Bike data (maps sliced by hour of day), and interactively linked multiple graphics, including brushing and linking scatterplot matrices. Consider, too, trelliscopes (Hafen and Schloerke 2021).

Another use is to adjust the focus of particular data within the context of others. Consider whether we can more compactly represent certain views of the data through interactivity.

Interactivity can enable trust, too, as previously explained by Gregor, CIO of DataWrapper.

We should ask: can interactivity simplify, clarify, provide focus to the contextual comparisons in our messages, or otherwise allow our audience to “test” relationships with their own choice of views?

With our understanding of the foundations of interactive, data graphics, and tools to make and organize them, let’s focus now on how we can guide our audience through entire interactive communications.

14.0.1 Flow factors

McKenna et al. (2017) has studied the ways skilled practitioners guide audiences — visual narrative flow — and categorizes some approaches into “flow factors”. These include navigation input, level of control, navigation progress, story layout, role of visualization, story progression, and navigation feedback. Let’s consider these in turn.

Navigation input is the way or ways a user progresses through a communication. Common approaches are through scrolling, clicking buttons, or dragging sliders.

By level of control, McKenna means the audience’s control over any changes to the document, whether text, data graphics, or other components. Control can be discrete or continuous.

Navigation progress refers to how an audience perceives where they are within the communication. Web browsers generally provide some indication by default through the scrollbar. But other common approaches are to show a series of dots, each representing some conceptual section of the communication.

The story layout refers to the visual appearance and organization of the communication. We can use one or multiple columns of information, we can organize the overall information vertically like a document, horizontally or stacked like a slide show, or use some hybrid of these.

The role of visualization is the purpose that they serve in a communication or narrative. Are they the primary focus with annotations helping the audience through it? Do they serve to illustrate some smaller component within an overall narrative? These are the questions we ask about the roles played by our data graphics.

Story progression refers to the one or more paths for a story to unfold. These paths may be temporally and spatially linear, temporally or spatially reversed, they may skip parts of sequences, or be some blend of these ideas. Linear paths may be effective through scrolling, while non-linear paths may benefit from use of, say, a button to jump from section to section representing time or space.

Finally, navigation feedback are the way or ways the interactive document shows the audience how their input affects the communication.

McKenna et al. (2017) in their study, collected numerous examples of each of the above. Along with studying those, review the interactive communications cited in Hohman et al. (2020) to see how those interactive communications approach the above concepts.

We should keep in mind that, just as static graphics require text, so too, do interactive graphics.

And interactive documents that explain, especially using the above concepts like scrollytelling or clicking for details on demand can lead to better audience recall. See Schneiders (2020).

14.0.2 Preserving proximity

14.0.2.1 Folding details on demand

Let’s consider a potentally helpful feature: enabling the audience to click to show additional details within a html, as discussed in Hohman et al. (2020). Some implementations can be simple:

The triangle beginning this sentence, when you click it, provides details on how to implement its functionality of hiding and showing additional information.

We can “fold” any type of information, and the functionality is commonly used to allow an audience to review code — by clicking or unfolding — associated with a result (like a graphic) in the main document view. We create folding with just two pairs of html tags. The outer tags are <details> … </details> and within these, we first place the words shown with the triangle between <summary> … </summary> and follow that with the information. To learn more, consult MDN Web Docs. <details>: The Details disclosure element.

Having multiple levels of details accessible to our audience through basic interactions can help us, in some ways, to keep related content closer together, and also help focus audience attention on our narrative. Scrollable interactions provide another way.

14.0.2.2 Scrollable interactions with the DOM

To motivate one basic use of a scrollytelling document, consider our experience in any recent textbook where significant narrative was needed to understand a data graphic. Best practices where less narrative is involved, as we’ve discussed, is to integrate the data graphic directly into the paragraphs. And this follows the principle of proximity: keep related information spatially together. But the concept breaks down when significant narrative is required to explain the data graphic. Typical approaches number the figure and then in the narrative, even pages later, refer back to that graphic. The audience needs to go back and forth between the locations. The concept of scrollytelling is a potential solution in some cases. We can freeze the data graphic in place, and scroll the narrative beside the data graphic, explaining new aspects as the paragraphs move along. The principle of proximity is preserved. And with the modern technology stack, it’s getting easier to accomplish. Let’s see a minimal working example.

Let’s place a minimal wireframe of a scrollable explanation inline below. Make sure the top of the inline frame is visible in your browser viewport, and take a moment to review:

Here is the original R markdown file.

Notice that as we scroll the document, the three figures each freeze as they come near the top of the inline frame while the narrative article paragraphs continue scrolling past. Then, when all paragraphs for a given data graphic move past the data graphic, the graphic leaves the top of the view with that final explanation. Then, another section containing a new data graphic comes into view with its own paragraphs. That graphic, too, freezes until all its paragraphs scroll past, and so forth.

The basic technology stack isn’t too difficult, and only requires a few lines of html and css to get working:

First, as shown, the <figure> element must have “empty” space inside the <section> element. Think of these elements like physical boxes, a small box inside a larger box. We could move the larger box to and fro and the inside box would move (or scroll) with it. Or, by adding the css code position: sticky with a sticky location at top: 5rem,1 we suspend the <figure> element within the <section> element such that the figure remains in place while the outer <section> box moves. But when either side of the outer box contact the inner <figure> box, it pushes that inner box along with it. Here’s the r markdown file to reproduce the above example.

Of note, just as we may place these interactive scrollable explainers of data graphics inside the inline frame, above, with <iframe>2 html tags, we may also place the scrollable explainers within any css grid area we define, enabling almost limitless layouts.

Holding graphics in place as explanations scroll by are one important way we can employ document-level interactivity. First, as with data-graphics more generally, the graphics we hold in place may be interactive, whether of the htmlwidgets variety or made with d3.js or svg, among other available technologies. Second, these technologies also enable our audience actions to not only change the graphic locations or switch graphics, but we can link those actions to changes within that htmlwidet or d3.js graphic.

14.0.2.3 Interactions with data graphics triggering changes to the DOM

We just considered how to enable interactions to flow from the DOM to, for example, placement of its data graphics and text to preserve the principle of proximity and guide our audience.

We can also enable interactions to flow the other way, where data graphics made with the technologies discussed in Chapter 13 can trigger changes to the DOM using event listeners and javascript.

Using ggiraph, again, to illustrate this type of functionality, its geoms natively include an onclick listener that can trigger custom javascript. From an onclick, then, we can trigger our own javascript functions that we include between <script> tags in the html, which in turn contains our ggiraph data graphic htmlwidget. Our triggered function can, say, add or remove custom css classes to an element in the html, add or remove elements, load other documents or images within an iframe or scroll text in another grid column to a new location, just to name a few of limitless options. Really, once we have the data graphic trigger javascript, we can design any modern idea using web technologies. Let’s set up a couple of examples. For a first, example, Click a circle below to trigger an onclick event that calls a javascript function, passing it a data value, and the function adds css formatting to some text in the DOM:

This text will change when you click a circle.

Click the triangle to see the code implementation below.

The above example is contained in this text, which is an html file. It includes this data graphics code within an r markdown code chunk:

set.seed(1)

df <- 
  data.frame(
    x = rnorm(5), 
    y = rnorm(5), 
    ID = seq(5))

p <- 
  ggplot(
    data = df, 
    mapping = aes(x, y)) +
  theme_void() +
  geom_point_interactive(
    size = 5,
    onclick = paste0("myFunction(", df$ID, ")")
  )

girafe(code = print(p))

The function it calls, myFunction(), is within <script> tags, like this:

<script>
function myFunction(info) {
  var el = document.getElementById("myDIV");
  el.classList.add("mystyle"); 
  el.innerText = "The clicked circle's ID is " + info + ".";  
}
</script>

The css style class we invoke (mystyle) looks like this:

<style>
.mystyle {
  color: purple;
  font-weight: 900;
}
</style>

Finally, here is the <div> element we identified as “myDIV”:

<div id="myDIV">This text will change when you click a **circle**.</div>

If we wanted our javascript function to load some document in an iframe, we might set it up this way:

<script>
function myFunction(page) {
  document.getElementById("iFrameName").src = page;
}
</script>

where page is the name of the file (like an svg or html) we pass to myFunction() inside the onclick event listener. The corresponding iframe element in the html might look like:

<iframe id="iFrameName"  data-external="1"></iframe>

Clicking the above triangle again will hide, or fold away, these details.

This functionality isn’t exclusive to ggiraph; we just used it for illustration. plotly provides similar ways to trigger custom javascript, which is explained in Sievert (2020). So do other htmlwidgets.

14.0.3 Interactivity guides audience

14.0.3.1 Help with flow

Communication educators recognize that documents are frequently organized for the author instead of for their audience (Doumont 2009). The problem is so prevalent that with documents generally, and especially academic articles, audiences are advised to read information out of order to be more efficient with consuming the information (Pain 2016).

That may not, however, be what we as authors who follow best practices prefer or what we believe is best for our audience. Yet we have no control over how ordinary documents are consumed. Interactive documents can help us. Along with preserving the principle of proximity, interactive documents can help us guide our audience through our preferred ordering of narrative. There are many approaches, but consider that the scrollytelling layout just described, by freezing material at a location during portions of the audience’s scroll does suggest the material be read before the next section, even if the feature does not prevent an audience from skipping the material entirely.

One a general note, the best designs become invisible to our audience to let them fully absorb and engage with our content. Having these concepts front of mind as we create interactive communications will help us help our audience achieve flow3. That should be our goal.

…

14.0.3.2 Help with interactions

Some interactions may be difficult, even when their affordances are well explained and understood. Since scatter plots in various forms are both extremely important and common in data analyses, let’s consider how to improve our user experiences through an example in that taxonomy. In a scatter plot, various constrants — such as ensuring precision in decoding — may limit how we design our visual encodings.

To make the issue specific, let’s say we have a scatter plot in which measurements are positioned along an x and y axis, and we are constrained in how large we draw these observed points, either by how accurately we need our audience to locate each point’s units of measure along the x and y axes, by the spatial density of those points, or both. The smaller the points and the closer they are together, the more difficultly our audience will have in hovering or clicking on that point as a means to obtain details (like in a tooltip), filter or focus on specific encodings.

Let’s consider an example. First, we simulate some data: for each x and y value of 20 observations, we show on the graph below, and allow the user to hover to learn more information:

Now, let’s see if we can improve the user’s experience in hovering over the observation to gain information. One creative approach that commonly improves user interaction is to overlay another very special geometry called a Voronoi diagram4. A Voronoi diagram is a partition of a plane into regions close to each of a given set of objects. In the context of our example, we divide the space between observations equally distance from each x and y location. We’ll just use the euclidean as our measure of distance, but special cases may invite other ways to measure.

We next partition the spaces, shown below5:

polyclip 1.10-6 built from Clipper C++ version 6.4.0

Notice how much easier it is for the user to hover over an intended selection. They no longer have to be precise, just closer to that point than any surrounding points. We’ve left visible the partitions for teaching, but we may remove these to improve readability:

In this example, and those similar, overlaying an interactive Voronoi diagram is a very useful and creative approach to improving user experience. We used this technique for user interaction in our working example for Citi Bike: interactive version of Spencer (2019).

Take the time to find similar, creative approaches to problem-solving other issues with user experience, too.

  1. rem is a relative unit of measure, just like px for pixels is an absolute unit. See MDN Web Docs, CSS values and units.↩︎

  2. The HTML Inline Frame element (<iframe>) represents a nested browsing context, embedding another HTML page into the current one. For more information, see MDN Web Docs. <iframe>: The Inline Frame element.↩︎

  3. See CSIKSZENTMIHALYI (1991) and Csikszentmihalyi (2014).↩︎

  4. A Veronoi diagram was named after its creator, a Russian Mathematician.↩︎

  5. Various software functions are available to perform the calculations. In the example below, we use the function polyclip() in the same-named package, and then plot the resulting polygons using ggiraph’s geom_polygon_interactive().↩︎