1 Introduction

The personal abilities and societal changes introduced by the increasingly widespread use of information and communication technology (ICT) have been considered as a facilitator of the inclusion of certain groups, especially of people with disabilities and older adults. At the same time, however, it has increased the need for digital literacy of all society members in order to maintain their daily independent living (e.g., education, employment, commerce, health services, etc.) both at home and at workplace. Recent research has shown that complexity of technology combined with inadequate technical assistance, high setup costs and exclusive design practices actually generates new barriers for those with special needs (people with disabilities, low literacy, elderly, etc.) [1–4]. Furthermore, the worldwide demographic trend indicates a constant increase in the elderly population that is associated with an increased desire for independent living and is highly affected by several factors (primarily functional and cognitive impairment, chronic diseases, reduced social activity and connectivity, reduced physical activity) that decrease their abilities to cope with emerging technologies [1, 5, 6]. As a result, an increasing percentage of the population needs assistance services for a wide range of activities related to their independent living (e.g., health management, social care services, technical support, leisure activities, etc.) [6].

The assistance services can be delivered either by humans or by machines directly to the consumer (end-user) or to some other home ICT infrastructure (e.g., assistive device), resulting in various supplier–consumer configurations: human-to-human, machine-to-human, machine-to-machine, etc. Even in the case of human-to-human supplier–consumer configuration, in many cases ICT can be used as intermediary infrastructure for assistance service publication/marketing or for remote delivery of the service. One example is the crowd-based service employed by the Amara project to offer captioning and subtitling services for videos [7]. Recently, cloud computing and the emerging solutions developed for enabling the Internet of things (IoT) have made possible the remote or enhanced delivery of assistance services to people in their own home [8] and introduced new types of services and service delivery paradigms (i.e., crowd-based approaches) [7]. Such specialized or general assistive services, developed using emerging technologies and/or payment models, can contribute toward the widespread availability of cost-effective services and applications better fitted to the needs of small groups, the so-called tails and tails of tails of the general population [9].

However, the intricacies of cloud hosts (virtual machine) management, code distribution, payment policies and resources management make the development of cloud scalable services and applications a rather cumbersome and difficult task. Platform-as-a-Service (PaaS) solutions, such as Windows Azure [10] or Google App Engine [11], although offering the developer support and certain developing tools and resources, are characterized by a tight vendor lock-in policy, limited control over deployment options, and still require a high-level expertise and platform-specific knowledge to be able to take advantage of their full potential. An infrastructure that would enable small ICT players (i.e., web entrepreneurs) and other actors (e.g., caregivers, associations of people with disabilities, etc.) to easily set up new assistance-on-demand services, by taking advantage of the novel cloud computing offerings, and at the same time more efficiently addressing the needs of specific target groups, would provide the means to reduce both the development and the operation costs for assistance services.

The current work presents the design of a novel open-source platform which enables diverse stakeholders (e.g., family members, professionals, caregivers, associations, etc.) to easily register and offer over the web assistance-on-demand (AoD) services catering to individual needs of persons with disabilities or people who are otherwise at risk of exclusion. Such services can then be delivered to the end-user using ICT or with physical presence (machine- or human-based assistive services), depending on the type of service offered. The AoD platform enables persons with disabilities to access a wealth of different human, or device services, by filtering the available solutions based on their preferences and by suggesting the best possible matching service for any given need. It also allows different patterns of assistive services usage, continuous or interruptible, periodic or random (on-need) and enables the use of different charging models (e.g., pay per use, pay per item, or any other), thus enabling the service provider to define both the type of service and the charging model during service registration procedure. Furthermore, the AoD platform is also offered as an open-source development platform that can be easily customized by interested stakeholders (e.g., associations of people with disabilities) to fit the needs of specific target groups that such stakeholders represent or assist. For instance, an association of people with vision impairments may use the open-source AoD platform to create an AoD instance offering assistance services specifically addressed to its members: blind or partially sighted individuals. Customization/instantiation of the AoD platform requires little development effort from the side of the user-stakeholder thanks to the deployment of an easy-to-use administration panel. Through this panel, the user-stakeholder is able to perform a number of customization actions including activation or deactivation of specific AoD features, depending on the AoD instance that they want to create, changing the look and feel of the AoD (e.g., logo, colors, contrast, fonts, language, etc.), modifying the categorization of services offered, and many more.

Compared with the existing platforms, the major contributions of this AoD platform are the open and inclusive character, and the enhanced configurability and manageability, both at the business (financial models, application components) and at the platform (non-functional services, communication protocols, etc.) levels. This is achieved through the exploitation of the Model–Template–View (MTV) of the Django framework [12] to implement the various platform layers for easy and efficient registration and online offering of assistance services.

The main characteristics of the AoD infrastructure, with regard to target user groups, types of services and other features and functionalities, were initially drafted by analyzing various existing assistance services covering various application domains (e.g., health, travel, domestic, leisure), such as Amara [7], RememberItNow [13], Castlight Health [14], HealthTap [15], Microsoft HealthVault [16], WebMD [17], NHS [18], GreatAupair [19], Care4Hire [20], DomesticHelpInIndia [21], CareAssist [22], Quikr [23], GetMaid [24], TaxiBeat [25], BeMyEyes [26], EssentialAccessibility [27], Booking [28], SongKick [29], BandsInTown [30], E-Food [31], Lotsa Helping Hands [32], You Describe [33]. Further details on the analysis of existing assistance services are presented in Sect. 2.1.

Section 2.2 introduces the overall infrastructure being implemented in the Prosperity4All project [34], part of which is the proposed AoD platform, with details on the dependencies and benefits.

Section 3 describes the procedure followed in order to determine the functional requirements of the AoD platform, which represented the ground for the design and prototype implementation (Sect. 4) and evaluation with end-users (Sect. 5). Section 4 provides details on the implemented functionality and the architecture of the AoD platform and presents examples of AoD instantiation prototypes and user interface usage. In Sect. 5, the evaluation with end-users is presented, including the study design details and results. The paper concludes with a discussion of challenges encountered and the main achievements and limitations of the proposed AoD infrastructure.

2 Technical background

2.1 Assistance services

