Navigating in Process Model Collections: A new Approach Inspired by Google Earth [original]

Navigating in Process Model Collections:

A new Approach Inspired by Google Earth?

Markus Hipp1, Bela Mutschler2, and Manfred Reichert3

1Group Research & Advanced Engineering, Daimler AG, Germany

[email protected]

2University of Applied Sciences Ravensburg-Weingarten, Germany

bela.mutschler@hs-weingarten.de

3Institute of Databases and Information Systems, University of Ulm, Germany

manfred.reichert@uni-ulm.de

Abstract. In complex business environments, business processes (e.g.,

engineering processes in the automobile industry) may comprise hun-

dreds up to thousands of process steps. Though typically captured in

a process model (or a collection of process models), these processes are

presented to process participants in a rather static manner, e.g., as sim-

ple drawings. However, to effectively support process enactment and to

link processes with relevant information, enterprises crave for new ways

of visualizing processes and for interacting with them. In particular, pro-

cess models must be provided in an interactive, more dynamic manner,

i.e., they must be both ”experiencable” and user-adequate from the per-

spective of the user. In this paper, we introduce a new process navigation

concept for querying process model collections. Specifically, we pick up

an existing navigation concept for complex information spaces, namely

Google Earth, and apply it to business processes. Thereby, we distinguish

between geographical and semantic zoom functions, introduce different

process views and filter mechanisms, and discuss options to manually

configure needed process visualizations.

Key words: process navigation, visualization and interaction

1 Motivation

In complex environments business processes (e.g., engineering processes for elec-

tric/electronic components in a car) may comprise hundreds up to thousands of

process steps, each of them being associated with process relevant information

such as engineering documents, contact information, or tool instructions. In ex-

isting process repositories models are typically visualized in a static and thus not

very helpful manner [1, 2, 3]. In this context van Wijk confirms that visualizing

large data sets often leads to large and static “images” with much detail [4].

Static visualization, in turn, results in a significant information overload, rather

?This research has been done in the niPRO project funded by the German Federal

Ministry of Education and Research (BMBF) under grant number 17102X10.

2 M. Hipp et al.

disturbing than supporting the user. As different process participants have dif-

ferent perspectives on a business process and related process information, a more

flexible visualization of process models and navigation within business process

collections become necessary. For example, a business manager is mainly inter-

ested in an overview of a process in order to evaluate its process progress, whereas

a knowledge-worker needs more detailed information about the process step he

is currently involved in. In a case study [5] we showed that no comprehensive

approach fulfilling this requirement is currently available. Only specific aspects

are addressed in literature so far.

PROVIADO [6], for example, tackles the challenge of flexible process visu-

alization but focuses on the technical viewpoint, i.e., the user viewpoint has

not been considered. Interesting concepts have been introduced in the area of

user interface design, e.g., zoomable user interfaces (ZUIs) [7]. Smirnov et al. [8]

state that abstraction has proven to be an effective means to present readable,

high-level views of business process models.

Picking up the demand to adopt the user perspective when navigating in

process models or process model collections [9, 10], we introduce an advanced

navigation concept allowing users to dynamically adapt the visualization of pro-

cesses depending on their personal needs. Figure 1 illustrates our understanding

of process navigation. The process user starts with a default visualization of a

business process (Visualization 1), e.g., depicting the entire process with detailed

process information. The user may then change the visualization by interacting

with the process(es). Process interaction is defined as an activity that trans-

forms one process visualization into another based on user-triggered operations.

For example, a user may adjust the zoom level, and the process visualization then

changes accordingly. Process navigation comprises a sequence of process interac-

tions and allows the process participant to navigate from a default visualization

(Visualization 1) to a more specific one (Visualization 4).

Visualization 1

Interaction 1

Process Navigation

Visualization 2

Interaction 2

Visualization 3

Interaction 3

Visualization 4

Fig. 1. Process Navigation: A sequence of process interactions.

This work was done in the context of the niPRO project, which applies

semantic technology to integrate information associated with business processes

in personalized process information portals. As examples of structured process

information consider graphical business process models or data from enterprise

information systems such as ERP or CRM systems. Examples of unstructured

process information include all kinds of office documents or e-mails, including

mainly plain text. The overall goal is to provide knowledge-workers and decision-

makers with the needed process information depending on their preferences and

current work context.

Navigating in Process Model Collections. 3

