will be short text passages. The size can vary from
just a keyword to a short note or whole paragraphs in-
cluding rich text marked up by using a Wiki syntax
provided by the back end.
These items can contain other items such that one
can use microcontent rather than long, unstructured
text passages. Longer texts are then a sub-map con-
taining a sequence of smaller text-items. The iMap
hierarchy goes down into deeply nested nodes which
can be zoomed into (see Fig. 1) such that a basic hi-
erarchy of information items is created.
The hierarchical structure is represented by visual
inclusion: nested items are shown inside one another.
Compared to a classical tree view like it is used, e.g.,
in Mind-Maps, this has the following benefits:
• It leaves more freedom to place items according
to gestalt principles (Metzger, 1953) (e.g., group-
ing).
• Node-and-link representations (like in classical
concept maps and many other visual languages)
are still possible without interfering with the hier-
archical structure.
• The layout principle stays the same on all levels of
the hierarchy (in concentric trees like Mind-Maps,
all sub-branches point in one direction). Like that,
each part of the map can be treated like a self-
contained sub-map which largely helps clustering
and modularization.
• Nesting by inclusion (which is also widespread,
e.g., in the use of parentheses, Venn diagrams,
tree-maps), is closer to natural orientation where
details are parts of their surrounding. In real life,
when we want to see the big picture, we take a step
back to see the surrounding context of something.
Of course, this kind of nesting is not new in itself.
However, traditional, paper-and-pencil based map-
ping techniques can not cover many levels of hierar-
chy like this. Today, however, with computer-based
mapping approaches, very deep nesting and zooming
is possible which opens up a virtually infinite amount
of space for iMaps to grow over time when used, e.g.,
as personal knowledge repositories.
Adding and creating content to an iMap is done by
clicking anywhere in the map and typing some text.
It is always possible to add vague and unstructured
content. Although allowing for semantic knowledge
management, it has been a fundamental design deci-
sion to never force the user to specify any semantics.
Content can later be refined and formalised incremen-
tally.
There can be multiple visual instances of one and
the same information object, because it may be rele-
vant in different contexts.
For establishing link structures, we distinguish
several different ways of interrelating items which can
be used in an iMap:
1. explicit linking on an item level (stating a rela-
tion between two objects); each of these can be
mere navigational links or carry formal semantics
if specified; in particular, we can distinguish four
kinds of links and ways of establishing them:
(a) labeled links: If no pre-existing relation type is
suitable, the user can always just enter the full
label of the link to be displayed, e.g., along the
arrow. By that, in the back-end a new relation
type with that name is automatically created;
(b) unlabeled links: Links do not have to be labeled
at all;
(c) relating items by short semantic statements
with the QuiKey tool explained below: When
relating two items, the user gets a choice of
existing relation types selectable by an incre-
mental text search over their names, support-
ing reuse of existing relation types and avoiding
misspellings;
(d) hyperlinks: Links do not have to be drawn as
arrows; hyperlinks go from within the text con-
tent of an item to any other item.
2. implicit linking: Following the principle of Spa-
tial Hypertext, items can also be loosely placed in
spatial relations to one another without explicitly
linking them at all. These spatial relations can be
parsed to extract implicit relations, like sequence,
grouping or hierarchy. Currently, the only actu-
ally implemented way of implicit linking is that
of nesting items into another (i.e. placing the link
target inside at a specified position) in order to in-
dicate their hierarchical ordering.
In classic graph-based approaches, nodes usually
have to be arranged in a layout that minimizes edge-
crossings in order to reduce visual complexity. But
even then, maps with large amounts of nodes and
links often suffer from tangled links (aka “spaghetti
syndrome”). To avoid that, unless selected otherwise,
links are only shown on demand. Like that, the links
of current interest are more salient and easier to visu-
ally integrate with the nodes they connect. Depending
on user settings, links can, for instance, become visi-
ble on an mouse-over event (see Fig. 1).
While iMaps can be freely navigated by panning
(scrolling) and zooming like it is known, e.g., from
Google maps, our user tests have shown that users
much prefer navigation guided by content structure
like directly zooming to specific items by point-and-
click or following links. Additional to that, a search
ICEIS 2010 - 12th International Conference on Enterprise Information Systems
182