We automatically generate Euler diagrams that are too large to be readable on screen con gurations commonly found in Universities and o ces. We discuss how principles from information visualisation can be employed to render large diagrams intelligible. Furthermore, concrete examples implementing these information visualisation principles are presented. This work is at an early stage of development.
{ overview rst, { zoom & lter, then
Example implementations of these principles can be seen in gures 1a, 1b and 6a respectively. The examples in gure 1 are drawn from the domain of computer games. In gure 1a a small scale map of the virtual world can be seen in the top right. It abstracts the graphical detail of the game in order to provide the player with an understanding of their situation within the game world. An implementation of a semantic zoom operation within the game, gure 1b, presents the possible area into which a particular game character (i.e. pawn c2) can move. Finally, details of the previous game moves can be accessed on demand, as seen in gure 6a. We now outline the structure of our discussion of how these operations can be applied to large Euler diagrams.
In section 2 we explain how we pragmatically generate large Euler diagrams. Following that, we provide examples of implementing overview functionality for large Euler diagrams; section 3.1. We proceed to address the zoom & lter concerns of Shneiderman's mantra in section 3.2. Thereafter, in section 3.3, we discuss the kinds of details-on-demand that are likely to be required in large Euler diagrams. Finally, we conclude with a discussion on how we expect to develop this work. 2
To generate large Euler diagrams, we rst generate Euler diagrams containing
a small number of contours. Following [
The abstract syntax of an Euler diagram is described by the tuple hC; Z; Z i where: C is a nite set of contours, Z is a subset of PC and denotes each zone of the diagram, and Z is a subset of Z and denotes the shaded zones within a diagram. Our presentation of a diagram zone di ers from some of the literature on Euler diagrams. In the literature it is common to present a zone as a partition of C of the form (in; out) where in C and out = C in. The above de nition of zone matches the implementation within iCircles, where it is assumed that all contours in C appear in a concrete diagram.
An arbitrary Euler diagram is generated where d = hC; Z; Z i such that C is a set of contours. In theory the set of zones, Z, is an arbitrary subset of the set of all possible zones generated from C and Z is an arbitrary subset of Z. The inductive circles algorithm then produces a concrete layout from this abstract description. In practice, the iCircles implementation of the inductive circles algorithm contains faults that limit it to generating concrete layouts for abstract descriptions that describe sparse Euler diagrams. For n contours, the most sparse Euler diagram contains n contours that are pairwise non-overlapping, the least sparse diagram is Venn-n. Hence, we accede to pragmatism and take a heuristic approach when generating Euler diagrams. We can reliably generate arbitrary Euler diagrams with up to 6 contours. For higher numbers of contours we must enforce sparseness heuristics. Improving the implementation of iCircles remains a priority for future work.
Our heuristics for generating sparse Euler diagrams are implemented as a
generator for arbitrary instances [
Having seen examples of overview, zoom & lter and details-on-demand in gure 1 we now present an examples of how to implement each of these principles within large Euler diagrams. 1 Available at https://github.com/tgdwyer/WebCola. Band
Organisation Agent
Band Organization MusicGroup { a grid system acting in a manner similar to contour lines on a geographic map, and { a smaller overview map embedded in the view. Organisation
Agent
Organization
Agent
MusicGroup Organisation
Organizton
In both of our attempts to provide overview features for large Euler diagrams we adopt well-known techniques from cartography. From the abstract description of an Euler diagram, there is no way to reason about the concrete relative position of contours x and y in a large diagram. Therefore, it remains to be seen, through user studies, whether or not large Euler diagrams lend themselves to the cartographic navigational approach. Zooming also a ects the small map. The viewport over the small map will increase in area as the user zooms out. Other concerns when considering zoom within large Euler diagrams include: { the level at which to remove information from the visualisation, and { the visual cost of not removing information from the visualisation. To explore these issues, consider the deep containment hierarchy in gure 4a. In order to reduce visual clutter in the diagram it appears reasonable to hide a number of the innermost contours from the view. Their suppression can be indicated by employing ellipses. This raises the question of how often the most deeply nested contour within the hierarchy is considered, for practical purposes, to be more important than the intermediate levels? In such cases the highest and lowest level contours can be presented and the intermediate level contours are suitably elided. However, gure 4b presents an example where the intermediate levels of a deep containment hierarchy introduce three zones at the lowest levels. Eliding the intermediate level contours in this example is not straightforward and suggests that there is no one-size- ts-all heuristic.
F E D C B
A (a)
D F E
C B
A (b)
Rather than remove information from the diagram we view ltering as the process of improving the signal to noise ratio of the visualisation. Figure 5 a user searches for the name of a contour present in the diagram. Searching for a contour name highlights all of the occurrences of that contour within the diagram, both in the main view and within the small map. Within the main view, highlighting the contour is intended to boost its signal with respect to the background noise. Highlighting a contour within the small map is intended to aid navigation when panning across a large Euler diagram.
The interaction between zoom & lter within a large Euler diagram requires further exploration. Suppose a contour is only visible at the most detailed zoom level. Furthermore, the contour has been omitted from the current view in order to reduce the visual clutter. If a user then searches for the name of the hidden contour, should it be added to the current view and highlighted, or is the lter operation restricted to searching the current zoom level? Moreover, can a general tradeo between zoom and lter be made for large Euler diagrams, or is the tradeo dependant on the domain of application i.e. should the balance be di erent when visualising a software engineering class diagram as opposed to medical information? Organisation
Agent
Organization
Agent MusicGroup Band
Organis ton provide a user with details ab out a particular contour of interest. Figure 6a is an example depicting three clusters consisting of 2 ; 3 and 4 contours. Supp ose a user is interested the details of the highlighted contour. Figure 6b uses constraint based layout to vertically align clusters containing the interesting contour. In this con guration the user needs only scroll through the list of details, rather than navigate the entire diagram
Organization (b)
Band Agent Organisation
We have presented a pragmatic approach to generating large Euler diagrams for the purposes of exploring their navigation. The pragmatic approach combines existing tools to generate small Euler diagrams that are combined into large diagrams using constraint based layout. Furthermore, we have presented an outline implementation Shneiderman's information visualisation mantra within a viewer for large Euler diagrams.
The work is at an early stage of development. Our intention is to develop
the Euler diagram generation such that it is using semantic web data from
DBPedia [