AdaptNow

Roberto César Vasconcelos Dias (Bachelor)

Thesis submitted to the Universidade da Madeira for

Obtaining a Master Degree in Computer Engineering

Funchal – Portugal

Fevereiro 20014

iii

Supervising Teacher:

Professor PhD Sergi Bermudez

Invited Assistant Professor of M-ITI

v

ABSTRACT Elderly population will become the largest age group of our society in the next twenty years.

Consequently, we need to be able to accommodate technologies to the needs of this population.

AdaptNow is a web-based application that allows users to adapt existing webpages and turn

them more accessible and user friendly. Users can do so directly from any web browser thanks

to AdaptNow's user personalisation and automatic adaptation artificial intelligence algorithms.

In this paper we present the design and implementation of AdaptNow, a solution that improves

navigation on the web for elderly users.

vii

KEYWORDS

Web enhance, AdaptNow, Elderly users

ix

RESUMO

Bla, bla, bla.

xi

KEYWORDS

Web enhance, AdaptNow, Elderly users

xiii

xv

ACKNOWLEDGMENT

…

Acknowledgements

xvi

xvii

TABLE OF CONTENTS

I. Introduction 1

I.1. Motivation ..................................................................................................................... 1

I.2. Context/Problematical................................................................................................ 2

I.3. Contribution ................................................................................................................. 3

I.4. Structure ........................................................................................................................ 4

II. State of the Art 5

II.1. Overview ....................................................................................................................... 5

II.2. Accessible computer design approaches .................................................................. 6 Assistive technology ............................................................................................................ 6 II.2.1. Rehabilitation Engineering ................................................................................................. 9 II.2.2. Universal design/ Design for all ..................................................................................... 10 II.2.3. Transgenerational design .................................................................................................. 11 II.2.4. User pyramid design ......................................................................................................... 12 II.2.5. Inclusive design .................................................................................................................. 13 II.2.6. Ability-based design .......................................................................................................... 15 II.2.7. Conclusion .......................................................................................................................... 16 II.2.8.

II.3. Architecture design ................................................................................................... 16

II.4. Types of user interfaces ............................................................................................ 18

II.5. Types of users ............................................................................................................. 22 Elderly users ....................................................................................................................... 22 II.5.1. Low vision users vs. dexterity impaired users .............................................................. 25 II.5.1.

III. AdaptNow – Experiments and Artificial Intelligent System 27

III.1. Web enhancements and artificial intelligence (AI) modelling ............................ 27 Method ............................................................................................................................... 27 III.1.1. Results ................................................................................................................................ 29 III.1.2.

III.2. Enhanced historic and bookmark view .................................................................. 33 Methods ............................................................................................................................. 33 III.2.1. Results ................................................................................................................................ 34 III.2.2.

IV. AdaptNow – Implementation 49

IV.1. Use cases ..................................................................................................................... 49

Table of Contents

xviii

IV.2. Task model ................................................................................................................. 51

IV.3. Requirements ............................................................................................................. 52 Functional Requirements ................................................................................................ 55 IV.3.1. Non-Functional Requirements ....................................................................................... 56 IV.3.2.

V. Conclusion and Future Work 68

Index 4

VI. References 5

Table of Contents

xix

xxi

LIST OF FIGURES

Figure 1 - (a) Ideal system interaction. (B) The user does not fit the system, so the interaction with it is made through an adaptation. Adapted from [5]. ........................................... 8

Figure 2 - The pyramid design method.- Adapted from [25]. .......................................................... 13 Figure 3 - The inclusive design cube. Adapted from [27]................................................................... 14 Figure 4 - Ability-based design principles. Adapted from [5]. .......................................................... 15 Figure 5 - Adaption based system proposals. Adapted from [29] rever ......................................... 18 Figure 6 - Two aprotches to dropdow menus: (a) static split menu, (b) adaptable split menu.

Adapted from [30] ............................................................................................................. 20 Figure 7 - Boxplot of menu types versus speed, from Findlater et al. experiment (N=27).

Adapted from [30] ............................................................................................................. 20 Figure 8 - Example of GUI interface that was automatically generated using Supple++. A)

Typical interface, b) interface for a mouse users with impaired dexterity, c) adaptation for low vision user, and d) for users with both low vision and impaired dexterity. Adapted from [38] .......................................................................... 26

Figure 9 – Principle component analyses of the date with the objective of finding relations between the features. ........................................................................................................ 31

Figure 10 – Example of mouse model used during the experiment where we can see the different sizes used. a) normal mouse appearance; b) mouse appearance when hover a clickable area ........................................................................................................ 32

Figure 11 - Number of hour using the computer per week ............................................................... 34 Figure 12 – Features importance for adding a shortcut (bookmark) to the webpage from each

group of inquired. ............................................................................................................. 35 Figure 13 – Features used to differentiate the most visited webpages for each inquired group .. 36 Figure 14 - Features used to differentiate the webpage where the most time was spent

according to each inquired group ................................................................................... 36 Figure 15 – How should the historic be displayed to facilitate the search. ...................................... 37 Figure 16 – Inquired answer to if audio feedback would improve navigation. .............................. 38 Figure 17 – What inquired classified as the most relevant information that should be

transmitted through audio feedback. ............................................................................. 38 Figure 18 – Historic view presented to the users with the intent of them choosing which

information would be displayed. .................................................................................... 39 Figure 19 – Inquired classification which information was more relevant on this type (Figure

18) of historic view. ........................................................................................................... 40 Figure 20 - Historic tree view presented to the users with the intent of them choosing which

information would be displayed. .................................................................................... 41 Figure 21 - Inquired classification which information was more relevant on this type (Figure

20) of historic view. ........................................................................................................... 41 Figure 22 - Historic chain view presented to the users with the intent of them choosing

which information would be displayed. ........................................................................ 42 Figure 23 - Inquired classification which information was more relevant on this type (Figure

22) of historic view. ........................................................................................................... 42 Figure 24 – User classification of historic, being d – per day, w – per week, d/w – last 7 days

and they weekly and d/w/m - last 7 days them last 4 weeks and them per month. The graphs are split by groups .......................................................................... 43

List of Figures

xxii

Figure 25 – Information placement on the historic icon view for the >40 group ........................... 45 Figure 26 - Information placement on the historic icon view for the >40 group ............................ 46 Figure 27 – Use case diagram for the AdaptNow application. ......................................................... 50 Figure 28 – Frequent user’s interaction with the AdaptNow system. ............................................. 51 Figure 29 – Users interaction for changing personal enhancement’s as mouse and colour. ........ 52

List of Figures

xxiii

xxv

LIST OF TABLES

Table 1 - The transgenerational design principles in order to provide a better product to everybody - Adapted from [22] ...................................................................................... 12

Table 2 - – Summary of the study analysed on the four types of interfaces and their result. ....... 22 Table 3 – Comparison table between different types of elderly users .............................................. 23 Table 4 – Elderly issues while navigating the web associated with the type of impairment it

is related. ............................................................................................................................. 25 Table 5 - Webpage characteristics and their corresponding significance in the web

enhancement AI model. The used web page characteristics are a) Screen Width, b) Page Height, c) Number of words, d) Biggest image Width, e) Average image width, f) Number of scripts, g) Number of H1 tags, h) Number of H2 tags, i) number of divisions. * p<0.05, ** p<0.01, and *** p<0.001. .......................................... 29

Table 6 - The weight and error of each of the feature model in relation to the webpage characteristic. The used web page characteristics are a) Screen Width, b) Page Height, c) Number of words, d) Biggest image Width, e) Average image width, f) Number of scripts, g) Number of H1 tags, h) Number of H2 tags, i) number of divisions. ............................................................................................................................. 31

Table 7 – Adaptation of Table 4, adding the solution to the uses present previously for the elderly interaction with the web. .................................................................................... 55

The functional requirements relate to all the operation that the system must allow the users perform. Through the analyses of Table 7 and the experiment conducted we got as requirements the following list: .................................................................................. 55

List of Figures

xxvi

xxvii

ACRONYMS

AI – Artificial Intelligence

1

I. INTRODUCTION

"People Propose, Science Studies, Technology Conforms"

Donald Norman person-centered motto for the 21st

century [Norman, 1993]

Bla, bla, bla.

I.1. MOTIVATION

"We see computers everywhere but in the productivity

statistics"

Attributed to Robert Solow [Landauer, 1997]

Bla, bla, bla.

Introction

2

I.2. CONTEXT/PROBLEMATICAL

bla

Introction

3

I.3. CONTRIBUTION

Introction

4

I.4. STRUCTURE

Introction

5

II. STATE OF THE ART

“The ideal engineer is a composite ... He is not a scientist, he is

not a mathematician, he is not a sociologist or a writer; but he

may use the knowledge and techniques of any or all of these

disciplines in solving engineering problems.”

—N. W. Dougherty (1955)

II.1. OVERVIEW

The difficulty in using technology for people with impairments is a well know problem. In an

attempt to make the usage of technology more comfortable there a large group of applications

designed to aid in the interaction with technology have been developed[1][2]. Unfortunately,

the development of some of these applications has been shut down, either by lack of funds, the

complexity and time required to spend is too high, and also the fact that the target audience is a

minority with low resources to pay to use these software. These types of software usually

change the interface of some application in an attempt to make his usage more comfortable,

since the interface is one of the key factors in the human-computer interaction.

Nowadays computer interfaces are typically designed with the assumptions 1) that they are

going to be used by an able-bodied individuals; 2) using an typical set of input/output devices;,

3) that users are in a stable environment [3]. This makes building user interfaces to allow access

to everyone a non-trivial task. Even non-impaired users sometimes cannot use certain tools

correctly if the environment is not the appropriated for the task that they are trying to perform.

This includes factors like location and technology used and the environment [4], for instance,

Introction

6

designing for someone that is on a bus or a train changes radically the interaction paradigm.

Moreover, it is important to note that not everyone uses the same input/output devices in the

same way and that should be taken in consideration while building a user interface. These

factors create a growing necessity for creating interfaces that can adapt and change based on the

user behaviour and also on the environmental changes. Most of the existing solutions are

expensive what creates a great barrier for the users with special needs/user with impairments.

User abilities and needs vary from one individual to another and may change over time.

Among people with long-term impairments, even individuals with similar medical diagnoses

can have very distinct functional abilities. Abilities can fluctuate throughout the day due to