This paper is organized as follows: Section 2 presents a navigation example of

a complex electric/electronic development process from the automotive domain

and summarizes requirements we previously identified on process navigation.

Our navigation concept is introduced in Section 3. Section 4 discusses related

work and Section 5 concludes with a summary and outlook.

2 Process Navigation: Example and Requirements

2.1 Practical Example

We first present a real-world case from the automotive domain to illustrate the

need for an intuitive process navigation concept. In this case, all relevant pro-

cesses are documented in forms of process diagrams captured in PDF documents.

Furthermore, they are categorized into process areas. Each process area is de-

picted as image map to users. Altogether, the entire “process world” (or process

model collection) comprises various models with different levels of information

(cf. Fig. 2).

Process Area "Development"

Process Area "Quality"

Process Area "Project Management"

Process Area "Product Management"

(a) Level 1 - time-based view

Refined Process Area "Architecture"

Refined Process Area "Release Management"

Refined Process Area "Requirements Engineering"

Refined Process Area "Verification"

Process Area "Development"

(b) Level 2 - time-based view

Manager Developer

PS1

PS2 PS3 PS5

PS4

Input

Output

Tools Contacts Persons

ControllingPremise

Task Description 1

Task Description 2

Task Description 3

(d) Level 4 - turtle-view

Fig. 2. Real-world example from the automotive industry.

4 M. Hipp et al.

Level 1 (cf. Fig. 2(a)) shows the entire process world, i.e., process areas. As

displaying single business processes would be too complex at this point, only

process areas are depicted. The respective view is time-based, i.e., the length of

the rectangles corresponds to the duration of process areas. Level 1 provides the

start point for the user. Based on it, he or she may select the process area includ-

ing the needed process step or process information. By choosing the process area

“Development”, for example, the user gets a more detailed, but still time-based

view of this process area on Level 2 (cf.Fig. 2(b)). The lots of single processes

can be displayed at Level 3 (cf. Fig. 2(c)). In our example, the process “Require-

ments Engineering” is depicted in terms of a process diagram, in which single

process steps (PS1. . . PS5) are connected to indicate causal relations. Further,

roles are introduced on this level and are displayed as swim lanes. As opposed

to Levels 1 and 2, the view on Level 3 is logic-based, e.g., it allows modelling

feedback loops (e.g., to jump back from PS3 to PS1) if a certain condition is not

met. Each process step is further refined on Level 4. It provides a “turtle-view”

and neither has time nor logic restrictions. A turtle only contains information

of a single process step in terms of task descriptions and additional information,

e.g., on tools or contact persons. The turtle-view is the most detailed visualiza-

tion and thus represents an important destination when searching for process

information.

This practical example exhibits two weaknesses. First, the presentation of

the different levels of information is inconsistent. While Levels 1 and 2 provide

static image maps, Levels 3 and 4 are PDF files. Navigating from Level 3 to

Level 4 corresponds to a simple scrolling through the PDF file. Second there are

missing relations between different processes.

2.2 Requirements

To elaborate the requirements for process navigation, we performed two case

studies, an online survey, and a literature study [5, 11]. Table 1 summarizes the

major requirements, we identified in these empirical studies. Requirements 1, 4

and 6 are picked up in the following as they directly concern process navigation.

3 Process Navigation Approach

As already mentioned in Section 1, we consider process navigation as the pro-

cedure to navigate in process model collections and process model repositories.

Process navigation is triggered by a user and comprises a sequence of user inter-

actions.

In this section we present our process navigation approach inspired by Google

Earth. Generally, process models and process model collections constitute com-

plex information spaces. Google Earth, in turn, provides a navigation concept

for one of the most complex existing information spaces, namely the global geo-

graphical information space. Of course, there exist significant differences be-

tween process models and global geographical information. Hence, we consider

Navigating in Process Model Collections. 5

Nr. Name CS1 CS2 OS Lit

#1 A graphical visualization of the entire business process is needed x x x x

#2 Enterprise-wide processes being easily accessible in every de-

partment are required

x x x

#3 Continuously provide information on the process progress x x

#4 An adequate visualization of process information is required x x x

#5 Process information must be explicitly linkable to single process

steps

#6 Information on contact persons should be adequately visualized x x

#7 Process steps must be linked with associated roles x

#8 Process information must be provided on the user’s role x x x x

