Keynote speech: Dr Evangelos Bekiaris, Centre for Research & Technology Hellas (CERTH), Hellenic Institute of Transport (HIT)

1. Modelling the user
Dr. Evangelos Bekiaris,
Centre for Research & Technology Hellas (CERTH)
Hellenic Institute of Transport (HIT)

2. The need
• As shown from a literature survey performed early in AEGIS IP project, AT is
widely used, and in many cases has improved the life of many end-
users.
• However, a majority of the people with disabilities (people with vision impairments
seemingly being an exception) do not use AT, or are simply unaware of
existing AT.
• They may also lack appropriate training to properly use it and, if they do,
are often disappointed with what it offers in relation to what they need.
• There is also lack of local language versions of AT or a common policy
regarding reimbursement schemes, etc.
• All the above together with other important findings, cross-checked and confirmed
by the project studies, constitute a first evidence that User Centred Design
(UCD) is necessary in the context of AT/AAC prototype development in
order to place the end user, user organisations, & support teams at the
fulcrum of the overall iterative design and testing process.

3. Our focus
• This presentation focuses on the UCD implementation plan
defined and followed in AEGIS IP project, mostly focusing on its
two first phases, which correspond to the “Modelling the user”
stage of the project:
• Phase 1: Gathering user needs
• Phase 2: Specifying user requirements

4. UCD Principles
• The centric principles followed for the construction of a UCD
implementation plan (followed also in AEGIS), are:
 Active user involvement in the project is not simply at the
end;
 User involvement in eInclusion is a particularly challenging
priority due to the extremely diverse nature of the target user
audience and the eInclusion goal;
 Everything users see, hear and touch should be designed
together with a multidisciplinary team.

5. UCD Phases & Interdependencies
in AEGIS

6. AEGIS UCD Phase 1: Gathering
User Needs (1/6)
Phase Goals
• To design and develop technology and applications that are useful,
usable and that provide a pleasant user experience, a first step is to
understand the user, his/her tasks and context.
• By understanding these factors, insight is gained in problems that
could be solved and in the users‟ needs with respect to the R&D
topics.
Expected Results
• The expected result in this phase in AEGIS, was the gathering of deep
and rich insights from a substantial panel of users regarding their
needs, problems and wants that should be fulfilled within the scope of
the project.

7. AEGIS UCD Phase 1: Gathering
User Needs (2/6)
UCD Techniques
• A combination of quantitative and qualitative methods were deployed.
• On quantitative level:
• User, task and context analysis by means of questionnaire surveys,
conducted by phone, e-mail, organised workshops or face-to-face
where necessary, addressing both end users with disabilities and
experts for all three areas of the project.
• On a qualitative level:
• In the context of face-to-face interviews (in severe cases), the
discussion of relevant topics on a deeper level as well as a more
ethnographic approach in doing contextual inquiries to observe the
users while doing relevant tasks was enabled.
• Based on the observations of participants performing everyday tasks
in their personal context, a hierarchical task analysis (HTA) was done,
to allow the investigation of existing situations.

8. AEGIS UCD Phase 1: Gathering
User Needs (3/6)
Indicative results
• According to the UCD plan, a series of field studies and workshops were held
in four European countries, namely Belgium, Spain, Sweden & UK in AEGIS.
• Both activities targeted end-users, end-user representatives (e.g. trainers,
accessibility assessors), domain experts and developers to gain an in-depth
understanding of the context of the use of ICT, i.e. mainstream and assistive
technologies (AT).
• The main goal of the field studies was to uncover all possibilities and
challenges that arise when end-users engage with mainstream or AT.
• In short, the AEGIS field studies pointed out that the use of technology is
reasonably widespread within each of the three application domains of the
project.
• However, the technologies and devices that would be most helpful for the
end-users targeted by the AEGIS Consortium, are seldom reaching this target
group, as pointed out also in the SoA.

9. AEGIS UCD Phase 1: Gathering
User Needs (4/6)
Indicative results
• Instead, the interviewed impaired end-users tend to own only the cheapest
and/or outdated devices and technologies.
• Basic functionalities like editing documents, sending emails or text messaging
are frequently used.
• Nevertheless, the outcomes show that end-users still face many challenges
when trying to access these basic functionalities.
• This implies the need for a stable groundwork when considering
accessibility.
• This need for better ways of accessing basic device or technology
functionalities -before moving on to more complex or advanced features-
is confirmed by the end-user representatives and developers.
• Nonetheless, this does not signify that end-users are not interested in
more advanced multimedia features.