Service specification analysis was performed on a large number of assistance services and platforms and indicated that the most popular application domains for assistance and on-demand services are: health care and monitoring, domestic/daily life support, transportation and travel services, and various leisure activities (Table 1). Some of the services and respective web-based platforms offering them may cover two domains (e.g., health and daily life), especially those targeting daily life and leisure activities. Table 1 also presents the targeted user groups, showing that the services address the needs of a large number of user groups. The types of services supported by the analyzed solutions are further detailed in Table 2 and considered for the derivation of the functional requirements of the AoD platform. Table 3 presents the analysis of types of user profiles supported by the selected assistance services, along with built-in options and features (e.g., dashboard type, configuration options, financial support, etc.). An important functional aspect for the setup and identification of cost-effective assistance services for people with special needs, the flexible trade-off between multi-criteria QoS and charging models, which we call “try-different” infrastructure, has been barely considered by the analyzed services.

Table 1 Application domains and target user groups covered by existing assistance services and platforms
Full size table
Table 2 Service types supported by the analyzed assistance services and platforms
Full size table
Table 3 User profile management, dashboard options and other characteristics of the analyzed assistance services and platforms
Full size table

2.2 AoD platform as part of a larger infrastructure for accessibility solutions

The AoD platform is implemented in the context of a larger inclusive infrastructure, the DeveloperSpace being developed by the Prosperity4All project, which in its turn builds on and expands the Global Public Inclusive Infrastructure (GPII) [35] in order to create a self-sustainable and growing infrastructure, where developers, implementers, consumers, prosumers and other directly and indirectly involved actors (e.g., teachers, caregivers, clinicians) may interact with and play a role in its viability and diversity.

The GPII is a cloud-based software and service enhancement of the global broadband infrastructure designed to allow users to invoke and use access features in a cross-platform and device-independent fashion while, at the same time, improving the interoperability between mainstream and assistive technologies. It is designed to support different delivery models in order to address the different platforms, degrees of lockdown and types of adaptation a person requires, as described in the following:

  1. (1)

    User agent-based solution, for access solutions installed and running on the user’s computer/device, including access features built into the operating systems or browsers, downloadable add-ons to platforms, commercial assistive technologies installed on a computer (e.g., FireVox, LowBrowse plug-ins, IBM Home Page Reader, etc.);

  2. (2)

    On-demand web services, which provide transformations on demand when called automatically from content, by a user or by other web services;

  3. (3)

    Proxy-based transcoding, which is represented by proxy services that sit between the user and the content and interpret or modify its presentation on its way to the user;

  4. (4)

    Web-based user agents, which include web-based access technologies that can be used anywhere, from any Internet-enabled device (e.g., WebAnywhere [36]).

The infrastructure being developed by Prosperity4All, including the AoD platform, expands the GPII with new strategies for developing accessibility services; it also introduces a new approach to accessibility solutions development addressing marginal consumer needs, most notably the needs of people with disabilities [37, 38]. The connection between the Prosperity4All infrastructure and GPII is shown in Fig. 1, where the position of the AoD platform is indicated as part of GPII. Further details on the particular stakeholders, projects and components/modules building up the GPII are provided at http://gpii.net/.

Fig. 1
figure 1

Prosperity4All infrastructure, including the AoD platform, positioned in relationship to GPII and corresponding projects implementing various aspects of GPII

Full size image

The AoD platform/infrastructure benefits from other major components of the GPII infrastructure, such as the developer space (DeveloperSpace), the Payment infrastructure, the Unified Listing, the Feedback and Feed-forward mechanisms, Security infrastructure, and others, as explained below.

The DeveloperSpace is a collaborative environment being developed by the Prosperity4All project as part of the GPII. Its purpose is to support developers in efficiently finding, using and contributing to inclusive software development, together with community resources and documentation. The repository of tools and parts of the DeveloperSpace provides various technical solutions and integration paradigms, along with design guides, technical documentation, licensing templates, multi-modal content creation tools, tutorials and work samples. Furthermore, it connects suppliers with end-users to enable co-design and early testing of solutions. The AoD as an open-source development platform is offered through the DeveloperSpace. Moreover, through the DeveloperSpace, the AoD service supplier has access to a large number of building blocks and tools which can be used to build the service itself and/or to make the service more accessible.

The Payment infrastructure enables the online payment of (multiple) services offered by different suppliers following different charging models; it also allows crowd-sourced financing of services by supporting micro-payments and bids upon need. The AoD platform offers integration with the Payment infrastructure. Therefore, a service supplier offering services through the AoD platform does not need to create and maintain their own charging and Payment infrastructure. Moreover, there are end-user benefits by being charged per usage: micro-charges per customer and per AoD service supplier are accumulated in the charging and payment system, while billing occurs either when a certain threshold is reached or on a regular basis. Thus, end-users avoid the burden of receiving multiple bills from many different AoD suppliers.

The Unified Listing (UL) database is another component of GPII. It provides the means to list at the international-level assistance solutions and services. Loose integration of the AoD platform with the UL may allow for synchronization and exchange of information between the AoD and UL. Nevertheless, the UL does not provide the means to build an assistance service, but only to market it.

The Feedback and Feed-forward mechanisms, together with the quality-of-service rating and searching functionality of the Prosperity4All project, provide the users with the necessary tools to ensure, monitor and assess the quality of the assistive services published through the AoD platform, taking into account also the post-engagement of the users (e.g., multi-modal ways to rate listed services, review writing, question and answer support, etc.).

Finally, the Security infrastructure of the Prosperity4All project undertakes the functionality of user identity and access management for all infrastructure-integrated solutions, components and platforms, including the AoD platform, thus providing single sign on without disclosing personal information to different service providers.

3 AoD platform requirements

The identification of functional requirements for the design of the AoD infrastructure was iteratively fine-tuned through the definition and analysis of representative use cases. In a first step, an initial user requirements set was derived through the analysis of the main actors and stakeholders that are expected to interact with the AoD platform. This set of initial requirements was enriched and fine-tuned through the definition of detailed interaction scenarios (use cases) derived for representative users (personae) of the various stakeholder groups [39]. The use cases were validated with target stakeholders to identify any missing user requirements, taking into account the open and generic character of the AoD platform. The refined use cases allowed for the definition of the user requirements, which were further analyzed to derive the functional requirements of the AoD platform.

