Anthony Savidis and Constantine Stephanidis
Institute of Computer Science
Foundation for Research and Technology-Hellas (FORTH)
Science and Technology Park
P.O. Box 1385, GR 711 10, Heraklion, Crete, Greece
Tel: +30-81-391741, Fax: +30-81-391740
Email: as@csi.forth.gr, cs@csi.forth.gr
Figure 1: Steps and issues to metaphor
development.
Another important feature is that the analogy of pop-up
dialogue boxes can be supported, with which the user has to
necessarily interact with. For example, a vertical "wall" group
can be dedicated for presenting dialogue boxes (e.g. messages,
data entry fields, confirmation boxes, etc). Imposing exclusive
interaction would result in the following actions: (i) to store
the present status of the dialogue, (ii) to directly focus the
dialogue to the specified "wall" group (the user can not exit
unless the interaction with this "wall" group is completed),
and (iii) to restore the previous dialogue state once the user
has completed interaction with this particular "wall" group.
Introduction
The motivation for this work was: (i) the lack of an interface
development toolkit for implementing non-visual User
Interfaces, and (ii) the fact that currently existing applications,
which are made accessible to blind users through run-time
adaptations, either implicitly support the visual Desktop
metaphor or they do not offer an explicit interaction metaphor.
The work presented in this paper concerns the general
metaphor for the interaction environment (i.e. how the user
realizes the overall interaction space, like the Desktop
metaphor) which is different from metaphors which are
embedded in the User Interface design (e.g. chalkboard,
business forms, restaurant menus, etc) [1]. The
methodological framework that has been constructed and
employed is illustrated in Figure 1. Generally, the metaphor
development process can be split in three distinct
phases: design, realization and implementation.
Following this scheme, modifications can be introduced
to a particular level without necessarily affecting the levels
above (i.e. various realizations can be constructed for a single
design and various implementations can be built for a
particular realization). For example, a visual realization of the
Rooms metaphor could be specified and implemented (for
instance, in terms of a 3D immersive graphical world through
Virtual Reality technology). The principal requirements on
which the design of the Rooms metaphor has been based are:
(1) to provide a real-world spatial but not necessarily visual
metaphor, (2) to enable blind users to conceive the interaction
space in a manner similar to the way the real world-analogy is
conceived in real life, and (3) to facilitate easy memorization
of the structure of the interaction space.
DESIGN OF THE ROOMS METAPHOR
The interaction space is structured in terms of Room objects
which form the main category of container-type entities.
Rooms may enclose interactive entities (the type of which is
defined via the realization phase). Room objects have
doors and a lift; doors lead to other
Room objects of the same floor, while the lift leads to Room
objects which are either at a level above or below. The objects
belonging to a Room object may be assigned to one of the
following six parenthood groups: front wall, back wall,
left wall, right wall, floor and ceiling. As it is outlined
in Figure 2, this property of supporting a two-dimensional
character for the parenthood relationship (i.e. the parent object
dimension and the group dimension), which is expressively
more general than the uni-dimensional existing approaches
(i.e. only the parent object dimension), can be illustrated by a
real world analogy. According to this scheme, within a
particular realization of a designed metaphor, the various
owned objects may inherit particular interaction properties
from the specific parenthood group in which they belong.
NON-VISUAL REALIZATION OF ROOMS
Some of the various classes of interaction objects are: Menu,
Textfield, Book (i.e. read only text reviewer), Switch (i.e.
toggle), Button, Label, etc. In order to reproduce the "door"
and "lift" concepts, it was decided to allow Room objects to
be specified as children of Room objects, with the following
representation to the user: in case that a child Room belongs
to the vertical wall group, it is represented as a door leading to
another Room object (which is the Room object itself), while
in case that it belongs to the "floor" or "ceiling" groups it is
made accessible through the lift which leads either to one level
above (providing access to the Room objects of the "ceiling"
group) or one level below (providing access to the Room
objects of the "floor" group). Two different non-visual
realizations of the Rooms metaphor have been assembled: (i)
a non-spatial simple realization, providing media space which
combines Braille, speech and non-speech audio output with
keyboard input, and (ii) a direct manipulation spatial
realization, with a media space combining 3D audio (speech
and non-speech), 3D pointing via a glove and hand gestures,
keyword speech recognition and keyboard input. Currently,
the first realization has been fully implemented (i.e. a software
development library is available) while the second is still
under development. In both realizations, special sound effects
accompany particular user actions such as selecting doors (e.g.
"opening door" sound), selecting the lift (e.g. "lift" sound),
pressing a Button or a Switch object, etc. Also, particular
emphasis was given on providing efficient navigation
facilities. For instance, the blind user is able to move forward /
backward in the list of parenthood groups, have dialogue
directly with the next / previous object in a group, to have
dialogue directly with the last or first object in a group, etc.
IMPLEMENTATION OF ROOMS: THE COMONKIT
DEVELOPMENT LIBRARY
The non-spatial realization has been implemented by means of
the development library called COMONKIT, which
constitutes a compact non-visual interface development toolkit
complying to the designed Rooms metaphor. It has been
developed in C++ and it provides an object oriented
programming model for interface development. It
encompasses many features of conventional toolkits (e.g. main
loop, callbacks, workprocs, etc) and currently it supports only
one client (i.e. it is not possible to run two or more
COMONKIT applications in parallel). It has been used for
developing a variety of non-visual User Interfaces and it has
been also integrated in a User Interface Management System.
FUTURE WORK
Future work concerns: (i) the extension of COMONKIT to
handle multiple clients; this will also require the development
of an efficient navigator handling the various clients (i.e. the
analogy of a window manager), and (ii) the completion of the
implementation for the spatial realization of the Rooms
metaphor by means of an appropriate interface development
toolkit handling directly multiple clients.
ACKNOWLEDGEMENTS
This work has been partially funded by the TIDE Programme
of the Commission of European Union (DG XIII), under the
project GUIB-II (TP 215). The partners of the GUIB
consortium are: IROE-CNR, Italy; Institute of Computer
Science-FORTH, Greece; Vrije Universiteit Brussel,
Belgium; Department of Computer Science-FUB, Germany;
Institute of Telecommunications-TUB, Germany; IFI,
University of Stuttgart, Germany; VTT, Finland; RNIB,
England; F. H. Papenmeier GmbH&Co,KG, Germany;
