María González

Lourdes Moreno
email: lmoreno@inf.uc3m.es

Paloma Martínez

Ana Iglesias
email: aiglesia@inf.uc3m.es

Web accessibility requirements for media players

Keywords: Web accessibility, user agent, media player, standard, evaluation

Video Content continues to strenghten on the Web, because of that fact, it is neccessary to include video content with suitable accessibility requirements to be used by all people. User Agent (such as player, browse), also have to include accessibility requirements. In this paper a set of basic guidelines is included for profesionals who want to embed video players on their Web.

Introduction

The Web is being overflowed with multimedia content, like video. This will keep on happening into the future [START_REF]Cisco Visual Networking[END_REF]. Not only multimedia content has to be accessible through standards like the Web Content Accessibility Guideline (WCAG) [START_REF]Cisco Visual Networking[END_REF] of Web Accessibility Initiative (WAI) [START_REF]W3C, Web Accessibility Initiative (WAI)[END_REF] among others, but it also has to satisfy accessibility requirements, which have independent components, for example those that are referred to the user agent such as media players, browser, etc.

Sometimes, accessibility problems appear because of accessibility barriers within the media player, such as browsers, assistive technologies or even user's inability, for example, when a user tries to watch a video, but do not have the appropriate software and do not how to install it.

To avoid these problems, media players have to be developed in agreement with User Agent Accessibility Guidelines (UAAG) [START_REF]User Agent Accessibility Guidelines (UAAG)[END_REF] of WAI, as well as, having into account different opinions based on studies to offer universal access solutions for the user.

The remaining of the paper is organized as follows: Section 2 discusses different accessibility standards for media players and provides technological solutions. In Section 3, accessibility guidelines for media players are presented. Finally, Section 4 presents the concluding remarks and future works.

Background

In this section, standards for Web accessibility, regulations about how to standardize accessibility in software and good practices guidelines will be indicated, as well as new contributions that are provided by the new standard HTML5.

The UAAG of WAI is an international standard that explains how to make user agent accessible for people with disabilities and how to increase accessibility on Web content. Nowadays, this standard has two versions, UAAG 1.0 [START_REF] W3c | User Agent Accessibility Guidelines 1[END_REF] (the reference version) and UAAG 2.0 [START_REF] W3c | User Agent Accessibility Guidelines 2[END_REF] (the draft version). Last version gives support to WCAG 2.0 [START_REF] W3c | Web Content Accessibility Guidelines 2[END_REF], being this one used to make the accessibility guidelines.

Another standard is ISO 9241-171:2008 [8], Ergonomics of human-system interaction, this standard provides a group of guidance on software accessibility.

The new standard HTML5 [START_REF]W3C, HTML5, A vocabulary and associated APIs for HTML and XHTML[END_REF] allows to play videos without installing plug-ins through the new labels such as <video> and <audio>. However, there are some problems due to the fact that it does not support all Web user agent completely in the keyboard access or through screen readers to the provided controls. On the other hand, the current draft version of HTML5 does not give support to include subtitles and audio description, so in order to become the official recommendation, it is necessary to include these requirements to satisfy UAAG 2.0 and WCAG 2.0 [START_REF] Moreno | HTML5 support for an accessible user-video-interaction on the Web[END_REF].

As well as these standards, there are works [START_REF] Webaim | Media Player Accessibility[END_REF][12] [START_REF] Moreno | Guías metodológicas para contenidos multimedia accesibles en la Web, X Congreso Internacional de Interacción Persona-Ordenador[END_REF] and institutions [14][15][16] that provide good practices guidelines according to accessible multimedia content on the Web.

With the knowledge that we obtain after carrying out a study of WAI standards such as WCAG 2.0, the agile evaluation method based on UAAG 2.0 as well as the study of others standards and relative works, following, we present as result, a help documentation to guide web professional. The documentation includes a set of basic guidelines and a group of elements to be introduced on a media player interface so a video is accessible on a Web media player. This documentation is elaborated to help Web professionals.

1) A media player has to provide different alternatives for audiovisual information next to the video: a. Captions (video subtitles). As it is shown in Figure 1. b. Audio description. c. Others (sing language, transcription, extended audio description, etc.). 2) Complete access to all the features has to be guaranteed, as well as towards the mouse: a. By keyboard. b. Through assistive technology (like screen reader). 3) Provide help and documentation about the features of media player accessibility on the user interface, which reports to the user about the availability of those features, as well as the information about their purpose and use. 4) Provide a keyboard focus cursor that shows visually what element has the focus on the user interface; it is also important that the media player has a text cursor to show the focus within a text element. Restore the state when the state focus is recovered. According to the previous guidelines, elements on the user interface have to be included like the following controls. These controls are divided in two groups: basic controls and additional controls that are necessary to obtain an accessible media player.

In the first group (basic controls) are included:

-Controls that allow users to play or to stop the video.

-Controls that allow users to resize the viewports.

-Controls that allow users to adjust the volume. Among additional controls, we introduce the following ones:

-Controls that allow users to enable or to disable subtitles. As it is shown in Figure 2, there is a button called 'CC' (Closed Caption) that provides this functionality.

Figure 2 YouTube's screenshot that shows CC button.

-Controls that allow users to enable or to disable the audio description.

-Controls that allow users to search within reproduction subtitles, as it is shown in Figure 3. -Controls that allow users to forward or to delay seconds within a reproduction.

-Controls that allow users to change the size, font or color of the text.

-Controls that allow users access to help documentation which reports keyboard shortcuts, as it is shown in Figure 4.

Figure 4

CCPlayer's screenshot that shows a command's menu.

5) According to other important requirements concerning accessibility close to usability, the following requirements have been found: a) It is very important to maintain accessibility features that are configured by the users in the following sessions and that those features only change when the user want. b) Controls that allow users to enable or to disable and to adjust accessibility features have to be easy to find and they have to be operable. c) Provide information that allows the user to know the keyboard shortcuts that can be used in the media player, such as the help menu shows in Figure 4. d) Allow navigating through the content without enabling any controls. e) Has to be easy so the user can move through the menus, submenus and list through different combinations of keyboards or direct keyboard commands. f) Allow users to set their preferences to configure the keyboard shortcuts.

Conclusions

Although Web multimedia content has grown, this growth is not comparable to the Web accessibility growth, because it is not accessible enough yet. Due to that fact, it is very important that the media players and their access through the Web are accessible.

This paper was elaborated to help Web professionals to create or to decide what media player has to be included on their Website to guarantee the same access for all and accessible content is provided. Because of this, a set of accessibility basic guidelines that have to be satisfied have been introduced to obtain an accessible media player. Besides, an agile method of evaluation is introduced, which was used previously to evaluate some media players, that help evaluators to prove if a media player labeled as accessible actually is.

Figure 1

 1 Figure 1 BBC iPlayer's screenshot showing subtitles.

Figure 3

 3 Figure 3 CCplayer's screenshot that shows a caption search.

Acknowledgments

This research work is supported by the Research Network MAVIR (S2009/TIC-1542 (see www.mavir.net/)), and GEMMA (TSI-020302-2010-141) and SAGAS (TSI-020100-2010-184) research projects.


José Abdelnour-Nocera

Andy Smith

John Moore

Cecilia Oyugi

Malte Souleymane Camara

Malte Ressin

Sujan Shresta
email: sujan.shresta@uwl.ac.uk

Alison Wiles
email: alison.wiles@uwl.ac.uk

{jose Abdelnour-Nocera

Ressin

The Centre for Internationalization and Usability: Enabling Culture-Centred Design for All

Keywords: internationalisation, usability, culture, sociotechnical, participatory design, empirical studies of software engineering

The Centre for Internationalisation and Usability within the School of Computing and Technology at The University of West London aims to enhance understanding of cultural differences in international software development. A particular focus is the development and usability of ICT products in a global market, both in terms of international software development and economic, community and social development. We host a number of researchers and PhD students working in topics such as usability evaluation and culture, socio-technical participatory design, internationalization attitudes of software engineers, mobile learning and library cognitive design.

Research Challenges and Agenda

The Centre for Internationalisation and Usability (CIU) aims to support software developers in building systems that meet all the needs of end users globally. A particular focus is concerned with software development in a global market and culture-centred design. Our research strategy is to enhance understanding and knowledge of cultural differences in international software development. There are two research challenges that need to be overcome to achieve this: a) Computer science and interdisciplinary challenges that need to be addressed in order to provide tools, techniques and methods that can be used by software developers and interaction designers. We research the differing nature of these challenges in both the commercial and international development domains. b) Institutional and governmental challenges to overcome resistance to change so that new tools, techniques and methods are actually implemented commercially. Implicit here is the requirement to collaborate with academics and practitioners internationally, both in promoting HCI and usability generally and localising the discipline itself, particularly in developing countries.

CIU has been successful in exploiting UK and EU funding streams in delivering its research strategy. We have accessed the EU Asia IT&C programme to support usability research in both India and China. We have been the lead partner in the Sino European Systems Usability Network (SESUN) and the Indo European Systems Usability Partnership [START_REF] Smith | Institutionalising HCI in Asia[END_REF], helping to develop active and sustainable links between Asia and Europe. This has included collaborating on India's first international HCI conference and co-chairing a major conference in Beijing.