3.1 Actors and target stakeholders

The generic AoD platform will be used by a wide variety of organizations and stakeholders, each trying to address the needs of different end-user groups; thus, it is highly important to provide an open-source scalable solution. Considering the aims of AoD and the overall GPII infrastructure to which it belongs, the AoD has to be easily configurable to form a gateway for all potential assistance services; it has to be easily set up and operated by different organizations and small groups so that the group members build, find and access the services of their interest. In addition, the AoD platform has to be simple to install/operate/use and to support a large number of users and services with diverse characteristics.

The identified main actors of the AoD platform are: (a) the assistance service providers and suppliers, i.e., entities producing either human/crowd or digital services and offering them for free or for a price through the AoD platform; (b) the end-users, acting as service consumers; here, we distinguish between those interested in consuming services for themselves (e.g., individuals with disabilities, older adults, etc.) and those interested in purchasing or setting up assistance services for the individual(s) that they care for (caregivers); (c) organizations (e.g., associations) that use the AoD open-source platform for setting up an own AoD instance that will specifically target the needs of the organization’s members; for this user category lowering development costs in terms of time and effort is important; and (d) parts of the GPII infrastructure (e.g., Security infrastructure, Payment infrastructure), with which the AoD integrates to provide the corresponding functionality. An overview of the main actors is provided in Fig. 2.

Fig. 2
figure 2

Main actors in the AoD environment

Full size image

While different classifications of disabilities may be found in the literature, the Web Accessibility Initiative (WAI) of W3C has developed a single shared standard for web content accessibility [40], which has been adopted for the implementation of the AoD design. For each disability type a set of potential difficulties in efficiently using the AoD have been identified and are presented in Table 4. The analysis of the identified difficulties, along with the four accessibility principles (perceivability, operability, understandability and robustness) and the corresponding guideline defined by WAI, has contributed to the identification of more generic functionality requirements with respect to the AoD design (Sect. 3.3).

Table 4 Potential difficulties in using the AoD platform for each disability type
Full size table

3.2 User groups, personae and use cases

The analysis of the main actors and stakeholders who are relevant to the AoD environment, as presented in the previous section, establishes three major groups of end-users:

  • User Group 1 includes service suppliers/providers and service developers;

  • User Group 2 includes service consumers, such as people with disabilities, older people, employees with different skills and expectations, caregivers, etc.

  • User Group 3 includes public or private organizations, such as communities or associations of people with disabilities in different countries.

For the identification of more specific user requirements for the various user groups, a preliminary online survey (adapted to each group) and semi-structured interviews were used to derive potential use models for the entire DeveloperSpace functionality, including the AoD platform being developed by the Prosperity4All project. Each use model consists of a user persona (description, user states and context maps) and the baseline use cases (narrative and stakeholder maps) identified for each persona. The usage scenarios and acts, derived from the narrative of each use case for the AoD platform, have been further detailed, analyzed and extended for all relevant personae, to further expand the list of design requirements.

Examples of usage scenarios include user registration and profile management, service registration and management, listing of assistance services, support of multiple charging models, using the AoD platform to produce an organization-specific AoD platform instance meeting the needs of specific groups that belong to the organization, etc. The potential interaction acts are further specialized, depending on the personae. For example, in case of user registration and profile management, the following cases have been identified: service consumer registration of user with multiple sclerosis; service provider registration with low visibility problems; registration of novice service provider; registration of user with severe visibility impairments; profile management for user with balance disorder; profile management for service supplier with low visibility problems, etc. The scenarios and acts are mainly stories expressed from the end-user side that do not reflect the system’s activities; thus, they have been broken down into use cases, which take into consideration both the user experience and the technology part. The specification of each use case includes the storyline, goals, actors, components, conditions (pre- and post-) and trigger events. The uses cases identification for the user registration and profile management scenarios is shown in Fig. 3.

Fig. 3
figure 3

Use cases diagram for the user registration and profile management scenario

Full size image

An evidence-based approach was adopted in order to collect the user needs and wants as well as to define the functional requirements for the AoD platform. An international survey was conducted with potential users of the AoD platform ranging from individuals with access needs, developers, service providers and representatives of end-user organizations. The results were used to shape the use cases and the relevant scenarios and subsequently select the functionalities of AoD listed in Sect. 3.3.

3.3 Functional requirements

The mediator role that the AoD platform plays between the various actors and target stakeholders, including services, service suppliers and developers, imposes a set of high-level requirements with respect to functionality design:

  1. 1.

    Implement assistance service search considering end-user needs and preferences;

  2. 2.

    Implement service rating and sorting according to diverse criteria;

  3. 3.

    Implement zero/default configuration options to support non-professional users with disabilities;

  4. 4.

    Support “try-different” concepts for each service search through a set of attributes, including charging model, service supplier;

  5. 5.

    For non-free services, upon service selection by the consumer, the AoD platform communicates with the Payment infrastructure for notifying on the selection and activation of payment procedures;

  6. 6.

    Implement usage monitoring tools that enable flexible and complex billing functionality;

  7. 7.

    Support flexible and easy configuration of a network of services addressed to the same consumer, even by non-ICT specialists;

  8. 8.

    Support high-quality multi-modal technical support to ensure service acceptance;

  9. 9.

    Technically support novel employment models to the mutual benefit of employer and employee. An example of novel employment models can be a community of assistants providing a certain service to consumers;

  10. 10.

    To users who cannot find services meeting their needs among existing services offer the option to initiate, participate and place offerings for new service(s) creation through micro-funding user-bid processes (e.g., connect to a crowd-funding platform).

The potential AoD usage difficulties (Table 4) and the implementation of the WAI accessibility guideline have imposed the following generic requirements:

  1. 11.

    Support Web Content Accessibility Guidelines (WCAG) 2.0 level AA accessibility and level AAA where possible;

  2. 12.

    Support different output modes (screen, audio, refreshable Braille display) and output customization (different format, font size, screen contrast);

  3. 13.

    Support views of different complexity/simplicity levels.

