d206.3 consumer participatory r&d mechanisms · 2017. 2. 20. · wp206 has developed three main...

Ecosystem infrastructure for smart and personalised inclusion and PROSPERITY for ALL stakeholders

D206.3 Consumer Participatory R&D Mechanisms

Project Acronym Prosperity4All Grant Agreement number FP7-610510

Deliverable number D206.3

Work package number WP206 Work package title Sustainable Meaningful Consumers-

Developer Connections (Pull vs Push) Authors Ilunion, RtF

Status Final Dissemination Level Public

Delivery Date 13/02/2017 Number of Pages 37

Ecosystem infrastructure for smart and personalised inclusion and PROSPERITY for ALL stakeholders www.prosperity4all.eu

http://www.prosperity4all.eu/


Keyword List

Survey, polls, editor, feedback, feed-forward, feed-sideways, DeveloperSpace, SAI

Version History

Rev Date Author Organisation Description

1 15/12/2016 Jesica Rivero ILUNION TOC and first draft

2 20/12/2016 Manuel Ortega ILUNION Minor updates in the whole doc

3 22/12/2016 Carla Zaldua RtF Section 3 update

4 27/12/2016 Ignacion Peinado RtF Integration aspects

5 30/12/2016 Manuel Ortega ILUNION Last review and update

6 30/01/2017 Doris Janssen Fraunhofer IAO Minor comments; Highlight the progress beyond the

state of the art; Add statements about ethical issues and privacy.

7 01/02/2017 Katerina Touliou CERTH/HIT Minor comments

8 03/02/2017 Manuel Ortega ILUNION Update according to reviews

9 10/02/2017 Karla Zaldua RtF Updates in section 3.2 according to previous reviews

10 13/02/2017 Manuel Ortega ILUNION Version to submit



Table of Contents

Executive Summary .......................................................................................................... 1

1 Contribution to the global architecture ................................................................... 2

2 Introduction ........................................................................................................... 4

3 Engagement strategy through feedforward, feedback and feedsideways mechanisms...................................................................................................................... 6

3.1 3F in the DeveloperSpace ............................................................................................ 6

3.2 Examples of use scenarios ........................................................................................... 8

4 Survey tool in Prosperity4all ..................................................................................11

4.1 Prosperity4all survey tool vs Existent survey tools ................................................... 11

4.2 Survey tool used in DeveloperSpace and SAI/UL ...................................................... 13

4.3 Privacy and ethics ...................................................................................................... 14

4.3.1 Survey creation process ..................................................................................... 15

4.3.1.1 Question types ............................................................................................ 16

4.3.1.2 Adding questions and sections ................................................................... 17

4.3.1.3 Adding response quotas ............................................................................. 19

4.3.1.4 Statistics ...................................................................................................... 20

4.3.2 Filling in the resulting survey ............................................................................. 22

4.4 Survey & Polling Tool ................................................................................................ 23

5 Architecture ..........................................................................................................24

5.1 Components .............................................................................................................. 24

5.1.1 Front-end ............................................................................................................ 25

5.1.2 Back-end ............................................................................................................. 25

5.2 Survey tool sequence ................................................................................................ 26

6 Conclusions and Future Work ................................................................................29

Annex I: Glossary .............................................................................................................31



List of Tables

Table 1. 3F implementation: Feedforward mechanisms. .......................................................... 7

List of Figures

Figure 1: Overall Picture of Prosperity4all ................................................................................. 2

Figure 3. Main screen with list of surveys ................................................................................ 16

Figure 4. Example of six types of questions ............................................................................. 17

Figure 5. List of questions in a created survey ......................................................................... 18

Figure 6. Creation of quotas ..................................................................................................... 19

Figure 7. Quotas progress ........................................................................................................ 20

Figure 8. Statistic section with general view ............................................................................ 21

Figure 9. Example of pie chart and bar chart ........................................................................... 21

Figure 10. Example of survey screen shown to survey respondent. ....................................... 22

Figure 11. Example of error while filled in the survey ............................................................. 23

Figure 12. Components diagram of Survey Tool ...................................................................... 24

Figure 13. Sequence diagram of the initial load of the survey respondent view of a survey . 27

Figure 14. Sequence diagram of the next pages of the survey respondent view of a survey . 28



1

Executive Summary

The purpose of Prosperity4All is to build the infrastructure to make it easier for developers, consumers, and others to work together to create new, better, and/or less expensive solutions, and to be able to market them internationally.

The core of this infrastructure is called the GPII DeveloperSpace. The DeveloperSpace acts as the central location or connection point for all of the different services, tools, and resources for this development infrastructure.

The DeveloperSpace is the central point for the Community and where the feedback, feed-forward and feed-sideways (3F) mechanisms are implemented as part of the engagement and communication strategy. Most of the tools to enable these 3F mechanisms are developed in WP206, but there are others in SP2 and SP3

This deliverable contains the results of “T206.3 Creation of Consumer Participatory R&D Mechanisms”. This result is an accessible open source survey tool1 able to collect information from users in order to understand their requirements, validate and tune ideas with them, and testing prototypes (at mid-stage) and product beta (at latter stages). This is indeed the first fully accessible tool in the world to create polls and surveys2, which will allow the Community to improve the communication and engagement mechanisms in place

The work has followed the guidelines of D206.1 Best ways to engage customers over time where main needs and requirements were defined, as well as the overall engagement strategy and design decisions made by the Consortium.

From a project perspective, the goal was to provide the means for the Community around the DeveloperSpace to implement 3F strategies.

