1 Introduction

The participation of end-users in the design of Ambient Assisted Living (AAL) solutions is traditionally made through social sciences techniques such as focus groups. This technique implies having representatives of selected target groups that meet together in a room to discuss questions that are raised by a moderator. The goal is to gather feedback and then analyze the outcome to infer key features the system must have as well as the impression of end-users about the interest of the technology.

There are many kinds of focus groups such as full groups (90 to 120 min of discussion among 8 to 10 people), minigroups (similar to a full group but with 4 to 6 people), and telephone group (similar to the previous ones, but conducted through a phone call) [1]. They imply a variety of costs such as recruitment expenses, participants and moderators fees, report elaboration plus transcriptions, external stimuli costs (to foster discussions), travel, preparation and facility occupation, to cite some [1, 2]. The possibility to consider an on-line version is attractive to reduce such costs and to provide some more agile working method, as well as the possibility to reach a wider participation. There is also an additional issue about what is the outcome of the focus group and how to apply it afterwards. If it is a document, there is a risk that the document is not applied correctly or it is even forgotten.

This work presents a web-based tool that assists in the execution of on-line focus groups. This is based on a customization of a widespread content management system, JoomlaFootnote 1, and the use of simulations, which are shown to users as videos representing scenarios of the problem and solutions, to support the discussion. An important contribution also is the approach for characterizing the results of the focus group into a set of formal norms that can be used to validate the simulation and accumulate knowledge about what features the simulated scenarios must have. The normative characterization of focus group results has as an antecedent in the context of admission procedures [3]. That work showed how to apply focus group techniques to gain knowledge on the admission process to a higher education institution, and then proceeded to formalize that knowledge.

The rest of the paper is organized as follows. Section 2 introduces basic concepts on on-line focus groups and how they can be supported by ICT tools. Section 3 addresses the second issue, how to express the main results of the analysis through an operationalization using normative systems. Section 4 exemplifies the approach with a sample case study. Related works are discussed along each section. Section 5 presents the conclusions.

2 On-line Focus Group Requirements

Henning [4] introduces the features of a focus group. A focus group does not pursue the agreement. It is made of people with some similar background or shared experiences that makes them suitable for the experience. The discussion is focused on a single or limited number of topics. Discussion is essential and it must be facilitated by the moderator, who will pose questions to promote the discussion. A non-threatening experience is essential.

Krueguer [5] established six requirements for a focus group interview: it involves people; it is conducted in a series; participants are homogeneous and unfamiliar with each other; it is a method of data collection; data are qualitative; and the discussion is focused. According to Turney and Pockne [6], on-line text-based focus groups can meet those six criteria. The on-line arrangement could be compatible with such features, but others are harder. For instance, the discussion itself in a focus group is recorded and anyone is free to participate. On-line methods could be made via video/audio-conference to give a similar feeling, but this would increase the costs (transcriptions costs to be precise).

On the other hand, the on-line focus group can offer greater anonymity than the telephone focus group approach in [1], but it may constraint the participation if users are not used to the Internet (which, in fact, is much less frequent as years go by). Despite whether the group is on-line or not, a focus group requires previous preparation. The participants have to be selected and the session be carefully planned: what questions and topics to raise, what to do if threatening situations arise, where to invest the discussion time the most. There may be needs to create additional stimuli [1] so that participants know better what to comment about. In the context of AAL, we assume that preliminary questions would be oriented either to understand better the context of the AAL system to be built; or to point out some desirable feature of the AAL system; or to get feedback on some available feature of the AAL system.

After consulting the literature, we decided to do a text-based on-line focus group to facilitate the access to participants. The reason for this approach is mainly to provide a free-text input that allows each participant to express whatever they think without constraints. This generates a posterior problem related with information management, which will be discussed later on. The principal disadvantage of text-based focus groups is inadequate data richness and quality. On-line participants often give fewer details and examples of their opinions or short answers [7]. Also, on-line communication is prone to misinterpretation and may drive to flaming or confrontations due to more extreme opinions [8].