10. AEGIS UCD Phase 1: Gathering
User Needs (5/6)
Indicative results
• Cost of AT was also raised.
• Lack of training or instruction materials presented in an adequate format that
targets specific needs following specific impairments.
• As a result, the poor accessibility of basic functionalities typically force end-
users to spend a lot of time and effort to master merely the most fundamental
features.
• Related to this lack of training is the general lack of knowledge; many interviewed
end-users were simply unaware of available solutions.
• In particular people who have limited mobility, and as a consequence also have
more trouble meeting people, seem to experience difficulties finding relevant
information sources.
• Need for customisation/personalisation. Practically all impairment user groups would
benefit from simpler, more straightforward interfaces; menus, lists, applications, etc.
that allow being configured towards personal needs and preferences.
• However, risks in over-customisation, where too many options might overwhelm
users.

11. AEGIS UCD Phase 1: Gathering
User Needs (6/6)
Indicative results
• Finally, lack of open source initiatives or active communities in the field of
accessible technologies.
• The experts are looking at the international market leaders to push
standardisation, make the prices drop and incorporate accessibility as a
norm, condemning the current practices of reverse engineering.
• Also, on a more abstract or policy level, experts claim focus should be
placed on allowing people to come to terms with their disability and then
introduce them to specific technological solutions that could assist in their
daily activities.

12. AEGIS UCD Phase 2: Specifying
User Requirements (1/14)
Phase Goals
• The aim of this phase was to translate the insights in the
users, their tasks and their contexts which were gathered in
phase 1, into system and user requirements.
Expected Results
• Translation of the succinct ranked list of the major end user,
developer, and system requirements, as emerging from
Phase 1, to specific Personas, Use Cases and scenarios and
conceptual models to enable the realisation of Phase 3,
which aims to interpret, finally, the first concepts to working
prototypes.

13. AEGIS UCD Phase 2: Specifying
User Requirements (2/14)
UCD Techniques
• Personas, Use Cases, user scenarios as well as
conceptual models.
• To verify the relevance and accuracy of all
aforementioned, focus group meetings with end users
and experts have been organised, some of them on
Pan-European level.
• The aim of these activities was to present preliminary
results and ideas in an open discussion format to obtain
feedback from individual end-users and stakeholders
(developers, end user representative organisations) in
an early design phase.

14. AEGIS UCD Phase 2: Specifying
User Requirements (3/14)
Indicative Results-Use Cases
• 36 Use Cases have been developed in total, 12
of which cover the accessible desktop
applications, 9 the accessible RIA, and 15 the
accessible mobile applications/services area.
• Only 4 of them supportive; the rest are all
considered essential.
• In addition, UML diagrams have been
developed for each of them.

16. AEGIS UCD Phase 2: Specifying
User Requirements (5/14)
Indicative Results-Example UC
Title Windows screen reader for Java (“Java Access Bridge”)
Context of use (aim) The aim is to ensure that Java applications running within Windows
environments are as or more accessible by Windows screen readers as
native Windows applications.
Primary actor 1.b Blind (without useful residual vision)
Secondary actor(s) -
Connected UCs -Screen magnification for the GNOME Desktop (and Sun Ray system)
-Visually impaired user using Java-based RIA application
Priority Level Essential
Scenario(s) A blind user using a system that is able to pass accessibility information
(e.g. name, role, state) from Java applications running in the Java
Runtime Environment (JRE) on Windows on to screen reader
applications running on Windows.

17. AEGIS UCD Phase 2: Specifying
User Requirements (6/14)
Indicative Results-Example UC
Title Windows screen reader for Java (“Java Access Bridge”)
System output Passing information from the Java Runtime Environment (JRE) to the
Windows accessibility architecture(s).
Preconditions User will need the required version of Windows.
User will need the required version of JRE.
User will need a screen reader using Iaccessible2.
Relevant ÆGIS WP WP2.2
Relevant ÆGIS Activity A2.2.2
Services involved Iaccessible, Iaccessible2, JDK
Application Area Desktop
Devices and restrictions It is intended that the solution will be robust enough to be applicable
across whatever device makes use of the Gnome desktop.
Critical success The users [blind users using screen reader s (JAWS, NVDA)] are not able
parameters to distinguish defects in their experience between using equivalent Java-
based and native Windows applications on the Windows platform. The
ability of Java applications to be usable with the scripting capabilities of
scriptable Windows screen readers (e.g., JAWS, NVDA).

18. AEGIS UCD Phase 2: Specifying
User Requirements (7/14)
Indicative Results-Example UC
Title Windows screen reader for Java (“Java Access Bridge”)
Environmental WindowsXP, Windows Vista
restrictions
Interaction level Step 1: The user opens a Java based application on Windows
Step 2: The system continuously passes accessibility information
from the Java Accessibility API in the JRE to the Windows
accessibility architecture, where it is usable by Windows screen
readers.
Alternative Paths -
Important accessibility Many assistive technologies exist for the Windows platform, but these
attributes do not have access to information and controls within Java
applications running inside the JRE without a “bridge”. The current
Java Access Bridge enables some access, but requires assistive
technologies to develop specifically for the bridge. By bridging to
MSAA and Iaccessible2, the new bridge will leverage the standard
accessibility APIs for the Windows platform that most assistive
technology developers are using.