From the technical perspective, the focus was on generating software components that could be useful and re-usable to the many tools existing in Prosperity4all and to ensure a smooth integration with them.

1 https://github.com/iluaepidi/surveytool 2 To the best of our knowledge



2

1 Contribution to the global architecture

This deliverable is part of WP206, in charge of providing Sustainable Meaningful Consumers-Developer Connections. Then, the tools developed through WP206 need to be a linking component between WP201 (implementing the core system architecture) and SP3 (proving the P4A infrastructure with real world applications) developments. In Prospority4all, these tools will be services and components of the Developer Space3 and Shopping Assistance Aid/Unified Listing (UL/SAI)4 developed under SP2.

Figure 1: Overall Picture of Prosperity4all

T206.3 develops a set of accessible tools to allow consumers to directly participate in developer's efforts to create new products. These mechanisms are intended to bring user (persons with disabilities, older people, and people with low levels of digital literacy) a deeper involvement in R&D.

These accessible mechanisms will address several phases of the R&D, such as:

3 Prototype at http://staging.developerspace.gpii.net/ 4 Prototype at http://staging.saa.gpii.net/



3

• Collection of consumers information to understand the context of use and consumers requirements (especially for new developers and student researchers)

• Validation and tuning of ideas with consumers at the early stages (including for new developers and student researchers)

• Evaluation, testing and improvements suggestions of prototypes (mid-stage) and product beta (latter stages) by consumers, providing feedback to developers for increasing its usability and accessibility before market launch.

WP206 has developed three main tools to enable these accessible mechanisms: a survey tool, a polling creator and a reviewing tool that includes both rating and comments. The reviewing tool is presented in “D206.4 Consumer feedback and information exchange mechanisms”, whereas “D206.2 Feedforward mechanisms for directing future developing efforts” introduces the 3F strategy in the Project and describes the polling tool. Additionally, D206.2 is an introductory document for this one (D206.3) and should be in the first place, since both the survey and polling tools share the same interface and code base.

The tools developed under WP206 are means of communication that will help the Consortium implement the 3F strategies through the integration with the DeveloperSpace and the UL/SAI.



4

2 Introduction

The objective of this document is to explain the work done in T206.3: the survey tool and its integration with the polling tool to create a complete suite.

The survey and poling tool has as main function to collect information from persons (users and developers/vendors) at different stages of the creation and development process. As such, we have been inspired by several ways to obtain information from others (See D206.1):

• Websites with active communities that are challenged to test something. This approach is pretty useful to validate ideas, and people are generally rewarded with nonmaterial incentives. This provides a set of feed-forward useful mechanisms to drive future developments on those aspects most important for others.

• Social networks with user communities discussing about certain topics in groups. These groups are usually very specialized around one topic.

• Crowdsourcing sites where users and developers can test developments and products and comment on them; report bugs; review content and functionalities; contact other users; rate ideas, projects, solutions and products; vote to different surveys and polls; or help in small tasks.

• Remote testing and user surveying to obtain feedback from users.

The interaction among users and between users and developers/vendors is controlled in Prosperity4All through the DeveloperSpace and the UL/SAI, so all the mentioned mechanisms to collect information need to be integrated with them.

D206.2 showed examples of this integration together with the polling tool. It allows anyone to compose a direct simple question that can be easily embedded in the website through an auto-generated iFrame5.

However, some subjects deserve more than one question, or the question type needs to be more complex. Those are the cases for the survey tool to be used. Unlike the polling tool, the way to access the survey generated is through a URL which can be linked from any regular website.

As the polling tool was fully explained in D206.2, this deliverable centers on the survey editor and its integration with the polling tool. In order to do it, this document is divided into four sections. First, the Engagement strategy section compiles the actions accomplished to fulfil the engagement plan. It summarizes those detailed in D206.2 about polls and completes them with those related to the surveys.

5 https://en.wikipedia.org/wiki/HTML_element#Frames



5

Next section explains the survey tool in detail. It all starts with how this tool is going to be integrated in the P4A architecture. It continues with a functional description and, in the end, the advances of this tool with respect to other survey applications in the market, as well as the synergies that emerge from having together a poll and a survey editor.

The fifth section explains how the survey tool works from a technical perspective: the technology used, the steps to provide the functionality previously explained, and how the composite shapes up the full survey tool.

At the end of the document, conclusions and future lines are drawn. They range from developments carry out inside the project beyond T206.3 to future developments to be done beyond Prosperity4all.



6

3 Engagement strategy through feedforward, feedback and feedsideways mechanisms

The different parts of the Prosperity4All infrastructure (UL/SAI, DeveloperSpace and the GPII website) are interconnected, both conceptually and technically. The three sites have been developed as a multi-site Drupal6 installation, which allows the three sites to share the same code base.

The purpose of P4A is to engage users in the decision-making process and to move consumers to a proactive position where they actually help shape the development of products. Within the different deliverables (especially 206.2) the engagement strategy to create sustainable consumer-developers connections has been explained.

In Deliverable 206.2 the three engagement mechanisms, named as 3F, were described as: - Feedback: the end user starts the interaction with developers - Feedforward: the developer starts the interaction with end users. - Feedsideways: communication among peers

This classification considers the role of someone (user/developer) as the reference point.

Another meaningful classification emerges considering the state of a product or service as the reference point. As described in D206.5:

- Feedback is any communication mechanism to report failures, malfunctioning, incidences or bugs.