Despite all these risks, scholars argue that, if executed properly, on-line text-based focus groups can be useful [7], especially in certain situations in which task orientation is more desirable than social interaction [9]. This methodology saves time and money because the complete transcription is available instantly, it also implies that participants can reflect on what has been written and refer to previous exchanges that are stored in easily accessible archives [10]. Furthermore, running costs are lower as there is no renting and no participants’ travels.

The size and composition of participants for on-line focus groups are key elements for the success [4]. Instead of performing a pre-selection, it may be worth to think the other way around: to open participation and devise a filter to know which participants meet the group criteria. After the filter, which can be implemented with a survey, it would be possible to conduct people to different groups and let them discuss the topics. Researchers would be free to ignore less experienced groups or to center their attention in some specific groups.

The access for the on-line focus group would be through a web page to reduce technology requirements to a minimum. This web page should include a short survey to filter out the participants. After filling in the survey, each participant would be driven to the proper discussion group page. The page should start with a brief description of the topic of the discussion plus a motivating video about the topic. There is an initial text explaining the aim of the research and how the participants can contribute. Then, the on-line participation would follow, with input forms that permit to give free text feedback, scoring, quote, or reply to other users. In the meantime, moderators could intervene to reorient the discussion or to prevent threatening situations.

These elements can be summarized with the following required features:

  1. 1.

    Create a web page with basic contents that introduce the research, the purpose of the focus group, including some motivating material, like videos.

  2. 2.

    Characterize participants through an initial survey to know more about their suitability towards the study. The initial survey is critical for later actions, since it permits to weight later actions.

  3. 3.

    Recognize which input is providing each individual. The review of each individual feedback needs to be done taking into account the background of the user. For instance, if the person is a health expert, the opinion will be more relevant than if it is a student of the subject.

  4. 4.

    Allow individuals to score the input to signify agreement or disagreement about the statement. This permits users to value which feedback is more relevant according to their opinion. Since users are identified and their profile is known, the importance of the feedback can be weighted too. It would represent situations where people tend to hum in approval when someone says something. Such signs constitute non-verbal cues that the moderator has to pay attention to [4]. An alternative to scoring to facilitate this non-verbal communication would be the use of emoticons. If scoring is anonymous for other participants, it becomes a more direct way of approving/disapproving whatever other people say, which suits better the nature of a focus group.

  5. 5.

    The existence of a score can be used to gamify the participation. Though it may add some bias to the discussion, if opinions with highest scores are highlighted, it can motivate people to contribute more actively.

  6. 6.

    Allow to quote or reply to posts in the discussion. The focus group should not promote the creation of separated discussion groups within the group and all the feedback should keep within the initial topics. Nevertheless, when one user needs to address or precise of another, such activities should not be prevented.

  7. 7.

    Support the moderator with the following basic functions: highlight feedback from the moderator, allow to kick out and ban IPs, also to post text that attracts the attention of the group. These functions pursue that the moderator can actually moderate the group if necessary and act rigorously when needed.

From these features, only the scoring is more extraordinary with respect to the traditional concept of focus group.

2.1 Tools for Implementing On-line Focus Groups

A content management system, such as Joomla, provides a set of modules with support for implementing the required functionality. The basic tool provides identification features (feature 3) plus the capability of setting up web pages with arbitrary content (feature 1). Modules for comments allow to handle moderation (feature 7) and user interaction (features 6 and 4). There is also a dash panel that includes indicators such as most popular topics, most active posters, and similar, which is in line with feature 5. Surveys can be conducted too within Joomla, what would allow to satisfy feature 2.

Figure 1 shows an example of an introductory page for an on-line focus group. On the left there is a simple survey for people that logs in. This survey can be configured by the developer depending on the subject and purpose of the research. The center of the page includes an introduction to the discussion group, with a motivating video. At the right there is the start of the discussion. The discussion happens as a set of comments added after a video that illustrates the problem and a potential solution. The user can approve or disapprove other people’s comments, or reply to them. The video is the cited stimuli in the previous section. It is produced using a software tool for capturing AAL scenarios, called AIDE [11]. This software translates a description of the system into a 3D simulation of the AAL context and the AAL solution.