CIU was involved in the EPSRC funded VeSeL project -Village e-science for Life -addressing issues associated with the digital divide in Africa. VeSeL aims to fuse educational and environmental objectives to empower African village communities. Our work focused on socio-technical participatory design and the localization of usability methods [START_REF] Camara | Augmenting Usability: Cultural elicitation in HCI, in Human Work Interaction Design: Usability in Social, Cultural and Organizational Contexts[END_REF]. More recently, CIU has begun to explore the use of emerging copyleft hardware technologies and how they might contribute to the fields of mobile learning and ICT for development (ICT4D) [START_REF] Shrestha | Low-cost hardware for ICT4D: what's right and what's left?[END_REF]. We believe that this open approach provides the opportunity for the community to directly influence the hardware roadmap of a device and thus generate sustainable solutions within markets of developing countries. In the e-learning domain, we are looking at university libraries' usability design from a socio-technical perspective. Our work with commercial usability agencies and clients such as Microsoft, HSBC, Siemens and Intercontinental has allowed us to develop a process model for developing usable cross-cultural websites [START_REF] Smith | A process model for developing usable cross-cultural websites[END_REF]. Current commercial foci of our research concerns issues in relation to integration of internationalisation approaches within software development methods such as Agile [START_REF] Ressin | Of Code and Context: Collaboration Between Developers and Translators[END_REF] and in global software offshoring [START_REF] Lee | Cultural differences affecting quality and productivity in Western / Asian offshore software development[END_REF].

The impact of context and culture poses many challenges that cannot be exposed as a one-off evaluation in technology design. Decisions and actions in product design often result in the emergence of cultural and socio-technical implications and issues. CIU's research is aimed at the early identification of these in order to promote enhanced stakeholder participation and better product usability and user experience.


Christian Detweiler
email: c.a.detweiler@tudelft.nl

Alina Pommeranz
email: a.pommeranz@tudelft.nl

Jeroen V D Hoven

Helen Nissenbaum
email: helen.nissenbaum@nyu.edu

Values in Design -Building Bridges between RE, HCI and Ethics

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Objectives

Designing for values has become increasingly important for technology development. In many technological systems (medical applications, social networks etc.) values (privacy, autonomy, trust etc.) play a role and are sometimes violated. In working with stakeholder requirements or user needs, various design methods in requirements engineering (RE) [START_REF] Proynova | Use of Personal Values in Requirements Engineering-A Research Preview[END_REF] and human computer interaction (HCI), in specific user-centered (UCD), deal with "soft issues" [START_REF] Thew | Investigating the Role of 'Soft Issues' in the RE Process[END_REF], "social issues", "people issues" or values. At the same time, applied ethics has begun to pay attention to design. We believe that many of the approaches could complement each other in useful ways. The aim of this workshop is to bring together people from different disciplines to share knowledge and insights about how to account for values in technology design, and to work towards integrating approaches, thereby putting value conscious design approaches (e.g. values-in-design [START_REF] Flanagan | Embodying Values in Technology: Theory and Practice[END_REF] or value sensitive design [START_REF] Friedman | Value Sensitive Design and Information Systems[END_REF]) to practice.

Theme and Topics

The main theme is the interdisciplinary exchange of knowledge, experiences and new ideas on values in technology design. The following list reflects possible topics: -Designing for specific values, experiences from value-oriented projects -Understanding and relating different notions of values -Integrating value-oriented methods with software engineering/ design methods -Accounting for values in experience oriented designs, e.g. "fun" as a value -Values used in evaluations of User Experience (UX) -Dealing with soft issues, social issues, and people issues in RE, Value-based RE -Value elicitation, dealing with a variety of stakeholder values -Capturing and reusing value knowledge (scenarios, design patterns, etc.) -Values in Persuasive Technology, Ambient Intelligence and Personal Informatics -Values in specific domains (health care, military, crisis management) 1 All authors of this proposal are to be considered key organizers of the workshop.

The target audience includes HCI and social science researchers interested in social aspects of technology and values in design. We also aim at researchers focusing on soft issues in RE, UCD and moral philosophers interested in ethics and technology. For interactions between academia and industry we will invite (interaction) designers and software engineers/developers.

Workshop Format

This is a one-day workshop divided into two parts. In the first half we will have four consecutive panel sessions: the values turn in design -"soft issues" in RE and UCD; the design turn in applied ethics; values across disciplines; and values in industry. Panels will be led by representatives in the respective field. Each panel will be initiated by short presentations by authors of accepted papers followed by a discussion with all workshop participants. In the second part, we will create groups of 4-5 participants with different backgrounds (RE, HCI and Ethics). Each group will be given a design case to work on using tools and methods proposed by the participants. The aim will be to create an overview of people issues, values, soft issues and (long term) social aspects emerging from each design case. In a debriefing session we will share experiences (regarding the cases and tools used) from the group work with all participants. Participants who wish to present their work as posters or demos will be given the opportunity to do so during the breaks.

Expected Outcomes

We expect that the interdisciplinary collaboration in the workshop will lead to new ideas and more practical approaches to the inclusion of values in technology design. More specifically, an outcome of the workshop will be the publication of a volume of extended versions of work submitted to the workshop highlighting the state of the art in addressing values in design. Additionally, insights from the panel discussions and interdisciplinary work will form the basis for a number of publications in a special issue of the "Ethics and Information Technology" journal focusing combining existing approaches, and on new approaches that emerge from the workshop.


C Martin
email: cemartin@brookes.ac.uk

D Flood

D Sutton
email: dsutton@brookes.ac.uk

A Aldea
email: aaldea@brookes.ac.uk

R Harrison
email: rachel.harrison@brookes.ac.uk

M Waite
email: mwaite@brookes.ac.uk

A Systematic Evaluation of Mobile Applications for Diabetes Management

Keywords: efficiency, effectiveness, keystroke level modelling, heuristics

This short paper contains a summary of work that is currently in progress towards the development of an intelligent, personalised tool for diabetes management. A preliminary part of the development process has consisted of a systematic evaluation of existing applications for mobile phones.

Introduction

The combined technologies of mobile phones and cloud computing have huge potential to improve health care services [START_REF] Alagöz | From Cloud Computing to Mobile Internet, From User Focus to Culture and Hedonism: The Crucible of Mobile Health Care and Wellness Applications[END_REF], but a crucial factor in the adoption of such services is the usability of the software [START_REF] Bellazzi | Telemedicine and Diabetes Management: Current Challenges and Future Resarch Directions[END_REF][START_REF] Greenhalgh | Adoption, non-adoption, and abandonment of a personal electronic health record: case study of HealthSpace[END_REF]. Previous studies have been conducted to evaluate the effectiveness of mobile phones for assisting with diabetes self-management, eg [START_REF] Preuveneers | Mobile phones assisting with health self-care: a diabetes case study[END_REF], and standards are beginning to emerge with regard to the design of mobile applications in general [START_REF]Mobile Web Application Best Practices[END_REF] as well as mobile medical applications in particular (eg ISO/IEC 62366), but research into the usability evaluation of applications for mobile devices is still a relatively new area [START_REF] Kjeldskov | J New techniques for usability evaluation of mobile systems[END_REF]. Some issues that affect the usability of mobile applications include mobile context, connectivity, screen size and resolution, limited processing power and data entry methods [START_REF] Zhang | Challenges, Methodologies, and Issues in the Usability Testing of Mobile Applications[END_REF], and these issues remain broadly the same despite recent advances in mobile phone technology. The purpose of this study is to uncover usability issues in order to know what pitfalls to avoid in the design of an application for diabetes management, and also to determine what functionality is typically included in such applications.

Type 1 diabetes (T1DM) occurs when the insulin producing cells of the pancreas are destroyed leaving the body unable to control its blood glucose levels. People with T1DM have to take insulin regularly to try to keep their glucose levels within a safe range. The vast majority of patients with T1DM in the UK administer their insulin through multiple daily injections, and the remaining proportion use insulin pumps. Modern insulin pumps include dose calculators to help patients determine how much insulin to administer, but people on multiple daily injections do not usually have this support, and tend to do the calculations themselves. The resulting need for electronic decision support, combined with the recent growth in smart phone use has led to the development of a plethora of diabetes management applications, despite the many barriers that have inhibited the adoption of electronic systems for diabetes management in the past [START_REF] Bertini | Appropriating Heuristic Evaluation Methods for Mobile[END_REF][START_REF] Klonoff | Using Telemedicine to Improve Outcomes in Diabetes -An Emerging Technology[END_REF]. One of the key barriers has been usability, and another has been the economic implications for healthcare providers, but the standardisation of controls and rigid human interface guidelines imposed by the providers of most phone platforms has already had a huge impact on usability, and the ease with which software applications for mobile phones can now be developed and distributed helps to mitigate against the economic factors. The usability issues listed in [START_REF] Zhang | Challenges, Methodologies, and Issues in the Usability Testing of Mobile Applications[END_REF], are all applicable to systems for diabetes management, but in addition, common complications of diabetes, such as retinopathy and peripheral neuropathy, could affect a patient's ability to view data or use a touch screen respectively.

The Evaluation