- Feedforward mechanism comprise contacting developers, describing your idea and see if a researcher or developers might build it, going to the DeveloperSpace and assemble a team to help you build it or suggestion new products or new features for products.

- Feedsideways mechanisms represent sharing side-uses, hacks, tips, tricks or alternatives uses for a product or service.

Whatever the perspective is, they all represent means of communication and interaction implemented in P4A. This deliverable focuses on the survey tool that is one of the tools to allow some of the 3F processes.

3.1 3F in the DeveloperSpace The table below summarizes main current actions and enabling mechanisms to implement the 3F strategy. A full description can be found in D206.5.

6 https://www.drupal.org/



7

Table 1. 3F implementation: Feedforward mechanisms.

Feed-way DS section Action Mechanism

Feedforward

TOOLS

create a survey/poll Survey/polling tool (T206.2-3)

share a survey/poll Survey/polling tool (T206.2-3)

create new challenges Challenge module

CHALLENGES

upvote a challenge Challenge module

contact the submitter of the challenge

Challenge module

PEOPLE contact developers Developers section

contact volunteers Volunteers section

One of these enabling feedforward mechanisms in the table is the survey tool (merged with the polling tool) developed under T206.3 and will be described in this document.

In order to communicate the existence of this tool P4a will create a handbook for registered users with different examples of the survey tool. Additionally, within our webinars7 targeted to developers and mainstream companies, we will also explain the 3F strategy and specifically we will show systematic examples that display the use of the poll and survey tool:

- To collect consumers requirements - To validate ideas with consumers in early development stages - To test prototypes and product beta and gather consumer feedback

Additionally, P4A’s strategy aims to facilitate the access to these polls. In this sense, the polls can easily be embedded in any page of the DeveloperSpace and the Unified Listing or in any HTML page and surveys can be created as a service provided through the DeveloperSpace. The ‘People’ section can also help survey/poll creators find people interested in collaborating . There is a full description and links to the DeveloperSpace sections in D206.5.

Additionally, within the DeveloperSpace developers will find information and links to help them disseminate and share their polls to targeted communities and websites. Moreover, other tools that collect consumer requirements will be the ‘Challenges’ section and the P4A

7 http://www.prosperity4all.eu/category/news-events/



8

campaign ‘Tell us your story!’. Within the ‘Challenges’ section a company, a developer, an end-user or any user with a ‘Contributor’ role can post a challenge requesting new features/solutions. In P4A’s campaign “Tell us your story!” different end-users describe the IT obstacles encounter and what is that they would like to find. In order to engage different end users in the campaign end user partner associations are involved identifying participants. These sections of the DeveloperSpace and the UL/SAI are further explained in D206.5.

An important part of the engagement strategy is to allow end-users to share their opinion, requirements and feedback on developments. There will be two fundamental ways of contacting end-users:

- Directly: users register within the DeveloperSpace as ‘Contributors’ are allowed to submit challenges, share ideas on solutions, prototypes and/or challenges, and sing up as testers.

- Through the people section: users interested in end-user sites and associations will be able to access complete information on where and how to contact them.

In order to let end-users know about us we have identified a series of actions:

- A webinar series targeted to end-users where we will explain the different mechanisms and tools end-users have to participate in the P4A sites.

- Disseminate the P4A end-user participation tools in our Partner End User Associations networks, (we have already started with our Tell us your story! Campaign)8.

- End-users mailing invitation to be part of the P4A sites

In March 2017 we will start our webinars targeted to end-users associations. The first webinar will focus on the Assistance on Demand Platform. We will organize a series of webinar and open days with end user associations and will highlight how they can contribute and be part of P4A and have their say in services and products.

Additionally, we will produce a how-to video (+screencast) that will show systematically how to use the survey and polling tools.

3.2 Examples of use scenarios Based on the work done in SP1 Use Model, the following list will present examples of use scenarios that illustrate how different stakeholders (end users, developers, vendors,

8 http://www.prosperity4all.eu/participate/users/tell-us-your-story/



9

advisors, etc...) can use the tools of the Project (including the Survey Tool) in order to gather feedback from other stakeholders:

• Nora Lindberg (AT Reasearcher/Educator)

Nora works with several Masters and PhD students at the Access Technologies

Research Lab in a public University. The Lab receives funding to develop an

accessibility solution. She decides to create a challenge in the Challenges section of

the DeveloperSpace offering an economic prize to the developers who can complete

a certain feature for the accessibility solution. Additionally, she is looking for new

fresh ideas to improve and shape up the Challenge, so that she decides to create and

share a Survey with her preliminary ideas to know the opinion of the Community.

James Olson (AT Developer freelance developer/entrepreneur) is an independent

developer working for the last 15 years in the area of accessibility. He started as

software developer for a large company, and then he decided that what he really

wanted was to be able to make his own decisions and choose the projects he would

love to work on to make a difference in the community. He is a frequent user of the

DeveloperSpace. He reads Nora’s challenge and decides to become a contributor as it

is one of his areas of expertise. On top of that, he helps Nora giving her his opinion

through the survey.

• Karl Hoffmann (AT Vendor) Karl and two of his good friends started the “Learning Tools” company a few years

ago. He checks different tech blogs, journals, social media and specific forums every

day. During the development process, Karl is responsible for recruiting end users to

test their products in exchange for free access to some of their applications. After the

product is out, he keeps track of user’s feedback, reviews and ratings to make sure all

the issues raised or concerns are communicated with the development team.

Within “Learning Tools” they want to update one of their solutions but are not sure