Fig. 1.
figure 1

The on-line discussion tool. Initial survey and the execution stage (two snapshots to the right side). The later is divided into two sections, the top part with the context (left), and the bottom part with the interaction (right)

Full size image

The Joomla styles have been modified to fit into a 5 in. mobile phone screen, though it is still visible in a 4 in. screen. When the on-line focus group is finished, data is gathered to make a qualitative analysis. Joomla does not facilitate the later analysis of this information (and this is not in the scope of this paper).

3 Formalizing the Feedback from On-line Focus Groups

Feedback from the on-line discussion is formalized in two ways: as a visual specification of the video and as a deontic description of what is allowed and what is forbidden. The video alternative is not developed fully here. The stimuli video from Fig. 1 is generated with the AIDE tool [11]. Since the discussion topic and video do refer to the same topic, it is expected that feedback can be translated too to the video and generate a new stimuli for another, or the same, on-line focus group. The 3D simulation captures the expected behavior of the assistive solution.

The outcome of the discussion in the on-line focus group will be a set of norms to be applied to the AAL case study, which will return the number of violations that have occurred during the generation of a video such as the aforementioned. This sets the development goal for the visual specification of the AAL system: to create a new specification that reduces the number of violations.

In this context, the representation of the knowledge is deontic because it bases on the use of permissions, obligations, and prohibitions. More specifically, the outcome of the discussion group could be expressed using deontic norms, in a language such as Drools, as it is done in [12], which is inspired in the work [13]. This formalism to express the norms is based on rule-based systems. In this kind of systems, there is an antecedent and a consequent, as the example in Fig. 2 shows. There evidences to be found may refer to information injected by the simulation or by other rules. The consequent creates new information, enacting a forward reasoning scheme.

A norm in this context is made of two elements: specific count-as rules [13] and definition of the norm state transitions, which will follow [12] representation. Mainly, the count-as rule will translate low level events into higher level evidences. In the example in Fig. 2, an AgentPHATEvent represents a low level simulation event. This event includes complete information about what is happening, in particular, what animation is the actor playing. The animation indicates what movements are being executed. In this case, the animation is translated as a separated information.

Fig. 2.
figure 2

Example of a count-as rule to identify the animation performed by some actor

Full size image

Time is important here. Drools implements temporal modal logic, but the version used for this development could not express time units or determine how soon, or late, something happens, only whether something happens after, before, or never. In order to cope with this issue, [12] proposed to include timestamps in the Drools facts and process them explicitly. A norm follows the life-cycle that is shown in Fig. 3. A norm is defined by a set of rules that define the transitions. Each norm specializes a generic transition rule.

Fig. 3.
figure 3

Norm life-cycle as presented in [12]

Full size image
Fig. 4.
figure 4

Template for prohibition/obligation transitions

Full size image

By default, a norm will be in the All OK state. In general, the violation in the case of a prohibition happens because an evidence appears that should not exist. In the Fig. 4, the violation is asserted as soon as the evidence is found. In the case of an obligation, because an evidence that should exist, does not anymore. Both cases can be represented through the existence operator in the Drools rule system and activate the state violated norm. The absence of information in the case of the obligation (something is not happening) implies some difficulty. In the Fig. 4, the solution is to consider a time window sufficiently big referred to two evidences that should occur in time farther than TIME_WINDOW. For instance, a person receives assistance whenever the person falls can be expressed as the coexistence of “person is falling” and“person is being assisted” within a TIME_WINDOW.

The transition from violated norm to punish (see Fig. 3) is automatic as long as the evidences that made the norm violated still holds. When evidences do not hold anymore, the All ok state is restored. This is handled automatically by the truth maintenance of Drools and the insertLogical operator. InsertLogical retracts asserted facts when the antecedent of the rule that created them are no more valid, i.e., they were modified and the antecedent is not true anymore.