The protocol used here to analyse the applications is fairly general and has also been applied to mobile spreadsheets [START_REF] Martin | A Protocol for Evaluating Mobile Applications[END_REF]. The results given below are limited to the iOS platform, but work is in progress to extend the evaluation to other platforms. The number of spreadsheet applications available for iOS is only a fraction of those for diabetes management, but some similar issues emerged with data entry and visualisation for example. The following steps were performed:

1. Identify all potentially relevant applications: this involved a search on the iPhone app store using the keyword diabetes which returned a total of 231 applications.

Remove light or old versions of each application.

There were 9 light versions of applications which were removed from the list, leaving 222 apps.

3. Identify the primary operating functions and exclude all applications that do not offer this functionality. The key functionality was mapped to corresponding tasks which are shown in Table 1. Only 8 applications had all of the functionality.

Identify all secondary functionality.

A full list of additional functionality that was offered by the various applications was compiled to be assessed by patients and clinicians in the second phase of this study.

Construct tasks to test the key functionality using each of the methods below:

a. Keystroke level modelling [START_REF] Card | The Psychology of Human-Computer Interaction[END_REF][START_REF] Schulz | Using the Keystroke-Level Model to Evaluate Mobile Phones[END_REF] was performed on the final 8 applications using the tasks from Table 1. The number of times the screen was touched in order to complete each task was recorded, where a touch might refer to a single touch or a swipe of the finger. The results are shown in Table 2. This analysis excluded the actual time taken to complete tasks, which will be measured in the study on patients. The KLM process highlighted a number of key differences between the applications that could have a significant effect on usability. For example, the data logging occurs so frequently that it is essential for it to be as efficient as possible, and yet a number of different methods were in use including sliders, pickers and various styles of keyboard. Some applications also made much more effective use of default settings than others.

b. Heuristics [START_REF] Nielsen | Heuristic evaluation of user interfaces[END_REF] were then used to identify more usability problems. The four applications that scored the best in the KLM were subjected to heuristic evaluation by five expert evaluators, using guidelines that take into account specific issues associated with mobile systems [START_REF] Bertini | Appropriating Heuristic Evaluation Methods for Mobile[END_REF]. Each heuristic was ranked using Nielsen's five-point Severity Ranking Scale (SRS) [START_REF] Nielsen | Usability Engineering[END_REF]. Diabetes Diary 0.5 0.8 0.9 0.5 0.9 0.7 1.4 0.8 6.5

Diabetes Personal Manager 0.6 0.8 0.9 1.1 1.1 0.9 1.6 2.3 9.3

Each evaluator provided evidence for each ranking, and this exposed some problems that had not been shown by the KLM. For example, there were problems with visibility of battery status, and limited ability to restore data if the device was lost. There were some navigation problems too, but some of these were only learnability issues. Some apps were over-crowded but most offered some degree of personalisation. There were some serious problems with error management and security: it was not easy to edit records on most apps, and data transfer was typically done via unencrypted email, which is not appropriate for healthcare information. Unfortunately it is beyond the scope of this paper to give a thorough analysis of the heuristic evaluation, but that will be the subject of a future paper.

This short paper has described a systematic evaluation of diabetes management applications for the iOS platform. The KLM evaluation highlighted a number of usability issues associated with data entry and personal settings, and the heuristic evaluation exposed further problems associated with loss of the device, learnability, aesthetics, error management and security. Future work includes a usability study on patients using additional mobile platforms, and the ultimate goal is to design an application for diabetes management with a decision support engine and secure data transfer taking into account the associated legal implications. Further work is also planned on keystroke level modelling of mobile applications, in order to standardise measurements such as what constitutes a single touch or swipe.

Table 1 .

 1 Tasks to evaluate primary functionality.

	Task	Description	Task	Description
	1	Set measurement units	4	Log insulin dose
	2	Log blood glucose level	5	Display data graphically
	3	Log carbohydrate intake	6	Export data via email or similar

Table 2 .

 2 Results of KLM.

	Application	Task:	1 2 3 4 5 6 Total
	RapidCalc Insulin Dose Manager		10 2 1 3 2 1	19
	GluCoMo		5 5 4 4 1 3	22
	Diabetes Diary		5 3 3 2 3 6	22
	Diabetes Personal Manager		3 7 4 3 3 6	26
	DiabetesPlus		2 7 6 6 1 6	28
	LogFrog DB		6 5 6 5 1 7	30
	Diabetes Buddy -Control your Blood Sugar 3 9 10 7 1 8	38
	Diabetes Pilot		5 5 7 3 3 27	50

Table 5 .

 5 Average heuristic ranking.

	Heuristic:	A	B	C	D	E	F	G	H Tot
	RapidCalc	1.1 0.9 0.4 0.4 0.8 1.3 1.3 2.0 8.2
	GluCoMo	0.6 1.4 1.2 1.7 0.8 1.3 1.3 1.7 10


Volker Thoma

Elliott P White

In two Minds about Usability? Rationality and Intuition in Usability Evaluations

Usability ratings of a university website by 60 students were analysed together with participant's self-ratings of their cognitive style. The degree of users' "rational" as well as their "intuitive" style correlated with evaluation scores. In particular, self-reported rational ability was connected with evaluations of Controllability, intuitive ability was related to Helpfulness scores of the interface. Thinking style significantly affects usability ratings (explaining over 9% of the ratings' variation), which has implications for evaluations across user groups.

Introduction

User centred design relies on a variety of methods and techniques which aim to involve potential users at different stages of product development. A common component of such projects often a summative evaluation that aims to measure "ease of use" [START_REF] Holzinger | Usability Engineering for Software Developers[END_REF][START_REF] Kirakowski | Human Centered Measures of Success in Web Site Design[END_REF]. The results of user evaluations affect decision making in IT projects, but the factors influencing the users' judgments are rarely analysed, even if they are subdivided into "user groups" according to socio-economic criteria or persona characteristics [START_REF] Thoma | Developing and Validating Personas in e-Commerce: A Heuristic Approach[END_REF]. Furthermore, only recently researchers and practitioners have embraced the concept of "affect" or "attractiveness" to account for "hedonic" or "fun" aspects of use [START_REF] Hassenzahl | The interplay of beauty, goodness, and usability in interactive products[END_REF]. However, modern research on human judgment, decision making, and social psychology has identified a great number of factors that may systematically influence preferences or ratings. For example, Slovic [START_REF] Slovic | Heuristics and biases: The psychology of intuitive[END_REF] identified the affect heuristic -a positive or negative feeling experienced by the evaluator informs their preferences between items or images.

There is growing evidence that human reasoning and decision making is the product of two distinct cognitive systems. Researchers share the labels 'System 1' and 'System 2' for these two systems [START_REF] Evans | In two minds: dual-process accounts of reasoning[END_REF], although they are more commonly referred to as "intuition" and "rationality". System 1 is a fast, effort-free collection of autonomous processes that are susceptible to emotional stimulation. System 2 is characterised by slow, deliberative, rule-based reasoning [START_REF] Evans | In two minds: dual-process accounts of reasoning[END_REF]. Humans seem to vary in their propensity for intuitive versus reflective thinking in their daily judgments. Thus, cognitive style, also called thinking style, refers to a person's preferred way of processing information and the way he or she perceives, conceptualises, and judges information [START_REF] Evans | In two minds: dual-process accounts of reasoning[END_REF]. One of the earliest and most reliable methods to investigate cognitive style is the Rationality and Experientiality Inventory (REI) developed by Epstein [START_REF] Epstein | Individual differences in intuitiveexperiential and analytical-rational thinking styles[END_REF]. The subscales of this questionnaire correspond to self-rated ability and preference of utilizing System 1 and System 2 respectively. Rationality and Experientiality have been found to be orthogonal constructs [START_REF] Epstein | Individual differences in intuitiveexperiential and analytical-rational thinking styles[END_REF] and are dissimilar to cognitive abilities because they do not describe peak performance, but they do influence attitudes and social interaction.

The aim of the current study is to test whether individual differences in "Experientiality" and "Rationality" may influence user evaluations, and whether aspects of usability ratings depend more on intuition rather than reflective thought. We used the WAMMI (Website Analysis and MeasureMent Inventory) [START_REF] Kirakowski | Human Centered Measures of Success in Web Site Design[END_REF] (after considering SUMI, QUIS, SUS [START_REF] Holzinger | Usability Engineering for Software Developers[END_REF]) to elicit usability ratings of a website, because of its widespread use, and because it employs a separate subscale of Attractiveness (A). Our predictions were that a) WAMMI scores are influenced by individual differences in thinking as measured by the REI and b) that some WAMMI subscales would correlate more strongly with rationality than others (A), as people would rely more on system 1 processes (i.e., automatic, implicit visual evaluations) in this case.

A web site evaluation and the role of intuition and reflexivity

Participants, Measures and Procedure

Sixty students (40 females, age range between 18 and 43, mean = 24.45) in a modern UK university were approached in one of the campus computer centres and invited to take part in a study to evaluate the university's website.