CS1: Case Study 1; CS2: Case Study 2; OS: Online Survey; Lit: Literature

Table 1. Derived requirements from our empirical studies.

the Google Earth navigation approach just as the starting point for our ideas

and we are working on necessary extensions and adaptations.

3.1 Google Earth

Google Earth2is a virtual globe, map and geographical information system. It

displays satellite images of varying resolution of the earth’s surface, allowing

users to browse items like cities and houses looking perpendicularly down or

at an oblique angle [12]. Google Earth allows users to search for addresses of

certain countries, to enter coordinates, or to simply use the mouse to browse to

a particular location. The user is able to zoom, to pan, and to rotate the maps.

The level of detail of the displayed information is automatically adjusted to the

geographic zoom level. Further, users can switch between different views of the

map, e.g., map-view, satellite-view and terrain-view.

3.2 Adopting Google Earth for Process Navigation

We now take the Google Earth navigation concept and adopt it to our scenario

from Section 2. Table 2 shows the four different levels of the previously described

process world from Section 2. Our goal is to map these levels to Google Earth.

Zoom-Level Business Processes Google Earth

Level 1 Process World Globe

Level 2 Process Area Continent

Level 3 Process Country

Level 4 Process Step City

Table 2. Mapping of terms.

As can be seen in Figure 3(a), Level 1 of our scenario corresponds to the entire

globe in Google Earth. Process areas, in turn, can be considered as continents

2earth.google.com

6 M. Hipp et al.

(cf. Fig. 3(b)). Note, that both the globe and the continents are depicted from

the same view (i.e., the satellite view). On Level 3 (cf. Fig. 3(c)), Google Earth

switches to another view, namely a map-oriented view. On this level Google

Earth shows single countries. Picking up again our scenario, a single country

corresponds to a single process. Finally, single process steps (Level 4) correspond

to single cities in Figure 3(d). The view has changed again, now to a terrain view

in Google Earth.

Obviously, Google Earth can be applied to our real-world scenario and to its

different levels of information detail and views.

Process Area "Development"

Process Area "Quality"

Process Area "Project Management"

Process Area "Product Management"

(a) Level 1 - satellite view

Refined Process Area "Architecture"

Refined Process Area "Release Management"

Refined Process Area "Requirements Engineering"

Refined Process Area "Verification"

Process Area "Development"

(b) Level 2 - satellite view

Manager Developer

PS1

PS2 PS3 PS5

PS4

Input

Output

Tools Contacts Persons

ControllingPremise

Task Description 1

Task Description 2

Task Description 3

(d) Level 4 - terrain view

Fig. 3. Mapping navigation concept to Google Earth.

However, in the presented example, process navigation still remains re-

stricted. The process user, for example, cannot manipulate the hard-wired zoom

levels and views. Level 3, for instance, is always depicted as a logic-based view.

Indeed, the user can adjust the level of information detail (i.e., one dimension,

the dimension X in Fig. 4(a)), but the view is then automatically selected.

The Google Earth concept, in turn, supports two navigation dimensions to

overcome these restrictions. The first dimension is the level of zoom (X) (i.e., the

information detail). The second dimension subsumes different views (Y). We can

depict these two dimensions as a matrix (cf. Fig.4(b)). As we can identify four

different information levels and three different views in our real-world scenario

(cf. Section 2), a corresponding Google Earth navigation can be depicted as 4×3

Navigating in Process Model Collections. 7

matrix. Thus, twelve different visualizations are possible compared to the four

visualizations of our original example (cf. Fig 2).

X: hard-wired zoom

and view dimension

(a) Real-world example

X X X

Y Y

X: Combined zoom dimension

Y: View dimension

(b) Google Earth

X: Geographic dimension

Y: Semantic dimemsion

Z: View dimension

Fig. 4. The enhancement of navigation dimensions.

Even the Google Earth navigation concept (with its two dimensions) is not

able to completely meet all the requirements described in Section 2. For example,

consider a manager who wants to see detailed information about the progress of

a specific process, but who must also have an overview over all other processes

at the same time. Picking up the Google Earth metaphor, this scenario can be

described be as follows: The user wants to see selected cities of countries, but

also wants to see the whole globe at the same time. The Google Earth navigation

concept cannot solve this problem. The user can either zoom in (i.e., he may see

single cities, but then looses the overview on the globe at the same time), or he