what improvements will be the most valuable for their users.



10

Using the ‘Surveys’ service available in the DeveloperSpace, he creates a survey for exploring the acceptability of the different potential improvements. With that survey, he can:

o Visit the Community section and look for an association or group of people that could be potential users of their solution and contact them, then share the URL of the survey with the association or user group.

o Go to the ‘People’ section in the DeveloperSpace and look for testers or volunteers who have expressed their interest in the field of accessible “learning tools”, then contact them directly and send them the URL to the survey.

• Pauline Rey (User Organization) Pauline has a lot of experience with ICTs and accessibility issues with kids. Through their experience, she has an idea for an accessible solution, but does not have the knowledge on how to implement it. She creates a challenge in the ‘Challenges’ section of the DeveloperSpace aiming to find any developer interested in implementing the solution. She finds a developer who implements the solution.

o Once she has a prototype, she can look in the COMMUNITY and volunteer section for users interested in testing it

o Her solution is highlighted in the ‘Success Stories’ section of the DeveloperSpace and she shares it in her social networks

o She thinks the prototype is great, but she would like to think on her next step forward. She creates a poll using the Polls’ tool and places it in the success story page. Then, she shares the implementation page in her social networks in order to find respondents



11

4 Survey tool in Prosperity4all

The prototype developed under T206.3 merges the results with T206.2, that’s to say, the survey editor and the polling tool compose a single tool. Having both things together provides the Community with a suite of complementary fully accessible tools to enable communication channels within the Project and outside, since this is an open source9 project. However, in order to be more concise in this document, we will refer just to the survey tool.

The survey tool let users do things like launching a single response questions embedded in external websites, or creating surveys with tens of sections, with pages and questions inside, with multimedia files and with set up the most complex logic rules in the market. In all cases, the editor can preview the evolution of the poll/survey and can do changes on-the-fly. And maybe the most important feature is that the survey tool is the only accessible survey editor in the market, so that a broader, more inclusive community of people can create and fill in surveys and polls.

4.1 Prosperity4all survey tool vs Existent survey tools During the first stages of the project, and especially as starting point for T206.3, some of the most popular survey tools were studied to detect their needs and problems.

The studied tools include typeform10, survio11, surveymonkey12, google forms13 and encuestafacil14. The main problem found was that none of them are totally accessible for survey respondents and survey takers, so it is not possible to include persons with disabilities in processes to collect feedback, feedforward or feed sideways. This involves that the creation of products and services doesn’t consider the needs and preferences of persons with disabilities, and that surveys can only be created by persons without disabilities.

The developed survey tool solves this problem. It is totally accessible for survey takers and for survey respondents:

- The colour contrast of texts and elements is suitable for persons with low vision. - The developed tool is compatible with all screen readers.

9 https://github.com/iluaepidi/surveytool 10 https://www.typeform.com 11 http://www.survio.com/ 12 https://surveymonkey.com 13 https://docs.google.com/forms/ 14 https://www.encuestafacil.com/Home.aspx



12

- The font size of the different types of headers, paragraphs and labels are suitable for persons with low vision.

- All options are keyboard navigable - All elements in the tool have alternative text or a label to know the function of the

element for persons using screen readers. - It is not possible to upload multimedia files without including a name and an

alternative text. This guarantee that persons using screen readers are going to have access to all elements in the survey.

- Accessibility in the creation and management process of surveys: o All pop-up windows are accessible for screen readers. o Charts shown in the statistic section have alternative text. This involves that a

person using screen reader can read the information presented in a graphical way in plain text. For example, when a person with screen reader set the focus on the graphical information presented in the pie chart in Figure 9, the screen reader is going to say “Option 1: 0%; Option 2: 80%; Option 3: 20%; option 4: 0%”

o In order to make charts accessible for persons with low vision, and avoid problems of not enough contrast in, for example, pie charts, when a survey taker put the mouse over a part of the chart, a label with the information under the mouse is going to be shown.

- Accessibility in the survey respondent view: o Buttons to rightly complete the survey have a higher contrast to make easier

for survey respondents to fill in the survey in a fast way. This could avoid frustration in persons with cognitive disabilities when they try to fill in the survey. For example, the Continue button has higher contrast than Back button.

o The error messages have been designed considering persons with low vision and also cognitive disabilities. The colour change around the question with error. It includes also a textual message explaining the error, and the focus of the survey is changed to that question.

o The focus is given to one by one question to help persons with cognitive disabilities to focus on one by one question. This could be a problem for persons with low vision or for persons with screen readers. Nevertheless they have been taken into account, and a person with screen reader is going to have the information that there are more questions in the list, and some buttons have been added before and after the question to give the information that there are more questions in the list to persons with low vision.



13

Together with the accessibility advantages of the developed survey tool with respect to others, there are also other functionalities that provide to it extra value:

- It is possible to create different versions of the same survey in different languages. It is not necessary to create a new survey copying the existent one. Only changing the language selector in the section of edition, the survey taker can change the texts and multimedia files to put them in the new language. As all versions are stored together (they are the same survey), all answers can be studied together in the statistics section or be downloaded together in the Excel.

- The polling tool and the survey tool are in the same tool. This gives a set of advantages that are going to be explained in the section (4.4).

Together with the previous advantages, it is also important to mention that the developed tool includes functionalities provided in a free way that others include in premium packs. Some functionalities include in premium packs that the created 3F tool provides in a freeway are the following:

- The creation and control of quotas. - The visualization of graphics and statistics. - The dependencies and logic jumps. - The possibility of downloading an Excel document with responses in raw data. - Unlimited number of questions by survey.

In addition, as it can be seen in section 6, a set of improvements are planned as future lines that do not have any of the studied tools.

4.2 Survey tool used in DeveloperSpace and SAI/UL As in the case of the polling tool, there are two roles in the survey tool:

- Survey taker. Any person registered in the tool that creates, at least, a survey to be sent to others.

- Survey respondent. Any person that receives and fills in a survey is a survey respondent. These persons are not registered in the tool, only their anonymous answers are stored to be analysed by the survey taker.

Within the DeveloperSpace community it is possible to find both profiles: developers interested on collecting feedback from users about a product or service in development, or users interested on knowing the opinion of developers/users about an idea with the objective of proposing a product to be developed.

The survey tool is going to be integrated within the DeveloperSpace as an external service in the menu of Service Infrastructure DeveloperSpace (see Figure 2). The Survey service page



14

will provide interested users with detailed instructions of how to create new surveys and link them from other pages or embed polls, either in the DeveloperSpace or in other website.

Although there are attempts to create an accessible survey tool, they usually refer to just the respondent part. Our survey prototype is accessible in both sides: survey creation and response.

4.3 Privacy and ethics The survey tool is designed to allow for a straightforward management of ethical and legal issues:

1. Recruitment. In Prosperity4all, the contact with volunteers to ask them to fill in a survey is carried out through the Testers Central. The survey tool generates a public URL with the survey for them to response.

2. Project information. Any participant in surveys should be aware of the objectives of research and what for their responses will be used. The survey tool allows to create an introduction page in which the participant could read the research project info and survey objectives before starting the survey.

3. Managing informed consents. It is quite common when doing user tests to provide users with informed consents before starting a survey. Although the survey tool is for general purpose and not conceived for user tests exclusively, any survey editor can create a mandatory simple question, with the informed consent and two options: Accept and Reject. If survey respondents do reject, they will not be part of the user test. The questions types will be further explained in the next section.

4. Confidentiality, privacy and data protection. The anonymity of participants in surveys should be guaranteed. At no stage in the process, users need to provide any personal information in the survey tool by default. In that way, any response provided to the survey tool is anonymous. Then, the survey tool does not store any information about users and there is no way to contact them directly through the tool. However, the question statements are to be defined by the survey creator, so there is the chance for some statements to gather sensible information. In that case, the survey manager should include informed consents to be accepted by the respondents before processing the data.Survey tool walkthrough

The survey tool can be divided into two sections: a) the part related to the creation process and, b) the part related to the visualization of the resulting survey and that is accessed by the survey respondent.

Both sections have been created following an agile methodology, with the work organized in sprints of 15-30 days and with end users and experts in the creation of surveys involved from the first moment in the project. This methodology has allowed to include not initially considered functionalities that raised in early inner testing processes that improve the user experience, as well as functionalities that increment the usefulness of the tool for real final users. Some examples of the functionalities that emerged are:



15

- The tool should allow to group questions in sections. Each section should be related to a given content type (e.g. demographic information, personal opinion…) making it easier for the survey respondent to answer the surveys.

- It is important to include some at least two kinds of logic to the survey. For example, the survey creator could want to include a jump from one question to another if the answer took a given value. This allows adapting the questions to the answers given to the survey, asking only useful information. E.g. If the respondent does not use public transport, to avoid all questions related to it. Similarly, some questions may be hidden as a consequence of previous answers.

- Closed questions, that is, those with a list of possible answers, should allow each answer option to be text, text and image, or just image. This allows you to reach different profiles of respondents, including those who have problems, for example, to read text.

- The way to show the resulting survey should help the respondent to answer it correctly. This could help to persons with cognitive disabilities to take part in processes to collect feedback.

- If the survey editor did not create a farewell page, the tool should show a standard one, inviting the user to participate in future surveys and thanking him for this time

4.3.1 Survey creation process

When survey takers want to create a survey, they just need to log in, click on the Surveys tab and add a new survey. If they already created some survey, these are shown in a list (see Figure 3).

Each row of the table contains the deadline for the survey to be unpublished, the survey name, the number of responses received, an access to survey statistics generated with the responses received, and a button to download the responses as raw data in an Excel file.

This page also provides survey takers with a search box to speed up the task of finding surveys, a selector to indicate the number of surveys shown by each partition of the table, buttons to navigate through the partitions of the table, and a button to create a new survey. Everything is provided through a clear, responsive and open layout.



16

Figure 2. Main screen with list of surveys

When a new survey is created, a pop up window requests the survey taker to provide a name for the survey, short description, related project and language. Surveys are organized by tags instead of using trees. This avoids to have several levels, complex navigation inside long trees, or to remember where a survey was stored. The survey taker only needs to write a related tag. For example, the survey takers can search a survey by the name of a campaign or project.

At any moment, the survey taker can edit the survey. To do it, the survey taker has to click on the name of the survey. If the survey taker decides to do it, s/he is going to see a new window (Figure 5) with the general information of the survey, and a list with all questions grouped by pages and sections. If the survey taker decides to create a copy of an existent survey in a different language, s/he only needs to change the language in the selector of this page and translate the texts or change images/videos. It is important to mention that it is not possible to remove elements in a language different to the initially defined language. Thus, the survey structure must remain unaltered.

4.3.1.1 Question types

