Criteria for Creating User-Friendly Interactive Network Visualizations

As a newcomer to the Digital Humanities, I first encountered network visualizations in early January of 2012; given my near-total inexperience and ignorance, there are doubtlessly more qualified people to write about the positive and negative qualities of such visualizations. However, I may have something valuable to contribute, precisely because I have attempted to navigate and make sense of these visualizations as an outsider.

When I began examining interactive network visualizations, I often found the internal logic and criteria used to create them baffling or arbitrary; however, I also found some visualizations to be completely intuitive. In an attempt to put my finger on the differences between these two sets of visualizations, I composed a list of features without which I was invariably lost. Eventually, this list grew into a set of criteria for generating relatively transparent and user-friendly network visualizations. I hope this set of criteria can be of use to someone:

1. Consider the reason for everything (including the criteria for item selection and identity, significance of physical space and distance between nodes, nature of relationships suggested by lines connecting nodes, how values are assigned to nodes, etc.), define discrete criteria, and be consistent
2.  Explain the reasons for everything; a visualization can be useful to its creators without this step, but will not be useful (or worse still, will not be used correctly) by others unless the reasoning behind a visualization is clear; all visualizations should be accompanied by methodological explanations if they are to be of use to the wider community
3.  Beware the argument of false analogy: the reduction of real-world items to nodes connected by lines is intrinsically metaphorical and can lead to false conclusions when nodes are used in ways that do not fit with the definitions of the nodes themselves, the nature of the relationships between them as defined in a visualization, or both; each visualization is a metaphor, and errors occur when arguments are made that take any metaphor too far; this is a particular danger when inheriting visualizations or visualization frameworks
4.  There is a tendency for network visualizations to decrease in utility as they increase in size and complexity. However, there are ways to counter this:   
• A text search option (a must)
• Enabling the application of multiple filters (it is typically not enough to highlight items selected by certain criteria, and there should be a way to eliminate the other data in a refined visualization); ideally, an interactive visualization would combine predefined and user-generated filters
• The reasoning behind these filters should be made explicit, as per points 1-3 
• If necessary, minimize interconnectivity and network density (everything can connect to everything else, but if it does, relationships are probably defined too generally to be useful – or nodes are not defined discretely enough)
• In the case of 3D visualizations, the depth of visualizations ought to be considered carefully; particularly in spherical visualizations, field depth often makes it difficult to see anything but the nearest surface (to such a degree that the outer surface of such a visualization may as well be opaque, for all the good its transparency does); often, opacity would be preferable, in fact, as the background noise in a 3D visualization can be extremely distracting
5. Visualizations ought to be supplemented with a text version of the data that that is being represented (I have not yet found this, but it would be extremely useful); though unexpected patterns can sometimes “jump out” of visualizations – to use the preferred metaphor of many visualization proponents – they can also jump out of raw data
6.  Enable an ordered way of entering complex or chaotic visualizations; something as simple as an alphabetized list of nodes linked to the visualization could make it much easier to access a visualization for a specific purpose (creating an arbitrary demarcation point is undesirable for a variety of reasons, but this would be preferable to no demarcation point)

Here are a couple of visualizations to consider:

GE. “Healthymagination.” http://visualization.geblogs.com/visualization/network/.

This visualization does many things effectively. First, it provides two distinct layout options (Images 1.1 & 1.2); given the complexity of this network, the ability to change perspective is very useful.

Image 1.1

The circular mode of visualization (1.2) is particularly useful because of the lack of labels and greatly varied type size in the first mode of visualization – though the latter remains somewhat of an issue even in the second mode of visualization.

Image 1.2

Even in the first mode of visualization, steps are taken to offset the lack of visibility created by the field depth and network density. Most significantly, a text box appears with information about a given node when the mouse pointer is placed over that node (1.3).

Image 1.3

In addition, this visualization provides both a useful set of predetermined categories, which greatly reduce the displayed information when selected (1.4 & 1.5), and a functional search option.

Image 1.4

Image 1.5

Finally, while this visualization does not provide access to raw data outside of the visualization, it does provide some information (though nowhere near enough) about both the reasoning behind the visualization, and the associated data (1.6).

Image 1.6

Moebio. “Spheres: Spherical Surface of Dialogue.” http://moebio.com/esfera/sphere/esfera.htm.

There are several issues that severely limit the utility of “Spheres.” First, the visual depth of field greatly limits the ability to be able to identify a significant number of nodes simultaneously (2.1).

Image 2.1

Even though there is a “point of vue” option that allows one to zoom in (2.2), this option does little to improve the situation; the zoom is not variable, and the pre-set zoom does not move to a distance that improves overall visibility.

Image 2.2

Although dragging the mouse causes the sphere to rotate, a large percentage of the nodes remain difficult to perceive simply because such small a portion of the nodes appear within a readable range. An option that would either flatten the sphere into two dimensions or reduce the field depth would solve this problem. In addition, a text-box that appears when the mouse pointer is placed over a node (as is shown in 1.3) would make it possible to see the connections between points on opposite ends of the sphere. As the visualization exists now, it is extremely difficult to seek and select a specific node the rear half of the sphere; connecting nodes on opposite sides of the sphere is virtually impossible.

Furthermore, the explanations for network connectivity are often arbitrary, pointless, and baffling. For instance, when selecting “pleasure” and “a white tiger,” the explanation that appears is “VWYEHRIFN” (2.3).

Image 2.3

Though “VWYEHRIFN” may mean something to someone, it means nothing to me; as nothing appeared when I entered this into google, I suspect that others are likely to find this explanation equally perplexing.

The issue here seems to be that the relationships between items are generated by the users, who are able to define or refine the relationships between any items they select. While this seems to bring an element of democratic collaboration to “Spheres,” it has the potential to undermine both the legitimacy of the connections drawn and the consistency of the types of relationships defined by the lines connecting nodes. (Incidentally, before capturing Image 2.3, I had intended to connect “pleasure” with “desire,” but as the footprint of the “a white tiger” node was too large to allow items near it to be chosen, I inadvertently selected “a white tiger.” When I repositioned the sphere and successfully connected “pleasure” with “desire,” no relationship appeared.)

Manicules: post-publication discussion

I want to use the opening sentence from the ArchBook entry on Manicules by Voytek Bialkowski, Christine DeLuca, and Kalina Lafreniere as a starting point for some post-publication discussion.

“While a manicule (fig. 1) may vary in size, shape, and quality, ranging from the simple outline of a hand (fig. 2) to a more detailed sketch featuring ornate sleeves and cuffs (fig. 3), the unifying characteristic is that of an extended index finger pointing towards a specific selection of text.”

What is striking about images two and three referenced in the opening sentence above is how much they differ (see the entry for comparison). While ms. manicules were widely used for notetaking in books and manuscripts of the medieval and early modern periods, no two readers’ manicules ever look the same. Indeed, the manicule image shown below is particularly interesting in this regard.

Gualterus Burlaeus, Burleus super octo libros Phisicorum Venetijs, Impressa p[er] S. de Luere, iussu A. Torresani de Asula, 1501. sig. B4r. Image Courtesy of the Thomas Fisher Rare Book Library.

While at first glance it would appear we are looking at the standard pointing finger, what we are actually looking at is a quill (and an active quill) that is indexing and underlining at once. This reminds me of how personalized handwritten annotation is as an activity, and it makes me wonder if we can say the same about annotation in digital environments? I can choose a bullet, a star and any number of symbols from Microsoft Word for annotating, listing and classifying material, but the key difference is that I didn’t actually design the symbol. Does it matter that we choose a symbol rather than design it when we annotate online? Another question: How global is the history of the manicule?