can zoom out (so that he sees the globe, but single cities are not shown).

We address this issue by picking up techniques from the area of user interface

design. Reiterer and Buering [7], for example, investigate respective techniques

and distinguish between geographic and semantic zoom. In the following, we

enhance the Google Earth navigation concept by introducing these additional

dimensions. In total, this leads to three navigation dimensions: the geographic

dimension (X), the semantic dimension (Y), and the view dimension (Z) (cf.

Fig4(c)).

3.3 Process Navigation Dimensions

We now describe the three mentioned dimensions in detail.

Geographic Dimension The geographic dimension allows for a visual zooming

without changing the level of information detail. Think of a magnifier while

reading a newspaper. To set different zooming levels, scales can be used. In the

area of user interface design, Wijk et al.[4] already introduced a similar technique.

8 M. Hipp et al.

Semantic Dimension In the semantic dimension, process information is dis-

played in different levels of detail. On a high semantic level, for example, only

the names of process steps are depicted. If the semantic level of the respective

process step is more detailed, further details like the duration, responsible roles

and contact persons may be shown as well.

View Dimension Different views enable the user to select different types of

process information, such as time aspects, documents, contact persons or logical

relationships to other information. As opposed to the semantic dimension, the

detail level of information remains on a constant level, i.e., only the point of

view is changed. In Figure 2, three dimensions have already been introduced.

The time-based view (cf. Fig.3(a)) emphasises time aspects and uses a time

line. The logic-based view accentuates logic relations between process steps (cf.

fig. 3(c)). Finally, the turtle-view represents task descriptions (cf. Fif 3(d)). An

additional (i.e., fourth) view is introduced in Figure 5. Here the focus is on the

information flow, i.e., on documents or responsible contact persons.

PS1 PS2 PS3

PS: Process Step

: additional information (e.g., lessons learned)

: responsible roles

Fig. 5. A view emphasising the information flow between different process steps.

With these three navigation dimensions, the user is able to navigate in and

across complex business processes.

Generally, a completely unrestricted navigation within and across process

models is not always useful as some visualizations do not make sense. As example

consider the following scenario in which the geographic zoom is on an abstract

level, i.e., the whole process world (the entire globe) is visible. At the same time

the semantic zoom corresponds to a very detailed level, i.e., process information

is displayed to each process step (information to all cities around the world are

shown). As result we would obtain the visualization of the process world with a

multitude of detailed process information, overlapping with each other, due to

limited screen size.

Figure 6 shows a schematic navigation element supporting these three di-

mensions. For the geographic dimension (G), a slider control (well known from

Google Earth) can be used. To adjust the semantic dimension (S), we use check

boxes. A check box gives the user the possibility to select or deselect single levels

of information. Finally, as only one view (V) can be depicted at the same time,

we use radio buttons to select the respective view.

Navigating in Process Model Collections. 9

G S V

Fig. 6. Three zooming options. (Geographic, Semantic, Views)

3.4 Filter Mechanism

As aforementioned, the freedom to arbitrarily navigate within three navigation

dimensions is not always meaningful for the user. Hence, we introduce additional

filter mechanisms enabling more sophisticated navigation possibilities. To illus-

trate our filter mechanism, we pick up our scenario again. Showing process steps

(semantic dimension) of the whole process world (geographic dimension) does

not make sense unless we use appropriate filter attributes to reduce the amount

of displayed information. In general, every process information represents an at-

tribute that can be potentially used to generate filters. Respective filters allow

reducing the information displayed in the context of a particular process visu-

alization based on certain rules. These rules, in turn, may refer to a number of

filter attributes. For example, one possible filter attribute could be the duration

of process steps or the responsible role. For example, the following inquiries are

possible:

– Show all process steps associated with the role “Quality Manager”.

– Show all process areas with the roles “Quality Manager” and “Software De-

veloper” being involved.

In the following we present an example to illustrate how our process naviga-

tion concept works in conjunction with the introduced filter mechanism. Table

3 shows the different views and levels we use in this example.

Level Semantic Zoom View

1 Process World time-based

2 Process Area logic-based

3 Process turtle-view

4 Process Step informationflow

Table 3. Caption for our example.

Navigation starts with a view of the entire process world (cf. Fig. 7(a)),

similar to the PDF document. However, it includes additional information. The

