Euler Diagrams are an accessible means of representing non hierarchical set-based relationships which have recently been used in resource management interfaces to facilitate user categorisation. We develop a novel, extensible Euler diagram based interface, called FunEuler, which integrates the concepts of visual classification, spatial arrangements and functional application, thereby greatly extending the power of such Euler diagram based interfaces by enabling fast application of a collection of predefined functions to collections of categorised resources. To demonstrate the principle, we provide several functionalities such as file zipping or creating playlists within the application, whilst also providing a mechanism to extend the functionality to facilitate end user development. Preliminary user testing suggests that the Euler diagram concept is easily comprehensible for resource categorisation purposes, the concept and application of functions can be understood and applied successfully, and that users perceived the addition of functions increased the usefulness of the application for repetitive tasks.
User based resource management tasks such as file categorisation are clearly important
tasks and yet there are serious limitations within current methodologies to assist users.
The traditional hierarchical-based representations are well known to have limitations in
the realms of user categorisation, with difficulties occurring when a user wants to
categorise resources in more than one place, to change the categorisation structure, or to
perform operations on sets of resources that are spread over multiple directories. An
alternative methodology is via tagging, and there are methods to handle specific resources
such as mp3’s or particular types of tagged documents, but they can be problematic if
the user wishes to utilise file type based methods for types such as TeX or eps, for
instance; also, tag-based methodologies have the downside that documents with missing
or mis-typed tags may be omitted from searches, for example. Some modern operating
systems do allow the use of facilities for both tag and file-type based save, search and
retrieval methods. As a proposed alternative approach, Euler Diagrams are a means of
representing non-hierarchical set-based relationships. They have recently been used in
resource management interfaces to facilitate user categorisation, in [
Copyright c 2012 for the individual papers by the papers’ authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors.
Looking from another perspective, we know that the organisation of desktop files or
links into groups can enhance working memory by utilising the spatial information [
To provide a concrete motivational example, we present one of the user based scenarios that we have developed,set within the mp3 application domain. Then, in Section 2, we provide Euler diagram interface background information and describe related works. The application is described in detail in Section 3, and some preliminary user testing is reported in Section 4. Subsequent to the user test, we developed a specialisation of the FunEuler interface within the music domain, providing an indication of how the interface can be specialised to cater for domain specific applications; this is reported in Section 5. Conclusions and future work avenues are suggested in Section 6. User based scenarios. Let us imagine George, a local student DJ, who often creates music based gifts for his friends as well as constructing larger distributions. Related tasks that he performs include: selecting a collection of mp3 tracks and creating a playlist; naming the playlist and printing out the tracklist as a PDF; zipping a playlist together with a tracklist, or collections of these; emailing the zip file, or uploading it to a musicsharing website; creating multiple zip files of playlists, together with tracklists, plus a global list of the zipped packages in order to distribute more efficiently. By developing a spatial palette (which is a virtual space in which he can arrange his resources and have the facilities to apply the relevant functionalities to them) we will assist George in performing his tasks more efficiently. To gain long term benefits, he would also like to store his music files in an accessible manner, and related tasks he performs include: categorising a collection of mp3 files, building a structure to hold them, storing (or tagging) the created zip files appropriately. These tasks are also facilitated via the use of an Euler diagram based structure and interface.
Venn diagrams [
Related Work. A clickable Venn diagram interface was developed in [
Venn diagrams have been used to represent non-hierarchical directories,
replacing the traditional hierarchical structure of file systems [
There has been relatively little actual user testing of the Euler diagram concept, with
the idea generally being taken for granted as being beneficial. In [
Background. We view the zones of an Euler diagram as a repository in which to place
resources, such as files and urls, and so the basic notion of Euler diagrams is
extended to capture the placement of items in the diagram; this is similar to unitary alpha
Spider diagrams in the diagrammatic logic context [
We describe the FunEuler interface, together with justifications for the design decisions
adopted. In Figure 1 a screenshot of the new FunEuler application developed is shown.
The application is available at [
We allow users to construct a diagram by adding curves, in the form of ellipses, one at
a time by a simple mechanism of left click and drag to specify one axis whilst using
the mouse scroll wheel to specify the other axis (cf. Figure 2 top-left). This allows
fast user construction of the diagrams, as well as a fast interpretation of the zones of
the diagram [
At the moment of creation of a curve, the system automatically assigns a random colour to the curves, as well as a choice of set name (according to a predetermined sequence), but these names and colours can be then edited by the user. This facilitates rapid user construction of diagrams via ellipse addition without the interruption of naming and choosing a colour for each curve, which could interrupt the flow of creation. The collection of parameters associated to each ellipse are easily accessible through a pop-up menu via a right-click action (cf. Figure 2 top-middle). Existing ellipses can be quickly modified by translation, rotation or by altering the size of its axes.
Although the general advice would be that users constructing categorisation diagrams should keep them as simple as possible, human readers of diagrams may have difficulties identifying zones correctly if complex diagrams which have small zones with a lot of bounding curves, or if zones are complex spatial regions (e.g. in the general case they can be disconnected or non-simple regions) are constructed. Therefore, we assist in helping a reader to understand a categorisation by providing the possibility of querying a zone: by selecting a point p within any zone using the eyedropper the entire zone containing p is highlighted, and the zone descriptor displayed in the status bar (cf. Figure 2 top-right).
To aid user navigation within larger diagrams, we allow the usual scrollbars for horizontal and vertical directions, but we also provide spatial zooming: this is accessed via a select zoom option and mouse wheel scroll in and out, providing a larger working area when needed. This facility is likely to be useful in cases when users are working with a lot of categories, or when there are a large number of items in an intersection of categories and one needs to enlarge the working space (i.e. to enlarge the region that is the spatial palette under consideration).
Item management. We utilise a drag and drop protocol for resource classification, simply placing items within the relevant region of the diagram. Item properties are visualized through tool tip text while the status bar, at the bottom of the interface, provides its current categorization (cf. Figure 2 bottom-left). Each item can be interactively repositioned and consequently re-classified. In order to not restrict the selection (and hence the functional application) of items to those sets of items corresponding to entire zones we also allow the selection of multiple items via a common box-selection (cf. Figure 2 bottom-middle/right). At the core of the FunEuler functionalities is the ability to select and apply one, or more, operations to regions of the diagram. Performing operations on zones uses the familiar drag and drop: the user simply drags the operation icon onto the desired zone of the diagram. To perform operations on multiple zones (or similarly for other selected sets of items), the user must first perform a selection (by using the eyedropper) on all of the zones that he/she wishes to apply the operation to, and then drag the operation icon onto one of the selected zones.
To demonstrate the principal of functional application within the Euler diagram structure we developed several operations including: zip (which individually zips all files in a region, creating a collection of zip files), ZipToSingle (which zips all files in a region to a single zip file), createplaylist (which creates a playlist when applied to a collection of mp3 files) and search (described below).
Tagging and Searching. The Euler diagram based interfaces commonly have a means to export to a tree based file system using conjunction of categories as node labels. However, we provide some specialised tag-based support for this interface. In general item tagging can be performed by adding information “inside” the item (e.g. utilising the genre field for mp3 files or tag data for office documents) or “outside” by utilising an item tagging database.
Now, if diagrams contain a large number of items then the user’s ability to find and use specific items may be adversely affected. Therefore we offer the user the option of hiding tagged items, so that a user can hide items classified within the zone, thereby controlling what is actually visualised. Then, users can display tagged items by using a specific Search functionality, which displays all of the items whose tags correspond to the appropriate intersection of categories. We have developed a simple yet powerful Search functionality that relies on the Windows Search feature (which was introduced with Windows Vista/Seven) which allows the user to query, using an SQL-like language, the SistemIndex catalogue of Windows machines; since we offer support for this kind of operation we have access to functions for searching and modifying tags. Developing new functions. FunEuler is designed to let the user to program to extend its functionalities. The very essence of the operational application within the interface is allowing users to assemble operations and this could be viewed as building a simple program or macro to support their tasks. The interface allows programmers to develop new operations by using their favourite scripting language (e.g. php, python, etc). Indeed, FunEuler provides access to two lists for the items and the zones that the operation is to be applied to: one list containing the pathnames of the items and the zones they belong to, and another list reporting the zones and the items that each zone contains. Each operation can produce zero, one or several files as result. As an example, the zip file operation produces a zipped file for each pathname in the input list, whilst the zip to single file operation produces one single zip file containing all of the files of the input list. On the other hand, the send by email operation does not produce any result files. Independent of the number of files produced the Results pane supports their representation in a special single-curve ED, where file icons are automatically placed within the curve representing the results set.
Closure. The application of an operation to a region of a diagram causes the generation of a new diagram in the Results part of the application window, and since the Results set is a diagram in its own right, operations can be applied to it generating a new Results diagram arising from the sequential application of the selected operations. Thus we can view the class of diagrams in FunEuler as being closed under the application of operations. Figure 3 shows the operations’ icons within the Results set; in the left hand side the items are the result of one operation (create playlist on mp3s) whilst on the right they are the result of two operations (create playlist followed by zip). Subsequent operation icons are added consecutively, above the previous operations’ icon. Due to the closure we allow the user to drag the Results set onto the main diagram pane. This permits the user to categorise items which are the result of one of more operations alongside the original items that were already displayed in their diagram.
We decided not to try to compare the Euler diagram concept directly with other existing methodologies, because it is difficult to determine a suitable comparator and it also seems likely that tasks set would have a good chance of being biased towards one methodology. For example, a comparison of the Euler diagram concept for categorisation/resource management versus a hierarchical structure is likely to favour the Euler diagram concept for tasks that utilise overlapping categories, providing the underlying concept of Euler diagrams is not challenging for users. Furthermore, knowledge of users’ level of comprehension and abilities with this underlying concept is a necessary precursor to allow us to accurately examine their abilities with the concept of the application of functions to regions of the diagram. 4
We decided to test users’ conceptual understanding of the basic concept of Euler diagrams within this domain, together with their perception of its utility. Since we also wish to know if users can understand and apply functions, we also perform a basic test of this, keeping the tasks fairly straightforward in order to test the basic concept, with significantly more complex operational tasks being planned for future studies (as well as a more direct comparison within a more specific domain application that we have subsequently developed and is described in Section 5).
We test the concepts within the FunEuler tool we developed, which means we cannot really separate the conceptual effects of the actual representation from the effects of the particular tool, since the tool may restrict a user’s actions and thus alter their behaviour; to acknowledge this, at the end of the tests, we asked users if they were aware of anything they would have liked to have been able to do but could not, either because of the representation or because of the tool. However, we believe these effect of the tool on the judgement of the representation will be minor in this instance due to the simplicity of the notation and the interface, whilst the tool based approach brings many benefits in that we can trace with the behaviour of the users in detail (e.g. the number of clicks, the number of corrections made during the test, etc. . . ).
We describe our experimental design, some of the actual tasks set to the users, and a summary of the results of the user tests. We provide very high-level broad hypotheses below, but note that we are actually testing a restricted class of fairly small simple diagrams (no more than five curves or twelve zones), and as always any statement of results must really be restricted to the diagrams used and the tasks set within the experiment; we take this restriction for granted in the following. However, we are provided with an indication of the potential usefulness of the interface.
Hypotheses.
H1 Users can easily comprehend, create and modify Euler diagram based categorisations using FunEuler.
H2 Users are able to utilise the application of functions using FunEuler effectively. H3 Users perceive FunEuler as an application they would find useful to improve their efficiency of operations.
The intention of the user testing is to investigate Hypotheses H1 and H2 using quantitative methods, by the recording of correctness of task completion, and efficiency in terms of timing, whilst we investigate the subjective questions related to Hypotheses H3 using qualitative methods. In order to test these hypothesis we carried out two different test sessions: test session 1 focused on H1 and H3, whilst test session 2 focussed on H2 and H3.
Participants. We recruited 19 volunteers, twelve of whom were male, aged between 21 and 31, who were a mix of undergraduate Computer Science students and Ph.D. students at the ISISLab, Universita` di Salerno. Three of these participated in pilot testing of successive versions of the experimental materials (e.g. the tasks and questionnaire). This allowed us to thoroughly check the experimental set-up, altering the language and providing more clarification of the tasks where necessary. The remaining sixteen participants were equally divided between two tests sessions (each of which were of approximately 25 minutes duration).
Test setting. In terms of the test conditions, both tests were carried out in a laboratory
setting where each user had a dedicated laptop. Each test was explained orally and
guided via a printed handout offering a short description of each of the stages. At the
end of each step the user was asked to take a snapshot of the diagram, by clicking a
special button in the application, in order to record both the duration of the last task and
the current state of the diagram. At the end of each session, the users were asked to fill in
a questionnaire, consisting of 26 questions divided into 6 sections: general application,
set creation, set manipulation, item categorisation, executing operations and perceived
effectiveness of FunEuler in accelerating daily activities. These were measured on a
Likert scale with score range [
Experimental design. In the first test session each user was provided with a sequence of five stages, with each stage describing a basic concept or functionality of FunEuler. A task was presented to the user which required the utilisation of that functionality in order to modify the diagram, for instance. Thus we could check the users’ comprehension of the induced modifications. Sample tasks included: reproduce a given diagram presented on paper utilising the tool, and to count the number of zones into which a given set was split. For each stage we recorded the completion time and we measured the percentage of the tasks performed correctly (e.g. the number of sets that were correctly represented, or the number of zone sets that were correctly counted). The second test session was aimed at assessing users’ ease of comprehension and their application of operations to zones containing items. This test session consisted of three stages. The first stage was to perform item tagging in the similar manner to that of the first test, whilst the next two stages focussed on the application of a zip operation to certain zones of the diagram. We provide a brief description of the tasks below.
User Tasks. We consider user tasks divided into the following categories: Interpretation (given a diagram interpret its meaning), Development (given some categories and items construct a diagram) and Functional (utilise diagrams, applying functions). Note that, as mentioned earlier, we had decided it was a priority to test the fundamental aspects of the concept and the application and to leave the complex task categories like end-user development to a future date.
Table 1 show the basic results related to the tasks that comprised the two test sessions. We briefly describe the tasks and the criteria that we adopted to evaluate their execution, where necessary: Diagram Construction To create a diagram containing certain specified zones. The presence of the given zones is checked.
Diagram Modification To modify a diagram by altering the sets represented (i.e modifying the curves which changes the set of zones present).
Zone Counting To count the number of zones contained belonging to certain set (i.e contained within a certain region).
Diagram Reproduction To reproduce a printed diagram. The presence of the given zones is checked.
Item Tagging To place eleven files onto zones of a given diagram. Each file is named according to the zone it should be placed in. The reason for this was to mimic the pre-existing knowledge of file content that a user would normally have at the time at which he/she is about to categorise a file. The correctness of the placement is checked.
Zip Items in one zone To apply the zip operation to files belonging to one zone which represented the intersection of two sets. Zip Items in multiple zones To apply the zip operation to files belonging to multiple zones from a single set.
In Figure 4 we present screenshots of diagrams constructed by users of the test. In the upper part the user has reproduced the diagram in Figure 1: on the left the diagram has no items, whilst on the right she had categorized 12 files, as requested, and a single file was misplaced (placed in E instead of D). In the lower part of the same figure we show a diagram used to categorize mp3 files. 4.1
In Table 1 we present a summary of the results of the two test session that were carried out. Within the context of the diagrams and tasks used, Hypothesis H1 is supported by a high score on the tasks of Diagram Construction, Diagram Modification and Diagram Reproduction. Hypothesis H2 has been tested in tasks Zip Items in one zone and Zip items in multiple zones which also report ≈ 100% success rates.
By comparing the two tests session results we could evaluate how the use of
operations influenced the users’ perceived usefulness of FunEuler: the average score was
0.13 for participants of the first test session but 1.88 for participants of the second test
session (the score range is [
The accurate responses to the tasks indicate that the underlying conceptual use of Euler diagrams for categorisation was easily grasped by users. The functional application utilising this structure did not appear to be a large conceptual step for them. The perceived usefulness of the FunEuler application was significantly enhanced by the utility for functional application. Users also reported that they would use the application in the future, suggesting areas where it would be useful, and some even stated that they would be interested in developing the associated functionality themselves. 5
FunEuler can be viewed as a flexible framework on which to host services based upon an Euler Diagram representation of information. As an example of this flexibility, and as an extension of FunEuler following the experiment, we developed a prototypical mp3 files management system. Since the music domain is of interest to the student participants, and since there are applications available to deal with mp3 files, we focussed on this specialisation area.
The diffusion of digital music has radically changed the manner of listening to
music for the average user, and one fundamental step toward this evolution is the
widespread adoption of the mp3 file format [
We have brought together concepts of visual non-hierarchical classification, spatial arrangements and functional application in the development of a novel Euler diagram based interface called FunEuler. The prototype application developed was utilised in user testing, which investigated if the Euler diagram concept was easily comprehensible for resource categorisation purposes, if the application of functions could be performed successfully, and if users perceived this idea to be useful either in its current state or together with future functionalities. The results were extremely encouraging.
The FunEuler interface also provides a firm base for future developments in many directions. For example, we could extend the power of the labels of curves, allowing a mixture of user defined categories (or tags) such as “Computational Geometry” and pre-determined types such as TeX files, or to allow functional labels such as “Before this year”, which would filter for files based on the timestamp. Allowing any Boolean expressions on labels would assist with scalability of the diagrams since more information could be encapsulated in the labels instead of via the addition of more curves. A useful option could be to allow users to select from a set of curves in a library (e.g. files modified yesterday, PDF files, etc). In terms of repetitive tasks, we observe that choosing specific groups of contacts for sending email to is a task that a user often needs to perform several times a day, and so enabling a fast mechanism to realise group selection as well as to facilitate repeated usage of related group selections could be of great assistance to end users, and we will extend an Euler diagram interface for such tasks.
Furthermore, there are many potential application areas within which the developed concept and interface could be applied. For instance, we briefly reported on the specialisation for mp3 files and we plan to run future user testing within this domain. Secondly, in the workflow application area (e.g. see Alfresco), we could allow the drag and drop of a TeX document into a particular region, automate the running of macros such as PDFTeX and observe the results appear automatically elsewhere as an item in the PDF category. Users could then understand and track workflow involving multiple people on different systems. Thirdly, we will consider Euler Diagram Programming, where we will assign behaviour to curves instead of to the zones. For example one might have “Hotel” and “Food” categories with different “print” functions but their intersection might make use of both functionalities, although one must deal with the usual multiple inheritance problems, of course (e.g. we do not want to print off a date twice due to its appearance in each categories’ behaviour).
One weakness of the representation is the need for continuous navigation in order to find specific sets/regions, particularly in larger diagrams. Whilst the representation may be an effective way of leveraging the spatial memory of the user, performance of actions by hand without specific automated support from the application may be annoying. A deeper investigation into the advantages and disadvantages of the representation, and exploration of potential tasks and application areas is a next step.
A wider investigation of the usability of EDs in a general context is required. There are many unanswered questions, such as: how large (in terms of the number of zones and number of curves) can a diagram be to be effectively manipulated by an average user; how well does the representation scale with the increasing of the complexity of the diagram; what effect does the representation have on user behaviour? Such questions require specifically targeted testing.
Acknowledgments. We wish to thank the anonymous reviewers for their useful comments, particularly reviewer number 3 whose insightful comments will be invaluable in future works.