The variability of potential roles and usage contexts among the user groups of the AoD platform results in the following requirements:

  1. 14.

    Support the user groups through different dashboards/views, further customized depending on the subgroup the user belongs to;

  2. 15.

    Use open-source tools for the development of the AoD platform;

  3. 16.

    Build the AoD platform to be as generic and flexible as possible, enabling use and customization in different contexts (e.g., leisure, daily life, education, etc.) and by different organizations with little development effort;

  4. 17.

    Support various service types such as (a) human services—allow for service registration to AoD, charging options, consumer feedback, etc.; (b) machine services—software services offered by various suppliers (companies/individuals/organizations/communities); (c) crowd-based services to facilitate contribution from volunteers (e.g., Amara project);

  5. 18.

    Support a rich set of service characteristics and categorization to allow proper description of services of all types;

  6. 19.

    Support various charging models, such as pay per use, one-off payment, pay per day/month of use, etc.

4 AoD platform design

To address the requirements elaborated in Sect. 3, the required functionality has been defined and analyzed in order to design and implement the AoD platform, using state-of-the-art technologies. The AoD platform is distributed in open-source format [41]. An AoD platform demonstration instance, including all functionalities presented in Sect. 4.1, has been configured and published on the web for demonstration, test and evaluation purposes [42].

4.1 AoD functionality

The presented AoD generic platform implements functionality which meets the needs of the target groups previously discussed and provides the means to implement assistance services which potentially outperform existing similar solutions when targeting the requirements of people with special needs. The high-level functional components of AoD include:

  • Flexible and efficient service search. The AoD elementary goal is to allow users to search for assistance services. The AoD platform presents all the registered assistance services to service consumers as either a list or a set of blocks, depending on the options selected by the user. Furthermore, the platform provides the capability to any consumer (individual or organization’s representative) to look for a service of his/her interest either by entering some keywords or by giving feedback in some filters (e.g., price range of service, type of service, quality of service, etc.). When the user finds the service he/she looks for, he/she can select it and access more details about it. In this case, the novelty and added value of the AoD platform lie on a set of factors; specifically, (a) it supports both digital and human-based services, i.e., software- or web-based solutions as well as services offered by humans (e.g., nurses, housekeepers, volunteers, etc.), (b) the services are organized in categories (e.g., daily living, health, entertainment) which are further divided into subcategories (e.g., daily living is divided in food services, caretaking, transportation and others); these categories are modifiable and can be (re)defined during AoD platform instantiation and thus be tailored to the needs of the target user group; (c) the service search can be narrowed down employing cost and quality criteria; the user can define boundaries in terms of minimum and maximum acceptable cost and quality (e.g., based on feedback provided by other service users); (d) free text keywords can also be used to search for a service; (e) geographical location filtering of services is also supported to improve the efficiency of the search (e.g., the user may define their location so that the services offered in this area are returned as a result of searching); (f) a try-different functionality based on a flexible cost versus quality-of-service (QoS) rating mechanism has been implemented, as explained hereafter. The users who have used a service are allowed to rate them. The number and type of rating scales are modifiable and are defined during the AoD instantiation by the administrator. On/Off or multiple rating scales can be selected, each contributing by a configurable weight to the overall rating of the service. For example, a user can rate a service with respect to usability, quality and user-friendliness. Based on this information, the list of services that match the user’s search criteria can be ranked based on cost or on QoS criteria. Moreover, the user can define a threshold both for cost and QoS in order to narrow down the service search results. In case that the user has selected to consume a certain service (say service A), which finally does not meet his/her expectations, on the dashboard the user can use “try-different” button. This will trigger a new search with the same parameters as the one that led to service A, but further restricts the results to services with QoS higher than that of the previously selected service;

  • Easy service registration and management. Any service provider is able to easily register a new service entering a block of information (using a wizard). Two different wizards are offered for experienced and novice users. Additionally, AoD offers to service providers (a) a Security and Payment infrastructure, i.e., they do not need to set up any payment gateway since they can use Prosperity4All’s payment functionality, which relies on PayPal (available worldwide); (b) the possibility to upload multi-modal material related to their service (i.e., upload documents, videos), or even initiate community-based support services); and (c) the option to communicate with other service suppliers through a dedicated social networking functionality. It also provides each provider with a management panel for their offerings where they can examine the analytics related to the use of their services;

  • Multi-modal (including community-based) technical support. AoD platform hosts a module, called multi-modal technical support (help center), that provides helpful guides (for instance documents, videos, etc.) to the registered users related to the platform and the services it offers. Additionally, technical support is also offered as a service through the platform. Specifically, AoD supports community-based and professional technical support for the AoD platform and individual services offered through the platform as well: A user can initiate/register a technical support service and, optionally, indicate that this is a community-based service; next, each person that intends to also provide technical support on the same topic can join this community. When a prospective consumer needs technical support to use the service, AoD presents him/her with the list of the online members of the corresponding community so that the consumer can select the person that they will contact to get technical support. This community-based service can be offered either by volunteers or by professionals. Other conventional technical support offerings (e.g., by only one professional or by the service providers themselves for their own services) are also supported;

  • Easy assistance service definition for caregivers. The AoD platform allows a caregiver (nurse, doctor, family member, volunteer, friend, etc.) to create by themselves a personal assistance-on-demand network of assistance services for someone he/she provides care to. The AoD guides caregivers through a wizard to select assistance services from a set of categories related to a person’s life activities to ensure that no necessary assistance service will be neglected. The services selected by the caregiver form a network of assistance services (NAS) will be presented to the end-user—consumer, who makes the final decision with respect to their appropriateness and completeness in relation to his/her needs and preferences. The caregiver can also configure a specific selected service. It is worth stressing that for a person to act as a caregiver, permission from the service consumer is necessary;

  • Social networking. AoD currently incorporates social networking functionality which intends to support primarily novice users to get connected with their peers and share experiences and good practices;

  • WCAG 2.0 AA support (or AAA, whenever possible). AoD supports the highest level of accessibility according to W3C standards so that the largest possible number of service suppliers, service consumers and caregivers with any type of disability can use it. Also, any user can personalize the GUI layout, e.g., fonts’ size and style, template color, etc.

  • AoD platform instantiation. Developers and organizations with special interest have the possibility to instantiate the AoD platform on their chosen deployment infrastructure and configure it, as platform administrators, to allow other networked service suppliers (volunteers and/or professionals) to set up dedicated assistance services.