Once participants agreed they were asked to visit to the university's homepage. They were not required to perform any tasks but simply asked whether they had used the website before. If so, participants completed the two questionnaires after brief inspection of the website. The WAMMI was used to elicit ratings regarding the usability of the website. The WAMMI is a 20 item questionnaire in which participants rate their strength of approval for statements like "The pages on this web site are very attractive" and "This web site has some annoying features", on a 1 -5 scale. Data from this scale were scored by the WAMMI's authors using a proprietary algorithm. Results are provided on five sub-scales: Learnability (L), Helpfulness (H), Efficiency (EC), Controllability (C), and Attractiveness (A), and a combined global usability score (G). After that participants filled in the Rational-Experiential Inventory-short form, a 24 item version of the original scale [START_REF] Epstein | Individual differences in intuitiveexperiential and analytical-rational thinking styles[END_REF]. Participants rate the strength of their agreement with statements like, "I have a logical mind" (rational ability) and "I believe in trusting my hunches" (experiential favourability), on a 1-5 scale. These items combine into four subscales: Rational Ability (RA), Rational Favorability (RF), Experiential Ability (EA), and Experiential Favorability (EF), which can be summed up for overall 'Rationality' (R) and 'Experientiality' (E) scores.

Results

Pearson correlation coefficients were calculated. Table 1 shows the pattern of correlations and level of significance. Global WAMMI scores correlated significantly with RA and Rationality, as well as with Experientiality. The WAMMI subscale for Controllability and Efficiency correlated with RA and Rationality, whereas Helpfulness correlated with RA, EA and Experientiality. Learnability correlated with EF only. Interestingly, against our prediction the subscale of Attractiveness did not correlate with experiential scales, but it did correlate with RA. In order to test whether individual differences in cognitive style can explain variations in how people rate the usability of this interface, we ran simple linear regression analyses with the REI subscales as predictors and the WAMMI scores as criterion. In the first analysis with the global WAMMI score as predictor, the ANOVA was marginally significant, F (4, 55) = 2.51, p = .052, meaning that the REI model predicted the global WAMMI scores to a significant degree (R=.39). However, only RA approached significance as a predictor (Beta = .26, t = 1.850, p = .07) all other predictors were t =< 1.07. Thus, the REI model explained 9% of the variance in WAMMI-G scores. For the analyses with a WAMMI subscore (A, EC, L) as criterion we obtained no significant model, all p > .1. However, for Controllability the REI model significantly predicted the WAMMI scores, F (4, 55) = 2.70, p < .05 (adjusted R 2 = 0.10), again with RA as the only significant predictor (t = 2.29, p < .05). The model reliably predicted Helpfulness, F (4, 55) = 3.69, p< .05, (adjusted R 2 = 0.15), this time only with EA explaining a significant part of the variance (t = 2.62, p < .05).

Conclusions

We asked whether usability measures could be differentially influenced by individual differences in cognitive style. There were two important findings. First, usability scores were higher the more people believed in their thinking ability: both "rational" and "experiential" scores correlated with WAMMI ratings. However, only rational ability self-ratings significantly predicted variations in WAMMI scores in a multiple regression model. It is outside the scope of the study to determine whether this means that people who feel they can rely on their (rational) thinking style in general feel more positive ("in control") about an interface, or whether this reflects overconfidence in participants about their abilities which may result in a sense of mastery of the interface. Whatever the interpretation of this effect, if confirmed this result would mean that comparing summative usability evaluations across different populations may be affected by differences in thinking style. For example, some Asian populations are found to be less overconfident in their judgments than Westerners and prefer a more global style of information processing [START_REF] Lee | Cross-national differences in overconfidence[END_REF][START_REF] Zhu | Probability judgment accuracy: China, Japan, and the United States[END_REF]. Hence, cross-cultural user research may be susceptible to thinking style.

The second result is more complex: self-belief in rational ability positively affects the experience with an interface, in particular in terms of its controllability. One explanation is that people who score high on RA are able to cope with poor interactive design features and feel less affected by it. For example, they may work out how to navigate even a poorly organised website and attribute this relative ease as inherent to the website -thereby inflating the Controllability scores. On the other hand, Helpfulness (but not Attractiveness) scores correlated highly with a global "experiential" style. The reasons for this are probably complex, but it is possible that the more "intuitive" participants relied successfully on processes which are unconscious and work automatically. Compared to the task of deciding whether a website is easy to control by recalling specific episodes of usage, judgments on Helpfulness may be harder to break down into distinct instances. As the experiential system operates in an automatic and holistic manner, users that score high on experiential ability may have simply a better mental "toolset" for making such a more global judgment, resulting in higher scores. In contrast, users may rely on rational criteria when asked to judge Attractiveness [START_REF] Leder | A model of aesthetic appreciation and aesthetic judgments[END_REF].

In conclusion, the current study provides evidence for a role of individual thinking styles in usability evaluations. Further research would need to establish -for example by using "verbal protocols" and different memory tests -whether user ratings can indeed be traced to reflective or intuitive processes .

Table 1 .

 1 Correlations of WAMMI and REI scales

		WAMMI					REI
		A	C	E	H	L	G	RA RF	R	EA EF	E
	WAMMI	Attractiveness	.59** .60** .60** .54** .83** .28* .11 .23 .186 .05 .15
		Controllability		.67** .56** .50** .84** .39** .24 .37* .17 .16 .20
		Efficiency			.48** .39** .79** .31* .23 .33* .06 .10 .09
		Helpfulness				.52** .8** .31* .10 .25 .41** .21 .39**
		Learnability				.72** .08 .15 .14 .09 .34** .25
		Global						.35** .21 .33** .23 .21 .27*
	**= significant at the 0.01 level, *=significant at the 0.05 level


Beant Dhillon

Areti Goulati

Ioannis Politis

Agata M Raczewska

Panos Markopoulos
email: markopoulos@tue.nl

K Dhillon

A Set of Customizable Games Supporting Therapy of Children with Cerebral Palsy

Keywords: Cerebral Palsy, Motor Skills, Rehabilitation, TagTiles, Therapeutic Games, Design

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Cerebral Palsy (CP) is a term describing a set of neurological disorders that cause physical disability, mainly affecting body movements and muscle coordination. In additional to traditional means of therapy, tabletop interactive surfaces offer a lot of potential. The TagTiles board [START_REF] Verhaegh | TagTiles: optimal challenge in educational electronics[END_REF] is a programmable grid of RFID sensors, able to provide visual and sound feedback, which is triggered by objects with attached RFID tags. The use of TagTiles in training for children with CP has been explored in the past [START_REF] Li | A tangible tabletop game supporting therapy of children with Cerebral Palsy[END_REF] resulting in a series of games that support the training of arm-hand skills.

However, that work did not address several requirements that relate to the use of the games in actual therapy. Interviews with therapists emphasized the importance of supporting customization to each child's needs, and flexibility: therapists need to interrupt games and switch to other ones fluently during a therapy session.

CP game design

Input collected over 4 sessions with 11 therapists and 9 children with upper extremities CP from 2 different Dutch clinics resulted in the design of five new games and accompanying objects. These train different hand movements; grasping, wrist supination, and finger, shoulder and wrist extension. Objects of varying shapes, sizes, textures and weights have been used along with adjustable Velcro tags (see Fig. 1). All objects have been designed so as to prevent compensation.

The interaction in all games involves matching the flashing squares on the board with the objects in the child's hand. Every game uses an engaging background story (e.g., feeding a hungry monster or playing the piano). The therapists can control the difficulty level (i.e. game speed and number of repetitions) through a specially designed menu. To maintain motivation, encouraging feedback is provided through sounds and music. At the end of the game, feedback regarding performance is provided in terms of 'stars' earned by the child.

An evaluation session with 14 healthy children was performed as well in order to assess the very important fun aspect of the games. The games are now fully functional and ready to be embedded in a therapy setup.

Fig. 1 .

 1 Fig. 1. The TagTiles board (left), the stars earned (top left), the game menu (bottom), the game speed indication (extreme left), the repetitions indication (middle), some of the objects designed (top right) and a child with CP interacting with the board (right).


Dinesh Katre
email: dinesh@cdac.in

Pedro Campos
email: pedro.campos.pt@gmail.com

Torkil Clemmensen

Rikke Ørngreen

Annelise Mark Pejtersen

Rikke Orngreen

Human Work Interaction Design for e-Government and Public Information Systems

Keywords: Interaction design, human work analysis, empirical case studies, e-government, public information systems

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Workshop theme

This proposal is for the one day workshop during INTERACT 2011 to be organized by the members of WG 13.6 Human Work Interaction Design (authors of this proposal). We propose to involve the community of WG 8.5 Information Systems in Public Administration.

The complex interplay and information exchanges between the models of Government to Government, Government to Business and Government to Citizen pose different kind of challenges while designing the e-government systems. Human work analysis is very critical in public information systems design as the procedures, working styles, organizational contexts are different in various public sector organizations. Interaction design of e-government system and public information systems has to simultaneously address the user experience requirements of diverse users such as people from varied educational and professional backgrounds, senior citizens, physically disabled, illiterate and people with different languages and cultural preferences. The combination of Human Work analysis and Interaction Design in user interface design for e-government systems has to adopt itself to diverse delivery media such as web, desktop, touch screen kiosks and mobile devices.