The survey tools currently let user select six different question types: Form fields, Figure 4(a), which are questions with open answer limited in number of characters. Paragraphs, - Figure 4 (b), are questions with open answer without limitation in number of characters. Simple questions (Figure 4 c) allow only one possible answer from a list of options. Multiple answer - questions Figure 4 (d) allow instead one or more possible answers from a list of



17

options. Matrix questions (Figure 4 e) provide a set of rows and columns with possible answers. Finally, Likert scales (Figure 4 f) show a scale to introduce rating.

Figure 3. Example of six types of questions

(a)

(b)

(c)

(d)

(e)

(f)

All types can include a statement/title, a brief description, an image or video, and a dependency indicating if the question will be displayed based on the answers given to simple questions from previous pages.

In addition, in the case of multiple, simple and matrix questions, the survey taker can write the possible options, as many as necessary, with an associated image or video in case of simple and multiple.

Finally, in the case of simple response questions, in addition to dependencies, a logical jump can also be associated. The logical jump indicates if the next page shown to survey respondent will be different to the immediately next one in function of the given answer.

4.3.1.2 Adding questions and sections

In order to create a new question, the survey taker only needs to click on Question button and introduces the following information in the pop-up window that appears at that



18

moment: question statement, type of question (any of previously mentioned types), and if it is mandatory that the survey respondent answers the question.

Figure 4. List of questions in a created survey

It is also possible to create new body contents and page breaks.

The body contents are textual information that allow to introduce sections, or to explain things to the survey respondent. Body contents include a text area to insert the indicated text. This text area has a bar with the different things that can be done with the text: text size, justification, link, bold…This bar is accessible for blind people or for people using screen readers. It is also possible to add multimedia files to body contents.

The survey taker can also create new sections inside the survey. At the end of each section there is a button to allow survey taker to do it. The new section is going to be below the



19

previous one with one empty page. Each section can have one or more pages inside, and, inside each page, it is possible to have one or more questions and body contents.

4.3.1.3 Adding response quotas

Quotas may also be included clicking on the corresponding tag of the webpage (Figure 6). The quotas allow to control how many answers are required for each question / option, as well as how many answers are needed in general. Quotas allow to survey taker to know if s/he has received enough information to obtain significant results or if it is necessary to have the survey available more time, or reopen it.

Figure 5. Creation of quotas

The results, or progress, of the quotas can be seen in the statistics section (Figure 7). To access them, the survey taker needs to click the last tag in the webpage. For each quota there will be a bar with the minimum and maximum number of answers required, and where are the answers that have been received so far.



20

Figure 6. Quotas progress

4.3.1.4 Statistics

In the statistics section, together with the progress of the quotas, the general results of the survey and the results of each question can be seen (Figure 8). The fact of having a section with graphs and statistical results reduces the time the survey taker needs to do analysis of data and final reports. A great effort has also been done to convey both an attractive aesthetics of the charts with accessibility.

The statistics at the general level will provide information about, namely, started, completed surveys and their rate; a linear chart with the temporal evolution of the started and completed surveys to date.



21

Figure 7. Statistic section with general view

In the case of the statistical information of each question, all of them will show the number of answers received and information of the answers given. The way to represent this last type of information will vary according to the type of question. For questions with open answer (form field or paragraph) a list with the answers will be shown. In the simple questions, a pie chart is used (Picture on the left in Figure 9). In the rest of the cases a bar chart will be plotted (Picture on the right in Figure 9). It is important to note that in all cases, graphics are accessible for people using screen readers, and that for people with low vision a label will be shown when the mouse is over the bar or section of the pie chart. The label will contain the name of the option and the percentage of answers that the option has received.

Figure 8. Example of pie chart and bar chart



22

4.3.2 Filling in the resulting survey

Once a survey is created, it can be filled in by accessing it through a URL provided by the tool and showing a survey with the appearance indicated in Figure 10 and Figure 11.

Each page will display a survey’s page with the questions it contains, a progress bar at the top to know where it is going, and buttons to navigate through pages.

The questions displayed on each page of the survey, as well as the pages themselves, will depend on the answers given by the survey respondent if there was a logic or associated dependency.

The middle pages of the survey will contain a button to go back and another to continue. The start page will contain only one button to start the survey, the first page of the survey will have no button to go back, and the last page will only have a button to end the survey.

It is important to highlight that only one question will be highlighted each time on the page. It is possible to change the highlighted question by changing the focus: click on another question, press the button to go up or down that are shown above and below the focused question, or doing scroll in the page.

Figure 9. Example of survey screen shown to survey respondent.

Each time that the button to go to the next page is clicked, the system checks if all questions were correctly completed in the current page. Respondents will not be allowed to continue to the next page of the survey if they do not answer mandatory questions, if they type words in a number field, exceed the maximum allowed length in a form field question or type a number out of a specified range. Any questions with error will display an accessible message explaining the error, and the first question with error will be focused (Figure 11).



23

Figure 10. Example of error while filled in the survey

4.4 Survey & Polling Tool One of the advantages of merging the survey and polling tools is that it provides the possibility of creating simple polls and complex surveys inside it. This is something that other products in the market do not provide and that gives a set of advantages:

- It is not necessary to learn how to use two different tools to create polls and surveys. The steps and interfaces are the same for both creation processes. This involves that the learning curve to create both things is reduced.

- It is possible to collect information from users using tools with different degree of complexity, or expended more or less time to create surveys. With polls it is possible to create surveys of one simple question that can be inserted in any website. In the case of surveys, they are more complete, and the obtained URL can be distributed to be accessed by any navigator.