4.2 AoD architecture

The high-level architecture of the AoD platform, as well as the actors interacting with it, are shown in Fig. 4. The architecture consists of two major components, here simply called the front-end and the back-end. The front-end represents the actual graphical user interface (GUI) of the AoD platform, which allows registered users to navigate through the platform and select modules to set up an assistance service or interact with in order to browse services, rate them or ask for support. Each module is responsible for the presentation of information relevant to one of the above-described functionalities. The back-end consists of two fundamental components, i.e., the assistance-on-demand application (AoD app) and the AoD Application Program Interface (AoD API).

Fig. 4
figure 4

AoD high-level architecture

Full size image

The AoD app consists of three high-level layers, and its implementation is based on the Django framework [12], exploiting the Model–Template–View (MTV) software architectural pattern as described below:

  1. a.

    View constitutes the Business layer of the back-end architecture and describes which data are presented. This layer consists of the Universal Resource Locators (URLs) and views modules. The former describes a set of AoD platform’s URLs, and the latter contains the business logic of the application. Each URL is served by a method included in the views;

  2. b.

    Template constitutes the Presentation layer of the architecture and describes how the data are presented;

  3. c.

    Model, which depicts the Data layer, stores data in the Data Resources component using the Django object-relational mapping (ORM) that maps the data from the relational way to object structure and vice versa.

The AoD API component interacts with the Data Resources component and provides a set of REpresentational State Transfer (RESTful) web services to external applications. This interface is used mainly for integration purposes with other applications and services, such as those that are part of Prosperity4All (i.e., the Unified Listing component, DeveloperSpace) or other AT applications and services. Parts and components of the AoD platform, as well as the AoD platform as an integrated whole, are shared as building blocks in the DeveloperSpace. Through the DeveloperSpace they can be accessed, downloaded and reused for faster implementation of any assistive service or other Assistive Technology (AT) solution that needs such components.

As shown in Fig. 3, the AoD infrastructure communicates (a) with the Identity and Access Management (IAM) infrastructure of the GPII, developed in the framework of Prosperity4All; this provides functionality for user authentication, user authorization—supporting the different roles foreseen for AoD users—and access management and (b) with the Payment infrastructure, also part of the GPII developed in the Prosperity4All project. Both the IAM and Payment infrastructures rely on well-established technologies and solutions, namely the OpenAM and PayPal gateway, which have been customized based on the AoD needs in the framework of the Prosperity4All project.

Since the AoD platform is implemented using the Django framework, the existence of the Python modules/packages and Django package is required in the back-end part. Another back-end component is the Web Server Gateway Interface (WSGI), which is used as a universal interface between the Apache web server and Django web application. The Apache web server provides a secure, efficient and extensible server that serves HTTP services in sync with the current HTTP standards.

Finally, the File System component of the back-end is responsible to store and share any type of files, documents and objects, which might be needed by any of the assistance services set up using the platform, or for other system file activities (e.g., testing, revision, etc.).

Summing up, the development of the AoD platform has been based on (a) Python, Django framework, Apache web server, WSGI server for back-end services, (b) HTML5, CSS3, JavaScript (jQuery, Angular), Bootstrap framework for UI development, (c) Django rest framework for REST API implementation, (d) Django packages for code analysis, (e) Django (and Python) packages for testing, (f) Visual Studio (community edition) as the development environment and (g) Git as the main source control system.

4.3 AoD instantiation, prototype interface and usage example

The administrator of any new instance of the AoD platform is offered a set of options to configure the instance based on specific needs through a user-friendly platform management panel, as shown in Fig. 5. The AoD offers a rich set of configuration options, including custom definition of service categories to be supported and modified (add, update, remove) according to the organization’s needs; activation/deactivation of a number of functional (sub)components, such as the support of carers, the support of QoS rating and relevant filtering options, and the crowd-funding support; custom setting of the instance metadata, logos, brand name, the languages that the specific instance supports, the contact attributes of the application (Skype, phone number, email account, address, etc.), the match between the AoD instance and the social networks of this instance (Facebook, Twitter, LinkedIn, etc.), and so on. With respect to specific AoD instance user interface and presentation attributes, the administrator has the option to select a presentation theme from the predefined ones or generate new themes. (Basic LESS/CSS experience is required.) Additionally, the administrator (or a dedicated translator) has the possibility to manage the translation of the text used in the specific AoD instance user interface, which is divided in two pools: text data that are given as input in the AoD instance from all users (e.g., the service descriptions) and static text data which are included in the JavaScript, HTML and Python files of the platform. Other configurable aspects of the AoD platform include:

Fig. 5
figure 5

AoD configuration options for the initiation of a new instance of the platform

Full size image

  • The multi-modal help center management, consisting of thematic areas public and/or private. Each thematic area includes articles, and each article may comprise of plain text, multiple audio/video files and documents such as PDFs, office documents;

  • Web robots [1] management, where the administrator can set up rules for the web robots (also called crawlers);

  • Cookie policy management, allowing customizing the context of the cookie policies from the administration panel in all available languages (template provided according to the European Commission legislation). The AoD platform keeps track of some user preferences such as the desired language and the presentation theme, to achieve optimized browsing experience for each user;

  • Integration with Google analytics, which is supported by default, to track the usage traffic in the platform. In addition, for more experienced users, integration with a set of analytics tools is feasible. For Google analytics setup, the administrator can retrieve a dedicated key from Google analytics service and import it in the platform. A basic programming experience is required for the completion of this task.

Instantiation of the AoD platform has been already implemented in the context of the Prosperity4All project, either for testing/evaluation purposes or for real-life usage, thus resulting in multiple prototypes. An example prototype (real-life instantiation of the platform) which is based on the technical support AoD platform option has been implemented by Lifetool, and its user interface is presented in Fig. 6.

Fig. 6
figure 6

Example of AoD platform instantiation by Lifetool

Full size image

The Prosperity4All demonstration prototype [42], used for testing and evaluation purposes, has been iteratively refined, and the following figures showing a usage example are screenshots of its current version. The example is based on the use of the AoD prototype by two fictive users (personas), Alice—a novice sign language translation service provider—and Mark—a service consumer with hearing problems.