We would like to invite position papers on the theme of the workshop following (but not excluded to) methodological approaches and domains such as - Human work analysis and interaction design case studies in egovernment and public information systems  The influence of socio-economical, political and cultural context on the design of public information systems  Social networks and collaborative user interfaces for policy crowdsourcing  Government-centric versus citizen-centric design approaches  User interface design for diverse delivery media for e-government services such as web, desktop, touch screen kiosk and mobile devices  Designing for diverse users, Every-citizen interface design, Mass personalization  Democratic design for e-government  HCI challenges in bridging the digital divide through e-government  Usability evaluation methods for e-government  User experience design for e-government

Intended audience

The theme of this workshop involves many disciplines across academic boundaries and hence a diverse audience can submit papers and attend the workshop. Obviously, people attending INTERACT 2011 and Participants of IFIP HWID WG 13.6, but also practitioners and researchers, who attend only this workshop, because they have a specific interest in the proposed themes. For example, researchers and practitioners in:

 e-government and public information systems  Organizational engineering and work analysis  Interaction design  E-government policy makers  Public information system design / development  HCI, Usability and UX practice This INTERACT workshop takes place in Portugal, and we encourage Portuguese researchers and practitioners to submit papers and to participate.

Publication of workshop papers

We have already formed an international programme committee for reviewing the research papers of this workshop. International Journal of Public Information Systems (IJPIS), Sweden has agreed to publish a special issue from the proceedings of this workshop.


Lourdes Moreno

Paloma Martínez

Ana Iglesias
email: aiglesia@inf.uc3m.es

María Gonzalez

HTML 5 support for an accessible user-videointeraction on the Web

Keywords: Web accessibility, video HTML 5, user agent, media players

Multimedia content covers the Web, and we should provide access to all people. For this reason, it is very important to take into account accessibility requirements in the player to avoid barriers and to ensure access to this multimedia content as well as their resources. One of the most frequent barriers is the technological obstacle: the necessity for the user to install the required plug-ins in to order to access video. The new standard HTML5 provides a solution to this problem. However, it does not fully support accessibility requirements of W3C standards, including WCAG and interaction requirement of UAAG. This paper 1 introduces an overall study of this new standard in relation to accessibility requirements for the players as well as an accessible HTML5 Media Player.

Introduction

The growth and access of rich and interactive contents such as video and audio have long filled the Web. Multimedia content must be accessible for people with disabilities according to standards like the Web Content Accessibility Guidelines (WCAG) [1] of Web Accessibility Initiative (WAI) [START_REF]W3C, Web Accessibility Initiative (WAI)[END_REF]. Additionally, multimedia accessibility content on the Web requires that a particular chain of essential, interdependent, and accessible components [START_REF] Moreno | Disability Standards for Multimedia on the Web[END_REF] should be taken into account for user agents. Specifically, media players should enable the delivery of accessible multimedia content and therefore a friendly user-video interaction would be a success. Furthermore, it is imperative that Web designers are familiar with the User Agent Accessibility Guidelines (UAAG) [4] of WAI as well as the existing media players capable of the accessible delivery of multimedia content.

The UAAG explains how to make user agents -including Web browsers, media players, and assistive technologies -accessible for people with disabilities, and particularly, how to increase the accessibility of Web content. Related to multimedia contents, there are accessibility requirements that must be taken into account respect to audio and video on the Web. In general, media players must ensure that all audio and video controls are accessible via keyboard and they should be accessed via screen readers. On the other hand, according the Guideline 1.2 of WCAG 2.0, media players must provide alternatives for time-based media and the media content must be accompanied by media alternatives as caption (or subtitles for deaf people), audio description, sign language, etc. in synchronized media. Moreover, according ATAG 2.0 guidelines, players should provide support for these media alternatives.

Previous studies [START_REF] Moreno | A study of accessibility requirements for media players on the Web[END_REF] demonstrated that current media players are not sufficiently accessible. Most of the online videos are delivered via Adobe Flash2 -based in-page video players. Flash has an excellent compression system that can deliver highfidelity audio and high-resolution video without taxing bandwidth. However, devices highly used for delivering video such as Apple3 -iPad and Apple -iPhone do not have support for this format.

As Universal alternative for solving accessibility problems appeared HTML5 [START_REF] W3c | HTML5. A vocabulary and associated APIs for HTML and XHTML[END_REF]. This marked language allows video delivery on the Web to be independent from used user devices, introducing the <audio> and <video> elements, which enables web browsers to natively support media.

Study of HTML 5 support for accessibility standards

The W3C is currently working on HTML 5, which will replace XHTML standards. HTML5 adds implicit semantic information, defines the basis of the documentoriented model (DOM), and presents a better structure. Regional landmarks on a webpage will have their own tags so that user agents can recognize them, which in turn will allow Web search robots gather more accurate information, letting authors embed accessibility multimedia elements natively (using <audio> and <video> tags), obviating the need for plug-ins.

HTML5 offers access in the embedded media player to be a huge step forward. The new standard introduces the latest commands (such as <video> and <audio>), which can create and label controls letting keyboard shortcuts to access them, and screen readers to tell the user which controls are available. Some HTML5 elements provide support for some UAAG 2.0 guidelines. However, the inclusion of caption and audio description, have not yet been included in the new standard because this is still under development. Problems have been detected in the current versions of most browsers in the support of <video> and <audio> labels 4 . Unfortunately, none of the current browser implementations are fully accessible by keyboard and screen-reader 5 . Others complications arise because the various browsers can't agree on what video codecs they're going to support, so actually using HTML5 <video> on the web is currently much more difficult than it should be 6 .

The current version of HTML5 provides some playback controls for the video: play/pause, full screen toggle, volume and audio element controller toolbar. These controls are very basic, not allowing the user to have full control of the video. Following WCAG 2.0 and UAAG 2.0 guidelines, these native controls of HTML 5 are not enough. It must have the following controls: end (stop), caption on/off, search captions for text strings and select caption language if closed captioning is available, audio description on/off, rewind/forward seconds, volume up/ down, screen reader full access and keyboard full access of controls.

In this work, we have developed an accessible HTML5 Media Player 7 as it is shown in the next section.

Accessible HTML5 Media Player

We have developed an accessible HTML5 Media Player, in order to build the mentioned controls as complement HTML5 support for interaction requirements included in UAAG 2.0, the use of JavaScript or Flash technology is required. We have chosen JavaScript because it does not require an external plug-in. Furthermore we have carried out different codifications of the same video to assure that the video can be played on all browsers. Currently there are three media formats that are under discussion of the different user agents: MP4, OGV, and WebM.

The attributes are included within <video> tag (see Figure 1), some of their values are called for JavaScript functions in order to achieve a high level of accessibility in the interaction with the video based on the standard UAAG 2.0. Some of the attributes are "controls" to load the native controls on devices with JavaScript disabled, and "onKeyDown" to control the video from the keyboard, so the user can use it for pause the video, stop it, show captions, etc. This function has been implemented with JavaScript. Because its complexity, it is not possible to describe in detail the code of each of the additional controls. Each of them has been implemented and its result is shown in Figure 3.

In order to add a caption in the player in HTML 5, an XML file was created with it. From this XML, file subtitles are being extracted and incorporated in a synchronized way through JavaScript and DOM is being modified.

In the case of access from devices with disabled JavaScript or CSS, the player will only appear with the HTML 5 native controls, allowing users access the video content. Moreover, to increase accessibility Keyboard Shortcuts have been defined to access the same functionality implemented using JavaScript technology and video 7 Available in http://labda.inf.uc3m.es/LourdesPlayer/ <div id="controls" onMouseOut="HideControls()"onMouseOver="ShowControls()" onKeyDown="KeyControls(event)"> <video width="660" id="player" onKeyDown="KeyControls(event)" onclick="repro()"> <source src="21.mp4" type="video/mp4" /> <source src="21.theora.ogv" type="video/ogg" /> <source src="21.webm" type="video/webm"> </video> transcriptions have also been provided. Finally, following UAAG requirements, which make reference to the usability, an alternative text have been associated for each of the player controls and the player offers a help guide, describing the keys associated with the keyboard shortcuts among others.

Conclusions

HTML 5 represents a step forward in the multimedia history on the Web, but there is still a lot of work to do in order to include accessibility requirements on user interaction, such as those that were done explicitly in this work based on W3C standard such as WCAG and UAAG. This issue is aggravated by the fragmentation between platforms. The question is posed, how should we deliver video, in Flash or HTML5? Currently, Flash supports more advanced interactions, but it presents some accessibility barriers. On the other hand, HTML5 provides accessible solutions, but it is still been developed and not all browsers implement it yet. Therefore, we suggest right now the smart strategy of implementing websites using both approaches, i.e.: approaches with accessible Flash players and with combination of HTML5 and JavaScript technology solution as it has been shown in this work.

Figure 1 .

 1 Figure 1.-HTML5 code of <video> Controls have been incorporated through JavaScript, included in a separate <div> for the rest of the code, as it is shown in Figure 2.

Figure 2 .

 2 Figure 2.-HTML5 code for controls

Figure 3 .

 3 Figure 3.-Accessible HTML5 Media Player

This research work is supported by the Research Network MAVIR (S2009/TIC-1542 (www.mavir.net/)), GEMMA (TSI-020302-2010-141) and SAGAS (TSI-020100-2010-184) research projects.

2011 Adobe Systems Incorporated, http://www.adobe.com/

Apple, http://www.apple.com/es/

New HTML5 feature accessibility support in Windows Browsers, http://html5accessibility.com/

