Modelling the user.


Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Modelling the user.

  1. 1. Modelling the user Dr. Evangelos Bekiaris, Centre for Research & Technology Hellas (CERTH) Hellenic Institute of Transport (HIT)
  2. 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. 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. 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. 5. UCD Phases & Interdependencies in AEGIS
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  15. 15. 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.
  16. 16. 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).
  17. 17. 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.
  18. 18. 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.
  19. 19. AEGIS UCD Phase 2: Specifying User Requirements (9/14) Indicative Results-Example UC UML
  20. 20. 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”
  21. 21. AEGIS UCD Phase 2: Specifying User Requirements (11/14) Indicative Results- Personas • 17 Personas
  22. 22. AEGIS UCD Phase 2: Specifying User Requirements (12/14) Indicative Results- Personas; an example
  23. 23. 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
  24. 24. AEGIS UCD Phase 2: Specifying User Requirements (14/14) Indicative Results- Conceptual Models_Example Symbol support in Relevant use cases: Graphic Symbol Support for facilitated text comprehension and production in Relevant personas: Jane Brown (speech/communication impairments), Wayne Edwards (cognitive impairments), Adam Ljung (cognitive impairments) Functionality The prototype will be a plugin extension to 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.
  25. 25. Conclusions • All above core elements are public and can be downloaded from the project web site (, 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.