Alice, a novice service provider, would like to offer her services as a sign language translator to people with significant hearing impairments through the AoD platform. User registration is a prerequisite (both for providers and for consumers) in the implemented AoD demonstration prototype. After registration and authentication Alice is directed to her simplified dashboard, with only two options: “The Services I offer” and “Add New Service.” She selects the option to register the service she intends to offer: translating spoken language into sign language, every working day. She names the service “BeMyEars” and offers it through Skype for a lower fee compared to other providers which seem to have higher level of expertise. To avoid confusing her, the AoD prompts Alice to fill in the information in a step-by-step approach (see Fig. 7), offering a help link for each field that has to be filled in.

Fig. 7
figure 7

New service registration interface of the AoD demonstration prototype

Full size image

Mark, who has hearing problems, has been an AoD service consumer for quite some time now. He has planned a work meeting on next Tuesday from 10.00 to 16.00, and few days earlier he uses the AoD platform to search for a sign language translation service to support his communication activities during this almost full-day work meeting. He can either enter keywords or use any of the filters that appear in the left side of the screen to narrow down the search (see Fig. 8). He selects daily life in the categories option, and caretaking/special needs from the subcategories. He also uses the service “type” option to select “human-based services,” as he prefers a human assistant over automatic sign language translation. Subsequently, he uses the “payment policies” button to select the “paid” option, as he feels that this usually leads to higher-quality services. Finally, he uses the location option to indicate where he wants the service to be delivered. When the list of services matching his options is presented in the AoD interface, he chooses to rank the services based on price from low to high. He selects the “BeMyEars” service, which seems to be the best offer for his needs.

Fig. 8
figure 8

AoD user interface for service search and advanced filtering options

Full size image

5 AoD prototype evaluation

An evaluation framework was established for the overall infrastructure built in the Prosperity4All project, including the AoD platform. It clearly delineates important dimensions for each evaluation step, such as the content, the interactions to be captured, the involved actors and the applied methodologies. The evaluation framework is adapted to the specific needs for testing and evaluation of each major DeveloperSpace infrastructure component [43]; this process was also applied in the case of the AoD platform evaluation. The main aim was to investigate the usefulness and usability of the main AoD features in an iterative manner by each targeted group. Two evaluation iterations were conducted, and two hypotheses were investigated: (a) “Is the UI usable by individuals with certain access needs (see Table 4)?” and (b) “Are the functions useful and user-friendly for each targeted group?”. The same study design method was applied in both iterations.

5.1 Study design

In the scope of the evaluation, the implemented AoD demonstration instance (called platform prototype or prototype hereafter) was deployed in a cloud server and different types of users, spanning among the actors identified in Sect. 3.1.

5.1.1 Participants

Pluralistic walkthrough sessions were organized by Prosperity4All organizations not directly related to the design and implementation of the AoD platform, with 21 participants in total (i.e., nine and twelve participants, respectively). The diagrams in Fig. 9 present the main characteristics of the sample for the first (left) and second (right) iterations.

Fig. 9
figure 9

Sample characteristics for the AoD prototype evaluation

Full size image

Two facilitators were always present for investigating how the existing functional prototype supports the first-time user while trying to complete a scenario (i.e., create an account, edit the account, add (search for) a service). Different scenarios were tested in each phase. Each session lasted for two hours. All participants consented prior to their participation (i.e., signed informed consent forms). Participation was on a volunteer basis with no compensation. The focus and distribution of participants over the AoD user groups are described in Table 5.

Table 5 Focus and user groups involved in the two phases of AoD platform testing
Full size table

5.1.2 Design/procedure

Pluralistic walkthroughs allow different users to interact with the technology under study and among them while completing the redefined scenarios. The aim was to identify usability issues by all the potential actors of the AoD platform. Participants were firstly introduced to the aims of the study, and a brief presentation was given. Each session was recorded in order to capture participants’ discussions and think-aloud processes. Scenarios were all presented and tested in the same order because they actually emulated the first interactions of the specific user group with the AoD platform. The same design was applied in both iterations.

5.2 Results

The results gathered and presented in this section fall under four categories:

  • Main usability issues that were primarily communicated to the development team in the form of sketches (see example in Fig. 10) and are also summarized in Table 4;

    Fig. 10
    figure 10

    Example of visual recording of user interface usability issues during evaluation

    Full size image

  • Primary and secondary user interface interaction points (Fig. 11 and Fig. 12);

    Fig. 11
    figure 11

    Primary and secondary interaction points with the AoD main landing page per user group

    Full size image
    Fig. 12
    figure 12

    Primary and secondary interactions with the carer dashboard

    Full size image

  • Overall usefulness, ease of use and comprehensibility (see Fig. 13 for a comparison between the first and second iteration phases);

    Fig. 13
    figure 13

    Comparison of usability attributes between the first two evaluation phases per user group

    Full size image

  • Main inferences drawn from the analysis of comments and think-alouds (formative analysis) and presented below per user group;

Data collected and processed included pre- and post-questionnaires and data collected during the session (e.g., comments, think-aloud, etc.).

5.2.1 Main usability issues

Usability issues reported by users were pinned on screenshots of the UI and shared with the development team in order to speed up the improvement process. The diagrams were accompanied by a table of feedback for each point on the screenshot and the advantages and disadvantages as perceived by each user group. An overview of the main usability issues, obtained during each iteration, is shown in Table 4. In addition, a diagram pinpointing the issues from the first iteration is presented in Fig. 10.

5.2.2 Primary and secondary user interface interaction points

Carers and service providers are more likely to interact (75%) with the AoD platform than end-users. However, this result is far from representative of the potential for interaction with other user groups. Interaction through other devices (e.g., mobile phones) would increase acceptance and engage more users. Figure 11 and Fig. 12 show the primary (dark shade) and secondary interaction paths (lighter shade) for (a) AoD main landing page, (b) the carer dashboard and (c) the social network module for each user group.