geographic level corresponds to Level 1, i.e., the entire process from its start

until its end is shown (from a time-based view). Semantically, only information

on the level of processes is depicted (semantic zoom level 3).

A user having role ”E/E (electric/electronic) developer” is only interested in

processes, he is involved in. For this purpose, he can use our filter mechanism

10 M. Hipp et al.

by setting up attribute role to “E/E developer” (cf. Fig. 7(b)). At the same

time he may select semantic level 4 to display all process steps in addition to

the processes he is involved in (semantic level 3). As the user is interested in a

specific process step in process B, he applies the geographical zoom to process B

(cf. Fig. 7(c)) in order to get a better overview on it. Note, that all interactions

are user-driven.

Finally, assume that the user is less interested in time aspects, but in what he

has to do next, when finishing the current process step. Therefore, he switches to

the logic-based view as depicted in Figure 7(d). Here, he can identify successors

of the current process step he has worked on.

G S V

Filter:

no Filter

(a) Visualization 1

G S V

Filter:

role = "E/E developer"

(b) Visualization 2

G S V

Filter:

role = "E/E developer"

G S V

Filter:

role = "E/E developer"

(d) Visualization 4

Fig. 7. Example of navigating in three dimensions including the use of filters.

The example demonstrates that the combination of our navigation concept

with the sketched filter mechanisms supports the user in finding needed infor-

mation in large process model repositories.

4 Related Work

Related work mainly stems from two areas: (1) business process visualization

and navigation & (2) zoomable user interfaces.

Vajna [13] introduces a system, which enables the modelling and evaluation

of any kind of process or project as well as the dynamic navigation through it.

The behaviour of this system is described as “navigation”, because it always

leaves the control and the decision for the user, as opposed to “process control”,

where processes are fixed and thus controlled automatically. Bobrik et al. [6]

criticise that existing BPM tools lack the flexibility of presenting personalized

Navigating in Process Model Collections. 11

process views to users. As different users have distinguished perspectives on busi-

ness processes and related data, in large organizations this flexibility becomes

crucial. In response, a view concept is suggested that enables advanced support

for process visualization with focus on reducing the complexity of business pro-

cesses. Schoenhage et al. [14] investigate business visualization in 3D. They pick

up a 2D visualization of a business process as a starting point, for which they

subsequently provide a 3D visualization. With this approach, data visualization

in multiple dimensions (e.g., past, present and simulated data) becomes possible.

In the area of zooming techniques van Wijk and Nuij [4] state that large 2D

information spaces such as maps, images or abstract visualizations require views

at various levels of detail. They further state that users often switch between

these different views and discuss how a smooth migration from one view to

another can be realized. For this purpose, they introduce a metric on the effect

of simultaneous zooming and panning.

With JAZZ [15] and Pad++ [16], Bederson show how zooming techniques

can be used as a foundation for intuitive user interfaces. More general zooming

techniques are presented by Reiterer et al. [7]. Zooming facilitates data presen-

tation on limited screen real-estate by allowing the users to alter the scale of the

viewpoint such that it shows decreasing fraction of the information space with

an increasing magnification. As additional technique, panning is introduced, i.e,

the moving in constant scale. Such user interface concepts are implemented in

Squidy, a zoomable design environment for natural user interfaces [17], in ZEUS,

a zoomable explorative user interface for searching and object presentation [18],

and in ZOIL, a cross-platform user interface paradigm for personal information

management [19]. Dieberger and Frank [20] propose a conceptional user inter-

face metaphor for complex information spaces based on the structure of a city,

as people are used to navigate within cities to reach particular destinations.

5 Summary and Outlook

In this paper we suggest a new process navigation approach for large process

model collections and process models. Specifically, we pick up an existing navi-

gation concept for complex information spaces, namely Google Earth, and apply

it to business processes. We introduce geographic and semantic zoom functions

and describe different process views and sophisticated filter mechanisms. The

presented process navigation ideas, though not fully implemented yet, allow users

to better navigate through complex process model collections. Future work will

address the further specification and formalization of the presented ideas and

their evaluation in case studies and user experiments.

References

1. Rosa, M.L., Reijers, H.A., van der Aalst, W.M.P., Dijkman, R.M., Mendling, J.,

Dumas, M., Garc´ıa-Ba˜nuelos, L.: Apromore: An advanced process model reposi-