Violations need to be recorded, and this is done automatically with additional rules that are enabled when a NameOfTheViolatedNorm instance exists.

A norm will represent something the focus group determined that should occur or that should not occur. The difference between a prohibition and an obligation can be as simple as a negation of the existence of the evidence. The concrete application requires some practice, but, in general, it conforms a four step procedure:

  1. 1.

    Translate the events in the system as “countas” rules to generate more high level information.

  2. 2.

    Label the information with the appropriate simulation time stamp.

  3. 3.

    Combine these pieces of information to express what should/should not happen

    1. (a)

      Should happen. Then the user has to define two evidences that should happen within a TIME_WINDOW.

    2. (b)

      Should not happen. Then the user has to identify one evidence that should not exist.

  4. 4.

    Execute the simulation and compute the number of violations.

At the end of the translation of focus group evidences to norms, the result should be:

  • A list of prohibition norms. Referring to events that should not happen.

  • A list of obligation norms. Referring to events that should happen.

Such norms can be stored and associated to the simulation that is being evaluated.

4 Case Study

The discussion with some groups in the context of the ColoSAAL project (see the Acknowledgements section after the Conclusions), has some illustrative cases such as the one that is shown in Fig. 1 under the title ‘Irregular sleep and disorientation’. This was supported by a simulation that depicts an scenario of a person waking up disoriented in the middle of the night. The simulation shows how the smart house assists the person.

Over the simulation, a text was included to explain the simulation and the starting question for participants’ interaction: “Someone with Alzheimer has irregular sleep and disorientation during the night if awakened. Deciding if the person is disoriented requires some information. In the example, a person wakes up during the night. The sensors detect something is going on and the AAL system tries to interact with the person talking to her. It is infrequent to wake up so late and walk around the house. Since the person is not answering, the AAL system decides that the person is disoriented (how the system processes context-aware information is out of the scope of this paper but a discussion is made in [14] and [15]). The question is how much information is needed to determine if the person is disoriented. Using cameras can help to read the body language and others, but they invade the privacy. Electronic wearables can keep better the privacy but are more inexact and less comfortable to wear. The AAL system can ask the person, but it may be annoying to have someone asking everytime. Each solution has its pros and cons. Would you sacrifice privacy and comfortability to have better assistance?”

Then, the question to be discussed is how much privacy a person would give in to have better assistance. As developers, we know cameras are the most effective option, but also the most invading one. This initial feedback is translated into norms following the approach from Sect. 3. In this case, the natural language description is included for the sake of space.

  • Obligation: There has to be more light than (set here the acceptable light threshold) to see. To check this, the simulation needs to return simulation parameters that permit to check luminosity level.

  • Obligation: Actors’ actions have to be visible. This obligation could be subsumed by the previous one.

  • Obligation: The actor should yawn at some point to show the person is sleepy. For this to be checked, two evidences are needed: the existence of a yawn animation (first evidence) within the TIME_WINDOW while using the bathroom (second evidence).

Such norms would be expressed as Drools rules following the templates from Sect. 3 and, then, they would be applied to the simulation in order to produce a quantitative evaluation of how many times the simulation violated the norms. Then, the developer could reorient the simulation with the goal of reducing the violations.

5 Conclusions

This work has justified the need of cost-efficient techniques to implement focus-groups. Performing these on-line contributes to reduce the costs, and is an opportunity to facilitate a wider application of this technique. However, the lack of direct interaction of the group in a room at the same time requires some extra motivation or incentives for participation. These issues have been addressed in the design of a on-line focus group, which is based on a content management system (Joomla in this case), which has been properly configured. The main tool for motivation here is the use of simulations of scenarios of problems and potential solutions. This allows to translate gathered feedback into visual specifications and norms. The support of model-driven development [16] with the AIDE toolbox [11] facilitates an agile development cycle with several iterations, where the on-line focus group facilitates the involvement of end-users and domain experts.