AoD main landing page Primary interactions were identical for People with Access Needs (PwANs) and caregivers. Service providers could not find their “place” in the landing page; therefore, their first interaction (entry point) was the account creation. On the contrary, the main interactions for PwANs and carers were the services “Search” menu and they further focused on exploring the services and options for search and find.

Carer dashboard Interactions are meaningful only for caregivers (informal and formal). Major interactions are the “Selection of a service” and the “Network setting up” process. Secondary interactions perceived were the “Responses” by the end-users and the “Help” function (i.e., steps and path not very clear for some participants).

5.2.3 Overall usability and usefulness

Usefulness remained high for both service providers and PwANs (80% and 85%, respectively); however, ease of use slightly decreased for carers (by 10%). The decrease is most prominently related to the evaluation of the carer dashboard and the dashboard content structure. Likewise, comprehensibility increased for all participating user groups and especially for PwANs (15% increase), meaning that the improvements made after the first evaluation phase enhanced the interaction between users and the AoD platform.

Overall, the perceived usefulness of the AoD prototype exceeds 80% (Fig. 13), with service consumers scoring higher than the other two groups (service suppliers and carers). Comprehensibility was higher for service providers, which was primarily attributed to the fact that the service consumers (especially in the second phase) were identified among people with poor digital literacy and non-native English language speakers. Although the current AoD architecture and prototype supports multiple languages, during the reported user testing session only the English language was supported. With respect to ease of use, the differences were rather negligible among the groups, as all user groups found it easy to interact with AoD albeit with room for improvements. A point of disagreement among the groups of users was that on one hand, service providers requested the search functionality to be bidirectional (i.e., to choose the customers) and not only one way (i.e., be there to be chosen), while on the other hand, end-users and caregivers considered this option rather negatively, as they do not wish to be approached by service providers who want to advertise or sell their services. The current design considers to solve this issue in future releases by providing the end-users the option to select either they wish their profile to be visible to service providers or not, and to control the amount of visible information.

5.2.4 Formative analysis

Service consumers (people seeking help) The AoD platform was well received, especially by the older participants. None of the users have ever encountered this or similar services, as they usually ask a younger relative for help and actually prefer to seek help from people rather than from machines. Multi-modality was also found, apart from availability in native language, to be a prerequisite as older people with vision impairments requested speech-based control capabilities, which are considered for the subsequent AoD platform releases.

Older people mentioned as greater advantages of the AoD platform (a) the increase in autonomy and self-reliance, (b) the lower burden for carers and families, (c) the access to refined and personalized services, (d) the motivation to use the Internet more because the gain might be immediate and (e) the inclusion of socially and geographically isolated people. Distribution through public services and associations of people with disabilities, or similar, would facilitate a sustainable and efficient establishment and use of AoD services through a common web-based platform. Similarly, the users suggested this service platform to be shared with volunteer or non-governmental organizations (NGOs) who offer their services to people who are in need, isolated and alone, which actually fully meets the current AoD deployment plans. They advocated that easy solutions prolong their independence and autonomy and thus are well received. Distinction between “Free” and “Paid” categories was considered as a positive aspect, as it might end up being time- and effort-consuming to search for services they could not afford otherwise, especially for retired and lonely users. Users mentioned that it is encouraging that free services could be offered and used by people who cannot afford to pay.

With respect to the capability to receive suggestions for services by their caregivers (both formal and informal) through the NAS component analyzed in Sect. 4.1 above, the users found it a very attractive feature and they declared interested in service suggestions made by end-user organizations and their healthcare professionals (e.g., family doctors). This component could also be very useful for public and private social security organizations supporting various categories of service consumers.

Service providers (offering help) This category of end-users considers the following as major advantages of using AoD to reach target consumer groups: (a) It saves time to reach target audiences providing information they wish to share; (b) it substantially increases the number of users they may reach in the context of a certain campaign or service (not necessarily the types of users, as these may be restricted anyway by the type of offered service); (c) they identified and positively received the potential increase in their income by using an online service platform; (d) the platform can become a very useful instrument for professionals or amateur/volunteer service providers; and (e) they found it fairly easy to use to create a profile and register a service, for both human- and machine-based services. This category of users identified the need of connecting this service with their professional page (e.g., LinkedIn, Facebook), which has already been considered for the subsequent design and releases of the AoD platform, and is currently supported. Moreover, these end-users had previous experience with other Web sites/platforms which provide interfaces/support for service offering setup, which, however, were not adequately structured and service-dedicated as the AoD platform. Thus, they perceived AoD as a safer and more secure option, with a more professional feeling when compared to other platforms they have used before. The Web sites/platforms they have used in the past were described as “too” commercial and generic, resulting in advertising their services as part of large online job offering centers with none or limited personalization. They perceived the flexible service setup with AoD (e.g., more variability in text fields to complete and options to add) as a means to better control the information shared with prospective clients in contrast to previously used Web sites, where limited options were offered (e.g., one text box with word limit).

They suggested the addition of examples of completed service templates both for human and for machine service creation in the FAQ area of the AoD platform, to make it even easier to set up a service by novice providers. They also pointed out that as important it is to easily and cost-efficiently set up the service, it is equally important to adequately and appropriately market and disseminate it. The video- and documentation-upload functionality was considered as very important for their AoD service offerings, together with the capability to offer multi-modal help for their service. One of the suggestions considered for future releases of the AoD platform refers to the possibility to set up notification options, which are primarily used in the case of a carer being accepted by the person in need and in the case of a payment being issued. Furthermore, the end-user should be able to directly contact the provider or send a question or request (again, need for communication resurfaces). Payment options are very important in choosing to use the platform as well as privacy issues, as access to their transactions and discussions (e.g., exchanged messages) with end-users are perceived as extremely important aspects. For example, they worry that the administrator(s) might have access to information (e.g., product technical specifications) and income from platform transaction. To deal with this wrongly perceived data security issue, the information/transactions safety and security issues will be included in future training sessions and in the user guides of the AoD platform.