Keyboard and Screen-reader Accessibility http://terrillthompson.blogspot.com/2010_08_01_archive.html

Dive Into HTML5, What Works on the Web http://diveintohtml5.org/video.html#what-works


Xavier Ferre
email: xavier.ferre@upm.es

Nigel Bevan

Usability Planner: A Tool to Support the Process of Selecting Usability Methods

Keywords: UCD method selection, development process, usability integration in systems development, standards

There is increasing pressure on developers to produce usable systems, which requires the use of appropriate methods to support user centred design during development. There is currently no consistent advice on which methods are appropriate in which circumstances, so the selection of methods relies on individual experience and expertise. Considerable effort is required to collate information from various sources and to understand the applicability of each method in a particular situation. Usability Planner is a tool aimed to support the selection of the most appropriate methods depending on project and organizational constraints. Many of the rules employed are derived from ISO standards, complemented with rules from the authors' experience.

Introduction

UCD (User Centred Design) approaches and methods for systems development are used to help build systems that are easy to use. While there is general consensus on the need for a user-centred approach to design, there is a great diversity of potential methods. Existing literature on usability methods offers little guidance on which specific methods should be used in a given situation.

In order to adopt a UCD focus in development, usability has to be considered throughout the different development stages. The specific UCD methods to apply at each stage must be selected, depending on the relevant project and organizational constraints. This is a challenge because systems development teams and organizations can experience difficulty when trying to understand UCD methods and their role in the overall development process [START_REF] Seffah | The obstacles and myths of usability and software engineering[END_REF].

Existing advice on UCD method selection starts with the method, rather than the purpose for which the method is used. Senior UCD professionals get acquainted during the development of their career with the different subtleties of each method that make it more advisable in certain situations, but other groups (junior UCD consultants, HCI students or even software developers with some HCI training) face important difficulties for choosing the most appropriate methods for a particular project. They need to gather information present in different sources, and they have to deal with different terminology across authors in terms of process descriptions, and in terms of criteria for considering the suitability of each method.

The ISO PAS (Publicly Available Specification) 18152:2003 [START_REF]A specification for the process assessment of human-system issues[END_REF] provides an overall view of the life cycle for developing systems for human use, highlighting the base practices associated with the different processes involved. It does not provide specific guidance on method selection but it serves as an overall process framework where to fit advice on UCD methods integration in the systems development process.

The ISO TR (Technical Report) 16982 [START_REF]Usability methods supporting human-centred design[END_REF], on the contrary, specifically addresses the issue of UCD method selection. It does not work with individual methods to be applied in a specific situation, but with categories of them. It has an important shortcoming from a professional perspective, in being "somewhat academic" (according to the Special Interest Group in Software Testing from the British Computer Society [START_REF]BCS SIGiST: Usability Guidelines[END_REF]). Furthermore, the usage of this technical report is not straightforward, since it requires moving between different tables and gathering all the relevant information that is scattered in the document.

Usability Planner [7] is an online tool that supports the process of UCD method selection. It aims to ease the present difficulties found in considering the different knowledge sources, integrating the overall view in ISO PAS 18152:2003 with the recommendations present in ISO TR 16982, and supplementing them with the authors' own experience.

Method selection with Usability Planner

The difficulties traditionally found in UCD method selection arise from the difficulty of dealing with a diversity of issues that may influence the choice of methods. In a common scenario, UCD has already been identified in the organization as necessary for improving the quality of the system to produce, and there is a decision on the -typically limited -resources to dedicate to UCD in the project.

In these circumstances only a few UCD methods may be chosen, with the aim of maximizing their impact on the final usability level of the system produced. The sequence for making this choice using Usability Planner is:

1. Establish the overall background to consider: Either a UX (User eXperience) -UCD background, or a software engineering (developer) one. Depending on the choice a different set of stages into which to allocate the methods is offered.

2. Identify the specific project stages for which methods are to be selected. At this point the user may optionally prioritize the stages according to business benefits or risk avoidance considerations.

3. Specify the constraints related to the project as a whole, or individual stages of the project, and see the recommended methods.

4. View a summary of the recommendations for the project in the form of a usability plan including the selection of methods for each stage.

Fig. 1 .

 1 Fig. 1. Three first steps in the usage of the tool for method selection.

Preliminary evaluation and conclusions

When a preliminary prototype [START_REF] Ferre | UCD Method Selection with Usability Planner[END_REF] was demonstrated to participants at the NordiCHI 2010 conference, all 11 people who tried using the tool were positive about its potential value. One continuing challenge has been to find a sequence that the different types of users find logical for the inter-related decisions that have to be made. Decisions on inter-stage prioritization have been made optional, since some users will not need to address such an issue, and the support that may provided for such prioritization is weaker than the support provided for method selection.

While the tool initially embodies the knowledge of the authors, this will be refined by iterative evaluation. Additionally, the content is customizable, so that any organization with UCD expertise may modify the criteria for method selection in the tool to match their own criteria.

The tool will be offered under an open source license (GNU General Public License, version 3 [START_REF] Gnu | General Public License version 3[END_REF]), so that the community can modify it or further extend it.

Initial responses to the value of the first complete prototype of the tool have been very positive. The next steps include: 1. Refining the set of methods and criteria, and the internal weighting, to find out whether the tool can consistently make similar recommendations to experts. 2. More formal evaluation of the usefulness and usability of the tool for the intended user groups. 3. Exploring whether the tool can take account of how methods are customised and adapted to project needs. 4. Extending the tool with additional functionalities like saving the current project.


Gregor Buchholz
email: gregor.buchholz@uni-rostock.de

Peter Forbrig
email: peter.forbrig@uni-rostock.de

Elaborating analysis models with tool support

Keywords: Task Models, Scenario Analysis, Model Based Development

Integrating models as essential elements into the software development process is supported by numerous methods and tools but the creation of such models still bears a considerable challenge. This paper proposes a structured modeling of tasks and activities during the requirements analysis in order to pave the way for the very early utilization of models. A tool implementation demonstrates the elaboration of models based on scenarios.

Introduction 1.Motivation

A considerable number of methods and tools for the integration of task models into software development and usability testing can be found. The underlying paradigms (model-based and model-driven development) include the use of models in all development stages [START_REF] Johnson | A Model-Driven Development Approach to Creating Service-Oriented Solutions[END_REF]. Models for design have to be deduced from requirements analysis results which would be much more convenient if the analysis stage itself purposed the formalization of its output as a model. While it might be a feasible objective to model user intentions, goals and tasks at a high level it becomes more and more difficult and laborious as the level of detail grows [START_REF] Paris | Environments for the Construction and Use of Task Models[END_REF]. We will introduce a tool supported method to create such models during the requirement analysis phase.

Related Work

Deriving descriptions of user and system tasks from recorded scenarios has been conducted and documented before. The CelLEST process [START_REF] El-Ramly | Recovering Software Requirements from System-user Interaction Traces[END_REF] reconstructs a navigation model of an existing application as state graph with screenshots as states and user inputs as state transitions, aiming at the documentation of existing systems. In [START_REF] Maulsby | Inductive Task Modeling for User Interface Customization[END_REF] ActionStreams is proposed for the creation of task models based on user behavior. The users' activities are observed and recorded for a comparatively long time ("a little more than a day") and a grammar production represents the autonomous learning of the system. An example for the analysis of interaction sequences to deduce domain knowledge for learning systems via Sequential Pattern Mining (SPM) is the framework described in [START_REF] Fournier-Viger | A Knowledge Discovery Framework for Learning Task Models from User Interactions in Intelligent Tutoring Systems[END_REF] that has been proved in the tutoring system RomanTutor. The ProM framework [START_REF] Van Dongen | The ProM framework: A New Era in Process Mining Tool Support[END_REF] features a wide variety of algorithms to discover and mine processes and a lot more. In addition to the construction of a formal correct model our approach includes the semantic meaningful abstractions of actions to task.

Collaborative Model Building as Learning Activity

The goal of the analysis phase is to define the problem to be solved and the desirable outcome is a clear and precise description of tasks for which software support has to be built. That elaboration of a common understanding of the problem is challenging and methods and artifacts are needed that help to arrange the acquired pieces of knowledge, to reveal missing information and to support discussion.

Gathering Domain Knowledge

This work supports the idea of the employment of task models as domain-independent modeling technique during all phases of software development. The selection of techniques for the first requirements elicitation is rather unaffected by the intention of task modeling. As usual, functional as well as non-functional requirements are wanted. That includes the identification of user roles, business objects, context information, use cases etc. and also descriptions of scenarios.

Structuring Domain Knowledge

The formal specification is started with the main goal of the problem to be solved on an abstract level which is then refined into more concrete tasks. Temporal relations between tasks can be modeled with the operators known from CTT (Concurrent Task Trees) [START_REF] Paternò | Model-Based Design and Evaluation of Interactive Applications[END_REF]; missing operators will be deduced later. Each model can be assigned to a role as a separation into distinct models for different roles may be useful.

The requirements elicitation not only unveils abstract tasks but will also comprise more concrete actions. These actions can be assigned as sub-elements to tasks, so as to build groups and specify which section an action belongs to.

Scenario-based Exemplifying