medication or fatigue, or evolve across days or months following longer-terms changes of the

underlying medical condition [3]. This makes it hard to create an application that can be a best

fit to everyone, so the ideal solution should be something that can adapt itself according to the

environment and the user condition. Consequently, technology should adapt to the person and

not the opposite.

II.2. ACCESSIBLE COMPUTER DESIGN APPROACHES

The approaches to accessible computing are numerous. All the accessible computing

approaches share the common goal of increasing the independence of people with disabilities

and also improving their quality of live [5]. Accessible computing approaches can be broadly

determined by the user group they address and how they aim at solving usability issues. When

studying the different approaches it is important to understand their temporal evolution and

that each of them was develop in different periods. The approaches that we are going to discuss

are: assistive technology, rehabilitation engineering, universal design, design for all,

transgenerational design, user pyramid design, inclusive design and ability-base design.

Assistive technology II.2.1.

Assistive technology is a standard term for devices or technological approaches with intend of

helping people to overcome their disabilities [6]. This concept was developed out of World War

II (WWII) and the post-war era with the objective to improve the quality of live for the war-

Introction

7

wounded that had lost body parts in the battlefield [7]. Although this concept was coined only

after the WWII there are ancient records of such methods being used. For instance, in the

ancient Egypt artificial limbs made out of fibber were used [8].

Assistive technologies try to fit a “non-standard user” to standard technology through the use

of assistive components, like ad-on inserted between the user and the system. This method was

suggested after the WWII, thus it emerged prior to the proliferation of interactive computing.

Consequently, this method has a tendency to assume that the environment is immutable and

cannot be easily changed [5]. Immutability is something that we cannot assume nowadays

when interacting with a computer or other technologies. Nowadays we have mobile and

portable technology that can be virtually used everywhere, forcing designers to consider a

broad number of environments.

As we can see in Figure 1, the adaptation works like a mask that aids in the interaction with the

system. This architecture shifts the responsibility of adapting from the user to the system. This

adaptation can be done in four different ways: static where the adaptation made by the

developer cannot be changed; adaptable where users control the changes that happen on the

interface; adaptive where the system changes the interface in an attempt to find a best fit to the

user; and finally a mixed interface where both the system and the user can change the interface.

In the latter case, the system suggests some changes to be done but the user can also change the

interface, it is then a mixture of the adaptable and the adaptive. These four groups of interfaces

will be discussed later in section II.4.

Introction

8

Figure 1 - (a) Ideal system interaction. (B) The user does not fit the

Introction

9

Rehabilitation Engineering II.2.2.

Rehabilitation engineering is the process of designing, developing, adapting, testing,

evaluating, applying, and distributing technological solutions to problems faced by individuals

with disabilities [9]. The areas addressed through rehabilitation engineering include mobility,

communications, hearing, vision, and cognition, and activities associated with employment,

independent living, education, and integration into the community [10].

As in the case of assistive technology, the objective of this approach is to improve the quality of

live for people with disabilities. Rehabilitation engineering is an engineering approach, and as

Introction

10

such quantifies, measures and tracks human performance in an attempt to provide the most

appropriated adaptation [5]. Rehabilitation engineering was created in part as a solution to the

trial and error approaches of many assistive technology practitioners [11].

Adaptations in rehabilitation engineering are often custom add-on devices or machines, giving

rehabilitation engineering a lot in common with assistive technology [5].

Universal design/ Design for all II.2.3.

Universal design aggregates a wide group of ideas that has the objective of producing

buildings, products and environments that are accessible and usable by both people with

disabilities and people without disabilities. Universal design was proposed by the architect

Ronald L. Mace to describe the concept of designing all products and the environment they are

built in to be aesthetic and usable to the greatest extent possible by everyone, regardless of their

age, ability, or status in life [12].This was also been focus by the European union as a priority

with them developing several projects [2], [13] This architectural approach was generalized [14],

mainly as an attempt to address the same limitations as assistive technologies and rehabilitation

engineering [15].

Although originally the main concerns were the physical aspects such as buildings and stairs,

the principles can be applied to many areas of design. This method is seen as a “one size fits all”

methodology, which may be valid for stairs, door handles and other physical objects is more

difficult to adapt to computer interfaces because it deals with complex motor, sensory, cognitive

and affective faculties of the user [5]. This method aims at guaranteeing that environments,

products, services and interfaces work for people of all ages and abilities under various

circumstances [16]. Design for all embraces the idea that is perfectly possible to design for all

potential users and that it should be easy to adapt according to different needs. According to

the European commission “The Design for All concept encourages manufacturers and service

providers to produce new technologies for everyone: technologies that are suitable for the

elderly and people with disabilities, as much as the teenage techno wizard” [13].

Design for all has become an important issue due to the aging of the population age and the

increasing multi-ethnic composition of our societies [17]. Some examples of designing for all

that where presented in the book “Diseños para Todos/Designs for All” [18]with the support of

Spain's Ministry of Education, Social Affairs and Sports (IMSERSO) and CEAPAT

[19].Automatic door , low-floor bus and audio books are some of the examples of the

application of this design for all. In conclusion design for all/universal design, focus on ways to

create a world accessible to everyone without the need of future customizations.

Introction

11

Transgenerational design II.2.4.

Transgenerational design is the process of making products and environments compatible with

physical and sensory impairments associated with human aging, which limit major activities of

daily living. Transgenerational design aims at making aging more comfortable, it softens the

effect of the aging process, extends independent living, and increases the quality of life for all

the young, the old, the able and the disabled[20]. This method proposes that in the production

phase of software, the test group should have people from all age groups in an attempt to make

the application available for a wide range of ages without any future modification.

This concept focuses on the age and not on the impairments of the user, although people with

the same age do not necessarily share the same impairments [21]. The general principle of

trying to assess age related problems during the development phase is valid as it is easier to

change the design if it does not fit a determined group of users that we are addressing than

fixing the application after it has been released. Thus, by making the changes during the

developments phase we make sure that the product will adapt to the user and not the other

way around. Transgenerational design is base in seven principles: safety – making all products

free from danger, injury or damage under reasonable conditions by all expected users; comfort

– provide physical and sensory comfort to the user; convenience; convenience – creating

products that are convenient, handy and appropriate use for all; ease of use – it should be

simple and uncomplicated for all expected users; ergonomic fit – physical fit and

accommodation for all expected users; suitable – appropriate size, appearance a functionalities;

1. SAFETY Design must provide the users freedom from danger, injury, or damage under reasonable conditions by all who may be expected to handle, use them.

2. COMFORT Design must be free from disturbing, painful, or stigmatizing forms or features.

3. CONVENIENCE Design must provide a convenient, handy, and appropriate use for all who would use them.

4. EASE OF USE Design must be simple, uncomplicated, and easy to use. Designs should offer readable and understandable instructions and directions.

5. ERGONOMIC FIT Design must accommodate the physical fit and sensory accommodation for the

widest possible range of appropriate human dimensions.

6. SUITABILITY Design must take in consideration the appropriate size, function, appearance, adjustability, accommodation, and symbolism suitable for the widest spectrum of anticipated users.

7. USER VALUE Design has to be useful with user-sensitive value-added perceptions, components, and features. User value satisfies consumers' desire by translating expectations into positive reactions

Introction

12

user vale – provide value for our users [22]. These are the basis of this design method, in which

the focus is to understand and neutralize the discriminating effects related to aging, and also

the impairments as sensory and physical. All this is done with the object of creating a product

without penalty to any of the users groups.

Table 1 - The transgenerational design principles in order to provide a better product to everybody - Adapted from [22]

User pyramid design II.2.5.

The pyramid design was proposed by Benktzon in 1993 as a graphic illustration that divided

the population into three broad and unequal groups (Figure 2). At the base of Benktzon’s

pyramid we find the larger group with the able-bodied people, the middle group comprises

people with reduced capabilities, and at the top people with severe impairments, including

people with very limited strength and mobility in their hands [23]. The principal idea of this

design strategy is that if we create software that can be used by the users at the top of the

pyramid, the users bellow will also be able to use. The main limitation here is that some designs

for impaired people may be sub-optimal for non-impaired users. When building a product

based on the pyramid concept, both a top-down and bottom-up approaches can be used. A

bottom-up approach takes a mainstream product and pushes the boundaries of the design

aiming at including as many users as possible. This kind of design is created for able-bodies

users and tries to make it more inclusive in an attempt to enlarge the target group of the

application [24].

Introction

13

Figure 2 - The pyramid design method.- Adapted from [25].

As for the top-down approach, because generally an application build for severely disabled

people can be used by able-bodied users, the objective of this approach is aim at making the

interaction as much user friendly as possible for capable users [26]. In conclusion, this approach

has the caveat that an application made for the top group will probably result problematic for

the individuals on the bottom layer. Because the user interface is a key element on computer

systems, some caution needs to be taken to ensure a comfortable and appropriate interaction

with every user.

Inclusive design II.2.6.

Inclusive design was proposed in 2000 by Simeon Keates et al , and is an approach to the

creation of products and environments to be usable by the largest target population, regardless

of their age, abilities or situation in which they are used [27]. This method took the pyramid

design idea and push it forward by creating an inclusive design cube, where each axis of the

cube represent users capability and the enclosed volumes shows the population coverage

(Figure 3). The user pyramid approach as seen before split the users in three groups, severely

impaired, moderately impaired and unimpaired. The Inclusive design cube extends this concept

with tree design approaches, where each of the cube dimensions represents one skill and its

level. The X axis represents the cognitive capability, the Y axis represents the sensory capability

and finally the Z axis represents the motion capability. It shares the same working principle

with the pyramid design, if you design a product for the less capable, people with more

capabilities will be also able to use it.

Introction

14

Figure 3 - The inclusive design cube. Adapted from [27].

The development process of inclusive design consists of five stages. All these stages of the

development process of inclusive design have the focus on the users and their needs, what is

one of the main concerns of adaptive systems [21]. The first stage of inclusive design relates to

the user needs [28]. In this stage we have to define the requirements of our system, for which

we need to take into account two aspects: first the product objective, and second the potential

users.

The second stage addresses user perception, in an attempt to understand how the information

will reach the user. Outputs to the user usually take one of three forms: visual symbolic

feedback, visual textual feedback and audio feedback. Visual symbolic feedback is often very

easy to understand - an image is worth a thousand words - but is difficult to reach users with