tory. Expert Syst. Appl., pp. 7029-7040 (2011)

12 M. Hipp et al.

2. Weber, B., Reichert, M., Mendling, J., Reijers, H.A.: Refactoring large process

model repositories. Computers in Industry, pp. 467-486 (2011)

3. Fauvet, M.C., Rosa, M.L., Sadegh, M., Alshareef, A., Dijkman, R.M., Garc´ıa-

Ba˜nuelos, L., Reijers, H.A., van der Aalst, W.M.P., Dumas, M., Mendling, J.: Man-

aging process model collections with apromore. In: ICSOC, pp. 699–701. (2010)

4. van Wijk, J.J., Nuij, W.A.A.: Smooth and efficient zooming and panning. In:

IEEE Symposium on Information Visualization, pp. 15–23, IEEE Computer Soci-

ety (2003)

5. Hipp, M., Mutschler, B., Reichert, M.: On the context-aware, personalized delivery

of process information: Viewpoints, problems, and requirements. In: Proc. of the

ARES 2011 (accepted for publication). (2011)

6. Bobrik, R., Reichert, M., Bauer, T.: View-based process visualization. In: 5th Int’l.

Conf. on Business Process Management (BPM’07), pp. 88–95. (2007)

7. Reiterer, H., B¨uring, T.: Zooming techniques. In: Encyclopedia of Database Sys-

tems, pp. 3684–3689. Springer US (2009)

8. Smirnov, S., Reijers, H.A., Weske, M.: A semantic approach for business pro-

cess model abstraction. In: Proceedings of the 23rd International Conference on

Advanced Information Systems Engineering (CAiSE’11). (2011)

9. Reijers, H.A., Freytag, T., Mendling, J., Eckleder, A.: Syntax highlighting in

business process models. Decision Support Systems, pp. 339-349 (2011)

10. Reijers, H.A., Mendling, J., Dijkman, R.M.: Human and automatic modulariza-

tions of process models to enhance their comprehension. Inf. Syst., pp. 881–897

(2011)

11. Michelberger, B., Mutschler, B., Reichert, M.: On Handling Process Information:

Results from Case Studies and a Survey. in: 2nd International Workshop on Em-

pirical Research in Business Process Management (ER-BPM 2011) (2011)

12. Rayle, R.: Google Earth: A platform for open data. Solstice : Electronic Journal

of Geography and Mathematics (2010)

13. Vajna, S.and Freisleben, D.: Project navigation modelling, improving and review

of engineering processes. In: Proc. of 2002 ASME, Design Engineering Technical

Conferences, DETC2002/DAC34132 h, pp. 919-925. (2002)

14. Sch¨onhage, B., van Ballegooij, A., Eli¨ens, A.: 3D gadgets for business process

visualization. In Spencer, S.N., ed.: Proc. of the 5th Symposium on the Virtual

Reality Modeling Language (WEB3D-VRML-00), pp. 131–138. (2000)

15. Bederson, B.B., Meyer, J., Good, L.: Jazz: an extensible zoomable user interface

graphics toolkit in java. In: ACM Symposium on User Interface Software and

Technology, pp. 171–180. (2000)

16. Bederson, B.B., Hollan, J.D.: Pad++: A zooming graphical interface for exploring

alternate interface physics. In: ACM Symposium on User Interface Software and

Technology, pp. 17–26. (1994)

17. K¨onig, W.A., R¨adle, R., Reiterer, H.: Squidy: a zoomable design environment for

natural user interfaces. In Jr., D.R.O., Arthur, R.B., Hinckley, K., Morris, M.R.,

Hudson, S.E., Greenberg, S., eds.: CHI Extended Abstracts, pp. 4561–4566. (2009)

18. Gundelsweiler, F., Memmel, T., Reiterer, H.: ZEUS - zoomable explorative user

interface for searching and object presentation. In: HCI (8). Volume 4557 of Lecture

Notes in Computer Science, pp. 288–297. (2007)

19. Jetter, H.C., Knig, W.A., Gerken, J., Reiterer, H.: ZOIL - a cross-platform user

interface paradigm for personal information management. In: CHI 2008 Workshop

- The Disappearing Desktop: Personal Information Management. (2008)

20. Dieberger, A., Frank, A.U.: A city metaphor to support navigation in complex

information spaces. J. Vis. Lang. Comput., pp. 597–622 (1998)