Carers—caregivers (people seeking help for others) Most often carers are the most important resource for caring for people with accessibility needs, and usually, they are informal members of the care team (i.e., family members and friends). This category of users identified the dashboard as a necessity for their assistance service planning, especially when the service consumer is an independent and functional individual (i.e., no frequent need for assistance). The main advantages of the AoD platform were identified with respect to the following functionalities: (a) the efficient communication and agreement between carer and the service consumer, (b) service organization and monitoring, (c) the storage of multiple services and contact details and (d) the capability to care for (offer the service to) more than one person at the time. The following major difference between informal and formal carers (i.e., paid services from professional workers) was identified during the sessions: Informal carers were mostly driven by a need to relief their family burden, while formal carers were mostly driven by occupational interest. Both carer groups mentioned that they would use mostly the social networking module, as it would help them to better cope with burden or improve their coping skills and mechanisms. Primarily informal carers were interested for “Book Now” or “last minute” reservation options (high flexibility services to be offered through a dedicated menu or highlighted) to be available through the platform, as they actually believe they can never leave their role and the burden is never really alleviated. In addition, they were more reluctant to use AoD compared to the other user groups primarily, because they would use it for a person they deeply care for and they were worried about (a) the security of the system and (b) the reliability of the person service provider (e.g., in most cases would visit the person they care for). Caregivers showed high interest to search for support (direct gain) for their own problems resulting from caring for another person (i.e., they accept well the fact that AoD is capable of addressing the needs of a wider population).

As discussed in the next section, evaluation sessions with developers (both internal and external participants) are scheduled for the final ongoing (at the time of writing the present) iteration. The aim will be to investigate the prospective value and cost-efficiency of AoD for developers, where the platform will be offered as an open-source service infrastructure through the DeveloperSpace for instantiation.

6 Discussion

The AoD platform is offered as open source, which renders it suitable for deployment (and instantiation) by different organizations (either for profit or for nonprofit) or even individual professionals to serve their target audience, thus considerably reducing the total costs of assistance services setup, publication and marketing. The AoD open-source platform aspires to go beyond existing commercial PaaS solutions (e.g., Windows Azure [10], Google App Engine [11])]) in terms of flexibility offered and easiness to be set up and deployed by non-expert users, which is currently under evaluation. Although initial tests show that the AoD open-source package is easy to install and set up, further testing with service supplier/developers and organizations is foreseen in the near future with consortium-internal and consortium-external developers as the next step toward completing the evaluation of the platform from all relevant aspects and for all targeted users.

As presented in Sect. 5, to date, the evaluation of AoD has focused on services providers, end-users (i.e., people with disabilities) and their carers. The results obtained from these evaluation activities enabled the AoD development team to verify the suitability of the developed platform for each user group. The results confirmed that the user and functional requirements established together with the users (co-design) have been met by the implemented AoD components and functionalities. Finally, valuable feedback concerning specific AoD platform improvements which guided subsequent implementation has been obtained and relevant updates of the AoD functionalities affected by users’ comments have been completed. It should be stressed that full-scale piloting of the AoD platform with large numbers of users was not in the scope of the presented research. The prototype evaluation with end-users, presented in Sect. 5, aimed at a confirmation that the developed AoD platform can be successfully used to produce AoD instances that meet various users’ needs in terms of assistance services.

Full deployment of the AoD platform is expected to take place through its wide adoption by accessibility developer communities and accessibility-related stakeholders in order for these actors to easily create AoD instances that meet the needs of all end-user groups, including the “tails of the tails.” Thus, the short-term future evaluation plans are focusing on collaborating with organizations (companies/associations) instantiating the AoD platform. Two different AoD instances have already been created using the AoD platform. Specifically, AoD as an open-source platform has been used by an NGO in order to enhance an existing AoD service in Spain focusing on assigning micro-jobs to people with disabilities (MicroLabora); it has also been used by an AT-selling company in Austria (Lifetool) in order to create a technical assistance-on-demand service related to the AT products of the company (deployed prototype presented in Fig. 6). Based on these AoD instances, the immediate next steps of the platform validation will be to capture the experience of the two development teams mentioned above and assess parameters related to the ease of use of AoD as a platform for developers of accessible/accessibility services, the time and resources gained by using it, etc. Furthermore, less extensive tests with a small number of project-external developers are also planned during the lifetime of the Prosperity4All project. The evaluation hypothesis that will be tested in order to complete the AoD evaluation is that offering organizations the opportunity to set up AoD to serve their target customer groups is anticipated to lower the cost of assistance service provisioning. An association of people with a specific disability/special need can set up AoD, irrespective of the number of its members. Any assistance service provider targeting this group should be able to reach it without spending effort and money on marketing, which significantly lowers the cost of service provisioning. Additionally, the fact that the service provider will be able to reach an adequate number of service consumers further contributes to service cost reduction. This way, AoD makes the support of “tails” feasible and affordable. The fact of bringing these people together is expected to trigger the probability to initiate crowd-funding processes for new innovative services.

AoD includes the AoD API component which allows external applications to interact with the AoD data storage through REST (or RESTful) web services. These RESTful web services use a stateless protocol and standard operation for improved performance, reliability and reusability, as components can be managed and updated without affecting the system as a whole, even at runtime. Thus, AoD can be easily integrated with already existing applications (e.g., MicroLabora) to exchange information about services and offer end-users/service consumers access to wider pools of assistance services. Through this integration, an application can retrieve data from AoD and visualize them, e.g., to extract valuable information about the popularity of services or the rates of the services so as to modify the offered or create new assistance services that meet the needs of the users.

7 Conclusion

The increasing requirements of assistance services for the independent everyday living of people with special needs (people with disabilities, low literacy, low digital literacy, older adults, etc.) results in an increased demand to easily set up and market such services, while keeping the entire process cost-efficient.

The AoD platform, implemented by Prosperity4All as part of the GPII, enables diverse stakeholders (e.g., family members, professionals, caregivers, associations, etc.) to easily set up, register and offer over the web assistance services catering to individual needs of persons with disabilities or otherwise at risk of exclusion. The evaluation tests of a demonstration instance of the AoD platform implementing all functionalities foreseen in the requirements decided with end-users indicated the value of the offered functionality for the service consumers and service providers; the overall perceived usefulness was higher than 80%. The proposed AoD platform provides a flexible and sufficiently generic architecture for the cost-effective setup, registration and publication over the web of a highly diversified range of assistance services by various stakeholder groups interested in satisfying the needs of persons with disabilities or at risk of exclusion.