- It is possible to use both together: use the poll to obtain the most important information, and use the URL of a survey in the thanks section to give the possible to the survey respondent of giving a more detailed information. This allows attracting more people to the complex survey and also to, at least, obtaining the most important information.



24

5 Architecture

5.1 Components The architecture of the survey tool is similar to the polling tool’s architecture explained in D206.2. It has client-server architecture, so it has two main sections (see Figure 12): the front-end, or client, and the back-end, or server. The back-end carries out all the processes needed to edit, manage and publish surveys, as well as the data processing and saving. The front-end includes some changes with respect to the polling tool architecture, but the final task is the same: provides the interfaces to create surveys and to show the survey to the survey respondent to be filled in.

Figure 11. Components diagram of Survey Tool



25

5.1.1 Front-end

In the case of the survey tool, the front-end includes two different types of interfaces, and each of them uses a different technology.

- Interfaces to edit and manage surveys (Interfaces from Figure 3 to Figure 9). These interfaces are developed with HTML515, CSS316, JQuery17 to carry out inserts, updates, deletes of all the information related to questions, and Chart.js to draw the charts with statistical information in the corresponding section. The communication with the server is carried out by using HTTP requests.

- Interfaces to be shown to the survey respondent to answer the survey (Figure 10 and Figure 11). Due to the fact that shown questions, pages and sections are generated in a dynamic way depending on answers in previous pages, it was decided to use AngularJS18 instead of Javascript and JQuery to generate this kind of interfaces. This change will allow also to make easier the inclusion of future changes in the creation of more types of questions or in the development of changes to include extra functionalities. So, HTML5 and CSS3 are also included, but Angular JS is being used instead of JQuery to give more flexibility and dynamism to the creation process. With respect to the communication with the back-end, the current architecture is using REST19 service to carry out requests of information and the responses contain a JSON20 with the interface to be shown.

5.1.2 Back-end

The back-end has the same structure and components of those in the polling tool. It has been developed in Java (JavaEE 8). The application server used to host the survey tool is Tomcat 8. The database is implemented in MySQL21.

The backend is composed of this set of components:

1. The SurveyTool is the entry point of the architecture. It receives the requests of the front-end, serves the interfaces and orchestrates the processes, invoking others components. This component uses REST of HTTP22 to receive the requests from front-ends. Furthermore, SurveyTool builds the interfaces for the part of the front-

15 http://www.w3schools.com/html/html5_intro.asp 16 http://www.w3schools.com/css/css3_intro.asp 17 http://www.w3schools.com/jquery/default.asp 18 https://angularjs.org/ 19 https://en.wikipedia.org/wiki/Representational_state_transfer 20 http://www.w3schools.com/js/js_json_intro.asp 21 21 https://www.mysql.com/ 22 https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol



26

end related to the management of surveys in JSP23, and also the interfaces that are going to be rendered by Angular JS for the part related to the survey respondent.

2. The SurveyManager carries out all the management processes of the survey tool editor side. It is in charge of creating and managing surveys and having the surveys info shown in the front-end.

3. The SurveyEngine carries out all the processes related to the survey respondent side. It is responsible for providing the survey data, including questions, to be shown through the front-end. Besides, it gets the responses from the SurveyTool, processes its data and saves them in the database.

4. The DatabaseMgr manages the connection to the database. This component is referenced by the SurveyManager and the SurveyEngine to complete their processes.

5.2 Survey tool sequence When a survey is created, the survey taker will obtain a URL to be sent to survey respondents thought the desired media. When a survey respondent clicks on the URL and accesses to the survey, a sequence of internal calls starts to generate the different pages of the survey as well as the questions that each one is going to contain.

The first task carried out by the survey tool is to generate the initial load (Figure 13). This is done always that a survey respondent clicks on a URL of a survey (independently of if it was the first time that the respondent entered in that survey). The process followed internally in the survey tool is the following:

- Angular JS sends a REST request to the SurveyTool component. - The SurveyTool creates the process, and after that it calls to the SurveyEngine asking

by the first page to be shown using the method getCurrentPageJson of the class SurveyProcessHandler. This first page could be the first page of the survey or that at which the respondent left the survey the previous time that s/he accessed to the survey or that at which s/he was when the F5 key was clicked. All the surveys are anonymous, the name of the respondent is not stored, and the way to know if that respondent started the survey before is because when a new survey respondent click on a URL, the system stores the IP from which the respondent accessed.

- After that, the SurveyEngine calls to DatabaseMgr using the method getQuestionnaireJson to obtain a JSON with the page to be load.

23 https://en.wikipedia.org/wiki/JavaServer_Pages



27

Figure 12. Sequence diagram of the initial load of the survey respondent view of a survey

Once that the first page is loaded and the respondent clicks in next or back button, a new process is started (Figure 14):

- Angular JS sends a REST request to the SurveyTool asking by the next page. - SurveyTool calls SurveyEngine using the method anonimousResponseProcess to start

the process of storing answers and obtaining the next page. Inside this method, the SurveyEngine follows the next steps:

o Check if the survey IP is registered in the database. If that is not the case, SurveyEngine calls to DatabaseMgr through the method insertAnonimousUser to insert the IP of the respondent in the database. This is done to avoid multiple answers from the same user/IP.

o Next, the SurveyEngine stores in the database the answers given to the questions of the current page calling insertAnonimousResponse method of DatabaseMgr.

o Finally, the attribute in the data base that controls the last page answered by the respondent is updated calling updateAnonimousUserCurrentPage method of DatabaseMgr.