poor vision capabilities. Visual textual feedback is not as immediate as symbolic feedback, and

requires cognitive ability to read. Last, a main limitation of audio feedback is the sound

intensity, which limits its use in quiet spaces and in noisy or multiuser environments. The secret

to success is balancing the output of the system among the three modalities.

The third stage aims at assessing user cognitive abilities, in an attempt to understand if the

users understand what is going on and if the behaviour of the system is matching the user’s

expectations.

The fourth stage is about the user’s motor function and how the physical interaction will be. For

instance, touch-screens are easy to learn but hard to use if not positioned at the right height.

Further, height is important because it can exclude kids, short persons, or people on wheelchair.

Introction

15

The fifth stage is the final usability stage where we have to evaluate the overall system usability

and accessibility. After this stage the system goes into re-designs taking into account all the data

gathered from the previous stages.

Ability-based design II.2.7.

Ability-based design was proposed in 2010 as a new approach to developing for everyone [5].

The question that this method tries to answer is “what can a person do?” instead of “what

disabilities does one have?”. The main idea behind it is to focus the development on the abilities

of the target group and design to take advantage of what the users’ condition still allows them

to do. Ability-based design consists of seven principles, split into three groups (Figure 4).

Figure 4 - Ability-based design principles. Adapted from [5].

The first two principles (1-2) relate to the designer’s group, and are the ability and accountability

principles. The ability principle states that development process show focus the user’s abilities

and not his dis-abilities, focusing on what all users can do, as for the accountability principle

that relates all the user performance issues to the designer and not to the users. These two

principles are classified as required for any ability-based design and constitute an essential

change from disability to ability design.

The next two principles (3-4) are adaptation that consist in transforming the interface self-

adaptive or user-adaptive in to provide the best possible match to the user abilities with the

objective of removing the need for external assistive systems and forces the system

accommodate user needs and not the opposite., and transparency which specify that the

Introction

16

interface should give the user awareness of the adaptations and everything that can be done

with them. These two principles are related to the interface and they are classified as

recommended in all ability-based system.

The last three (5-7) principles concern the ability-based systems in general, and this principles

are: performance and context (5-6) which are both recommended and the last one (7) is

commodity which is encouraged to be used. The performance principle recommends that the

system should regard user’s performance and monitor, measure and predict that performance.

As for context principle it states that the system should be proactive and sense the context and

anticipate its effects on user’s abilities. The last principle it commodity and it is encouraged in

an attempted to remove the barriers cause by price/cost, complexity and maintenance. Through

the usage of commodity it is possible to distribute ability-based systems via web without the

challenge of manufacturing or distributing specialized hardware. In conclusion, for a design to

be considered ability-based it must have the first two principles of ability and accountability, as

for the rest of the principles if they are correctly applied it can significantly improve the design

usability and accessibility.

Conclusion II.2.8.

In this section we have described a set of design approaches. Some of them are being applied by

governments in an attempt to improve the quality of live for people with needs to the modern

society. Some of the methods originate from other disciplines aiming at physical accessibility,

but they can be generalized to software design. All of the presented approaches share the goal

of creating an environment that is accessible by everyone. Although the approach they take to

solve the problem is different, they share a common goal.

II.3. ARCHITECTURE DESIGN

A crucial step in designing any kind of application is to choose the most appropriated

architecture. We have studied two architectural approaches that can be used to build an

adaptive system. The first model is to build the program under the original application (Figure

5(a)). With this model the adaptation will interact directly with the application and change the

original source code, making the enhance merge with the application. For this we need to

ensure that the communication between the original application and the operative system is

successfully made through the adaptation that was built. Another was to merge the adaptation

Introction

17

with the program is through the operation system, providing an infrastructure for the assistive

technology to communicate out of process to other application, what requires trustworthy

access to the operative system functionalities. Also these way users have a feeling of interacting

with the application and with the adaptation, which is good due to the important of notifying

the status to the users. The second option is to build an adaptation that is going to work over

the original application like a mask that will change the user interface without having to take in

account the communication with the operative system since it only work as a mask that changes

the interface without change the functionalities or the original source. Both this approaches

gives support on how should we project a user interface adaptation software, but it is important

to remind that this should only be used to improve de usability in existing software, because

when building new software this should be already taken in account right from the beginning.

As a result of this analysis the proposed adaptation-based system seems to be appropriate for

adaptive solution, since we don’t need to change the source of the base application there is no

policy violation problem with the creator company in case of the adaptation being an outside

job.

Introction

18

Figure 5 - Adaption based system proposals. Adapted from [29]

rever

II.4. TYPES OF USER INTERFACES

The interface can be defined as where the interaction between humans and machines occurs,

and therefore it is the key element of any interactive application. Skipping over interface design

methods can result in interfaces that are confusing and hard to use. In this project we want to

adapt a computer program to be usable at the same time user-friendly for our target population.

For this we need to study what kind of interfaces can be build and what benefits would each of

them bring to our users [30]. The first and most common type of user interface is the Static User

Interface. This type of interface is present in almost all programs we use on a daily basis. This

Introction

19

type of interface, as the name suggests, does no change over time and remains as the designer

created it. Another type of interface is the Adaptable User Interface. In this case users can

customize the interface as they want in an attempt to accommodate the user needs and leave’s

them more comfortable with the interface, allowing the user to take the most out of the

application. The third type is the Adaptive User Interface. In this case the computer stores user

action patterns and automatically changes the interface in an attempt to improve the

performance of the user. In essence, this approach adapts the layout and elements to the needs

of the user or to the context. The last type of interface is the Mixed User Interface, where the

adaptive and the adaptable interfaces are combined onto a single one. This type of interface

shares the control of the adaptation on the application with both the computer system and the

user, letting the user decide if he wants to adopt the changes that system proposes or if it is

more desirable to ignore them.

Figure 6 shows an example of a static menu (a) and an adaptable menu (b). It can be observed in

(b) that instead of having a group on the top of the menu created by the designer, the user can

chose the more frequently used options and place them manually at the top. This approach

gives the user more power over the application [29].

The experiment realized by Leah Findlater et al [30] studied the comparison between static,

adaptable and adaptive user interfaces. The goal of the experiment was to compare the

efficiencies of the different types of menus. For each type of interface, a split menu was

implemented (Figure 6). For the static interface, it consisted of a classic split menu where the

items on the top partition where the ones that occurred more frequently during the

experimental task. For the adaptive one, there was an algorithm that computed the most

frequently used options and moved them to the top. For the adaptable one, the goal was to

create a simple user customization process. The experiment was realized by 27 persons, users

where split between three different test paths: Static – Adaptive – Adaptable; Adaptive –

Adaptable – Static; and Adaptable – Static – Adaptive. Every participant was confronted with

the three types of menus and the time they took to perform the required tasks was recorded and

is showed in the Figure 7.

Introction

20

Figure 6 - Two aprotches to dropdow menus: (a) static

split menu, (b) adaptable split menu. Adapted from

[30]

Figure 7 - Boxplot of menu types versus speed, from Findlater et al. experiment (N=27). Adapted from [30]

From the box plot in Figure 7 we can see that static and the adaptable had the same time

response median, but with a smaller dispersion of data in the static case. The adaptive revealed

to be slower than the adaptable one. This was not the case if users had used the adaptable

interface first [30]. Interestingly, four out of the five users that did not customize anything

experienced the adaptable menu first, suggesting that users did not understand the

customization process [30]. On the other hand, users that started with the static or adaptive

interface moved the more frequently used option to the top when confronted with the

adaptable menu. Overall, users preferred the adaptable over the static menu, but generally not

the adaptive one. Consequently, we see that even taking more time to do the tasks, users feel

Introction

21

more comfortable when they control the menus and customize them. This led to better

perceived performance and higher overall satisfaction.

Another study that was conducted by Debevc et al. compare an Adaptive bar that allowed users

to customize the interface and also would suggest changes to the users in order to improve the

usage of the application, with the original built-in toolbar customization facility present in

MSword at the study Debevc et al. compare their Adaptive bar to the built-in toolbar

customization facility present in MSword at the study. The tool bar presented by them was

classified as mixed interface because it allowed the user to change as they want and on the other

hand would suggest the changes to the users. They stated that mixed interfaces give the user a

notion of what they can gain through adaptation through the suggestions given by the system,

and also by giving the final decisions to the user it increases the overall satisfaction as in

adaptable [31].

Paper Interface: Static Interface: Adaptable

Interface: Adaptive

Interface: Mixed

The experiments conducted in MsWord. Users where tested in the different interfaces with the objective of comparing the three approaches (static, adaptable, adaptive) [30]

Was the faster, but the difference was not significant.

Faster that adaptive, except for people that start with this type of menu.

Was the slowest, except for people that used the adaptable first.

*

Users preferred this menu over the others Four out of the five users that did not customize the application started with it.

The experiment was conducted on MsWord. First with an adaptable version for four weeks and then switched for the adaptive type for two weeks. [32]

20% of the participants of the two week experiment like better the original version of MsWord.

65% preferred the new adaptable version.

15% did prefer the adaptive version given later called Smart Menus.

*

Greenberg et al. compared an adaptive versus an static strategy for hierarchical menu organization in a telephone directory system [33]

Only 31% preferred the static.

* Was significantly faster.

*

Fewer errors. 69% preferred the

Introction

22

adaptive. A simple interface where the most the items position would change according to the frequency of use [34]

81% of the users preferred the static.

* Was slower. *

Debevc et al. compare their adaptive bar to the built-in toolbar customization facilities present in Msword [35]

Was slower. * * Significantly improved the performance.

* Not considered in the experime

Table 2 - – Summary of the study analysed on the four types of interfaces and their result.

After analysing these experiments we find inconsistent results for the same types of menus.

This effect seems to be related to the nature of the application in cause. One hypothesis that

came out of these studies is that in more complex applications users tend to be more

comfortable with adaptive systems because they save time sorting the more frequently used

actions. However, when it comes to small lists of options, users feel confused by the changes

and can take more time performing the task. As for the mixed interface, it shows promise but

there is little research done on them and there is still need to do further research on this type of

interfaces.

II.5. TYPES OF USERS

A very important step in the development of any assistive application is to create study and

understand the group of users that our program will target. Therefore, we need to determine

the group of people we are addressing with our application so that we can design the

technology according to their needs. In this application domain, we can divide users in 3

