What does Superuser.com look like? Beyond the questions, the answers, the votes, the comments, the edits, are there clear patterns of community activity? Do trends emerge? Are social norms evident? Is visualising this sort of information useful? Can visualisation support existing community processes? These are the sorts of questions we pursued with Explore.SU – a visualisation environment developed on the Superuser.com public API. In this blog post, we will take a look at the development of Explore.SU, briefly explore how online communities have been visualised to date and examine the rationale for our design decisions. We also discuss findings from a small study and draw some initial conclusions based on our experiences.

Visualising online communities

So, where do we stand with online community visualisation? The term social visualisation (coined by Judith Donath of MIT) is regularly used to describe “visualisation of social information for social purposes”. Some of the most interesting work on social visualisation has been carried out by Mark Watternberg and Fernanda Viegas during their tenure at IBM (they now reside at Google). Outside of the visualisation community, they are probably best known for ManyEyes – a community-orientated approach to the application of visual analytics.

Historyflow and Chromograms, as developed by Viégas, Wattenberg and Dave.

However, they have also developed novel, analytic visualisations of Wikipedia. Historyflow, a stratified visualisation of edit activity, for instance, emphasises patterns of coordination – as illustrated by Wikipedia talk pages – and conflict – as illustrated by the edit-war phenomenon. Chromograms, on the other hand, are data-intense, pixel-orientated visualisations of administrator activity in Wikipedia. Again, notable patterns of activity emerge such as the systematic edit – whereby an administrator systematically sets about working on a set of articles – and the reactive edit – whereby an administrator is forced into editing an article due to constant reverts or vandalism. There are, of course, other approaches to social visualisation that have had some notable influence. Kellogg and Erickson developed the idea of a socially-translucent system – an online social system that provides a certain amount of transparency through the application of social proxies. Social proxies are small visualisations that show who or how people are interacting on a thread or in a chat room. So, for instance, if someone is lurking, the social proxy will illustrate their presence – similar to the approach implemented on StackExchange chat. While over ten years old, their work has resonated widely. Ed Chi, originally of Parc and now also with Google, drew from Kellogg and Erickson’s work when developing Wikidashboard – a social analytics utility that provides a degree of transparency around the creation of a Wikipedia article.

An image of Wikidashboard, as developed by Chi, Shu and Kittur.

Given the connectivity of online conversations, social network visualisation has also featured. One of the first approaches was Sack’s conversation map, however, other researchers have used node-link (network-based) visualisations on Usenet to illustrate the emergence of social roles.

.

An image of Honeycomb by van Ham, Schulz and Dimicco, and MatrixExplorer by Henry and Fekete.

More recent research on social network visualisation has sought to deal with the difficulties of scale, an issue of importance given the scale-free topologies of large online social systems (such as Stack Overflow or Super user). Node-link visualisations are generally incomprehensible with networks of over 150 nodes and tend to handle change rather inelegantly. Two researchers, in particular, have investigated the use of matrices for visualising large social networks. The first is Nathalie Henry, who is now at Microsoft, and the second is Frank van Ham, who is with IBM. Honeycomb, by van Ham, visualises large social networks (of over 150 million nodes) through the application of organisational hierarchies, while MatrixExplorer, by Henry, visualises large social networks through the application of clustering techniques.

Explore.SU

Several design decisions informed our approach to Explore.SU. First, we wanted to capture the dynamics of the entire community (to provide a sort of map of Superuser.com). We also wanted to visualise the communication acts (answers, comments, etc) in the community. So, for example, we could capture connections between different users or sections of the community. We choose to use a matrix, as opposed to the more familiar node-link visualisations. However, this approach still required the use of an abstract representation as, given the size of the community, rendering a single one-to-one matrix is unfeasible. We choose reputation, after experimenting with tags, badges, etc. Second, we wanted to see could we develop a relatively simple mechanism for performing temporal analysis. So, for instance, a user could examine network spread or identify sudden and emergent shifts in activity. To achieve this, we took a nightly snapshot of community activity, using the public API, and provided a simple slider to enable the user traverse across different days. Third, we wanted to develop the tool as a community artefact. To this end, we implemented simple annotation and collaboration tools with the aim of exploring the possibilities of collaborative analysis.

A screen shot of Explore.SU. The Matrix visualises the communication acts (such as question/answer) in Superuser.com for a given day.

Was it successful?

From a research perspective, several notable points emerge from our experience with Explore.SU. The first is that the tool needs improvement. While it provided a certain degree of insight, the level of insight was limited and could be improved significantly with further iterations. The second is a need to clarify context. While receiving some positive feedback, we also received less positive comments such as “meh” or “what’s the point”. These comments help, for instance, to raise the question of how to develop visualisations that address specific community needs or concerns. Or, for example, how can visualisation support certain community roles, such as moderator, or be used to assist the more casual community member. Finally, we probably focused a little too earnestly on developing a collaboration tool, which resulted in an under-developed approach to visualisation. Some users expressed frustration at no being able to delve deeper into the data or compare and contrast different sections of the data.

Room for improvement

So, where does this leave Explore.SU? First, there are clear limitations with the current implementation. Users must be able to filter on user, or user type, as well as filtering on user action, or indeed a combination of all three. Second, time needs to be addressed differently. Currently, time is divided into single 24 hour units and the activity for each unit is reflected in the matrix. This provides a very static representation of time, which inhibits a deeper level of analysis. Users must be able to adjust the time interval to include weeks or months and to compare activity across different time spans. The well articulated information visualisation mantra – overview, zoom & filter, details on the demand – could, in fact, be applied with a little more fidelity on future iterations. Third, as opposed to visualising the communication flows in the community, a more beneficial approach may seek to address, or indeed illustrate, significant change across the community. Simple change detection algorithms could prove very effective in this context. Finally, from a technical perspective, Explore.SU was implemented in Java, and may benefit from a port to javascript.

Conclusions

As a first outing, Explore.SU has not fared too badly. While it is clear that the current implementation requires work, it has enabled us to put some early ideas into a more material form. I think that for visualisation to be successfully adopted into a community work-flow, to have genuine and lasting reach beyond the lab for instance, there needs to be a tighter integration between requirements and implementation. Drawing from these experiences, we aim to iterate on Explore.SU over the coming months. Hopefully, we can drive each iteration with some feedback from the Superuser.com community!