In the next step the models with tasks and actions are used to generate examples of scenarios. The developed tool supports the role-based recording of actions as well as a file import functionality to include traces produced by other systems, such as a log file from an existing software system.

Construction of Detailed Models

A tree with abstract tasks ("Manage account", and "Use account" in Fig. 1), a set of actions assigned to these tasks, and a set of action traces exemplifying the fulfillment of the tasks (see Fig. 1) are the basis for model generation. The resulting tree structure is a candidate for suitable representation of processes the system is to support (see the tree in Fig. 1). The tool features three steps of model generation: Pattern recognition identifies frequently occurring sequences of actions in the traces based on the assumption, that actions observed together may be steps of a more abstract task. For finding such patterns the Apriori algorithm, PrefixSpan, and BIDE+ are implemented. The recognition results in groups of potentially related actions. A reviewing of these groups comprises a reasonableness check and labeling. The goal of hierarchy creation is to combine the manually top-down decomposed tasks with the generated parts created bottom-up, only loosely coupled to the upper part. In short, this step merges analytic and synthetic parts using a LearnModel algorithm modification without objects assigned to tasks and with the notation and operators of CTT until all actions from the protocols are assigned directly (one edge connecting both nodes) or indirectly (one or more nodes between the nodes) to a task. In the process of identifying temporal relations initially all sibling nodes are considered to be in an enabling relation following their first occurrence in the first trace of the analyzed trace set they occur respectively. The protocol analysis corrects this assumption and order independence, iterations and concurrency are suggested. Each time an operator is modified all operators up to the root are modified, if violated. This process can be repeated any number of times, selecting different sets of task traces and with varying settings for operator detection. Thus, different rival model versions can be created and discussed.

Evaluating the Progress and Starting of new Iteration

The models can be simulated by the provided tool. Therefore, one or more clients connect to the server; a stored model is selected and opened in the simulation module with a specific role. Then, the execution of actions is simulated by activating the actions in the wanted order according to the previously detected scenarios. If any needed action is not accessible (that is, it is not in the enabled task set) or an action is enabled but known to be forbidden at that time, the model can be corrected. These simulations' protocols can serve as input for the next model generation iteration.

Conclusion and Future Work

This paper describes a method to establish models as an integral part of requirements analysis. Traces of scenarios can be combined with the structured knowledge about tasks to formalize the findings about the current situation. The approach employs modified data mining and association algorithms to derive relations between actions and tasks and build a hierarchical task structure. Results of the process have to be interpreted as a model of an existing situation. The approach and the tool support may help in simplifying the transfer of previously informal knowledge to structured and formal presentations.

Next steps will be the improvement of tool for annotations and references to other artifacts. Furthermore, it has to be investigated in which way the implemented tool can contribute to test prospected scenarios. In this situation, not the generation but the validation of models will be in focus.

Fig. 1 .

 1 Fig. 1. Sample scenario traces and resulting model.


Ole Andreas Alsos

Dag Svanaes
email: dag.svanes@idi.ntnu.no

Designing for the Secondary User Experience

Keywords: User experience, UX, end user, secondary user, secondary user experience, patient experience, clinical simulation, usability evaluation

) is tailored for the secondary user. Sometimes a focus on the secondary user implies that the designer must deal with conflicting needs between the primary and the secondary users.

Introduction

Most user interfaces are designed for single users. This is true even for the user interfaces of collaborative applications, such as Facebook and Skype (although the applications are collaborative). However, as systems are being used in collaborative settings, the use of computing systems will increasingly involve people beside the primary user. Sometimes other people indirectly become users of the user interface without even interacting with it. One such situation is face-to-face interactions where one person, the primary user, is using an information system while interacting with another person face-to-face, i.e. the secondary user. It could be a physician talking with a patient in a medical consultation while interacting with an electronic patient record system, or a clerk serving a customer while looking up information in a product directory (e.g. in banks, travel agencies, or shops). In such situations one could expect that both persons are affected directly or indirectly by the user interface of the information system; both the primary user, who is using the system directly, and the secondary user, who relies on the primary user to obtain information from the system and is affected by the primary user's experiences with the system.

The needs of the secondary users are rarely in the minds of the system designers and developers of information systems, and are often neglected [START_REF] Sharp | Stakeholder identification in the requirements engineering process[END_REF]. While the user experience (UX) is considered important when designing for the primary user, there is no equivalent concept in the HCI literature for the secondary users.

In this paper we seek to extend focus on user experience to go beyond the traditional "first person user" perspective and to include secondary users. We do this by defining the secondary user experience. Then, by drawing on two different usability evaluation studies of mobile devices used in a realistic hospital setting, we identify some ways in which the design of the user interface can affect the secondary user experience. Finally, we provide preliminary guidelines for designing for the secondary user experience in a hospital setting.

Secondary User Experience

Eason [START_REF] Eason | Information Technology and Organisational Change[END_REF] identifies three categories of users; (1) primary users who are frequent hands-on users of the system; (2) secondary users who are occasional users or use the system through an intermediary, and (3) tertiary users, who are affected by the introduction of the system or influence its purchase. Other researchers have defined other comparable end-user variations [START_REF] Faulkner | Usability Engineering[END_REF][START_REF] Ågerfalk | Who is the user in user-centered design? HCII[END_REF].

It is the authors' impression that designers and developers to some extent are aware of the peripheral end-user groups, i.e. those who do not directly interact with the systems, but that few actually design for them. They mainly take the direct/primary user into account when designing system. Thorough work is often done in identifying stakeholders in the requirements process, but end-users are mainly considered those who directly interact with the system (e.g. [START_REF] Sharp | Stakeholder identification in the requirements engineering process[END_REF]).

The current usability definition, ISO 9241-11:1998 [START_REF]Ergonomics of human system interaction -Part 11: Guidance on usability specification and measures[END_REF], does not distinguish between different end-users. However, a number of HCI publications refer to a 1997 draft of the definition. This version contained a reference to people that do not directly interact with the system: "[Satisfaction is] the comfort and acceptability of the work system to its users and other people affected by its use" (our emphasis). However, this reference to "other people" was omitted in the final version of the usability standard (see [START_REF] O'grady | Mobile agents for mobile tourists: a user evaluation of Gulliver's Genie[END_REF] for an example).

In many use situations, especially from client-service relations and health care, the primary users of information systems are engaged in face-to-face interaction with customers or patients. They may for example be a client making deposits in a bank, a globetrotter booking a flight in a travel agency, or a customer buying products in a shop. The way we see it, these types of secondary users are recognized by the following characteristics:

-They are interacting with the primary user, who interacts with the system.

-They are not (or in little extent) interacting directly with the system themselves.

-They rely on the primary user to obtain information from the system.

-They are influenced by the primary user's experiences with the system (e.g. effectiveness, efficiency, satisfaction, etc.)

User Experience and Co-Experience

Researchers and practitioners have different views on what the user experience (UX) is [START_REF] Law | Understanding, scoping and defining user experience: a survey approach[END_REF]. As defined in ISO 9421-210 [8], it is "a person's perceptions and responses that result from the use or anticipated use of a product, system or service". UX is here associated with the primary user.

Others have proposed comparable definitions, such as Law et al., [START_REF] Law | Understanding, scoping and defining user experience: a survey approach[END_REF], who propose that "UX focuses on interaction between a person and something that has a user interface". The study excludes face-to-face interaction between people, unless a user interface is involved in the interaction. For this kind of interactions, Co-Experience provides a better explanation; it is the user experience created in social interaction with the presence of a system or product [START_REF] Battarbee | Defining Co-Experience[END_REF]. For use situations as described in the introduction, UX and co-experience relates as follows: While UX concerns the primary user, co-experience relates to both the primary and secondary user (Figure 1).

Secondary User Experience

We have found few examples of secondary user experiences in literature. An exception is provided by Montague [START_REF] Montague | Understanding Patient User Experience in Obstetric Work Systems[END_REF], who claims that patients have a user experience of technology used by care providers even if they are passive users of it. During childbirth, the health care providers use technology to monitor the health condition of the unborn child. By interviewing mothers about the technology used on them, Montague found that when technology worked well, it created positive experiences and increased the patients' connection with their babies. When technology did not work well, or when care providers could not get technologies to work properly, negative experiences occurred.

We have found no existing definitions of the user experience of secondary users. Therefore we define it as follows:

The secondary user experience of a system is the part of the overall experience of the secondary user that can be attributed to (1) the primary user's interaction with the system, or [START_REF] Eason | Information Technology and Organisational Change[END_REF] the secondary user's interaction with the system with the primary user as an intermediary.

Secondary UX is different from UX and co-experience in that it only relates to the experiences of the secondary user (see Figure 1). The ward round is a situation with both a primary user (the doctor) and a secondary user of a system (the patient). Mobile electronic patient record systems for bedside usage are primarily designed with the doctor in mind. Few have considered the effects on the patient. Therefore, we have retrospectively analyzed the data and findings from two previously conducted usability evaluation studies of prototype mobile systems for hospitals [START_REF] Alsos | Interaction techniques for using handhelds and PCs together in a clinical setting[END_REF][START_REF] Alsos | Doctors' Concerns of PDAs in the Ward Round Situation -Lessons from a Formative Simulation Study[END_REF]. Both evaluations were conducted in a simulated hospital environment with multiple persons involved; real physicians consulting patient actors lying in the hospital beds.