groups: elderly people (usually taken as impaired users because they lose skill as they get older)

[29]; low vision users; and dexterity impaired users. The two last groups are presented

compared to each other to show their differences.

Elderly users II.5.1.

Elderly users usually lack confidence when confronted with technology because they feel that

they are too old for the new developments [29]. Further, complex and multi-functional systems

may present substantial cognitive challenges for elderly, on top of lack of confidence. When

Introction

23

developing for elderly we need to support their confidence. For instance, one of the things that

elderly users do not like is undesired changes that result in confusion. To solve this problem we

should try a three step approach [29]. First we should let them know that there is a solution for

the problem they are facing, creating awareness for the issue and it is not their problem. Then

we should explain the existing solution, and finally present the solution to them. This approach

helps in the sense that the change is not so aggressive, and they can understand what has

changed and why. Also, according to the study made by Sloan et al. [29] elderly users tend to

like less disruptive accessibility technologies that does not change the interface completely.

Elderly users are generally classified as a group and they are compared to impaired users

because of the loss of motor and visual capabilities due to the ageing process. In the table (Table

3) below we can see three subtypes of elder users according to Peter et al. [36], where they

groups elderly users in three groups: fit older people that have less impairments and less need

for assistive technologies, frail older people which have one or more disabilities and great skill

reduction in comparison with the fit group, and finally disabled people who grow older and

with the aging the long term disabilities deteriorated and are the group that need assistive

technologies for most of their task.

Table 3 – Comparison table between different types of elderly users

Another study about elderly people and their problem while interaction with the web was

conducted by Kurniawan et al. [37] and they approach the by dividing the issues in three big

groups: vision impairments, dexterity impairments and cognitive impairments. The results they

got are summered in Table 4.

Area of impairments Type of the problem Problem

Vision impairments Use of graphics 1. Icons should be simple and meaningful

Fit Older people Frail older people Disabled People who grow older Do not appear disabled Has one or more disabilities The long term disabilities affected

the ageing process and created more disabilities

Still need some assistance on doing some tasks due to age

Often disabilities are severe The disabilities are severe

Great reduction of skills in comparison with fit older people

reduction of skills

Need a lot of assistance on performing task

Requires assistance on almost every task performed

Introction

24

Target design 2. Providing larger targets

3. Clear confirmation of target capture

Navigation 4. Provide location of the current page

Content layout 5. Avoid irrelevant information on the screen

6. Important information should be highlighted

Text design 7. Avoid moving text

Dexterity impairments Target design 8. Providing larger targets

9. Do not expect double clicks

Browsers windows features 10. Avoid scroll bars

Cognitive impairments Use of graphics 11. Graphics should be relevant,

not for decoration

Navigation 12. Clear navigation should be provided

Browsers windows features 13. Avoid pop-ups and animated advertisement

Introction

25

Cognitive design 14. Reduce the demand on working memory

Table 4 – Elderly issues while navigating the web associated with the type of impairment it is related.

Low vision users vs. dexterity impaired users II.5.1.

For low vision users the main challenge is related with the display, while the problem for motor

impaired users is in the physical interaction. In the case of low vision users, aspects such as

display size, lighting, and distance from the screen need to be addressed in order to allow for a

more comfortable use of a system. Instead, for motor impaired users not only the application

need to be adapted, but also the interaction with the system needs to be taken into account.

More concretely, the peripherals represent a key disabling aspect in the interaction [4]. If we

move away from the peripherals and focus only on the application, we need to adapt elements

such as tabs, multiple windows, the mouse double click. Low motor impaired users will not be

able to keep the mouse pointer still for the two clicks, or may not do it fast enough.

An example of the mentioned adaptations was presented by Gajos et al [38]. In Figure 8 we can

see the adaptations made in Supple++ to accommodate each type of user. For low vision users

the main change was the size of the objects and text. Instead, when addressing users with

impaired dexterity the main concern was the distance from the each available option so that

pointing and clicks would be less problematic for them. For this reason it is important to

understand what can we compacted in order to make objects bigger without making the

application not user friendly.

Introction

26

Figure 8 - Example of GUI interface that was automatically generated using Supple++. A) Typical interface, b) interface for a mouse users with impaired dexterity, c) adaptation for low vision user, and d) for users with both low vision and impaired dexterity. Adapted from [38]

To conclude, related work shows that there is a lot of research done in this area over the past

years, and that governments are getting more interested in accessibility and inclusive design

methods in an attempt to provide a barrier free society. However, more work needs to be done

in this field to make informatics systems able to usable by everyone. It is important to note that

elderly users are an important segment, and studies conducted by the European Union [17]

predicts that the percentage of elderly people become a major group in our society in the next

twenty year. Therefore it is important to accommodate technologies to their needs.

Introction

27

III. ADAPTNOW – EXPERIMENTS AND ARTIFICIAL INTELLIGENT SYSTEM

AdaptNow web base enhancement application for elderly and was designed throw an

interactive process with several experiments with users. The first interaction with users was

designed to understand how people would react to what we proposed and what they would do

with the given tools. Also we wanted to analyse if there was any relation between webpage

characteristics and user adaptations.

III.1. WEB ENHANCEMENTS AND ARTIFICIAL INTELLIGENCE (AI) MODELLING

In order to fully understand what elderly users would do with a toll like we proposed and how

would they react and use it we conducted an experiment that would help us better understand

our target group and what the issues that they really had.

Method III.1.1.

For the study (anexo X) we allowed users to modify several features of web pages, such as 1)

highlighting (box/underline) clickable objects with user defined colours; change the mouse

pointer 2) size and 3) visual aspect; modify 4) zoom as well 5) font sizes; and 6) page scrolling

mode. The highlighting features would mark all clickable links with a specific colour and

thickness controlled by the users as they fell. With this feature we wanted to understand if it

would create more awareness for what is around and what they can interact with.

Introction

28

The second and third features was the mouse size and colour, this was done with a set of

custom make mouse pointers that we created in three different size and that would change

colour if hover a clickable area. We asked users for every webpage what mouse pointer they

would use and what size would be more suitable, we tested three different sizes and nine

different models. This was tested, since one of the problems detected was the fact that elderly

users would lose sight of the mouse pointer and by making it bigger we want to provide an

easier navigation.

The last feature test was tested was the automatic scroll that would allow user to scroll the page

depending the position of the mouse, this could be done in two different way, one being only if

the mouse moves on the top or bottom of the page and the other every time the mouse in o

certain position. With this we wanted to remove another of the issues related to mouse control.

This study was performed with 12 users between 51 and 63 year old and was conducted in 10

webpages from 5 different types (social, news, travel, mail and search engines), and in each

webpage we conducted the experiment two times if different resolutions. Due to the fact that

users had to enhance each webpage two times each users only experimented 5 distinct

webpages.

During the interview process we asked users how would they change the webpage, using a set

o given tools, how would they change the webpage in order to improve the comprehension and

effectiveness of the interaction with the given webpage. This process was repeated for all the

experiments webpage. With this type of approach we gave the users the system full control and

made them aware that all the changes should be undone and that they could change who they

fell would make them more comfortable. One of the aspects that we focuses was if the user

could read well the text on the webpage or if increasing the text font or applying zoom would

help in this situation. After finished the adaptation, the system would save the configuration as

well the webpage characteristics (website dimensions; number of images, buttons, heading tags,

divisions, scripts, and links; flash content; image sizes; and screen resolution).

Having in consideration all the data collect we realizes a multivariable linear modelling

approach, using step-wise regression to create a model of user’s preferences based on the web

page characteristics. Another mathematical model realized was a principle component analyses

with the intent of identifying possible behaviour groups and what would be the impact of that

in the analyses.

Introction

29

Results III.1.2.

The first experiment, as explained before, allowed us to define the core AI that models each web

enhancement (zoom factor, font size, mouse cursor, etc.) as a multivariate linear regression of

the variables that define the web page characteristics (resolution, page height, number of words,

etc.). Interestingly, our modelling approach allows us to identify and quantify to what extent

web site features do determine the enhancement choices made by elderly (Table 5).

Propriety P-VAL Model signify-cance.

a) b) c) d) e) f) g) h) i)

Zoom (0-100) 2,61E-10 *** 0,0001 - - - 0,0088 - 0,0005 0,0237 -

Text Size (0-100) 3,06E-18 *** - 0,0001 0,0008 - - - 0,0001 - 0,0001

Link Enhances

Box (0-1)

0,4264 - - - - - - - - - -

Underline (0-1)

0,4264 - - - - - - - - - -

Colour 0,1851 - - - - - - - 0,0108 - -

Border Size (0-100)

0,0034 ** - 0,0001 - - - - - - 0,0001

Button

Enhanced (0-1)

3,60E-173 *** - - - - - - - - -

Colour 0,0356 * - - - - - 0,0003 - - -

Border Size (0-100)

1,38E-09 *** - - - 0,0003 - - - - -

Table 5 - Webpage characteristics and their corresponding significance in the web enhancement AI model. The used web page characteristics are a) Screen Width, b) Page Height, c) Number of words, d) Biggest image Width, e) Average image width, f) Number of scripts, g) Number of H1 tags, h) Number of H2 tags, i) number of divisions. * p<0.05, ** p<0.01, and *** p<0.001.

From the model built we were able identify a set of features that we could not model due to

their nature, this features where the underline and box due to the fact that they had binary

result and that when users did not choose one the other was chosen, and also because users

tended to keep their choice of underline of box during all the experiment webpage. With this

information we can conclude that box and underline is a user’s specific characteristics and that

should be treated as such. Another of the features that we were not able to model was button

enhance because it was also an binary option and due to the fact that 100% of the participant

activated this option we could only conclude that the button enhance should be active as

default.

The last feature that we could not model was the colour of the link and button enhance, even

though the model was given significant on the calculations we still could not model colours,

this happen because the values are completely district and we cannot compare red with blue.

But we could observe that approximately 91% of the users tend to keep the same colour during

the experiment, and with this in mind we can consider this also as a user’s characteristic.

Introction

30

Finally we got the 4 models that where significant, zoom, text size, link border and button

border, and with them we calculated throw a step wise regression the weight of the webpages

characteristics on each (Table 6). We got for each model an AI algorithm that based on the

webpage characteristics would apply a certain value. Starting with the zoom, we got that the

zoom value would be equal to “0,0347 X Screen Width + 0,0209 X Average image width + 0,9153

