Modelling the user

Modelling the user

Dr. Evangelos Bekiaris,Centre for Research & Technology Hellas (CERTH)

Hellenic Institute of Transport (HIT)

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.

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

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.

UCD Phases & Interdependencies in AEGIS

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.


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.


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.


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.


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.


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.

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.


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.


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.


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.


Indicative Results-Example UCTitle 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

parameters

The users [blind users using screen readers (JAWS, NVDA)] are not able

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).


Indicative Results-Example UCTitle Windows screen reader for Java (“Java Access Bridge”)

Environmental

restrictions

WindowsXP, Windows Vista

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

attributes

Many assistive technologies exist for the Windows platform, but these

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.


Indicative Results-Example UC

Title Windows screen reader for Java (“Java Access Bridge”)

Background info/reason

on selection and on

assigning the priority

level

Fully blind users using screen readers (JAWS, NVDA) should not

able to distinguish defects in their experience between using

equivalent Java-based and native Windows applications on the

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.


Indicative Results-Example UC UML


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”


Indicative Results- Personas

• 17 Personas


Indicative Results- Personas; an example


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


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.

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.

http://www.aegis-project.eu/