Using handhelds and patient terminals together. In the first evaluation, we explored several ways of allowing doctors to use handheld devices together with bedside mounted patient terminals for viewing x-ray images in collaboration with the patient (Figure 2). Five pairs consisting of a physician and a patient each performed eight ward rounds using different variants of the x-ray image viewer. In total, 40 ward rounds where performed. For each evaluation, the physician and the patient were interviewed simultaneously about aspects concerning the user experience of the system. The prototypes and research approach are previously described in [START_REF] Alsos | Interaction techniques for using handhelds and PCs together in a clinical setting[END_REF].

Handheld medication system.

In the second study we explored interaction techniques for a handheld medication system; one paper based and three mobile patient record systems (Figure 3). 14 physicians conducting in total 56 ward rounds. Physicians and the patients were interviewed separately about aspects concerning the user experience. The study and prototypes are previously described in [START_REF] Alsos | Doctors' Concerns of PDAs in the Ward Round Situation -Lessons from a Formative Simulation Study[END_REF].

With assistance from a physician and a nurse, much effort was used designing the patient scenarios, tasks and environment for both evaluations as close to their real working environment as possible. The patient actors were carefully instructed how to behave and what to say, to make the behavior as realistic as possible. Senior sociologists with experience from health care studies, as well as facilitators and participating physicians and patients considered the scenarios played out in the evaluations to be realistic instances of hospital work. The video recordings from the evaluations were analyzed using methods from video-based studies of human interaction with technology [START_REF] Heath | Video in qualitative research[END_REF], while the interview data was analyzed qualitatively using methods influenced by grounded theory.

Results

When replacing the non-digital solutions, such as paper based records and x-rays images with mobile computing technology, we found a number of issues related to the user experience for the primary and secondary users:

The primary users preferred digital over non-digital. Although the physicians in general were confident in using the paper chart (study 2), they preferred using the mobile computing device. A number of functions and attributes, such as pocket size, error prevention and undo mechanisms, contributed positively to the UX.

Secondary users had strong opinions about unused system. In the first study the patients, as passive users of the system, had strong opinions about the different versions of the x-ray viewer, even if the patient's part of the system was identical (or nearly identical) for all versions. The main difference was on the mobile device, which was only used by the physician. However, the physicians' usage of the different variants of the system had large effects, both on how smoothly they were able to present new x-ray images on the patient terminal, and how both the physicians and patients rated them afterwards.

Mobile devices hampered the nonverbal communication.

The physical form factor of the paper chart allowed the physician to use it as a channel for nonverbal communication. For example, some doctors signaled that the consultation was ending by closing the chart, or invited the patients to speak by tilting the chart towards them. This was harder with the PDA, and was considered negative by the patients.

Mobile devices reduced the doctor-patient dialogue. The user interface of the mobile device increased legibility and allowed the physicians to undo and minimize medication errors. On the other hand, the user interface gave poor information overview and had unfamiliar interaction techniques. This required much of the physicians' attention, and according to the patients it hampered the doctor-patient dialogue and reduced their satisfaction of the consultation.

Good for the doctors was (sometimes) bad for the patients. In most of the design solutions of the first study, the doctor controlled the patient terminal through a mobile device. While this was seen as a major benefit from the perspective of the physicians, who could hide private information on the mobile device and display public information on the patient terminal, it was perceived as negative from the perspective of the patients. They did not understand what was going on and did not like that information was hidden for them.

Good for the patients was (sometimes) bad for the doctors.

In other design solutions the physicians controlled the system directly through the patient terminal. Unintentionally it also allowed the patient to partly interact with the terminal. For the patient this was perceived as an improvement. For the physicians, however, it became harder to control the system as they had to bend over the patient to use it.

User interface complexity confused patients.

In some versions of the first study, the controls for changing information content were present on the patient terminal. The increased complexity of the GUI confused some patients. They rather preferred the versions where these controls were moved onto the physician's mobile device.

Spoken language was influenced by GUI. In the second study, a pause symbol (as used in music and video players) was used on the mobile device to temporarily cease medical treatment without removing it from the medication list. This lead the physicians to use words like "pausing this drug" rather than the more incomprehensible term "cessation", which was commonly used when using the paper chart. While the first term was obvious for the patients, the latter was a foreign word.

Discussion

The findings in this study demonstrate that secondary users have a kind of user experience of an information system that is used by primary users. Further it shows that designers sometimes face tradeoffs between the primary and secondary UX.

User experience is Relevant for Secondary Users.

The studies demonstrated, not surprisingly, that technology had an impact on the primary user (i.e. physician), who was directly interacting with the system. Further, our observations showed that the primary users' interaction with the system also had an impact on the secondary users. For example, the patients had some sort of user experience; they had strong perceptions and responses about the system, although they had not used the systems directly themselves.

The positive correlation between patient satisfaction on health outcome has long been established [START_REF] Ong | Doctor-patient communication: A review of the literature[END_REF]. When patients report that they are satisfied or dissatisfied because of the physician's interaction with the system (i.e. their experiences as a secondary user), we can assume that it has some impact on the overall patient satisfaction. This was for example seen when the complexity of the GUI confused patients.

Trade-off between Primary and Secondary User Experience

The analysis indicates that designers are faced with tradeoffs between the needs of the primary and secondary users. When the user experience was improved for the physicians, it had in some cases negative effects for the patients, e.g. the ability to hide information on the mobile device. In addition, we found that when the secondary user experience was improved, it sometimes created new problems for the physicians, e.g. reducing the ergonomics when interacting with the system. Consequently, aspects of the user experience for the primary user can have negative consequences for the secondary user. In a similar manner, improving the user experience for the secondary user can have negative consequences for the primary user.

How should one deal with the potential trade-offs between the design of the primary and secondary user experience? One cannot design the primary user experience first and then the secondary user experience. It may lead to a suboptimal solution for the latter. Both user experiences must therefore be designed together. Yet, the designers must often prioritize. In the hospital it could be a bad priority to propose designs that threat patient safety just to make the patient experience slightly better.

First Steps towards Design Guidelines

Accommodating the needs of the secondary users is important. In the context of a ward round with a physician and patients, a positive secondary user experience can have positive effect on the doctor patient dialogue, which is important for the treatment and care of the patients [START_REF] Ong | Doctor-patient communication: A review of the literature[END_REF]. In the context of business, for example a travel agent serving a potential traveler, or a checker handling a customer, improving the secondary user experience can have positive effect on the overall customer experience. This often means satisfied returning customers and increased revenue [START_REF] Peppers | Return on customer: creating maximum value from your scarcest resource[END_REF]. Drawing on our findings, we suggest four preliminary design guidelines that we find relevant for information systems involving a secondary user experience. Research in other domains and with other technologies will be needed to make the list more complete:

-Give system feedback to the secondary user. By increasing the action transparency (i.e. increase the visibility of actions) or providing alternative system feedback to the secondary user, one can improve the secondary user experience. -Support non-verbal communication. The quality of the non-verbal aspects of faceto-face communication has a strong impact on the secondary user experience. Our findings indicate that the system can hinder this communication, especially when the system occupies the hands or hides the face of the primary user. Therefore, the physical form factor of the system needs to support nonverbal communication. -Use the language and representation of the secondary user. By presenting the information for the primary user in the language of the secondary user, the primary user can be guided to use simpler terms and communicate on the same level as them, i.e. physicians use terms like "blood sugar level" instead of "glucose". This can make it easier for the secondary user to understand. -Provide a GUI and/or device tailored for the secondary user. If feasible and necessary, an additional device/GUI with information tailored for the secondary user should be provided. This will give the secondary users a version of the information where unnecessary complexity and irrelevant information is removed. In addition to the above suggestions, we suggest that (1) the perspectives of the secondary user are included throughout the design process, and that (2) usability evaluations include both the primary and secondary users together.

Limitations and Future Work

It is important to note that the evaluation studies presented here were not explicitly designed for the purpose of illuminating the secondary user experience. The data was analyzed retrospectively. Moreover, we recognize the limitations regarding the use of "role-plays" as one of our primary data sources.

The design guidelines are very preliminary and their validity is limited to ward round scenarios with mobile technology. We do believe, however, that other domains with secondary users may benefit from similar studies to improve the secondary user experience. Future work should further investigate the concept of secondary user experience, as well as the generalizability outside the presented case.

Conclusion

The needs of secondary users, who only use an information system occasionally or through an intermediary, are often neglected. Designers and developers must address the need of secondary users and include them in the design and evaluation process of the system. This means designing devices or GUIs that (1) support non-verbal communication, (2) provide feedback to the secondary users, (3) use their language and representations, and ( 4) is tailored for the secondary user. Sometimes this implies that the designers deal with conflicting needs between primary and secondary users.

Figure 1 :

 1 Figure 1: UX relates to the primary user, Co-experience relates to the shared experience by the system of both users, and secondary UX relates to the secondary user. The solid arrows indicate interaction, while the dotted arrow indicates indirect interaction.

Figure 2 :

 2 Figure 2: Using handheld devices together with bedside mounted patient terminals

Figure 3 :

 3 Figure 3: Comparing interaction techniques for handheld medication system