* Number of H1 – 0,1047 * Number of H2”. With this formula we could calculate desired the

amount of zoom in any webpage with an error of 5,57% and considering that the zoom value

varies from 0% to 100% and that the minimum increment value is 10%.

Another significant model was the text size were the amount of increment on the font was

calculate from “0,0079 * page height - 0,0128 * number of words - 0,04 * number of H1 - 0,04 *

number of divisions”, this model had an error of 6,6% and with the value variation from 0% to

100% with a minimum amount of 10%.

As for the link border we got that the value was gotten from “0,0038 * page height - 0,0269 *

number of divisions”, this value had a 7,9% error with the border size going from 0% to 100%

and with the minimum increment value being 10% which again is bigger.

The last enhancement that we were able to model was border size and its calculation was only

relate to the biggest image with the value being “-5,533 * biggest image”, and again in contrast

with the other value we had the border amount ranging from 0% to 100% with an error of 5,6%.

All this calculation is going to be used in our AI enhancement that will enhance any webpage

based on its characteristics. And for the features that we were no able to fully model we will

used them as a user specific and associate them with the users account due to the nature of the

data and the tendencies of the users during the experiment.

Propriety Mean

Error (Un) a) b) c) d) e) f) g) h) i)

Zoom (0-100) 5,5739 0,0347 - - - 0,0209 - 0,9153 -0,1047 -

Text Size (0-100) 6,6132 - 0,0079 -0,0128 - - - -0,04 - -0,04

Link Enhances

Box 0,4207 - - - - - - - - -

(0-1)

Underline 0,4207 - - - - - - - - -

(0-1)

Colour 0,7008 - - - - - - 0,0724 - -

Border Size 7,8799 - 0,0038 - - - - - - -0,0269

(0-100)

Button Enhanced 0,0023 0,0004 -0,0002 - - -0,0765 -0,0031 -0,0765 -0,0124 0,0006

Introction

31

(0-1)

Colour 0,5833 - - - - - 0,0247 - - -

Border Size 5,5729 - - - -5,533 - - - - -

(0-100)

Table 6 - The weight and error of each of the feature model in relation to the webpage characteristic. The used web page characteristics are a) Screen Width, b) Page Height, c) Number of words, d) Biggest image Width, e) Average image width, f) Number of scripts, g) Number of H1 tags, h) Number of H2 tags, i) number of divisions.

From the principle component analyses that we conducted (Figure 9) we were able to identify

user’s tendency and understand if there were relationship between featured and in case they

exist which are. With this analyses we were able to identify a clear relation between zoom and

text size which show that adding zoom reduces the amount of text size increment and vice

versa, which also indicates that we have two distinct groups of users, being that one focus more

on zoom and another on text size. This shows that creating personal models for each users after

they used the application a certain amount of time would be the most appropriate way since we

can’t identify which type of users we are dealing with. Also we were able to confirm the clear

relationship between link box and underline with their result being completely opposite.

Figure 9 – Principle component analyses of the date with the objective of finding relations between the features.

The last featured option was the scroll we got that in average users classified the scroll only

when the mouse is moving with 4 out of 5 for improving the navigation, while the scroll on

Introction

32

fixed position only got 3 out of 5. From the interviews and the user’s reaction we understood

that the scroll on movements gave them more control and due to that was considered as better

and given preference due to that. Also one of the inquired suggested that the application should

support side scroll. Having in consideration this we fell that the scroll system gives more

control to users that lack motor coordination and cannot control with precision the original

scroll.

In relation to the mouse enhance where we proposed three different sizes (Figure 10) an several

models, we got hat all users went with the medium size, also everyone chose the same model

during the experiment, and taking in account that it was asked on every webpage if they

wanted to change they model we can say that the mouse model used it is not related to the

webpage but to an user preference. With this in consideration we decided that the mouse model

propriety should be a related to the account and that we should remove this customization from

the main view of our interface. As for the less liked features we got that 83% classified the font

family as the less important feature followed by the border thinness with 67% and the button

marking with 58%. From here we can say that the font family had no effect on the users and that

and due to that should be reconsidered as a feature, and as for the mouse enhance is the priority

feature and the one most users classified as a must have.

Figure 10 – Example of mouse model used during the experiment where we can see the different sizes used. a) normal mouse appearance; b) mouse appearance

when hover a clickable area

Introction

33

In the end of our experiment we inquired users about the featured enhancements and asked

them to choose the three that helped them more. From here we got that 91% of the users chose

the mouse enhance as the feature that helped the more, followed by zoom with 50% and finally

the scroll on movement and the colour options with both having 42%. Also we inquired users

about the utility of such a toll on a daily basis we got a 4 out of 5 which we considered an

indication that such a toll would improve the navigation experience for elderly users.

III.2. ENHANCED HISTORIC AND BOOKMARK VIEW

After the analyses of the navigation, we concluded that other aspect could also be enhanced and

improved for a better an easier web experience. With that in mind we hypothesized a revamped

view for the historic and an addition of dynamic bookmark view. With that new hypothesis we

decided to conduct a new survey that would help us understand this issue and build a

validated new system.

Methods III.2.1.

This second survey conducted had the objective of understanding the most relevant

information while navigating, and how should it be displayed. With that in mind we wanted to

create a revamped historic view and a dynamic bookmark navigation, and for that we

conducted a new experiment where we interviewed 17 people of two age groups (>40 (A) and

<40 (B) years old). The average age from was 47.8 and 22.6 years old for A and B respectively.

The reason that made us interview also a younger group (B) was the fact that they have more

web experience. Information provided by B could bring in interesting insights and can acts as a

control group for A.

We asked users about what information they value more in a historic view (time spent on a web

page, number of visits, type of content), how to highlight pages they visit the most (icon size,

colour, contrast, total visits counter), and how to present the information (all pages at once,

showing the order of navigation, grouping pages of the same domain). Another aspect that we

focuses was how should the information be displayed, and so we asked users to create their

own icon displayed with the information that they felt relevant and on the position they

considered more relevant. With this in mind we wanted to build a model of the appropriate

icon that we should display either on the historic view or on the bookmarks view. Due to

Introction

34

number of participants on the experiments the presented data was obtained throw the

calculation of the mean value.

Results III.2.2.

In relation to the performed survey we got an interesting insight to what users would react

better and what was really important for them while navigating the web. The following results

are splitted by each question asked, the obtained result and graphic that sums up the results.

Question: “Number of hour using the computer per week”, with possible answers 1 to 3 hours,

3 to 7 hours and +7 hours, from where we obtained ( Figure 11) >40 group uses the computer

between 1 and 7 hour per week, while the <40 group is situated almost on 7+ hour per week.

This shows that the <40 group is and experienced group, and also that the older group has a

certain level of experience, which may help us improve the accuracy of the result due to the

existence of web experience.

Figure 11 - Number of hour using the computer per week

Question: “Which features would be more important to add shortcut to a webpage on the

screen?” Figure 12, the featured options where: time spent on the webpage, number of times the

webpage was visited, and type of contend. This feature where all asked to classify from 1, very

low importance, to 5, very important. From this question we wanted to analyze what would it

be more import to add bookmarks, from where we got that according to >40 group the most

important is the number of visits, classified between average importance and important, while

the other two features where classified between low and very low importance. As for the <40

group both option, time on the page and number of visit, where classified as important while

the page content was classified has of average importance.

Introction

35

Figure 12 – Features importance for adding a shortcut (bookmark) to the webpage from each group of inquired.

Question: “Which features would you use to differentiate the most visited webpages?” (Figure

13), the featured options where: icon size, color of webpage name, showing the number of visits

to the webpage, webpage icon background, and color contrast. This feature where all asked to

classify from 1, very little importance, to 5, very important. Here we got similar results on both

groups for some of the options, icon size and the color of webpage name where classified by

both as of average importance. As for Icon background as contrast the >40 groups classified it

as of average importance while <40 classified it between low and average importance. In

relation of number of visits >40 group classified it between low and average importance while

<40 puts it between average and important.

Introction

36

Figure 13 – Features used to differentiate the most visited webpages for each inquired group

Question: “Which features would you use to differentiate the webpages where you spend more

time?” (Figure 14), the featured options where: icon size, color of webpage name, display the

number of visits to the webpage, webpage icon background, and color contrast. This feature

where all asked to classify from 1, very little importance, to 5, very important. In this features

both groups where in sync in most of the features, with classifying icon size, name color and

number of visits as of average importance. As for icon background and contras >40 group

classified It also of average importance while <40 gave it lo importance.

Figure 14 - Features used to differentiate the webpage where the most time was spent according to each inquired group

Introction

37

Question: “On a search through the webpage historic, what would make it easier to find the

desired page?” (Figure 15), the featured options where group all pages of the same domain,

showing all pages at once, showing the pathway of pages visited webpages. This feature where

all asked to classify from 1, very little importance, to 5, very important. Here we want to

understand what would help during a search throw the navigation history so we could

compare to the actual model presented in the actual browsers. With this in mind we can see that

the actual model was classified by both groups as of low importance, while grouping all pages

of the same doing was classified as important. Also the other featured option, showing

pathways has average importance to the users.

Figure 15 – How should the historic be displayed to facilitate the search.

Question: “How much would it help having an application giving audio feedback?” (Figure 16).

This feature was asked to classify from 1, very little importance, to 5, very important. With this

we wanted to understand how users would feel by having voice feedback of their action while

navigating on the web. Here we got some expected results, with >40 classifying this as of

average importance and, in the other hand, the most experienced group, <40, gave it low

importance.

Introction

38

Figure 16 – Inquired answer to if audio feedback would improve navigation.

Question: “What type of information should be communicated by voice” (Figure 17) we asked

users to select what would help them more, the available option where confirmation of insert

data, notification of webpage state, suggest possible option for next action, and explain all

available options. This question had Yes/No answers. Here we got that around 60% of the

inquired chose confirmation of inserted data as a viable feature, as for suggestions and

explaining all options both had around 25%. In relation to notifications, none of the inquired of

the >40 group selected it in the other hand around 50% of the <40 group chose it as a viable

option.

Figure 17 – What inquired classified as the most relevant information that should be transmitted through audio feedback.

Introction

39

Question: “What would be the importance of having a bar with the most visited webpages?”

This feature was asked to classify from 1, very little importance, to 5, very important. In this

question we got similar results in both groups, with both answering as important the fact of