19. AEGIS UCD Phase 2: Specifying
User Requirements (8/14)
Indicative Results-Example UC
Title Windows screen reader for Java (“Java Access Bridge”)
Background info/reason Fully blind users using screen readers (JAWS, NVDA) should not
on selection and on able to distinguish defects in their experience between using
assigning the priority equivalent Java-based and native Windows applications on the
level Windows platform.
Relevant PERSONAS - Gert Van Dijk (partly blurred vision)
- Nitesh Sarin (dyslexic and colour blind)
References -
Comments The “Java Access Bridge” is a process-to-process communication
system and does not include any direct user interface per se.

20. AEGIS UCD Phase 2: Specifying
User Requirements (9/14)
Indicative Results-Example UC UML

21. AEGIS UCD Phase 2: Specifying
User Requirements (10/14)
Indicative Results- Personas
• Fictitious character based on real data
• Interpreting:
• Problems
• Needs
• Wishes
....of user groups
• Bring target group to life, create empathy
• “Someone to design for”; not just the “average user”

22. AEGIS UCD Phase 2: Specifying
User Requirements (11/14)
Indicative Results- Personas
• 17 Personas

23. AEGIS UCD Phase 2: Specifying
User Requirements (12/14)
Indicative Results- Personas; an example

24. AEGIS UCD Phase 2: Specifying
User Requirements (13/14)
Indicative Results- Use Scenarios and Conceptual Models
• The final step in this process has been the formulation of some condense use
scenarios, on the basis of the above Use Cases, which have constituted the basis for
the detailed and more specific evaluation scenarios that will orient the evaluation
activities of the project.
• On the basis of the Phase 1 outcomes and taking into account the Use Cases, Personas
and user scenarios developed, a conceptual model has been developed for each AEGIS
available prototype, reflecting the functional requirements of the upcoming prototypes,
after cross-checked with the user insights.
• A conceptual model represents a high-level structure for the system. These models
answer questions such as „which services and features does the system offer?‟, ‟how
does the user interact with the services and features?‟, etc.
• So far, 14 conceptual models have been developed in AEGIS.
• 5 corresponding to desktop applications
• 3 corresponding to mobile applications
• 6 corresponding to RIA

25. AEGIS UCD Phase 2: Specifying
User Requirements (14/14)
Indicative Results- Conceptual Models_Example
Symbol support in OpenOffice.org
Relevant use cases: Graphic Symbol Support for facilitated text comprehension and production in OpenOffice.org
Relevant personas: Jane Brown (speech/communication impairments), Wayne Edwards (cognitive impairments), Adam Ljung (cognitive impairments)
Functionality The prototype will be a plugin extension to OpenOffice.org that adds graphical symbol support to text files. More concretely, the graphical symbols
illustrate the meaning of the words as they are entered into the text, or when text content is loaded from a file. This allows the user to:
 produce text with some degree of graphical symbol support,
 open a document and access and comprehend unknown text content with the support of grpahical symbols,
 manage the document content: change display mode, save, print ...
Interaction The user wants to produce symbol (and speech) supported text, be able to access and comprehend unknown text content with the support of graphical
symbols (and speech), and manage the document content – editing, saving, printing. The following activities/tasks are involved in producing and
comprehending text:
 The user can enter standard text into the system character by character. Afterwards, the user can select a word from the text and request a symbol
look-up. The system looks up the concept(s) matching the word and displays the corresponding graphical symbol.
 The system can also display matching concepts and graphical symbols after each word.
 The user can also enter text into the system by selecting words or phrases on a word/symbol chart.
 The user can also open and read an existing file, and save it via a Save or Save as command. Files are saved with the graphical annotations.
 Displaying and printing a file is also possible: as a document with text and symbols, as a standard text document, as a symbol only document, or
with an alternative text representation.
User User groups
 3. Primarily users with Cognitive Impairments,
 5. Users with Speech and/or Hearing impairments,
 2. Users with Motor impairment having profound problems with text processing
Extra requirements
For users with a cognitive or speech impairment, access to good integrated text-to-speech support, as well as alternative phrase/word/symbol based input is
required. For users with a motor impairment, access to alternative text input support is required.

26. Conclusions
• All above core elements are public and can be downloaded from the project web site
(http://www.aegis-project.eu), while are all considered working documents that may
undergo several updates and revisions, following the progress of the project as well as
the evolution noticed in the open source accessibility community.
• All above outcomes have been presented per test site in the context of focus groups
and workshops and showed that the end user and development community is keen on
embracing AEGIS, under the condition it remains an "open project" and considers the
needs of end users.
• This implies applying the UCD approach throughout the project as well as involving
development communities and organisations that promote open software, offering
access to source code and publishing information throughout the entire course.
• Above all, the UCD approach as being defined and adopted by AEGIS project may serve
as a valuable practice for similar initiatives that need to be user-centric in order to
achieve usable, useful and easy to penetrate products in the eInclusion field and
beyond.