28

Figure 13. Sequence diagram of the next pages of the survey respondent view of a survey

- Finally, the SurveyTool checks if the answered page was the last page of the survey: o If it wasn’t the last page, the SurveyTool obtains the next page to be shown

with its questions taking into account the answers given to all questions in previous pages and that had associated some dependency or logical hop. The method called to obtain this information is getQuestionnaireJson of DatabaseMgr. This method returns a JSON with the information of the page.

o If it was the last page, the survey information for the survey respondent is updated to finished. This is done using the updateAnonimousUserFinished method of SurveyEngine, which in turn calls the updateAnonimousUserFinished method of DatabaseMgr. In this case, the information on the last page is returned in a JSON. This last page can be a page automatically generated by the tool, or a page created by the survey taker in the survey editor. The automatic final page will only be generated in case the survey taker did not create a last page with only one body content in the survey.

The project with all the code is available on the SurveyTool repository, accessible from the following URL: https://github.com/iluaepidi/surveytool.



29

6 Conclusions and Future Work

At the end of T206.3, there is a complete prototype of a Survey and polling tool. It helps covering some important communication needs identified in the Prosperity4all community. It covers a range of topics related to gathering information errors, improvements and ideas about existent products or services, or opinion about functions or way of working of a service or product in development stage.

Next step is to improve the integration with the DeveloperSpace. For instance, the single-sing-on integration of the survey tool in the DeveloperSpace would provide some advantages in the creation process as users will not need to have several accounts to access the services provided from the Developer Space or the SAI.

The resulting tool is going to be tested by end users and developers according to Prosperity4All user tests planning. According to current plans of SP4, these tests would be carried out in 2017. At the end of those tests, the conclusions may imply some changes in the tools in order to improve them.

Improvements coming from user testing and integration process will need to be undertaken in 2017. The objective is creating a stable tool ready to be launched and evolve together with the DeveloperSpace and that allows all persons (independently of their needs) to provide their feedback, feedforward and feed sideways about products and services.

These are the main foreseen lines to be developed:

- To limit that surveys were answered once the maximum of a quota was reached. It is necessary to think how to tell the survey respondent that s/he can no longer answer. For example, by proposing to answer another survey that is open and that may be related to the previous one in some way. This could be used to take advantage of the desire, or the predisposition, that the person had to complete a survey.

- To link with the Testers Central to help people easily find respondents. - To save information on the quality of answers. This will allow to make a selection of

to which surveys should be considered first. In an scenario with 1000 responses received, some of them may be just random responses. Survey takers need to know what to devote their time to.

- To create alternative versions of the same survey for different user profiles. For example, a version with pictograms and another without pictograms to take into account people with cognitive disabilities. The most suitable version of the survey could be sent to each survey respondent profile. This functionality does not have any of the survey tools studied, which would give added value to the tool developed.



30

- To create an API to expose the active surveys and number of responses received by any survey taker. This information will be shown in the user profile on the DeveloperSpace through a module.

- To be able to copy surveys or questions previously created, as well as to use surveys as a template to reduce the time of creation of new surveys.

- To use the polls to redirect survey respondents to different surveys or websites. The current version of the poll only allows to provide a URL in the “Thanks” section, but it could be useful to change the thanking message and also the associated URL in function of the given answer to the simple question in the poll. The redirection could link to different surveys, to different webpages of products enquired in the poll, to different webpages, for example, Kickstarter to give contribution to one product or other…

- To give the survey taker the possibility to choose between different themes or styles, so that the created survey or poll has a more corporative style or that is more in line with the style of the topic.

- To manage deadlines of surveys/polls, so that it is possible to define when the survey/poll closes and is no longer available for survey respondents.



31

Annex I: Glossary

Abbreviation Full form

3F Feed-back, Feed-forward and Feed-Sideways

AAL Ambient Assisted Living

ACS AsteRICS Configuration Suite

AoD Assistance on Demand

API Application Program Interface

AsteRICS Assistive Technology Rapid Integration & Construction Set

AT Assistive Technology

C4A Cloud4All

D Deliverable

DoW Description of Work

DSpace DeveloperSpace

GUI Graphical User Interface

GPII Global Public Inclusive Infrastructure

ICT Information and Communications Technology

IDE Integrated Development Environment

ISO International Organization for Standardization

IT Information Technology

KPI Key Performance Indicator

P4A Prosperity4all

R&D Research and Development

SAI Shopping Assistance Aid

SP Sub-Project

UI User Interface

UL Unified Listing

UX User Experience



32

Abbreviation Full form

WP Work Package


Executive Summary1 Contribution to the global architecture2 Introduction3 Engagement strategy through feedforward, feedback and feedsideways mechanisms3.1 3F in the DeveloperSpace3.2 Examples of use scenarios

4 Survey tool in Prosperity4all4.1 Prosperity4all survey tool vs Existent survey tools4.2 Survey tool used in DeveloperSpace and SAI/UL4.3 Privacy and ethics4.3.1 Survey creation process4.3.1.1 Question types4.3.1.2 Adding questions and sections4.3.1.3 Adding response quotas4.3.1.4 Statistics

4.3.2 Filling in the resulting survey

4.4 Survey & Polling Tool

5 Architecture5.1 Components5.1.1 Front-end5.1.2 Back-end

5.2 Survey tool sequence

6 Conclusions and Future WorkAnnex I: Glossary

d206.3 consumer participatory r&d mechanisms · 2017. 2. 20. · wp206 has developed three main...

Documents