having a bar with the most visited webpages.

Question: “What would be used to identify the most visited webpages on Figure 18 ”(Figure 19)

we asked users to select what would help them more, the available option where A – Size of the

icon, B – Color of page title, C – Having the number of visit to the webpage on screen, D – Icon

background, and E – Color contrast. This question had Yes/No answers. In relation to this

question we got similar results on both groups for all of the featured options. Being that the

options that chosen the most where icon size, with 65% and number of visits, with 58%. The

other option where given less importance, with background being chosen around 23%, title

color around 27% and contrast scoring 30%.

Figure 18 – Historic view presented to the users with the intent of them choosing which information would be displayed.

Introction

40

Figure 19 – Inquired classification which information was more relevant on this type (Figure 18) of historic view.

Question: “What would be used to identify the most visited webpages on Figure 20 ” (Figure

21) we asked users to select what would help them more, the available option where size of the

icon, color of page title, having the number of visit to the webpage on screen, icon background,

and color contrast. This question had Yes/No answers. In the above question there were some

disagreements between both groups’ answers. On the icon size feature we got similar results on

both groups, being that 47% chose it as a way to identify the most visited. In relation to the title

color feature, we got some discrepancies between the groups, even with the answer tending for

the same side the values had a considerable difference, with >40 choosing title color with 17%

and <40 group with 33%. In relation to the number of visits, >40 group had split opinions, with

50% selecting this feature, and from <40 group 78% of the inquired selected this feature. As for

the background option both groups were in agreement, with only 23% of the inquired selecting

this options. Finally for the contrast feature only 27% of the inquired chose it, while from <40

group 44% users chose it as a viable option.

Introction

41

Figure 20 - Historic tree view presented to the users with the intent of them choosing which information would be displayed.

Figure 21 - Inquired classification which information was more relevant on this type (Figure 20) of historic view.

Question: “What would be used to identify the most visited webpages on Figure 22” (Figure 23)

we asked users to select what would help them more, the available option where size of the

icon, color of page title, having the number of visit to the webpage on screen, icon background,

and color contrast. This question had Yes/No answers. In this question groups had difrente

Introction

42

opinions on most of the features. In relation to icon seize both groups had equal result, with

33% on the inquired slecting this option. In relation to title color and number of visits no one

one from >40 group selected this options leving it with 0%, on the other hand <40 group got

44% and 78% respectively. As for the background we got similar result on both groups again,

with 33% inquirid slecting this feature. Finaly the contrast got discrepant results, with 67 % of

the inquired from >40 group chosing it, and from <40 group only 44%.

Figure 22 - Historic chain view presented to the users with the intent of them choosing which information would be displayed.

Figure 23 - Inquired classification which information was more relevant on this type (Figure 22) of historic view.

Introction

43

Question: “How would you group the webpage historic?” (Figure 24) we asked users to select

the one that would make it easier to find a designated webpage, the available option where per

day, per week, per month, per day (7 days) and others per week, per day (7 days) and others

per month, per week (4 weeks) and others per month, and per day (7 days), per week (4 weeks)

and others per month. This was a single selection question. Here both groups went with

different approaches; >40 group gave more credit to option per day (7 days) and others per

week with 50%, and <40 group chose option per day (7 days), per week (4 weeks) and others

per month with 56% of the inquired options.

Figure 24 – User classification of historic, being d – per day, w – per week, d/w – last 7 days and they weekly and d/w/m - last 7 days them last 4 weeks and them per month. The graphs are split by groups

Question: “Where would you place each of the following information on the icon?” we asked

users to select where would they place a certain amount of information on the displayed icon.

The information that was asked to be displayed was: A – Number of visits to this webpage, B –

Total time spent on that page, C – Page name, D – Hour of visit, and E – Number of grouped

pages. (Figure 25, Figure 26)

From the analyses of the date of >40 group we got that some types of information had a favorite

place to be placed between the inquired. Information like page name was the only option that

was place on the center bellow the icon. On the sides of the name inquired placed on the left

hour of the visit, this being the only information that they place there, and on the right the total

amount of time spent with a 83% choice. In relation to top, inquired were split between number

of visit to the page and number of grouped pages on the center, on the left side the options

selected where the name with 60% and the number of visits with 40%. As for the right side we

got 50% for the number of visits, and 25% for number of grouped and for the total amount of

time spend on the page. In relation to the information place on the side of the icon, nothing was

D 16%

W 17%

D/W 50%

D/W/M 17%

>40

D 22%

D/M 11%

W/M 11%

D/W/M 56%

<40

Introction

44

placed on the left side, and on the right side 80% was number of grouped pages and 20% was

hour of visit.

From the analyses of the date from <40 group we got that the choice for the information place

on the bottom of the icon was: on the center 80% was for page name and 10% for number of

visit and number of grouped pages, on the left we got 100% for hour of visit, and on the right

we got 83% for total time spend on the page and 17% for number of visits. In relation to top,

inquired only place on the center total amount of time spent of the page, on the left side the

options selected where the number of visits to the page with 67% and number of grouped pages

with 33%. As for the right side we got 63% for number of grouped pages, and 37% number of

visits to the page. In relation to the information place on the side of the icon, on the left side we

got 100% for number of visits, and on the right side 40% was hour of the visit and 20% for total

time spent on that page, page name, and number of grouped pages. Also we got that 22% of the

inquired said that the number of grouped pages and the total amount of time spent on a

webpage should not be displayed, even though we did not ask that question to them.

Introction

45

Figure 25 – Information placement on the historic icon view for the >40 group

Introction

46

Figure 26 - Information placement on the historic icon view for the >40 group

47

In conclusion, we got two groups of inquired where the younger group, <40, where a more

experienced group that used more the computer but the older group had a certain amount of

experience due to the fact that they used the computer regularly. The feature that inquired

chose more importance for having a bookmark to a webpage was the number of visits, also for

the <40 group classified as more experienced the time spent on a page is also important,

therefore we will consider both time spent on the webpage and number of visits when

considering adding a certain webpage to our most visited section. In relation to how we should

differentiate the most visited pages from the less visited the data was too similar with the

features of changing the webpage name color and having the total amount of visits to that

webpage present being the ones with a slight advantage, however the differences between the

features where small and so we may include others features as icon size.

In relation to the voice system where we would give some kind of feedback to the users, the

inquired from <40 group gave it low importance and we can relate that to their experience, on

the other hand the >40 groups considered that this may give some help during navigation. As

for what should be communicated both groups agreed that be best option was the confirmation

of data.

Another of the areas that we wanted to adapt was the historic of visited pages, because we felt

that the actual system was hard to use for the users. Whit that in mind we wanted to know

what would be the easier way to find a page on the historic and the answer we obtain was

group all pages of the same domain, what is the opposite of what we had right now on the

browsers. Also having the pathway of the visited pages was given some importance. After this

e tried to understand what kind of featured could be used to differentiate the most visited

pages while navigating so we could create a viable model to be implemented. The most

consensual feature between both groups was having the total amount of visits visible on the

webpage icon. Others features where selected in different way for each of our models, on the

most visited groups icon size was considered also a good option by both groups, this may be

one of the used features, but we still are unsure due to the visual impact that this may cause to

the others users we will add an option to enable and disable icon size. On the tree view historic

we got that icon size with around 50% from both groups and also contrast with around 50 from

<40 group, as for the contrast it could also be a good solution because it is more smother than

changing the size of the icon and had similar results of icon size for the <40 group. Our final

model was the timeline view where users could see their path of the navigation, and the chosen

feature to identify the most visited was the contrast with around 55% of both groups. Also

having the number of visits had 76% between the inquired of <40 group, another thing to note

here what the fact that the icon size only had 33% of selections on both groups, although we

can’t compare this result with the ones of the previous models it is important to note this

Introction

48

difference. Another thing we wanted to know was how should we group the historic since we

wanted to compare with the actual model of the browsers, here we got different answers from

both groups but they were similar because one was a more generic visualization of the same

model, therefore we will adopt the model that was chosen by <40 group, split the first seven

days per day, the next 3 weeks per week and the rest per month, this was done because this

would group the option chosen by them >40 group, per day seven days and the rest per week,

and let us have a viable model since the only difference between the implemented model and

the chosen by the >40 will be for users that used the system for more than one month and that

want to search for pages that they have visits more than 4 weeks ago. About this theme we will

implement the three models and users can change between them as they like, also we will to

further test the visual impact of some of the features with a visual example of it.

The final question was to understand what data should be displayed and where, and after

analyzing the result from both groups can see that the hour of visit will be bottom left, the name

of the web page will be bellow de icon and that the number of visit to the webpage will be top

right of the icon. This will be the final model of the icon we will present. Although the other

options had valid results we decided not to place them on the final model due to the fact of a

substantial number of the enquired from <40 classifying it as not relevant even without we

asking.

Introction

49

IV. ADAPTNOW – IMPLEMENTATION

With the knowledge from the two studies and from the state of art we started to build a web

application that will automatically enhance any given web page based on the it’s characteristics.

This would be done based on the AI model that was proposed with the data collected from the

first study. This web application while adapting and enhancing the user’s navigation would

collect and map user’s personal adaptation and webpage characteristics in order to change and

improve the accuracy of our model with more data. Also as said before, since there where two

types of behaviour in relation to adaptation where one group would focus on zoom and the

other on text size, this will allow us to build personal models after a certain amount of time that

would serve as a better fit the end user. With this in mind we will allow admin access to the

application in order to access this information and analyses it. From here we design a series of

model that would help us better understand the normal user’s interaction with the system and

with it improve the usability. This models will present all the desired features of the system,

even if some of them are not fully implemented in the first version, we hope to release them in

future versions of AdaptNow.

IV.1. USE CASES

Following the development of AdaptNow we built the use case diagram (Figure 27) that will

help us better identify the system requirements. With this model we also want understand what

will be the event step during the interaction with AdaptNow. For this model we user three

components, actor - that are both the user and the system admin; action – that specifies the

interaction; and system – that correspond to AdaptNow.

Introction

50

Navigate to a webpage

Adaptnow User

Change zoom

Change text size

Change link border

Change button border

Activate/deactivate link enhance

Activate/deactivate button enhance

<extends><extends>

<extends>

<extends>

<extends><extends>

Change webpage

<extends>

<include>

Log in

Recover password

Create account

<extends><extends>

