This paper reports on the lessons learnt during the application of a methodology to develop intelligent environments. One important feature of the methodology is that of being strongly user-centred, and the authors report on how that interaction with users took place and how it continuously shaped our project aspirations and outcomes. The methodology was applied to a project which aimed at helping people with Down’s Syndrome and those with similar conditions and needs, to be more included in society. The project was developed by a consortium of commercial, academic, and end user supporting organizations. The paper elaborates on what type of stakeholders engaging activities were considered and how these were distributed along the lifetime of the project and their impact.
1 Introduction
Technology is finding its way through society, and developed systems are increasingly intertwined with our daily lives. They are related to health, safety, socialization, entertainment, news, and more. These systems are increasingly challenging to build, because in order to be useful wherever and whenever we may need their benefits, engineers need to rely on a mix of system components, which are complex on their own and even more when combined. This is not entirely new in the Computer Science and Information and Communication Technology fields, which have been developing systems of increasing complexity for decades. One benefit of this rich history is that engineers now have a body of experience, methods, and tools to use when embarking in creative processes. On the other hand, these methods are not infallible as we all experience on a regular basis when technology lets us down one way or another. To make matters worse, the new systems which have spawn from the Ubiquitous Computing [23] movement two decades ago have a mix of components and expectations which are slightly different than those which led to the development of the methods and tools most widely used nowadays. There are several areas related to Ubiquitous Computing, such as Pervasive Computing, Internet of Things, Smart Environments, Ambient Intelligence, which largely share the objectives and building blocks and which we will refer to collectively as intelligent environments [4]. They have in common (with different emphasis in each of them) the use of sensing technology and innovative interaction devices interconnected with a network and supplemented with intelligent and context-aware software to create useful services for humans in whatever space and time they need support. One of the many important hurdles in the way of this new area is the lack of methodologies and tools to support developers connected to a strategy which guides them through the process in a way so as to increase their chances of success. New system developing strategies have been proposed recently based on the experience of the last decade of building sensorized environments [5]. Such high-level strategies are not new to Computer Science, and there are well-established options like “waterfall” inspired methods and “agile” inspired methods, which were created in the 1980s and 1990s. After much debate and criticisms from defenders of each approach, there is recognition now these methods are not always the best option and they shine at their best only when the project to be applied to has certain characteristics. The development method used and assessed in the project we report in the context of this paper is flexible enough so that it can be used in ways which can resemble either the waterfall or agile approaches, although the emphasis is more as a user-centred iterative process. The following section describes the method followed, while Sect. 3 elaborates on the project it was applied to. Sections 4 and 5 focus on explaining the co-creation/co-design activities and how they continuously shaped the services being created.
2 U-C IEDP
It has been acknowledged by researchers in the field of intelligent environments that there is limited research regarding software development methodologies for building and deploying such sophisticated environments; see for example [1]. Consistent with this perceived lack of any agreed standard on the software development methodology for building and deploying intelligent environments, [5] proposed the User-Centred Software Development Process (U-C SDP), which was grounded on the experience of a decade building systems based on sensors. That initial name of the methodology recognized that Software was one of the main components in the development of sensor-based system such as those developed in the areas of Ubiquitous and Pervasive Computing, Ambient Intelligence, Internet of Things, or intelligent environments. The name of the methodology has now been changed to User-Centred Intelligent Environments Development Process (U-C IEDP), to recognize it is not only software we consider in building these systems but also hardware, networks, and interfaces. We assume the physical space where the system is going to be deployed, for example, the smart home, office, or shopping centre is already built. Our focus is not the technological aspect, we are less concerned with the creation of artefacts (e.g. specialized sensors), and we largely assume the sensors and devices to be used are available in the market. Our focus is on how to put together technology and create the software which allows the infrastructure to provide the required services.
Fig. 1
Overview of the user-centric IE development process
×
Anzeige
Although advances in network and communications technology have made it possible to conceive such “Systems of Systems” (SoS), engineering and maintaining them is still challenging. According to Nielsen et al. [19], it is primordial to identify the boundaries of the overall SoS and of the independent constituent systems within it. These boundaries relate to both technical aspects such as interfaces, integration and testing, and management aspects such as governance and stakeholder involvement. Further challenges relate to the gaining of confidence in system operation, in terms of behavioural correctness, performance qualities, and their validation. In addition, the range of stakeholders involved, including the owners and operators of constituent systems, their integrators, and ultimately those who experience the system behaviour of the SoS, implies the need to employ methods and tools that support collaborative working from the elicitation of requirements to testing and maintenance. Hence, SoS engineering is much more complicated than traditional systems engineering [10].
The purpose of this model is to guide developers in building IEs which meet customer expectations and which are technically robust and correct. Compared to other user-centred approaches [13] such as the ISO 9241-210 [14] (human-centred design for interactive systems), the development of intelligent environments has specific needs, unlike those of conventional systems. While ISO 9241-210 provides a holistic approach focusing mostly on the needs of the future user in order to develop a usable human machine interface, the U-CIEDP methodology is more tailored for end users of IEs. On the other hand, our area is largely influenced by the technology deployed in the real world as the technology in an intelligent environment is conceived to influence on people’s daily lives more or less directly one way or another. This goes beyond interaction, and some parts of an IE can sense and make decisions and make changes to an environment in a way the users may not know or cannot revert. A system can be passing information to other humans about what is being sensed. IEs can have a great deal of autonomy and power depending on the technology being deployed and the way it is deployed. For that reason, the choice of technology and services has to be considered not only by developers, but also by all stakeholders. This is not something to be discussed once, at the beginning of the project. It typically takes several iterations for the developers and stakeholders to converge into a compromise solution where stakeholders get solutions to their needs and preferences in an acceptable way. This is an important insight gained from practical experience which is at the heart of U-C IEDP; it is based on an fluid dialogue with the stakeholders to agree on how the different ingredients of IEs (HW, SW, HCI, and networking) can be put to work in an acceptable way for everyone.
Because the final aim of products in this area is to satisfy users’ expectations, one important feature of this systems creation strategy is the cognizance paid to the importance of the stakeholders involvement of the project, in what is usually called in creative industries as “co-creation”. Users are at the heart of the methodology, and their involvement is crucial during each phase of the development process. This ensures that the final product has a higher acceptance rate. Several studies have emphasized the importance of user acceptance and involvement in our area since they are at the heart of intelligent environments [11]. Pennings et al. [20] reported that success of an intelligent environment is mainly determined by the extent to which it is adopted by users. Corno et al. [7] carried an extensive literature review on the involvement of users in the research, design, development, and validation of intelligent environments over the last 15 years. They also emphasized that IEs should be built with the users in mind and made a strong case for user-appreciated systems. Besides, Lock and Sommerville [18] reflected on the need for better understanding of the interaction between humans and SoSs, and between humans mediated through the SoS for a truly comprehensive approach to SoS engineering.
Applications developed for IEs also have very strict safety requirements. Therefore, rigorous verification and validation in an environment as close to the end user is embedded in the methodology. This ensures failures and inefficiencies due to inadequate system design are kept to a minimum. Another preponderant characteristic of the methodology is that it is guided by an Ethical Framework which enforces privacy and security of the users.
Anzeige
The U-C IEDP model has three primary loops: initial scoping, main development and IE installation. Solid arrows represent mandatory steps, while dashed arrows represent optional steps. The model consists of a number of smaller loops which allow refinements of the system based on the stakeholder feedback. This also gives the strategy flexibility in the sense that a project can spend more time (possibly through several iterations) in each of these loops (in a more waterfall fashion) or instead try to complete the entire process quickly and iterate that several times to target specific features (in a more agile fashion).
During initial scoping, requirements for the IE to be conceptualized are initially gathered by interviewing the stakeholders. This useful information is then translated into services which the system must provide. Next, the technical team works on the hardware requirements as well as interfaces for building the IE. An initial prototype is thus built and given to the stakeholders who assess the system based on their expectations and provide vital feedback to the developers.
Upon customer approval, the team moves to the next loop, main development. To begin with, a thorough design is carried out and various design documents are produced at this stage. These serve as blueprint for building, validating, and verifying the IE. Stakeholders are kept in the loop at this stage as well and their input is particularly valuable to avoid any unpleasant surprises in the future. The next step in this loop is coding and testing of the IE using suitable tools. Testing should be carried out on hardware, software, and human–computer interfaces. A rigorous approach such as model checking is recommended to check the correctness of the systems. Moreover, verification and testing should desirably be performed in conjunction to make sure the system is correctly built.
The third loop entails the installation of the IE. Initially, the infrastructure is set up by installing various hardware components such as sensors, actuators, and network interfaces. Next, the software is installed on the infrastructure, and various stakeholders carry out functional testing, to ensure compliance. Any suggestions, changes or modifications are reported and reworked. During services validation, the stakeholders test the IE continuously over longer periods of time. The model is also guided by an Ethical Framework to secure fundamental issues that are addressed within system development [16]. A high-level architecture diagram of the process model is given in Fig. 1.
3 The POSEIDON project
The project POSEIDON (PersOnalized Smart Environments to increase Inclusion of people with DOwn’s syNdrome) focuses on the task of bringing some of the latest technological advances to increase inclusion in our society of a specific group of citizens: people with Down’s Syndrome (DS). It tries to answer questions posed before in the AAL community about inclusion and the role of AAL beyond the current focus on supporting independence for the elderly [2].
People with Down’s Syndrome (DS) have certain characteristics which include areas of strength and areas of weakness, and within those features which may be statistically preponderant amongst them, there is also a huge diversity and range of skills (see for example, [6, 8, 12, 15]). The POSEIDON project aims at giving priority to their preferences to create technology that is appealing and useful to them. People with DS (along with their relatives and other potential users) were given the opportunity to co-design a solution along the project, and we believe this had increased the chances of producing a solution which is really useful for the intended beneficiaries. We gathered the direct participation of companies, research centres and Down’s Syndrome Associations primarily from Germany, Norway, and the UK.
However, the consortium also gathered the opinion of and attracted participation from other EU countries. The overarching goals were achieved by empowering first and foremost people with DS. However, support is also available to those who interact with them on a daily basis (family, carers, friends, and service providers). Although there are some technological products in the market, these are very limited and specialized on narrow services, without integrating and leveraging all the potential available by today’s technology and expertise. Some of the challenges people with Down’s Syndrome face include the following:
Access to education and support provided is limited,
Fewer opportunities to find employment,
Difficulties accessing and maintaining social networks,
Sedentarism can result in health problems,
Public information is often in formats that are not easily accessible (e.g. bus timetables),
Reading and writing can be more difficult.
POSEIDON aims to provide a technological infrastructure to foster the development of services which can support people with Down’s Syndrome and, to some extent, also those who interact with them on a daily basis. The infrastructure is illustrated with the creation of a system providing services supporting inclusion based on static and mobile Smart Environments to empower people with DS in different daily life situations. These services provide evidence and guidance on how technology can help people with DS to be more integrated within their society through education, work, mobility, and socialization.
This project cannot eradicate all of the problems that people with DS may experience; however, POSEIDON aims to provide an added layer of support that will facilitate their immersion in usual daily life activities as most of the population experiences it. The project is creating extra support for people with DS. POSEIDON offers information and guidance to encourage decision-making and independence. This is achieved through devices which will provide the infrastructure for a Smart Environment and software providing the Ambient Intelligence needed to guide and support them on interacting with the complex real world. Part of this Smart Environment and Ambient Intelligence infrastructure is available in the market, and part is created new specifically to support people with Down’s Syndrome or those with similar preferences and needs. There are static devices used at specific locations, for example at home, school or work, while the users also have access to the inclusion services everywhere and at all times through mobile computing. The main users are people with DS; however, their family, school teachers, employers, bus drivers, and other people interacting with them are also able to use the static and mobile devices with different interfaces and benefits. Some recent services built as part of POSEIDON have been reported by [9, 17].
Each individual is different though overall citizens with Down’s Syndrome may require some level of extra support in a variety of situations. Although POSEIDON cannot address all possible situations, it considered a few which are related to some of the core challenge areas they face: education, socialization, well-being, and mobility. User-centredness is paramount for successful adoption of intelligent environments, and this is even more important in a system like POSEIDON where there is little done before for the intended users and not much is really known about their interaction with technology. Hence, stakeholders’ involvement was something which drove the project from the earliest stages. Our project considered different types of users and stakeholders as depicted in Table 1.
Development was underpinned by a Development Framework, that is, methodologies and tools assisting specific tasks (e.g. gathering requirements and supporting context-aware development). These methodologies and tools will be reported in detail in other publications. The focus of this paper instead is on the overarching IE creation strategy and the role of stakeholders in co-creation. The intensity and type of user engaging activities is explained in Sect. 4 and how it affected the project development is described in Sect. 5.
Table 1
Different types of POSEIDON stakeholders
Generic name
Description
Primary users (PU)
People with Down's Syndrome
Secondary users (SU)
Main carers (e.g. relatives or social workers)
Tertiary users (TU)
Other system users (e.g. teachers, bus drivers)
Other (O)
Those interested in the system but no direct users, e.g. local authorities, user-related organizations, companies developing services, field experts
4 User involvement in POSEIDON
Technology design needs to consider a set of cognitive and physical abilities to achieve optimal performance. A 3D representation of a real environment might fail to communicate effectively to people who do not have the ability to abstract concepts and worlds. In order to upgrade the lives of some, technology has to be designed for diversity and ability. In developing useful technology in our area, there are several phases to consider: initial scoping, design, development, testing, and deployment. Although there is user involvement in a reasonable number of projects, often in practice this means user involvement mostly in the testing phase. Although this is necessary, it is not sufficient. There are projects which involve stakeholders at design stage, and this is more consistent with our approach. However, the underlying ethos of the methodology described in this article is that we have to go beyond those sparse stakeholders engagement standards of practice and increase stakeholders' engagement both in quality and quantity, having them engaged at more stages of the process and with a more relevant role in guiding the developers.
In particular, the experience reported in this article certainly suggests when the aim is to increase independence of people with special needs, an alternating interaction between developers and stakeholders is important to create a meaningful product. Because of the varying range of capabilities and difficulties of the target population, developers need to maintain an updating loop of the proposed solution, in which they consider the feedback of a significant number of stakeholders. In POSEIDON, we used U-C IEDP, an iterative co-design methodology that brought together all the involved stakeholders (primary users, caregivers, therapists, and developers). We involved stakeholders through a variety of activities. These include questionnaires, interviews, project pilots, workshops with primary and secondary users as well as with the Project Advisory Committee. A summary of these activities is provided in Table 2.
Initially, the aim was to understand and be able to conceptualize the needs and specific issues of the stakeholders. Then, we produced solutions that address the observations we made in the first step. To validate the design and content of the proposed system, we asked stakeholders to use and experience it. All these sessions were analysed in detail in aspects related to functionality, user interaction, and quality of experience. Each interaction of the users with the system brought new insights about our stakeholders through this analysis, but also through the provided feedback.
It is important to highlight that the organization of the different events which facilitated interaction or gathering of feedback from stakeholders were organized mostly following the lead of the Berlin Institute for Social Research (BIS), one of the partners of the POSEIDON project. Although the type of interactions to have, their frequency and their timing were planned and agreed with most of the partners of the project, BIS provided the protocols of interaction with the stakeholders, especially the documents, including surveys, to use when presenting and gathering information from stakeholders [21, 22].
4.1 Questionnaires/interviews
The aim of this phase was to assess the requirements of people with DS and to bring up any significant issues that need to be addressed. The requirements analysis was done using different methods: questionnaires (people with DS and caregivers) and face-to-face interviews with the stakeholders. The Berlin Institute for Social Research conducted an initial web-based questionnaire to almost 400 parents, from three different countries. The answers were used to analyse the type of technologies people with DS use, the level and type of support they need when interacting with these technologies. Additionally, focus was put on their living situation to identify how they travel, manage time, handle money, and communicate. All this information was used in proposing a set of scenarios and "personas" that were meant to illustrate the aspects targeted by. The scenarios presented characteristics and possible daily activities of people with DS from different countries.
4.2 Workshops with primary/secondary users
The first project workshop took place at the beginning of the project. Different technological solutions were presented to the primary users (VR games controlled through Wii control, mouse/keyboard or tablet); see Fig. 5. The aim of this interaction with people with DS and caregivers was to explore user engagement with different technologies and their quality of experience.
These initial observations were used in creating a mock-up of the system with a set of proposed interaction methods. This first prototype was introduced to the users during a workshop that took place in Mainz, Germany, in month 8 of the project with participants from 5 countries. We conducted a set of experiments with PUs over 2 days with the intention of assessing the usability of our first prototype and the advantages and disadvantages of using specific proposed technologies. This workshop was followed by a series of shorter workshops (half a day long), held primarily in London, as well as additional ones in Germany and Norway. These events were meant to facilitate the design of the functionality of the product and interface. Developers participated in these meetings in order to gain a deeper understanding of the necessary modifications.
Additionally, there were complementary workshops with the Project Advisory Committee, a group of experts which provided useful insights by sharing their expertise, and also a quality check.
4.3 Project pilots
Over the course of the POSEIDON project, there were two pilots of one month each and a single-day extended pilot. These pilots were carried out in the UK, Norway, and Germany. During the month-long pilots, three families from each of the countries were selected to participate in the evaluation. The process involved screening of potential families through a questionnaire, to check on their suitability for the pilot. Once the families were selected, users were given diary sheets, as a way of documenting their use of the POSEIDON system. Main topics were: who used it, what they liked and did not like. Each family received four visits. In the first visit, project developers and Down’s Syndrome Association (DSA) monitors went to get to know the families and establish a good relationship with both PU and SU. Information sheets and consent forms were distributed and filled in. Following this, the Home Training of Navigation Services application (a program which allows people with DS to rehearse routes in advance), POSEIDON Mobile application (an app which helps with navigation outdoors), POSEIDON Context Reasoner (part of the system which recognizes useful contexts) and Carer’s web (a system which provides centralized access to carers of available services) were installed and set up for the users. Over the course of the pilot, different interviews and questionnaires were completed to gain feedback of the different systems. Moreover, application usage was logged, which allowed us to see how many times the users used each component of the system and how they benefited from it.
Table 2
User engagement activities during POSEIDON
ID
Type of involvement
Month number
No. of main stakeholders involved
W1
Workshop
2
5 PU 5 SU
Q1
Questionnaire
2-4
400 SU
W2
Workshop
10
5 PU 7 SU
A1
Advisory Committee
12
3 TU/O 4 SU
W3
Workshop
14
13 PU
P1
Pilot 1
20–23
9 PU 9 SU
P2
Extended Pilot
25
26 PU
A2
Advisory Committee
26
3 TU/O 5 SU
P3
Pilot 2
31
9 PU 9 SU
For the extended pilot, in a similar fashion, different day events were held in all three countries. A total of 26 people with DS took part (10 in the UK, 13 in Germany, and 3 in Norway). During the extended pilot, there were three items and we wanted to evaluate new functionality added to the different systems including more contexts being handled in the POSEIDON mobile application, a new learning and assessment mode in the Home Training of Navigational Services, and further tests of the Money Handling application. All these events allowed for a prolonged utilization of the proposed solution. Stakeholders were able to integrate its functionality in their daily lives and to choose the frequency of using the provided services. A quantitative summary of these activities is given in Table 2, while a qualitative overview is provided in Fig. 2.
The proposed method of co-design based on continuous feedback from the stakeholders and of triggered adaptations of the product allowed the developers to maintain a strong connection with the stakeholders. Moreover, developers gained a better understanding of the way primary users interact with different features.
Fig. 2
Diagram of the stakeholders—developers co-design interaction activities
Fig. 3
Temporal overview of meetings with stakeholders
×
×
5 Service refinement and evolution
The U-C IEDP method is based on several small and big project iterations and frequent interactions with stakeholders. In this section, we explain how the POSEIDON concept, in the form of successive prototypes, was being shaped through the different stages of the U-C IEDP method. Figure 3 shows how they happened in time.
5.1 Prototype one
Initial scoping As central to all the main loops in the U-C IEDP, we started gathering the expectations of the stakeholders. Initially, this happened in the form of a questionnaire (Q and U1) to people with Down’s Syndrome and their parents. This gave the team feedback about the activities to support. It was found that the participants were often quite capable of carrying out different tasks, including navigating, even if with some support. It was felt that areas of achievable tasks with assistance were likely to be a more successful target of development. The first workshop (W1) covered the stages “Define Required Services” and “Define required IE infrastructure” from the U-C IEDP. The technical teams translated the information gathered from the stakeholders into services that were useful for them, during the first workshop. Developers proposed a set of services to support the main activities in which people with DS required help, according to the questionnaire. The questionnaires were also discussed to determine the most suitable technology for people with DS and their parents, selecting the devices and interfaces that materialized the IE. Finally, a requirements document was produced, as a contract between all the stakeholders, defining what POSEIDON would do. After the first workshop, the teams prepared the initial design and started preparing the first prototype. Based on related work, developers mocked up a potential future state of the system.
Main development This first design was discussed in a technical meeting in month 5 of the project with initial ideas. The teams gathered both feedback and suggestions from the national Down’s Syndrome Associations based on these ideas. Based on this feedback, the development teams identified areas that needed to be refined, defined and clarified. In the second workshop (W2), the developers introduced a mobile navigation system, using Google Directions for route data. These data were supplemented with photographs of the specific Google waypoints, in an effort to see whether photographs helped them navigate. A racing game was also developed for use with a large smart table, as a way to assess the participants' motor skills, and whether they find the interaction device enjoyable to use.
IE installation The second workshop also covered the whole IE installation loop of the U-C IEDP. The users were instructed on how to use the system. The event was held in Mainz, Germany, including 5 people with DS. Partners responsible for different components of the system each took turns to introduce their components, demonstrate, and present ideas for further development. Participants were asked questions in terms of their opinions of the components and any features that could be of use. Feedback gained highlighted the need of considering time management, and not being too sensitive regarding offering contact for support, due to common abuse by primary users. During the second workshop, the prototype of mobile navigation application was tested in order to gather feedback about the primary users using the devices. It was found that using automatically generated directions from services including Google Directions did not give sufficiently understandable directions for navigation. Based on this finding, it was decided that secondary users should have the ability to decide their own routes, using their own decision point photographs, and textual commands. Using textual commands, the secondary users can generate additional information that can be useful to the primary user including what side of the road to be on, whether to cross at particular places, etc. Usability tests of the smart table were carried. These tests were carried out using a combination of task performance and direct feedback by the primary users. The primary users were presented with a basic game, which required the movement of an avatar to avoid collision with upcoming objects. To do this, the users had to swipe their hands across the table in the direction they wished to move the avatar. Feedback from primary and their secondary users was positive on its use as an interface tool regarding the game in question (Table 3).
Table 3
Prototype 1
U-C IEDP main loop
U-C IEDP secondary loop
Event type
Outcome
Initial scoping
Interview stakeholders
Q + U1
“Way finding” identified as an important activity to support
Interactive user devices engaged the users and were considered an interesting approach
Development Framework outlined
Define Required Services
W1
The provided services need to maintain users safety
The use of virtual reality was considered for training way finding skills in a safe/customizable environment
Define required IEs infrastructure
W1
The use of a stationary system controlled through various input devices was proposed
Initial design
A virtual environment of a building was created to test and prototype if the users were able to transfer navigational knowledge between virtual and real environment
Main development
Interview stakeholders
U2
SUs tested and provided feedback about proposed prototype (i.e. type of displayed customized information, application flow)
SUs provided guidance for developers future choices (i.e. strategies when travelling to a new destination)
Design I
A simple navigational task where users need to find a destination based on an arrow is used
Implementation and testing
5 students (without special needs) familiarized with the environment tried to solve the task functionality
Verify correctness
Not all the routes a PU could take can be virtualized in an efficient way
Design II
VR should be tried just for training indoor navigation in buildings with an available 3D model
IE installation
Interview stakeholders
W2
SUs thought the system offers an interesting approach on learning a new route if customized on real imagery
Equipment Validation
PUs could not match real buildings and their virtual representations
Software validation
Flow of the application difficult to follow led to restructure the application
Services validation
VR should be replaced with mixed reality
Automated way of retrieving route information
5.2 Prototype two
Initial scoping As input for the “initial scoping”, during the interviews with the stakeholders, the families presented daily activities of primary users with an emphasis on areas where they needed more support.
Main development For prototype two, a number of changes had been added to the POSEIDON system. First, routes for the user could be designed in the Home Training of Navigation Services application by the secondary user. This allowed secondary users to tailor the routes by adding custom waypoint instructions and photographs to assist the primary user. These routes are then synchronized to the main POSEIDON application using POSEIDON web services. Other developed services include a specialized calendar service which allows the user to keep track of their events and add additional data to events including linking personalized routes. A website for use by the SU was created, named Carers web. On this site, the carer can view where the PU is, alter POSEIDON personalizable features, and also edit calendar events. Other developed services include a context reasoner, which can determine different contexts to assist the user in the main POSEIDON application, including weather information on navigation destinations. Lastly, a game for practicing money handling was created for the primary users, paired with a smart table.
IE installation Prototype two was tested during Pilot 1 and Extended Pilot 1 (P1). As described earlier, different instrumentation tools designed by BIS were used for data collection. The first includes diaries given to the pilot participants. These sheets were designed to be completed following the usage of a particular component of the system. The user would need to select which application they used and answer long questions including: “Who used it?”, “What did you/and the person with Down’s Syndrome user it for?”, and “Did you and/or the person with Down's syndrome experience any problems?”. Interviews were designed to be carried out once a week, either over the telephone or in person. Each interview was broken up into different components with some generic questions for each including “What did you like?”, “What did you not like? Why?”. Then there were more specific questions related to each functionality. For example, context-aware notifications were designed to present the user with clothing advice based on weather conditions. We therefore included questions including “Did you receive weather notifications? If yes, how useful did you find them?”. In addition, observations were taken by technical staff and DS association staff. Feedback from the pilot was driven mostly by observation and interviews. Diaries had low use, so very little data were acquired this way. There were technical difficulties with using the smart table in the participants’ houses. As it proved too difficult for the families to use without technical supervision, it was not used. The calendar functionality was overall positive; however, some PUs required their SUs to input the events due to impaired literacy skills. The main POSEIDON mobile application was viewed as promising and useful. There was feedback that there were some concerns regarding safety, similar to those reported in [17]. It was decided that additional steps should be addable to a route, instead of just editing the Google given instructions. The PU and SUs were positive about the use of context awareness to drive different notifications to the user including whether specific clothing was necessary based on weather conditions. Personalization, however, was an area that looked to require more investment (Table 4).
Table 4
Prototype 2
U-C IEDP main loop
U-C IEDP secondary loop
Event type
Outcome
Initial scoping
Interview stakeholders
U3
Families emphasized where PUs needed more support
Importance of calendar and money handling identified
Define Required Services
A1
Emphasis on the quality of image and the contrast in building applications for the target population
Define required IEs infrastructure
A1
Emphasis on using devices with high resolutions
Initial design and prototyping
A1
The design of the training navigational services application should consider visual issues of people with DS
Main development
Interview stakeholders
U4
Validation of using panoramic real-world imagery when training navigation (PUs recognized places presented from this view)
Importance of having contextualized information (PUs struggled to match places in different light or weather conditions)
Design I
W3
A mixed reality solution was proposed where the user needs to navigate between two points based on customized information
Implementation and testing
W3
Navigation is based on Street View panoramic imagery for decision points retrieved from Google Directions
Each decision point is customized with text and photograph
Verify correctness
W3
No street view data for certain GPS coordinates
Design II
W3
Developers designed game modes to assess users’ route knowledge
IE installation
Interview stakeholders
P1
Lack of route personalization possibilities (insufficient decision points provided by Google directions) leads to new approach to create routes based on GPS coordinates of photographs
Equipment validation
P1
Some of the SUs computers could not support the minimum requirements of the navigation app
Software validation
P1
Improvements in design needed
Services validation
P1
Inaccurate information provided by Google Directions especially
5.3 Prototype three
Initial scoping Pilot 1 questionnaires were used as the first stage of the initial scoping in the U-C SDP, “Interviewing the stakeholders”. During Pilot 1, the users demanded more personalization possibilities when defining a route (insufficient number of decision point provided by Google directions). Also, they demanded some other features for ensuring the well-being of the primary user, when she/he gets lost. Taking this feedback from the stakeholders, the developers redefined the required services to have a new approach for route creation. The secondary users took photographs of the routes in the streets, which were automatically translated into a route by using the GPS coordinates from the place they were taken. After that, developers created the definition of the infrastructure, by adding new context awareness. The creation of new contexts was complemented by a questionnaire conducted with 130 families with children with DS. Specifically for context awareness, two new contexts were identified: “When the primary user is standing still for a long time” and “When the primary user needs assistance with the navigation”. Finally, the initial design for the final prototype started.
Main development For prototype three, a new version of the POSEIDON navigation application was introduced with further improvements to navigation and calendar handling. An application for creating routes was developed for mobile devices. This was due to added complications in making the user create the routes on a static computer at home. With the route creator application, the SU can walk the intended route, taking photographs, and automatically tagging decision points with their current location. Money handling assistance was improved by the creation of a mobile application which the user can take with them to local shops for purchasing various goods. It allows them to not only practice picking the correct money for particular items, but can also assist them in notifying them how much money they need to take, and what money denominations are required to pay for a particular shopping basket. The context reasoner was extended with personalizable contexts, allowing different context settings to be tailored to suit the user. An updated version of the Home Training of Navigation Services was developed to include the ability to add new decision points to routes, add voice commands and further assessment modes to allow the PU to train a route more. Finally, the online Carers web included more personalization features, the inclusion of money handling to let the SU set up shopping lists for use with the mobile application. Lastly a new querying service based on previous events allows the PU and SU to compare how well they have navigated previously over different time windows.
IE installation Prototype three was tested in the final pilot of POSEIDON. Unlike Pilot 1, diaries were not used due to poor use in Pilot 1. Instead, we had weekly questionnaires for the different components that the new participants were requested to complete. These questions were designed for questions in the following categories: Design and Handling, Fun and Acceptance, and Helpfulness. The questions were this time not open, but instead simple selection between “Completely Agree” and “Completely disagree”. Some questions regarding the different components included generic UI related including whether fonts were appropriate, and whether colour and contrast ensured good readability. In addition, there were specific questions related to only those components including on whether the money handling assistance helps to better distinguish bills in everyday life. Interviews in this pilot were restricted to the first and final visit, as it was proposed that weekly interviews including questionnaires were too taxing on the participants. Many of these questions were more generic including “What did you like about X?” and “What did you not like about X?” Currently, feedback from the pilots is being analysed by our partner, BIS. Feedback from observations generally showed interest in the main navigation support applications including the route creator, HTNS, and mobile navigation applications. Other applications including money assistance show promise, although there were more difficulties in using them (Table 5).
Table 5
Prototype 3
U-C IEDP main loop
U-C IEDP secondary loop
Event type
Outcome
Initial scoping
Interview stakeholders
Q +
Stakeholders indicate importance of customizing routes
U5
HNS feedback modes to be improved
Development Framework revised
Define Required Services
Need of replacing Google Directions identified
Define required IEs infrastructure
A1
Interactive tables presented challenges to configure and use
Issues with computer versions
Initial design and prototyping
Alternative methods to create routes based on Google MyMaps and GPS coordinates extraction
Main development
Interview stakeholders
U6
SUs preferred GPS coordinates automatic extraction and display of information
Design I
A2
Lack of application to support way finding for people with special needs
Implementation and testing
A2
Created customized routes
Verify correctness
A2
Problems with public transport identified
Design II
A2
Check overall prototype with Ethical Framework
IE installation
Interview stakeholders
P2
Product was well received overall
Calendar reached maturity
Development Framework more mature
Equipment validation
P2
Interactive table was not used
Focus on home training and outdoor apps
Software validation
P2
Stakeholders asked for small changes in design (i.e. possibility to drag and drop a button)
Services validation
P2
Some of the stakeholders asked for the possibility to disable the Street View panoramic image
5.4 Final overview
Figure 4 summarizes how the main milestones of the projects were met. It presents the interactions between stakeholders and developers and how these led to an increasingly mature system. Theoretical assumptions were thoroughly tested in different ways with different categories of stakeholders. The observations, suggestions, and results of every interaction were analysed by developers with different outputs overt time. The figure shows one of the possible instantiations of the method presented earlier on in Fig. 1, though in this case it reflects a process which readers will identify shares characteristics with pre-existing software engineering strategies such as iterative refinement, spiral, or agile. The project is portrayed as evolving from the centre of the image outwards in clockwise direction. It shows there were three main iterations linked to the three main prototypes produced. The project was producing a diversity of outcomes which were broadly classified into three groups: software, documentation and hardware. One can classify to any level of granularity required. Stakeholders' engagement led naturally to documents and influenced hardware choices and informed earlier design and software prototype outcomes in the initial scoping stage. The development stage was primarily concerned with software although this software will also come with documentation in the code and the user manuals, and the installation stage mainly produced documents which were used to inform the global iteration of the process. Colour codes were used to reflect the level of maturity of the global system as a whole through the maturity of the single output elements. The mix of colours tends to reflect increasing appearance of maturity evidence towards the end (external lower central part); however, the main visual message is one of a mix of maturity at all times that is precisely consistent with the strategy and expectations of the project. For example, should everything have been green at the beginning and would have evolved steadily into yellow, orange and red would have been indicated an initial settled and mostly unchanging set of requirements which the team pursued until being successfully validated. However, this was not the case in this project. We had some initial hints from our stakeholder consortium partners; however, some of the requirements were revised, priorities changed, some requirements were discarded, and some new were added. This is reflected in the mix of colours and gives evidence that developers listened to stakeholders and were prepared to try new ideas.
The project overall kept an emphasis on mobile support of users, as the main objective of the funding programme was to increase the inclusion of citizens in society so the main overarching support was on facilitating people with Down’s Syndrome to carry out everyday activities outside home. This translated on services to guide them, which were specifically designed for them and then other supportive “apps”, such as to help them with specific practical daily challenges like using public transport, handling shopping lists and money, and more recently, we started developing support for the understanding of food, physical activity, and weight management. There were also “static” services that are designed to be used at home; however, they were all to support whatever the challenges the individual will face outside home. A key enabler was the agenda where activities can be scheduled and the system can then produce contextualized reminders, for example reminding the person with DS of weather-specific clothing (umbrella if rain has been forecast) and relevant objects to the planned activities (books for the school). The home version of the outdoor navigation system allows the setting up of routes and also the training of the route in a “gamified” version. Figure 5 shows some of the activities carried out during the stakeholder engagement activities.
On the developer’s side, we also created tools which helped with identification, design and implementation of relevant contexts, which are generically referred as the “Development Framework”; however, this is not the focus of this article.
Fig. 4
Product evolution through iterations
Fig. 5
Interactions with primary users
×
×
6 The Ethical Framework
An essential component of our User-centred Intelligent Environments Development Process is its Ethical Framework. Figure 1 shows the Ethical Framework as extending to all stages of the process. Different teams can adopt different Ethical Frameworks. Our team adopted eFRIENDS [16] as it has been especially designed for intelligent environments and it results in the embedding of ethics in a practical sense in the product creation itself.
As a result of the use of the eFRIENDS framework in POSEIDON, a substantial percentage of requirements can be directly or indirectly linked to ethical issues: 7 Framework (Fr) requirements, 20 Functional (Fun) requirements, 10 Non-functional (NF) requirements, 4 Hardware (H) constraints, and 6 Design (D) constraints.
The eFRIEND Ethical Framework is based on the following 9 principles:
1.
Non-maleficence and beneficence
2.
User-centred
3.
Multiple users
4.
Privacy
5.
Data protection
6.
Security
7.
Autonomy
8.
Transparency
9.
Equality, dignity and inclusiveness
Those principles are informed by the Intelligent Environments Manifesto proposed by [4] that advocates the development of systems in a manner which is aligned with a number of explicitly defined user-centred principles, especially to: (P3) deliver help according to the needs and preferences of those who are being helped, (P5) preserve the privacy of the user/s, (P6) prioritize safety of the user/s at all times, and (P9) adhere to the strict principle that the user is in command and the computer obeys. Next, we explain and provide examples of how these nine principles materialized in POSEIDON.
Non-maleficence/beneficence POSEIDON aims not only to enhance the welfare and quality of life of its main beneficiaries, but also incorporates measures to avoid any risk of harming the user. Both are equally important objectives driving all aspects on decision-making during the project.
Multiple users POSEIDON is specifically designed for a multi-user environment and incorporates the needs and requirements of various stakeholders, including primary users, secondary users and tertiary users, as explained in Table 1. It is acknowledged that these requirements and preferences may need to be balanced and/or prioritized and that they may change dynamically over time.
User centricity As this article testifies, the POSEIDON project has been one of the co-creations amongst all stakeholders, everyone contributing from their own expertise. Substantial effort was placed on the understanding of preferences and needs of the main users and on the specific features which makes current technology more useful to them.
Reliability Given that users may be dependent on the POSEIDON system outside the home, it must be robust, stable, and reliable. Some examples of requirements which carry this message are: “Fr17: When live, framework components should have robustness and fault-tolerance comparable to non-vital commercial systems”, and “NF11: The system should be available 24/7, except for short periods of downtime for maintenance such as system upgrades”.
Safety and security The use of digital tools provides new important support and also opens up new vulnerabilities, in terms of safety of the individual and on security of the digital system. The same platform also provides help in safety (e.g. geolocation) and security (e.g. antivirus). Examples of requirements related to this principle are: “Fr5: When live, support the safety of the end users”, “Fun2: System should provide immediate access to phone call”, “H9: Device level access security should be present”, and “NF5: Network level security for mobile component”.
Privacy The results of the requirements analysis confirm that privacy is of high importance to potential users of POSEIDON and must be guaranteed in usage outside the home. There is a tension between privacy and safety, and the balance amongst these two is defined by the main user, for example, a PU who does not have legal capacity may have less privacy in benefit of safety, while an older adult living independently will naturally have more privacy rights and most likely will claim it. So, privacy is subjective and hence should be embedded in a flexible way within the system as exemplified by the following requirements: “Fr6: When live, support the privacy of end users. Provide optional user privacy settings to enable customization”, and “Fun10: Users should be able to decide on, and vary, the level of privacy at a specific point in time”.
Data protection While the effective use of POSEIDON makes it necessary to collect and analyse personal data to provide appropriate tools for different situations, data protection principles will be adhered to regarding informed consent for data collection, controlled access to secondary uses of personal data, and storage of (un)necessary data according to specified time limits. “Fr9: Safeguard user data at the server-side with appropriate backup”, “Fun11: Users should be able to decide the type of information stored in the devices used”, and “NF10: Context-related data should be stored for no more than 6 months”.
Social inclusion Amongst the most important requirements to emerge from survey data was the importance of communication and socialization. Social inclusion was in turn found to be closely related to mobility and travel independence, a major factor in feeling independent and less reliant on others. Some examples of requirements used in relation to this dimension are: “Fun15a: First User-level contexts to be considered are: travelling, communicating”, and “D5: Give priority to plans involving public transport”.
Autonomy The survey and interview data suggested a strong wish on the part of the target users to be more independent and less reliant on carers and relatives. Autonomy also means users being able to control technology; hence, POSEIDON is adjustable to individual preferences and personal needs. Some examples of requirements used in relation to this dimension are: “NF1: System should promote users autonomy and independence”, “Fr8: Support for optional interface customization to suit the end-users needs”, “Fun9: The system functionality should be customizable”, and “D7: Special consideration given to the way time is represented and communicated”.
Transparency To be in the control of the system, users need to understand its (re)actions, feedback and possible uses. Potential weaknesses, limitations and vulnerabilities in the POSEIDON system will be made transparent to users, including system operations, data collection and use, and surveillance activities. Some examples of requirements used in relation to this dimension are: “NF8: System should be open and transparent to users with respect to expected system functionality and weaknesses”, “Fr11: Documentation must be provided to enable project participants and third parties to develop POSEIDON components”, and “Fun31: Provide confirmation that system has processed a request so user knows what is going on”.
Equality of access POSEIDON has been designed simply enough so that it can be used by the widest possible range of users with different levels of capabilities in all dimensions of life. Some examples of requirements used in relation to this dimension are: “NF9: The system should provide help regardless of age and technical ability”, “H1: Cost of tablet should be less than ...”, “NF17: Motivating to use”, and “D2: Interface preferably based on symbol, icons and animations”.
The eFRIENDS methodology has been developed through several projects in this area to benefit different groups of citizens, and in POSEIDON was also approved by the Advisory Committee. Readers can find full details of the eFRIENDS methodology in [16].
7 Conclusions
This paper reports on the application of the User-Centred Intelligent Environments Development Process (U-C IEDP) to the co-creation of a system which fosters inclusion of individuals with special needs into society.
The project exercised the U-C IEDP in several ways, through its micro- and macro-loops. Core to the method used is the frequent interaction with stakeholders. We provided details of the nature of these interactions, their relation to the different stages of U-C IEDP, and also of their effect in the services being produced. This has kept the specific related user groups informed of the evolution of the project. It has allowed different project stakeholders to iterate until each of them has secured some level of benefit from the project. For example, primary and secondary users voiced needs, preferences and concerns, and the companies involved are more confident their product will be satisfactory for the intended market niche. Developers on the other hand feel the product has higher possibilities of being well received and adopted by the relevant sections of society.
The application of the methodology was overall successful, fulfilling the needs of a diversity of stakeholders and flexibility to adopt promising options appearing at different stages and to side-line others when the evidence was not favourable.
This methodology requires stakeholders willing to engage and developers with capacity to listen. This can be achieved in various degrees of intensity according to the characteristics of the project; however, the ethos is that given the complexity of the technology considered and the potential impact in peoples lives, it is better to avoid surprises so stakeholders should be kept somehow in the loop at key stages. This does not mean information travels unidirectionally from stakeholders to the developers; instead, it means that a process is put in place to secure a dialogue with stakeholders and developers so that together with developers being respected as the technical experts, stakeholders are respected as the experts on what they need.
Specific tool support is still lacking, and developing tools which can help automating and tracking the different stages will help to apply this methodology more efficiently. This is one of the main current objectives in our research group.
Acknowledgements
The research leading to these results has been partly supported by the POSEIDON project funded by the European Union (FP7/2007-2013) under grant agreement n 610840.
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