Enter AdaptNow <extends>

<inclu

de>

Change personal enhancements

Change link colour

Change button colour

Change mouse model

Change mouse size

<exte

nds>

<extends><extends> <e

xten

ds>

<extends>

Adaptnow Admin

Change AI model

View general adaptation data

View historic

View feeds<e

xten

ds>

System

Figure 27 – Use case diagram for the AdaptNow application.

Introction

51

IV.2. TASK MODEL

Task models provide possible interactions with the system by the users and are used to provide

a better understanding of how the system interacts with the users and what should be the

expected interaction in the given time. The first model (Figure 28) presented is relates to a

normal interaction with the application, where a user visits a desired webpage through the

AdapNow application.

Figure 28 – Frequent user’s interaction with the AdaptNow system.

Introction

52

Another of the interaction that we have is the change personal enhancements (Figure 29) where

we place the enhancements that we verified during the experiment as being users related and

not changed frequently. With that in mind we will place this controls all together and with that

remove unnecessary icons that could generate confusion.

Figure 29 – Users interaction for changing personal enhancement’s as mouse and colour.

The last interaction that we model was dedicated to the system admin (Figure 30) that will be

able to manually change the AI model, and also view the adaptation data with the objective of

understanding the evolution of the data and if there are any tendencies between the users.

Introction

53

Figure 30 – System admin interaction with AdaptNow

IV.3. REQUIREMENTS

From everything that we analysed before in the state of art we built a series of system required

features that would help improving the elderly web experience. Base on Table 4 we created a

new table (Table 7) that to each issue offers a possible solution that we can implement to solve

it. With this in mind we built the system requirement table for the final system and with the

intent of a better understanding the needs of each stakeholder. The requirements were divided

into two groups, the functional that relate to all operation and non-function that relate to the

system.

Introction

54

Area of impairments

Type of the problem

Problem Solution

Vision impairments

Use of graphics 1. Icons should be simple and meaningful

Try to use icons that they can relate to their world

Target design 2. Providing larger targets

Make the buttons bigger so they can be easily detected

3. Clear confirmation of target capture

Give constant feedback to the user, so user can see if their actions were successful

Navigation 4. Provide location of the current page

It is important for old users to know their current location in the web site, so we should give that feedback to them

Content layout 5. Avoid irrelevant information on the screen

Reduce page density and increase comprehension. It is important to keep the page simple.

6. Important information should be highlighted

Browsing time can be lowered by highlighting the important information

Text design 7. Avoid moving text Moving text confounds the user so it should be avoided

Dexterity impairments

Target design 8. Providing larger targets

Make the buttons bigger so they can be easy to click

9. Do not expect double clicks

Remove double clicks because it is hard for older people to do it

Browsers windows features

10. Avoid scroll bars Scroll bars should be avoided because elderly users tend to have problem with the mouse and scrolling will be another problem

Cognitive impairments

Use of graphics 11. Graphics should be relevant, not for decoration

Remove object that does not serve any purpose for the task that is being performed

Navigation 12. Clear navigation should be provided

Provide help for users to move smoothly over the page

Introction

55

Browsers windows features

13. Avoid pop-ups and animated advertisement

Block pop-ups

Cognitive design

14. Reduce the demand on working memory

Identifying the clickable areas

Table 7 – Adaptation of Table 4, adding the solution to the uses present previously for the elderly interaction with the web.

Functional Requirements IV.3.1.

The functional requirements relate to all the operation that the system must allow the users

perform. Through the analyses of Table 8 and the experiment conducted we got as

requirements the following list:

1. Change the zoom.

2. Change the font size.

3. Activate and deactivate the link enhance.

4. Alternate link enhance from box to underline.

5. Change the link colour.

6. Change the link border.

7. Activate and deactivate the button enhance.

8. Change button colour.

9. Change button border.

10. Activate and deactivate the scrolling system.

11. Change the scrolling method.

12. Allow users to login.

13. Allow users to logout.

14. Reapply the original setting.

Introction

56

15. Disable the enhancement on a desired page.

16. Allow users to go back and forward on the webpages

17. Visualize the navigation historic.

18. Alternate between feeds and regular webpage.

19. Change their account settings.

20. Allow users to refresh the current page.

21. Block popups.

22. Block adds.

23. Change the mouse size.

24. Change the mouse model.

25. Allow users registration

Non-Functional Requirements IV.3.2.

The non-functional requirements are related the functionalities which users don’t have control

but they interfere with their performance, but also are related with performance, robustness,

security, scalability, and other.

In our system scenario we can identify the following non-functional requirements:

1. Usability – The used icon must be standard and easy to understand by user.

2. Usability – Notify the user if the webpage has feeds

3. Operability – The system should allow users to adapt and save their setting even

without and account.

4. Operability – System must save the user session.

5. Security – System must save the session using MD5 encryption.

6. Portability – The system must be accessible from any browser.

7. Price – System must be free to everyone.

Introction

57

8. Scalability – Save all webpage configuration and characteristics, link, buttons, etc., for

enhancement of the AI model.

9. Platform – System must be usable in all operating system.

10. Privacy – All sensible data must be encrypted with MD5.

IV.4. TECHNOLOGIES

Having built all the system requirements we have to analyses the available options for the

development of the application and chose the best option that will best fit our need and the

ones of the users, and in case that we need to adapt the requirements due to restrictions chose

accordingly. For the design of AdaptNow there were three approaches that we identify as

possible web enhancement applications. The three approaches were, first a browser plugin

which would work as mask changing the original webpage view; second would be build a new

browser with all the adaptations on its core; and third and would be Furthermore a web

application that would mask the original webpage. Furthermore

After analysis the proposed approaches we identified the limitation and advantages of each one

(Table 9). Starting with the plug-in we identified that it could a good option but since it

required installation and also users to have a specific web browser, the users that we could

address would be much smaller. With all this in mind we decided that the plug-in was not the

better option and decided to analyses the Browser approach. The browser would allow us

access every functionality that we need and was the most powerful option available, but again

the requirements of installations and requiring users to change the normal web browser would

represent a drastic change on the web usage habits. Furthermore the constant need to

maintenance for the browser led us to also give up on this approach. For the web application

we found that the biggest issues were the security concerns with cookies and associate with that

the cross domain access restriction that denies the ability to open a webpage from another

domain inside our own. For this to work we would need to create and application that would

rebuild the desired webpage locally in order for us to adapt. Being this the main barrier we

decided to further investigate this issue and search for applications that already solve this issue,

understand their approach to it and try finding a framework that would allow us to bypass this

setback.

Introction

58

Problem Plug-in Browser Web site/server Session No problem No problem Security concerns with cookies

and cross domain access Edit CSS No problem No problem No problem

What does the hard work?

Browser Himself Server

Saves data online? Yes No Yes Multiple browser

compatibility Need some changes No Yes

Operative system compatibility

Yes No Yes

Table 9 – Comparison of possible technologies to use on AdaptNow

After a closer research we identified WebAnywhere platform [39] that was a web based screen

reader for blind users that allowed them access to the internet everywhere for free without the

need for installations. This platform was an open source project that allow users to create their

how screen reader and help improve it This would solve us the cross domain problem that they

already implemented and at the same time improve our application every time a new version of

WebAnywhere is released. With this solution we decided to build AdaptNow as a web

application based on the WebAnywhere platform. Having said this, it means that our project

will be based on a web page application that will use JavaScript to dynamically change the

webpage through the injection of CSS. As for the server side we will use PHP to execute the AI

algorithm and save the user settings and finally for the database we are going to user MySQL.

The reason we had to go with PHP ASP/.net is because the WebAnywhere users PHP and a

Linux server to run and so we keep the same technologies in order to facilitate the future

compatibility.

IV.5. ARCHITECTURE

AdaptNow is a client server web application that that users WebAnywhere platform.

WebAnywhere uses a web proxy to reconstruct the desired webpage locally to overcome the

cross domain restrictions, and with this allow us to apply modifications. What we do is during

the reconstruction of the webpage on the local server we inject a set of scripts that will enhance

the page (Figure 31). This way we are able to keep the compatibility with future versions if they

don’t change completely the reconstruction process. Also we execute some PHP function that

calculate during this reconstruction with the objective of calculating the enhancement values

and with this remove the need of another server communication to get the correct values and

with it improve the performance. AdaptNow also has function library that is responsible to

Introction

59

interact with the data base and at the same time generate all the enhancements based on the AI

parameters.

Figure 31 –AdaptNow web application architecture based on the WebAnywhere platform.

IV.6. DATA BASE

As show before on the architecture of the system we have a data base that saves all the users

adaptation of the webpages and their characteristic to improve our model. The data base uses

MySQL and PHP and it is executed by a Linux server. This data base saves the data related to

the user historic so they can have access to it in any computer that they login and the

enhancements modal that we use, it is important to note that the data base is already prepared

for the possibility of adding personal adaptation model. In Figure 32 we present the data base

model that the AdaptNow system currently uses.

60

Figure 32 - AdaptNow system data base model

61

IV.7. APPLICATION FUNCTIONALITIES

Based on the requirements and the solutions presented on the Table 7 we started to implement

the system functionalities. The implemented functionalities that we were able to implement so

far were: zoom, text size, button and link enhance, rss reader, historic view and the mouse

enhance. Also the server side adaptation algorithm is fully implemented to generate adaptation

using the AI algorithm.

Zoom enhance IV.7.1.

The zoom functionality increases the size of everything of the webpage, and for a better

compatibility we users the function that access and uses the browser zoom functionality and

with it keep the compatibility between browser without the need of changes. The zoom

function can be seen in Figure 32 where we present the comparison between the original

webpage and the enhanced page, with the screenshot being in the same scale.

Introction

62

Figure 33 – Zoom functionality example in the page www.sapo.pt (the two images are in the same scale); a) original page; b) adapted page with zoom

Text enhance IV.7.2.

The text enhance feature increases the text size, variation from 10 to 20 pixels in size. For this

functionality we users JavaScript to inject the font size we want. The result is presented on

Figure 34 were we can check the difference between the text and its readability.

Introction

63

Figure 34 - Text size enhance feature (the two images are in the same scale); a) original page; b) adapted page with zoom.

Button and link enhance IV.7.3.

The button and link enhance where grouped together since we observed that the users tended

to keep the same colour for both and did not really understood the difference between them we

decided to group the functionalities together and with that reduce the number of item on the

interface. With this feature we can change the size of the border, change the colour that we want

to be marked and if we wanted the underline option or the box. In Figure 35 we can check the

example of a box enhance on the links.

Introction

64

Figure 35 – Link enhance using the box option with the blue colour. a) Original page; b) adapted page with zoom.

Rss Reader IV.7.4.

The rss readers we build allow users to navigate throw the information with less background

noise and with it improving the navigation. This feature was designed with the objective of

facilitating the navigation on news webpages that usually have news feeds and very complex

webpages. The implemented page is available in Figure 36, and as any other page the

enhancement system also works here.

Introction

65

Figure 36 – RSS reader of AdaptNow.

Historic IV.7.5.

The historic view will allow user to have a visual view of their navigation and for that we

present a tree view where users can see the navigation inside each webpage domain. The

example of an historic view is in Figure 37 where we present the historic navigation of the

www.sapo.pt webpage.

Figure 37 – AdaptNow historic view

Introction

66

Ad removal IV.7.6.

With the WebAnywhere framework we are able to remove most of the ads when we rebuild the

webpage locally, what also solves one of our issues identified in Table 7. The example can be

seen in Figure 38 the example the removal of the ad.

Figure 38 – AdaptNow ad removal.

Mouse enhance IV.7.7.

As show before we created a mouse enhance that would change the appearance when over link

and it was customizable in three different sizes (Figure 10). This was done with the objective of

solve the dexterity problem and increase the control and visibility of the mouse. In Figure 39 we

can see an example of how the mouse reacts on a normal webpage.

Figure 39 – AdaptNow mouse enhance. A ) normal mouse; b) mouse when hover a link

Introction

67

AdaptNow IV.7.8.

With all the features show before we present AdaptNow with its 3 main visual components:

navigation, adaptation, and webpage. The first component presents the user with: 1) an address

bar to choose where to navigate, and a back, forward and refresh buttons; 2) A login

button/functionality is also available where the user can access and modify his/her settings

and default information; and 3) a button to the historic view (Figure 40).

Figure 40 – The entire AdaptNow enhancement features during the navigation.

Uncompleted features IV.7.9.

Some of the AdaptNow feature still required some work, and some have not been

implemented, either due the lack of time or the complexity of the problem. In this section we

will explain the features that still need to be implemented. Starting with the historic there is the

need to implement the view for changing the pages and the period of time we want to view.

The current already has the queries that support that features just need graphic interface.

Another of the not implemented features that will be soon added is the registration feature that

currently has to be done manually by the admin. The interface to change the personal setting

related to the account also need interface. This happen because we decided to change the all this

feature to one place since they were no changed that often.

All this features will be implemented as soon as possible in order to have the first official

version released with 100% of the functionalities as soon as possible.

Limitation IV.7.10.

AdaptNow has some limitations that are inherited from WebAnywhere. Currently they don’t

fully support pages with flash, and have problem with pages like Facebook that don’t allow the

local reconstruction of the webpage. This is a disadvantage of this approach but since the

WebAnywhere is an ongoing project and some of the issues are said to be resolve soon, we can

integrate our application with the newer versions.

Introction

68

V. CONCLUSION AND FUTURE WORK

Falar sobre o artigo que foi escrito

1

3

4

INDEX

References

5

VI. REFERENCES

[1] European Commission, “Web Accessibility,” 2014. [Online]. Available: http://ec.europa.eu/digital-agenda/en/web-accessibility. [Accessed: 10-Jan-2014].

[2] European Commission, “Design for all for eInclusion,” 2013. [Online]. Available: http://ec.europa.eu/digital-agenda/en/content/design-all-einclusion. [Accessed: 13-Dec-2013].

[3] K. Z. Gajos, D. S. Weld, and J. O. Wobbrock, “Automatically generating personalized user interfaces with Supple,” Artif. Intell., vol. 174, no. 12–13, pp. 910–950, Aug. 2010.

[4] J. Abascal, A. Aizpurua, I. Cearreta, and B. Gamecho, “A modular approach to user interface adaptation for people with disabilities in ubiquitous environments Foundations of the EGOKI Adaptive System,” Intelligence, 2011.

[5] J. O. Wobbrock and S. K. Kane, “Ability-Based Design : Concept , Principles and Examples,” Engineering, vol. 1, no. 212, pp. 1–36, 2010.

[6] J. M. P. Albert M. Cook, Cook and Hussey’s Assistive Technologies: Principles and Practice. Mosby Elsevier, 2008.

[7] Albert M. Cook and S. M. Hussey, Assistive technologies. 2002.

[8] “The History of Prosthetics: Artificial Limbs Past and Present.” [Online]. Available: http://www.disaboom.com/amputations-information/the-history-of-prosthetics-artificial-limbs-past-and-present. [Accessed: 27-Jan-2012].

[9] R. A. Cooper, Rehabilitation Engineering Applied to Mobility and Manipulation. 1995.

[10] V. Impaired and P. Manual, “Rehabilitation technology,” Rehabilitation, pp. 8–9, 2011.

[11] G. V. Kondraske, “Rehabilitation engineering: Towards a systematic process,” IEEE Eng. Med. Biol. Mag., vol. 7, pp. 11–15, 1988.

[12] Ron Mace, “North CarolinaState University - Ronald L. Mace,” 1998. [Online]. Available: http://www.ncsu.edu/ncsu/design/cud/about_us/usronmacespeech.htm. [Accessed: 31-Jan-2012].

References

6

[13] European Commission, “European Commission Design for All,” 2012. [Online]. Available: http://ec.europa.eu/information_society/activities/einclusion/policy/accessibility/dfa/index_en.htm. [Accessed: 30-May-2012].

[14] J. P. Mace, R. L., Hardie, G. J. and Place, “Accesible environments: Toward universal design,” 1991.

[15] J. Vanderheiden, G., Weber, G. and Ziegler, “Toward an information society for all: An international R&D agenda.,” Int. J. Hum. Comput. Interact., vol. 10, pp. 107–134, 1998.

[16] P. Kumar, “Human Factors & Ergonomics in Design,” 2010.

[17] P. L. Emiliani, L. Burzagli, M. Billi, F. Gabbanini, and E. Palchetti, Report on the impact of technological developments on eAccessibility. 2008.

[18] Optimastudio, Diseños para Todos/Designs for Al. 2008.

[19] “Designs for all,” 2014. [Online]. Available: http://www.optimastudio.com/disenosparatodos/en/index.php. [Accessed: 01-Feb-2014].

[20] “Transgenerational Design Matters,” 2012. [Online]. Available: http://www.transgenerational.org/viewpoint/transgenerational.htm. [Accessed: 01-Feb-2012].

[21] S. Keates, P. J. Clarkson, L. A. Harrison, and P. Robinson, “Towards a practical inclusive design approach,” in Proceedings on the 2000 conference on Universal Usability, 2000, pp. 45–52.

[22] transgenerational.org, “Transgenerational Design - Benefits and Principles,” 2014. [Online]. Available: http://www.transgenerational.org/viewpoint/transgenerational.htm#Benefits. [Accessed: 11-Dec-2013].

[23] J. Hanson, “The Inclusive City : delivering a more accessible urban environment through inclusive design .,” pp. 1–39, 2004.

[24] Cambridge Engineering Design Center, “The bottom-up approach,” 2005. [Online]. Available: http://www.eng.cam.ac.uk/inclusivedesign/index.php?section=approaches&page=bottomup. [Accessed: 02-Feb-2012].

[25] Cambridge Engineering Design Center, “Top/Bottom approaches,” 2005. [Online]. Available: http://www.eng.cam.ac.uk/inclusivedesign/index.php?section=approaches. [Accessed: 25-Jan-2012].

[26] Cambridge Engineering Design Center, “Top-down approaches,” 2005. [Online]. Available: http://www.eng.cam.ac.uk/inclusivedesign/index.php?section=approaches&page=topdown. [Accessed: 02-Feb-2012].

[27] P. I. N. Ayudhya, “The Inclusive Incapability-Culture-EconomyCube: A design framework for complex barriers,” designresearchsociety.org, 2010.

References

7

[28] S. Keates, P. John Clarkson, and P. Robinson, “Developing a practical inclusive interface design approach,” Interact. Comput., vol. 14, no. 4, pp. 271–299, Jul. 2002.

[29] D. Sloan, M. T. Atkinson, C. Machin, and Y. Li, “The potential of adaptive interfaces as an accessibility aid for older web users,” Proc. 2010 Int. Cross Discip. Conf. Web Access. - W4A ’10, p. 1, 2010.

[30] L. Findlater and J. Mcgrenere, “A Comparison of Static , Adaptive , and Adaptable Menus,” Most, vol. 6, no. 1, pp. 89–96, 2004.

[31] and R. S. M. Debevc, B. Meyer, D. Donlagic, “Design and evaluation of an adaptive icon toolbar,” 1996.

[32] J.McGrenere, R. M. Baecker, and K. S. Booth, “An evaluation of a multiple interface design solution for bloated software,” pp. 163–170, 2002.

[33] S. Greenberg and I. H. Witten, “Adaptive personalized interfaces – a question of viability.” 1985.

[34] J. Mitchell and B. Shneiderman, “Dynamic versus static menus: an ex- ploratory comparison,” SIGCHI Bull., vol. 20, no. 4, pp. 33–37, 1989.

[35] M. Debevc, B. Meyer, D. Donlagic, and R. Svecko, “Design and evaluation of an adaptive icon toolbar,” Des. Eval. an Adapt. icon toolbar, vol. 1, no. 6, pp. 1–21, 1996.

[36] P. Gregor, A. F. Newell, and M. Zajicek, “Designing for dynamic diversity: interfaces for older people,” in Proceedings of the fifth international ACM conference on Assistive technologies, 2002, pp. 151–156.

[37] S. Kurniawan, “Research-Derived Web Design Guidelines for Older People,” Human-Computer Interact., pp. 1–8, 2005.

[38] K. Z. Gajos, J. O. Wobbrock, and D. S. Weld, “Automatically generating user interfaces adapted to users’ motor and vision capabilities,” in Proceedings of the 20th annual ACM symposium on User interface software and technology, 2007, pp. 231–240.

[39] J. Bigham, C. Prince, and R. Ladner, “WebAnywhere: a screen reader on-the-go,” Proc. 2008 …, pp. 4–5, 2008.