Alexander G Mirnig

Sandra Troesterer

Elke Beck

Manfred Tscheligi

To Trust or not to Trust Six Recommendations for System Feedback in a Dynamic Environment

Keywords: trust, automation, dynamic web services, feedback design

. The outcome we present in this paper is an adapted list of trust principles for dynamic systems.

Introduction: The User in A Dynamic Environment

As technology advances, the status quo of static web services is increasingly on the verge of being replaced by more dynamic solutions (e.g., Facebook's dynamic targeted advertising based on likes, etc. is probably one of the most well-known examples for this). The additional flexibility and convenience such a dynamic context can provide comes at the price of new privacy and security issues. These have to be tackled before a truly dynamic web can be regarded as a realistic alternative to today' still majorly static web services. A dynamic web platform is a framework for a multitude of web services which are presented to the web service end user, who comes into contact with only a very small part of the whole platform (see Figure 1 -service end users), in a dynamic way. The ANIKETOS project 1 , which our research is based on, is one such attempt at providing a platform for secure and trustworthy Internet services. The number of services presented to the user depends not only on the user's requirements, but also on whether or not the service is regarded as trustworthy by the platform. This is where the dynamic component comes into play, as the status of a certain web service might change due to an attack, a change of policies, etc. In such a case, the platform can adapt to these changes as they happen and replace the service with a different, more trusted one. Being in a dynamic environment means that service consumers will be interacting with applications based on a multitude of exchangeable service components that can adapt in an instant to changes in service availability, price, and security attributes. The security attributes and how well the system can handle them is ultimately what determines the success of such a system. With static and disconnected web services, a user might lose trust in the one web service they had a bad experience with. But if that one web service is part of a service platform, then the user might not only lose trust in the web service, but in the entire service platform the web service is part of. Thus, one bad apple could quite easily spoil the whole digital fruit basket, making it all the more important to ensure trust in the system at all times.

Currently it is not intended that the service end user is notified about any changes (recompositions) taking place "behind the user interface" by the platform developers, i.e., the replacement of a service component with a similar, but more secure and trustworthy one (see Figure 1 for an illustration of such a dynamic web service recomposition) is intended to occur without the end user ever noticing it. On one hand, this way of shaping what the user perceives has many benefits, e.g., to avoid annoying the users with uninteresting system in- formation. On the other hand, the system remains a black box for the user and it is difficult for them to judge whether or not to trust it (e.g., to provide sensitive personal data). But even with such a system a complete secure internet experience cannot be guaranteed. So how should one deal with dynamic systems and their process (in)transparency for users and how does this affect the user's trust in the system? It needs to be clarified, which parts of the black box should be made visible to the user, so that they can make informed decisions whenever necessary, while still benefitting from the added convenience of automatic web service supply.

Trustworthy User Feedback Design

System transparency is an important topic in user interface design in general. In Johnston et al.'s [START_REF] Johnston | Security and human computer interfaces[END_REF] proposal of criteria for a positive HCI (Human Computer Interaction) and user experience applied in the area of security, "visibility of system status" is among these criteria. It is understood as "it is important for the user to be able to observe the security status of the internal operations." Studies have shown that system transparency affects how much trust a user puts into a system. For instance, the model for trust in automated systems of Hoff and Bashir [START_REF] Hoff | A theoretical model for trust in automated systems[END_REF] stresses the importance of design features for the user's perception of a system's performance, such as ease-of-use, transparency, and appearance. Therefore, designing for trust is an important issue ( [START_REF] Riegelsberger | The researcher's dilemma: evaluating trust in computer-mediated communication[END_REF], [START_REF] Riegelsberger | The mechanics of trust: A framework for research and design[END_REF]). Patrick et al. [START_REF] Patrick | Designing systems that people will trust[END_REF] define trust as "a positive expectation regarding the behaviour of someone or something in a situation that entails risk to the trusting party". Specifically for on-line trust, Corritore et al. [START_REF] Corritore | On-line trust: concepts, evolving themes, a model[END_REF] provide the following definition. Onlinetrust is "an attitude of confident expectation in an online situation of risk that one's vulnerabilities will not be exploited". Therefore, by this definition, trust is necessary only in situations of vulnerability and risk. Trust can be considered as a process with the goal of risk reduction, which is dynamic and develops over time ( [START_REF] Diller | The human-computer interaction handbook[END_REF], [START_REF] Corritore | On-line trust: concepts, evolving themes, a model[END_REF]). Risk is "the likelihood of an undesirable outcome" (Deutsch, 1958, c.f. [START_REF] Corritore | On-line trust: concepts, evolving themes, a model[END_REF]), p.751). From that point of view, the higher the user's perception of being in control, the less the user has a need to trust.

Closely related to trust is trustworthiness, i.e., a characteristic of someone or something that is the object of trust [START_REF] Corritore | On-line trust: concepts, evolving themes, a model[END_REF]. Generally, there exist several hints in literature (e.g., [START_REF] Corritore | On-line trust: concepts, evolving themes, a model[END_REF], [START_REF] Diller | The human-computer interaction handbook[END_REF], [START_REF] Belanche | How to make online public services trustworthy[END_REF], [START_REF] Flavián | The role played by perceived usability, satisfaction and consumer trust on website loyalty[END_REF]) that the perception of the trustworthiness of a website is determined by numerous factors such as e.g., ease of navigation or freedom from grammatical and typographical errors. A further reason for different perceptions of the trustworthiness and security of a website is that there is a variety of different attitudes about privacy among Internet users. Ackerman et al. [START_REF] Ackerman | Privacy in E-Commerce: Examining User Scenarios and Privacy Preferences[END_REF] differentiate between privacy fundamentalists, pragmatists, and marginally concerned Internet users. Further categorizations are provided by Sheehan et al. [START_REF] Sheehan | Toward a typology of internet users and online privacy concerns[END_REF] and Berendt et al. [START_REF] Berendt | Privacy in e-commerce: stated preferences vs. actual behavior[END_REF]. Another important factor is acceptance, with the Technology Acceptance Model (TAM) [START_REF] Pavlou | Consumer acceptance of electronic commerce: Integrating trust and risk with the technology acceptance model[END_REF] being one of the most influential and widely used explanatory models for explaining and measuring user/computer/technology acceptance. All of these system-and user-related factors finally point towards the central problem of user feedback design, i.e., how to provide users with security-related information in an adequate way. Which feedback does the user require in order to be able to reasonably judge whether a certain service or website is trustworthy or not? Existing approaches on risk communication and security alert dialogs are manifold (e.g., [START_REF] Egelman | You've been warned: an empirical study of the effectiveness of web browser phishing warnings[END_REF], [START_REF] Bravo-Lillo | Improving computer security dialogs[END_REF], [START_REF] Raja | A brick wall, a locked door, and a bandit: a physical security metaphor for firewall warnings[END_REF], [START_REF] Stoll | Sesame: informing user security decisions with system visualization[END_REF]). But their success is not undisputed -Raja et al. [START_REF] Raja | A brick wall, a locked door, and a bandit: a physical security metaphor for firewall warnings[END_REF] summarize the situation well by stating that users do not pay attention to risk communications, that they do not read or simply ignore security warning texts, as the users often do not understand the messages, nor the options provided to them for responding to the warning. They are unaware of the risks or have an incorrect mental model of the risks. So a truly successful and widely applicable way to communicate trust-relevant information is still not an easy task with a uniform solution. Maurer et al. [START_REF] Maurer | Using data type based security alert dialogs to raise online security awareness[END_REF] have recently shown a very promising attempt at what they call a "semi-blocking" approach to help users identify fraudulent websites. Another interesting approach towards facilitating secure and trustworthy design is the work of Riegelsberger and Sasse [START_REF] Riegelsberger | Ignore these at your peril: Ten principles for trust design[END_REF]. They have put forward a comprehensive set of principles for trustworthy and usable design, that builds on a vast pool of research and puts it into a concise and comprehensible format.

To date, HCI research on system transparency and trust has mostly focused on automated systems (e.g., [START_REF] Hoff | A theoretical model for trust in automated systems[END_REF], [START_REF] Wang | Trust and reliance on an automated combat identification system[END_REF]), recommender systems (e.g., [START_REF] Sinha | The role of transparency in recommender systems[END_REF]), and e-commerce systems (e.g., [START_REF] Corritore | On-line trust: concepts, evolving themes, a model[END_REF], [START_REF] Friedman | Trust online[END_REF]). Contemporary research on automation is mostly focused robotics and social computing (e.g., [START_REF] Glass | Toward establishing trust in adaptive agents[END_REF], [START_REF] Pak | Decision support aids with anthropomorphic characteristics influence trust and performance in younger and older adults[END_REF]). In the blinded project, however, we were confronted with a different kind of system, namely a dynamic system of composite web services. A composite web service consists of several sub-services, and any of these services could be exchanged for another one at any time. So while the individual sub-services are more or less static individuals, the composite web service is the complete opposite and may change rapidly in composition in irregular intervals. Services in the blinded framework are modeled in a goal-oriented language [START_REF] Elahi | A Goal Oriented Approach for Modeling and Analyzing Security Trade-Offs In[END_REF] which depicts threats as their own entities. As Patrick et al. [START_REF] Patrick | Designing systems that people will trust[END_REF] state, "Any security system is only as secure as its weakest link. Invariably, because of their social nature (and because of their human nature), the weakest links are often humans." Therefore, it is not enough to design systems that are theoretically secure without taking the end users into account. It needs to be investigated, how end user feedback has to be implemented in such a framework, so that an appropriate level of security can be provided and communicated, while at the same time not inconveniencing the user.

It can be assumed that what is known about (static) trust design or trust design for automation of a different nature (recommender systems, anthropomorphic robots) might not completely hold for composite web services as well. Therefore, we decided to investigate this issue further and expand the status quo on security and trust design, both in general as well as for dynamic web services. Our goal was to expand what is known about trust and trustworthy design in familiar contexts, with the final aim of being able to derive recommen-dations for trust design in dynamic web systems that are grounded in an actual application Starting from the assumption that automated processes should not be completely invisible to the end user [START_REF] Hoff | A theoretical model for trust in automated systems[END_REF], we focused on the following areas in our research:

-Means of feedback provision about automated processes (behind the web interface) of a dynamic system to users -Conditions under which such user feedback should be provided -The effect of appropriate user feedback on the user's trust in and acceptance of a web service that is part of a dynamic system

We started with the first two of these and conducted an initial, qualitative interview study to collect information on user's needs and priorities regarding trust and system feedback in a web environment with dynamic composite services.

Based on these findings we designed feedback prototypes along with concrete use scenarios for a final quantitative questionnaire study. There, we investigated trust and acceptance in both prototypes. As final step, we contrasted our findings regarding acceptance and trust influence of the feedback solutions in the scenarios with Riegelsberger and Sasse's principles for trust design.

Interview Study

In order to find out what information should be presented to the end-user and how it should be presented, we conducted an interview study with 8 participants (4 male, 4 female), aged between 24 and 40 (mean age 30 years). The subjects were recruited at our institution in Austria, out of a pool of about 45 possible subjects and all of them were external to the project. Each subject had a different professional background, to ensure a diversity of viewpoints. They were all frequent Internet users, i.e., seven participants used the Internet several times a day, and one several times a week for private purposes. Only one participant reported that they are always aware whether the website they are visiting is safe when surfing the Internet, and one participant that they do not care at all. All other participants reported that they only took care in specific cases, such as online banking, online shopping, entering contact data, entering credit card information, transmission of private data in general, when no choice is available concerning a specific website, or when information is only available on an insecure website. None of the participants were familiar with dynamic web services or details of the blinded project. Each interview lasted between half an hour and an hour, was audio-recorded, conducted individually, and in German. The interview was set up in a way that the interviewee got an oral description of a possible scenario at the beginning of the interview, and the questions were posed in conjunction with this scenario. The participant had to imagine a vacation planning website, consisting of different web services, e.g., weather information, flight booking, hotel booking, and payment services. They were told that the website was controlled by a platform in the background that made sure that the services were trustworthy and secure, and that in case a threat was detected, the service would be substituted by another service that fulfilled the security requirements. This was illustrated with an example concerning credit card payment. Questions posed during the interview focused on how the subjects would want to be informed about such a service substitution, followed by questions about whether they would need that information and why they would need it. For the analysis the interviews were first transcribed. Then the individual statements were paraphrased in English and further summarized for each question.

Study Results

In the following we present the most relevant the results from the larger preliminary interview study, together with a summary of the overall implications for our further research at the end.

How should the information be provided? Whereas two participants suggested something like a pop-up window, other participants suggested a less obtrusive way, with the motivation that something like a pop-up window would probably scare them, or that they would think they have done something wrong. The message should not appear as a warning, but could be, e.g., a field at the bottom of the website which nicely explains the issue. One participant suggested to have no message at all, but that the website generally provides a statement in the sense "It is ensured that the most secure service is provided" and in case a change happens, it should be added that a new service is available or has been changed because it is ensured that the safest service is always available. Further information should be not provided directly, "only when one clicks on the message or a part of the message". Also the opportunity to click the window/field away if one is not interested should be given. All interviewees suggested visual feedback, expect for one participant who said they wanted to be informed, e.g., via telephone if there were harmful consequences (high financial damage) for them. The participants preferring a dynamic, situated information provision, e.g., a pop-up window, said that this should be shown to point out the urgency, or that it should show up before logging in, informing that there have been changes of services due to this and that, and whether one agrees to use it.

Which information should be provided?

There was a general agreement among interviewees that information about which service was changed, and why it was changed, is relevant. However, the message should be kept short, and further information could be provided when clicking on a link for further information. Such further information could include a list of web services to choose from, or information about whether a web service was changed very often. Additionally, it was suggested that the message should contain information whether the user has been already affected in some way by the insecurity. One participant, however, mentioned that the feedback should not happen while they were in the middle of doing something, because this would disturb their workflow.

Which information do the users require in order to trust the platform the web service is part of ? One important issue which was raised in this regard is the reputation and popularity of the platform itself. It has to be made sure, that the platform is a certified platform and is secure and safe against phishing threats. Interviewees mentioned that the platform needs to gather reputation over time, and, therefore, information about which websites use the platform, and how this impacts their security, is relevant. Additionally, having the "big players", e.g., Amazon, or bank websites, visibly use the platform would increase user trust in it (or not, in case these big players themselves are untrustworthy in the user's eyes). Two interviewees also mentioned that the platform should provide a "seal of quality" that should be displayed on a protected website.

Conditions for (not) notifying users about web service changes

Kind of web service (security relevance): Services that are related to the provision of personal data (credit card data, log-in data, personal email addresses) were generally seen as very security relevant and in case of an exchange of such services, end users prefer to be notified about the change. For less security relevant web services (e.g., weather information service), users do not seem to want further information about any related changes.

Visibility of changes for users: In case that any changes of web services cause additional changes that are visible for users, then users would like to be informed, because if another service appeared without information, they could get the impression that the website is not alright or has been hacked. Thus, in case of a "something is different" experience, users should be provided with an explanation for the change. In case of a change being unnoticeable to the user, one interviewee explicitly stated to prefer to not be informed about the change.

General trust or distrust in website:

The general impression the website conveys to a user (trust or distrust in the website) also seems to affect their need for information about web service changes. If they generally trusted the website, they did not wish to be informed about service exchanges, whereas the opposite was true for websites they did not trust.

Change of data policy, contact person, web service functionality: Being informed about what happens to personal data once provided to the service, e.g., in case, when data are disclosed to 3rd parties, was of general importance to the interviewees. For some users it is also important to know who the contact person is in case something goes wrong during the use of a service. Finally, an exchange of web services may also lead to changed functionality, which affects the use of the service by the user. In such cases, the interviewees preferred to be informed about any changes regarding data policy, contact person, or web service functionality.

Existing negative consequences for users: In case of existing negative consequences for users due to a security flaw, users want to be informed about this flaw and any related security incidents with the web service(s) in question. One interviewee, for instance, mentioned that if there had been a security problem when they used a service, and the problem affected them personally, they wanted to get informed about it and about what they could do, e.g., to carefully check their credit card bills. Participants mentioned that when loosing confidence in one of the web services, this will also have a trust-reducing effect for any related web service within the application.

User contribution to security: Finally, some users are willing to contribute to security and want to be informed of opportunities to do so. One interviewee explained that when they can actively do something to improve the security of a service, e.g., to update their browser, then they want to be informed about these possibilities.

Overall, our primary finding was that, even in a dynamic environment, the users expect to receive feedback in the traditional and established ways. So as the logical next step in our research, we wanted to know whether this preference of traditional feedback still held true when actually put into practice. The interviews showed a clear tendency towards the need for feedback in cases where a change directly affected the user and potentially put them at risk. Risk and its influence on the desire for feedback is not a strictly binary affair [START_REF] Diller | The human-computer interaction handbook[END_REF], we wanted to take closer look at the extent to which risk influences the need for feedback. Based on our findings, we decided to examine two cases of risk for our follow-up research: (a) cases in which both the user's personal data and their money are at risk; and (b) cases in which only a user's personal data is at risk. Considering the dynamic environment and its high feedback potential, it was quite surprising to still see so many non-feedback related factors being mentioned. So It seems that appropriate and well-designed feedback might not be enough to ensure trust on its own. Although it can certainly maintain a certain level of trust, that trust likely has to be built up beforehand via other means.

Building on the results of the interview study, we decided to conduct a workshop involving only HCI and usability experts (all external to the project) to create low fidelity feedback design prototypes as examples for how feedback about dynamic web service recompositions might look like in practice. With these we would then prepare a final, quantitative study focused primarily on trust and acceptance. In the workshop, our general approach was to put the designers into the shoes of a particular user type via a persona [START_REF] Cooper | About Face 3: CoThe Essentials of Interaction Design[END_REF]-like user description, and have them experience a certain scenario of an interaction with dynamically exchanged web services. To achieve this we decided to develop and make use of a user type description, more specifically a description of a privacy pragmatist (which is likely the numerically broadest user group [START_REF] Ackerman | Privacy in E-Commerce: Examining User Scenarios and Privacy Preferences[END_REF]) according to Westin's General Privacy Concern Index [START_REF] Kumaraguru | Privacy indexes: A survey of Westin's studies[END_REF]. To avoid characterising only a particular subgroup of security pragmatists and to keep the characterisation as broad as possible, we described the user type such that it could not be classified as a purely circumspect/wary [START_REF] Sheehan | Toward a typology of internet users and online privacy concerns[END_REF] or identity concerned/profile averse [START_REF] Berendt | Privacy in e-commerce: stated preferences vs. actual behavior[END_REF] user re-spectively. The workshop participants, six in total, were divided into two groups, and each group was given the aforementioned user type description as well as a scenario. Both scenarios (an online payment and a forum post scenario) were designed in a way so that the recomposition component was initially invisible to the user. The outcome of the workshop were two paper prototypes designed to provide adequate feedback for both scenarios. These would then serve as the basis for the follow-up questionnaire study, in which we wanted to investigate, how the users would react to these scenarios and the prototype designs (i.e., whether these feedback solutions were perceived as adequate by them as well).

Questionnaire Study

The aim of the questionnaire2 was to evaluate on a broader basis whether website users wanted feedback regarding service recomposition in scenarios of different risk (personal data vs. payment credentials) whether the provided feedback solutions are helpful in terms of acceptance of and trust in the website. Therefore, participants were given the textual description of the two scenarios in randomized order, followed by questions regarding the general use of the described website, general need for information about the occurring service recomposition, and items regarding acceptance of and overall trust in the website (based on existing questionnaires ( [START_REF] Pavlou | Consumer acceptance of electronic commerce: Integrating trust and risk with the technology acceptance model[END_REF], [START_REF] Master | Measurement of trust over time in hybrid inspection systems: Research articles[END_REF], [START_REF] Mcknight | Trust in a specific technology: An investigation of its components and measures[END_REF]) and adapted for our purposes). In addition, participants were provided with an image of the corresponding feedback prototype for one of the scenarios developed in the workshop (see Figure 2 and Figure 3) with textual explanations of each step, before being asked to answer the questions. The scenarios were chosen randomly, so that each participant saw one scenario with the feedback solution, and the other one without in random order.The participants were then asked whether they would like to be informed about the service recomposition in the proposed manner. After that, they answered the 30 adapted trust and acceptance items (e.g., "The website is deceptive.", "I could imagine using this website", "The website is reliable", to name a few). We chose this approach in order to be able to compare acceptance and trust in the website when (1) no feedback about the service recomposition is given to cases in which (2) feedback about the service composition is provided. Our assumption was that providing feedback to the website user should raise the acceptance of and trust in the website, compared to the no-feedback condition.

The questionnaire contained 38 questions in total, including demographic questions (age, gender, education), which were asked at the beginning. The items had to be answered on a 5-point Likert scale. Answering the questionnaire took about 10-15 minutes, and participants could win one of five Amazon vouchers worth 20 Euro as incentive. The questionnaire was distributed via several channels (student distribution list, Facebook, online portal of the Austrian National Student Union). In total, we received 101 completed questionnaires. The mean age of the participants was 26 years (SD=8.59); the youngest person was 18 and the oldest 65 years old. Female participants comprised 75%, while 25% were male. Some of the results that were gained from the online payment scenario questionnaire were discussed at a workshop at SOUPS 2013 [START_REF] Raja | No choice, no trust? A Turn for the Worse: Trustbusters for User Interfaces Workshop[END_REF]. In the following sections we describe the scenarios and prototypes that were created in the design workshop, followed by the questionnaire results for each scenario.

Scenario 1: Online Payment

Data at risk: payment credentials. A web shop offers its customers the possibility to add several payment options as well as all the necessary information to complete a financial transaction to their customer profile. The user must then choose one as the default payment option and rank the remaining options according to his/her preference. At the time a purchase is made the system will automatically attempt to the transaction via the default payment method. If this fails for any reason, the system will try again with the next in the list and so on, until it is either successful or has exhausted all available payment methods, all without any additional user input. In the case of a successful transaction, the user is not immediately notified of any failed attempts the system might have encountered internally. The reasons for failed payment attempts range from harmless (e.g., temporarily busy server) to severe (e.g., stolen credit card or malware infection). In this particular case, a payment is made and, after payment via the default option fails, successfully concluded via the second option. The prototype for the online payment scenario (see Figure 2) displays multiple animated progress bars (one for each payment method) upon the user confirming their purchase. If one payment method fails, the prototype would halt its respective progress bar, grey it out, and shift focus to the next method's progress bar, until payment succeeded. Once that happened, another window opens that informs the user of the successful transaction as well as any unsuccessful attempts. Each mention of an unsuccessful attempt would contain a link to wherever the user could find out more about the details as to why that particular attempt had been unsuccessful (e.g., to the credit card company's website). Generally, 14% of participants confirmed that they would use a website with automated payment transposition, whereas 37% indicated that they would rather not use such a website and 48% stated that they would not use it by any means. This high rejection seemed to further suggest that trust in such a system would have to be built in advance, as opposed to more traditional static services. In general, 78% of participants replied that they want to be informed in all cases about the payment transposition, 17% would prefer to be informed, and only 5% did not wish to be informed. This confirms our initial assumption that there is indeed a need for adequate feedback among a significant majority of all participants (i.e., the black box should not remain completely invisible to the user, even in a dynamic system).

Half of the participants were presented the feedback solution as described above and shown in figure 2 (the others did not receive this feedback). These participants were further asked whether they would want to be informed about the payment transposition in the presented way. More than a half of the participants (60% ) replied that they wanted to be informed in this way while 40% would prefer another way. Comparing the feedback and the no-feedback condition, we could not find any significant differences regarding the acceptance of the website, independent of whether the participants were happy with the feedback solution (t(76)=1.569, n.s.) or not (t(68)=-.420, n.s.). For trust, we found different results. Participants who were satisfied with the feedback solution did indeed show significantly higher trust in the website when feedback was provided (t(77)=2.546, p<.05).

However, 40% would have preferred a different feedback solution. Here we also found no difference regarding trust in the website compared to the nofeedback condition (t(68)=-.146, n.s.). To account for that possibility we had included the possibility to comment on which feedback the participants would prefer. Approximately 40% were dissatisfied with the overly passive nature of the feedback solution. They wanted to be able to choose whether the system should try again with the second credit card or cancel the payment as a whole. Another 20% expressed that the red warning box at the end (see Figure 2) had frightened them too much. They had automatically associated it with errors, danger, and money loss -regardless of the fact that payment was eventually successful.

So while we can conclude that, even in dynamic systems, the need to keep the user informed at all times takes priority over convenience, the discrepancy between effective feedback and convenience is not to be underestimated and can potentially devastating effects, considering the low initial trust users seem to put in such systems.

Scenario 2: Forum Post

Data at risk: personal data. An Internet Forum is split into a private and a public section. The private section is visible only to registered members, the public section to everyone. In this particular scenario, a posting is made in the private section, containing personal details such as name, mailing address and phone number. During the time the post is written, but before it is submitted, owing to unfortunate circumstances the private section is switched to be visible to the public as well, so that at the time the user clicks "submit", the message is visible to everyone. The user notices this only a day later upon noticing that all sections of the forum are accessible without having logged in beforehand. We consciously chose a scenario in which the default configuration was sub-optimal in order to elicit when and how the user would want to be informed about and deal with such cases. The prototype from the forum post scenario (see Figure 3) notifies the user of the change in forum visibility directly via private message as well as via a notification in the system and privacy settings menu. Links to both sections are visible all the time (envelope and lightning bolt in the top frame) and superimposed with an exclamation mark whenever an important change occurs. In addition, the prototype featured a real-time warning system that worked similarly to an autocorrect function: It scans the text typed in for strings that look like addresses, telephone numbers, etc., highlights them and gives the user a brief warning that the information will be posted in a public section. In addition, the user also receives a brief recommendation on how to handle potentially sensitive data (e.g., "You might want to send this as a personal message instead."). Upon trying to send the message, the user receives another warning and is prompted to confirm that they want to send the message. They are presented with three options: send the message, delete it, or edit it. The button to edit the message is highlighted by default.

Scenario 2 Questionnaire Results

After being given the textual description of the scenario, participants were asked whether they would use the described website to post their contact details. Only 18% replied that they would use it, whereas 49% expressed that would rather not use it, and 33% that they would definitely not use it. An overwhelming majority (84%) wanted to be informed by all means if a change in the privacy Fig. 3. Forum post scenario prototype excerpt settings occurred, whereas 11% would rather be informed and only 3% were not interested in being informed at all. Once again, half of the participants were presented the feedback solution as described above and shown in figure 3, while the other half did not. Almost all of the participants (92%) presented with the feedback solution for this scenario, replied that they want to be informed in this way, while only 8% would have preferred another way. Here it was mentioned that some general hints and tips at the end with the possibility to confirm, cancel, or change would be better as it could be "exaggerated and disturbing if a warning appears at every underlined word". As opposed to scenario 1 we could find highly significant differences regarding acceptance (t(99)=-3.67, p<.001) and trust (t(99)=-9.20, p<.001) in the website depending on whether feedback was provided or not. Acceptance (M=3.31, SD=.60) and trust (M=3.40, SD=.65) were higher when feedback was given compared to when no feedback was given (acceptance: M=2.90, SD=.53; trust: M=2.34, SD=.50). We believe that this is due to the much higher satisfaction with the provided feedback solution as compared to scenario 1.

Summary Regarding feedback modality, it seems that established ways of providing user feedback work and are understandable as well as acceptable in cases of dynamic web service exchanges. Furthermore, we can confirm that when high or medium risk is involved, the need for adequate and frequent feedback is higher than the desire for convenience, even in a dynamic system. Even so, a solution like the one in scenario 2 (potentially underlining every word was considered to be too much) shows that there is a fine line that separates what is necessary from what is too much.

It should be noted at this point, that when we designed the scenarios, we wanted to simulate a world in which dynamic web service systems were already part of a user's everyday web experience. We did this in order to gain more natural reactions and results that are less influenced by any sense of novelty of dynamic service transposition. So we took interactions we assumed everyone would be mostly familiar with (online payment and forum posting) and included a dynamic component. This also meant that the scenarios were only similar in principle to how a dynamic web platform would operate. While we succeeded in eliciting familiarity from the workshop participants, the dynamic component seemed weird and alienating to some. We received comments like "I would never use a service that works in such a strange way." or "But why does it work exactly like this? That seems very strange to me". Scenario 2 (forum post) seemed particularly unrealistic in this regard. It could furthermore be assumed that the high rejection rates (14% and 18%, respectively) of the feedback solution in the questionnaire study is at least somewhat due to the scenario description not being entirely adequate. In retrospect, it might have been better to put less emphasis on the user's familiarity with a given scenario and to focus more on making it work exactly as it would in a dynamic system instead.

The feedback solution for scenario 1 had a significantly positive effect on the user's trust in the system as opposed to when no feedback was given, but only when the way feedback was provided was accepted by the user. The same was true for scenario 2, except that we could not find a significant difference for participants who did not accept the feedback solution, due to the low number of participants who were dissatisfied with the feedback from scenario 2. Our finding, that adequate feedback does indeed increase trust in the platform, might not be very surprising on its own. However, automatisation and convenience are two of the main benefits of dynamic systems. So it is interesting to see a clear priority of feedback over convenience even here.

Discussion

In the following we discuss and analyze our results from the interview and questionnaire study, contrasting them (if applicable) with the principles for trust design developed by Riegelsberger and Sasse [START_REF] Riegelsberger | Ignore these at your peril: Ten principles for trust design[END_REF]. Our aim is to derive recommendations for security feedback and trust in dynamic websites and to point out, which particularities have to be considered in this specific context.

Trust assessment: According to Riegelsberger and Sasse [START_REF] Riegelsberger | Ignore these at your peril: Ten principles for trust design[END_REF], a user's assessment of the trustworthiness of a website is always a secondary task to their primary goal, whichever that might be. The whole point of automation in a dynamic web system is to let the users focus on their primary tasks. The interviewee's preferences expressed during the interview studies seemed to emphasize that as soon as a user has to devote more effort to trust assessment than to their initial primary goal, the automated system loses its purpose and advantage over traditional systems. So establishing trust as well as providing adequate security becomes an even more difficult balancing act in the case of dynamic systems, as inadequate trustbuilding strategies and/or feedback solutions might lead to the system losing its main advantage. Hence, it should be kept in mind at all times when designing for a dynamic systems, that trust assessment is a secondary task of primary importance.

Risk: A dynamic service platform cannot remain a completely invisible black box once risk for the user is involved, or the user's uncertainty will increase, and their trust in the platform decrease as a consequence [START_REF] Dzindolet | The role of trust in automation reliance[END_REF]. The results from the interview study showed a clear influence of risk on the desire for feedback among users, i.e., while our interviewees wanted to be informed, e.g., when financial risk was involved, they did not care about changes of weather services. The high rejection rates of both scenarios from the questionnaire study further suggest, that the benefits of dynamic services do not counteract the potential risk of personal data or even money loss. Although we also have to point out here, that the participants did not get any further information about the underlying system responsible for the web service recomposition, i.e., information in terms of a trust seal (as wished by some participants in the interview study) or information about its reputation was missing. Hence, we certainly had the worst case scenario here with the website user knowing nothing about the "security guard in the background", i.e., the trustee was "opaque" to the trustor. Furthermore, a problem lies in the fact that a potential risk for the user might not always perceived as such. It is, therefore, further recommended that feedback messages should contain information on the type of risk involved, in order to gain the user's understanding and their trust, but only if it is really warranted. This goes hand in hand with the principle of "Trust requires risk and uncertainty" by Riegelsberger and Sasse.

Reliance: From both the interview and questionnaire studies we found that users have very low initial trust in a dynamic web service platform. This is certainly in part due to the fact that such services are not yet very widespread in today's Internet. Another factor that is likely a great influence here is what we like to call the "opaque trustee" phenomenon, as mentioned above. The interview study showed a desire of users to know who they are interacting with. So the users know of the fact that they are interacting with a multitude of services, but it cannot be expected of them to separately assess every single of these services with regard to its trustworthiness. However, if the user has had successful interactions with the system and its services, then the resulting reliance should take precedence over the unrealistic expectation of having to assess each potential web service's trustworthiness individually. So we suggest to go even further than Riegelsberger and Sasse's original principle "Support reliance, as well as trust", and argue that in dynamic systems, reliance is fundamental for trust and reliance-fostering measures should be treated as important as (or perhaps even more important than) traditional trust building strategies.

Feedback density: Security feedback is a difficult balancing act of giving the user all the information necessary without annoying or frightening them. A high density of warning messages or similarly alarming feedback might easily intimidate a user and scare them off from using a certain web service. Nevertheless, the emphasis the design prototypes put on frequent and dense feedback, together with the relative success these feedback solutions had in the questionnaire study, suggests that in risk-involving cases the emphasis should clearly be put on informing and warning the user, with less regard for potential side effects. In dynamic systems the user needs to be able to act immediately on any potential security issues. This is only possible if these issues are clearly perceived as such by the user. However, one question remains at this point. Although most participants indicated in the questionnaire study that they wanted to be informed about the service recomposition by all means, further focus should be put on the active perception of such feedback over a longer period of time. As pointed out in section 2, after some time website users might get annoyed by these messages or just click them away without reading them. Furthermore, it still needs to be investigated how frequent web service recompositions, and with it frequent security feedback, would impact the overall trust in the website.

Choice and control: When using a dynamic platform, the user is already delegating many of their choices to the platform. It is therefore very important that, when any event occurs that is important enough so that the user needs to know about it, the user is able to make a choice. The results of the questionnaire study clearly showed, that the feedback solution for the payment scenario was less preferred than the feedback solution for the posting scenario. In the former scenario, the users complained about not being given a choice (as opposed to the posting scenario) when the feedback was given, even though the scenario had allowed a multitude of choices via a user preference menu. This means that the user needs to be able to make an active choice right as the feedback happens, regardless of any other choices made by the user before that time. If the user perceives that they have no control at all even when risk is involved, they will not trust the platform. This goes hand in hand with the previous recommendation regarding the security feedback, in that a user will appreciate feedback that offers them to make a choice over being railroaded. From our findings we can only confirm this for cases in which risk is involved and, as a consequence, recommend this strategy to be applied only in such cases and not overload the user with information in low or no risk cases.

Color coding: The perception of trust signals also depends on the situation the user is in at the time of interacting with the system. So if there is a multitude of situations a user of the system could potentially be in (e.g., using a payment service vs. reading a news site), then these differences must be accounted for. In our research we found that a high feedback density, with an emphasis of clearly warning the user, was acceptable over a more passive approach in risk-involving cases. However, a large number of participants from the questionnaire study was not satisfied with the feedback provided for the payment scenario. Apart from the problem of no choice mentioned above, many users had expressed dissatisfaction with the color coding, which had mainly adhered to common practices (red to warn the user, green to express everything works normally, etc.). However, when a web service recomposition happens, conflicting information has to be provided to the website user, i.e., that one service is secure and working, while the other is not. We conclude, that it is better to avoid signal colors that connote danger or peril in cases of feedback in dynamic systems. In such cases, the warning should be communicated via the feedback text and not via its color.

Conclusion and Future Work

We wanted to know how and under which conditions security feedback in dynamic web systems should be given and what its influence on user trust is. After a qualitative study, in which we explored these questions from a user perspective, we refined our findings in a final quantitative study. We matched our findings to the trust design principles laid out by Riegelsberger and Sasse [START_REF] Riegelsberger | Ignore these at your peril: Ten principles for trust design[END_REF] and were able to generate a concise list of recommendations for security feedback design in dynamic systems. This list shall serve as a reference for user-system trust design in HCI. There are still some unanswered issues that need to be investigated in the future. In our investigations, we focused on scenarios involving financial risk and the risk of losing personal data. While these rather medium to high risk cases are certainly the most important ones, we only gathered preliminary insights for low or no risk cases in the interview study and did not examine long-term security feedback effects in the subsequent study. More research with actual high-fidelity prototypes is needed for a more decisive answer on how feedback should be given in such cases. In the workshop for developing the feedback prototypes, we were working with a security pragmatist persona in order to cover the majority of Internet users. Although this is a good starting point, we believe that further research is needed on other (more extreme) user types. A one-for-all approach would be desirable, and we believe that shedding more light on the different particularities of certain user types, would help to refine and adapt security feedback in dynamic systems.

Fig. 1 .

 1 Fig. 1. The user in a dynamic composite web service environment (Image c Per Håkon Meland)

Fig. 2 .

 2 Fig. 2. Online payment scenario prototype excerpt

available at http://aniketos.icts.sbg.ac.at/questionnaire.html

Acknowledgments

This work was funded by the European Union Seventh Framework Programme (FP7/2007-2013) under grant 257930 (ANIKETOS; see http://www.aniketos.eu/).


Gabriella Lucci
email: gabriella.lucci@isti.cnr.it

Fabio Paternò
email: fabio.paterno@isti.cnr.it

Understanding End-User Development of Context-Dependent Applications in Smartphones

Keywords:

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

In recent years we have witnessed the use of computers in an increasing number of dynamic contexts. The number and variety of users of computational devices and tasks are increasing [START_REF] Scaffidi | Estimating the Numbers of End Users and End User Programmers[END_REF]. Users' backgrounds can vary from management, engineering, construction, education, research, health, insurance, sales, administration or other areas. However, such users share a common requirement for software to support their common tasks, which may vary rapidly. With a different range of backgrounds, their software needs are diverse, complex, and require frequent modifications. On the other hand, slow software development cycles and the lack of domain knowledge on the part of software developers are limitations to addressing the requirements of different users. End-user development can help to mitigate this gap. Lieberman et al. [START_REF] Lieberman | End-user development: An emerging paradigm[END_REF] defined End-User Development (EUD) as "a set of methods, techniques, and tools that allow users of software systems, who are acting as nonprofessional software developers, at some point to create, modify or extend a software artefact". The main EUD approaches have mainly considered the desktop platform and applications that are unable to adapt to the changing context of use. For example, desktop spreadsheets have been the most used EUD tools so far. Often, EUD approaches support users in composing and customizing sets of available basic elements developed by programmers. Such basic elements are represented by and composed through intuitive metaphors, such as the jigsaw in which the basic elements correspond to the pieces to compose, or iconic data flow representations in which the icons correspond to the basic elements. HANDS [START_REF] Pane | Using HCI techniques to Design a More Usable Programming System[END_REF] was an interesting contribution in investigating how to use HCI techniques to design a more usable programming system. It was a desktop environment exploiting an event-based language; the events considered were those related to application objects, while in this study we focus on how to indicate the reaction to events occurring in the context of use.

More recently, some EUD work has considered user mobility but in a limited manner. MIT App Inventor [4] is an EUD tool that allows users to create applications on the desktop to be executed on Android mobile devices, thus it still does not support development directly on the mobile device. MIT App Inventor expresses the application logic through OpenBlocks [5], where programming is performed by combining jigsaw pieces. Domain specific tools have also been developed targeting contextsensitive applications ranging from support for a set of template applications for tourism [START_REF] Ghiani | Cicero Designer: An Environment for End-User Development of Multi-Device Museum Guides[END_REF], domain-related content management to support guided tours [START_REF] Celentano | An end-user oriented building pattern for interactive art guides[END_REF], up to an EUD environment using concepts such as event-based rules and workflow rules [START_REF] Realinho | An event-driven workflow framework to develop context-aware mobile applications[END_REF].

More generally, desktop EUD environments lack the advantages of enabling endusers to create applications opportunistically in mobile scenarios. Recent advances in smartphones have enabled the creation of mobile EUD environments. Contributions for mobile EUD address: easy parameter contextualization for mobile applications, as in Tasker [9] (one of the Android apps considered in the study presented in the following); frameworks to support mobile authoring and execution, as in Puzzle [START_REF] Danado | Puzzle: a visual-based environment for end-user development in touch-based mobile phones[END_REF]; creation of UIs through sketching or by adding interactive techniques in the touch screen [START_REF] Seifert | Mobidev: a tool for creating apps on mobile phones[END_REF].

The evolution of EUD for mobile applications is particularly important because users' mobility and the usage of smaller screens drive the need for context-awareness. However, the research in this field is currently at an early stage. Floch [START_REF] Floch | A Framework for User-Tailored City Exploration[END_REF] describes the initial design of a city guide that can be tailored by end-users in order to include information from different service providers according to the visitor's position and visiting purpose. Our aim is to reach a better understanding of the requirements that should be satisfied by general end-users development environments that also offer the possibility to specify how the interactive application should behave according to the context of use. A first contribution in this direction has been recently put forward [START_REF] Ur | Practical trigger-action programming in the smart home[END_REF] but it has only considered practical trigger-action programming in the smart home by using the IFTTT ("If This Then That") Web environment, which still requires some technical knowledge greater than that of average persons.

More precisely, in the study that we present, we have considered three Android apps, which aim to support even user without programming knowledge to define their context-dependent applications that exploit the smartphones' sensors and capabilities. We have conducted an analysis of the three environments from two viewpoints: expressiveness (to what extent they support the relevant concepts) and usability (for which a user study has been carried out). We conclude with some indications drawn from this study that can inform future work. Tasker is ds is in the on the user on (which is called context) or the actions (grouped in tasks). Unlike other solutions, in Tasker when a context type is selected for specifying a condition, then it is no longer available for another use within the current application (profile). A Tasker profile can contain up to four conditions. In addition, Tasker provides some specific functionalities to better handle the elements. For example, it supports an invert functionality that changes the state of an element (e.g. wifi active with this function becomes wifi deactivated). Figure 1 shows the initial steps in creating a context-dependent application in Tasker. The user starts a profile, and indicates first the type of context (Time in the example) and then specifies the corresponding parameters (in this case from 9:00 to 20:00). Tasker requires that when users specify a condition then they have to immediately indicate one or more corresponding actions. If an additional condition is to be added, then at the end of the profile creation the condition specified firstly should be selected, followed by the Add button in order to indicate the additional condition. As shown in Figure 1, at first the Tasks and Scenes tabs are also available. Tasks allows users to identify a set of actions that can be associated to a condition later on, while Scenes allows users to personalize some user interface elements that can be used to trigger a task. Tasker also allows users to specify what should happen when a condition is no longer satisfied. A further feature is the use of variables that allows users to indicate actions for unknown data in advance, for example to visualize in a notification the current state of a connection or to send an SMS when a call is missed.

Atooma

Atooma stems from the work of a young startup. Its first appearance was in September 2012, when the application became available on the Android Market and can be downloaded free. At the Mobile World Congress in 2013, Atooma won the Mobile Premier Award competition, obtaining first place among more than a thousand concurrent applications. To date, the number of downloads of the app is between 100,000 and 500,000. Atooma represents the condition/action model using the IF … DO … representation through circular representations to indicate the relevant categories and elements. Figure 2 shows how to specify with Atooma whether the battery level is less than 20%. It requires four steps, one to select the category of the condition (mobile), next the type (battery), then the attribute (level), and lastly the corresponding value (less than 20%) In Atooma an application can contain up to five conditions (even of the same type) and up to five actions. It is also possible to share the Atooma applications with other users.

Locale

Unlikely Atooma, Locale is not a free application but can be purchased for 7 euro and 99 cents. Its release took place in 2008, and the number of installations is in the range of 50,000 / 100,000.

The main feature is its extensibility. The application in fact has a limited number of integrated elements but allows users to extend its functionality through the use of more than 400 Plugins downloaded from the Android Market (free or pay-for).

The process of creating a Situation is not sequential: the user can arbitrarily decide the selection order of the elements because the interface is designed to show simultaneously (i.e. on the same screen) buttons for adding conditions and actions (in this environment they are called Settings), as shown in Figure 3.

Fig. 3. Example of Locale User Interface

In Locale there is no maximum number of conditions to include in a Situation. It is also possible to specify actions to perform when no condition is satisfied.

Android Applications: A First Comparison

Even if we have introduced three applications for the same platform (Android Smartphones) with similar goals, there are some differences in the way they support users in achieving them. In general, they use slightly different vocabularies for the same concepts: application, event, action. In Atooma an application is called Atooma and is structured in an IF and a DO part. Locale supports the development of situations described in terms of Conditions and Settings. Tasker is used to create profiles structured into Contexts and associated Actions. In terms of number of events and actions to specify, Atooma limits them to a maximum of five for both; Tasker only limits the events (max four), while Locale does not specify any limit.

In terms of the development process, Atooma is completely sequential: developers have first to indicate the conditions and then the actions. In Locale it is not sequential and developers can freely choose to specify situations and settings in any order. Tasker is semi-sequential in the sense that the starting point can be either the condition or the action, but if a condition is specified then the corresponding actions must be indicated. Atooma and Tasker also support the sharing of the small context-dependent applications created. Tasker also allows the specification of exit tasks, which are actions to perform when the condition associated with the current rule is no longer verified. In addition, Tasker also supports the possibility to specify an execution order among rules that are triggered at the same time.

The support of logical operators in the conditions definition is rather limited: Tasker supports the specification of the NOT operator through the INVERT element (e.g. it is possible to specify conditions such as "the Bluetooth is not connected"), while Locale allows users to indicate OR conditions.

Expressiveness

In order to analyse the expressiveness of the environments in terms of their ability to support users to specify the relevant concepts, we have focused on the triggers that they allow users to indicate and the corresponding effects. Indeed, the three environments differ in terms of how they model what can be specified (events and actions). For example, right at the beginning Atooma asks users to select from four main macrocategories, Locale provides a list of conditions with some possible parameters, which can be extended through plugins, while Tasker structures the selectable events and conditions in terms of six Contexts. If we gather the elements that all three environments provide for both parts we can obtain a structure as indicated in Figure 4.

Note that what can be specified in terms of conditions is similar to what can be specified in terms of actions, but there are also some differences: conditions can also depend on locations, while actions can also generate alerts. We can also analyse more in detail what they support with the following diagrams, one for the triggers and one for the actions. Tasker has the greatest expressiveness (more than double Locale's) and a number of actions that can be expressed (108) greater than the triggers (83). These numbers are to be attributed to the abundance of support in almost all categories. Figure 6 and7 show that Tasker has a number of features always greater than or equal to Atooma and Locale, with the exception of the Applications (triggers and actions) and Connections (triggers) categories. In Atooma the number of expressible conditions (70) is greater than the actions (48). Its expressiveness result is influenced mainly by the large number of features in the Applications category, but also by those of the Connections, Telephone and Sensors categories. The Applications and Telephone categories appear to be the most significant also as regards the functionality of the actions. In general, the ability to directly access the status and information of some of the applications installed on the device (including social networking applications, such as Facebook and Twitter) significantly increases the total value of its expressiveness. In both triggers and actions, Locale results to have the same number of expressible functionalities (40) and, of the three environments, is the one that has the lowest total expressiveness. On a total of 80 features, 58 are obtained through plugins and this makes it even clearer how few elements are directly integrated into the environment. The presence of plugins, especially numerous in the Phone category, but also in the Sensors and Connections categories, allows the environment to significantly increase its degree of expressiveness, severely limited by the low number of features found in the Applications category and the inability to set conditions that relate to the File category.

Usability

In order to analyse the usability of the three environments we have carried out a user test with 18 users with some familiarity in the use of interactive applications on mobile devices though without any expertise in the field of computer programming. Each participant was asked to perform two tasks of increasing difficulty on all three Android apps. To avoid that users being influenced by the order in which they used the applications, the 18 participants were divided into six groups; each one associated with one possible combination in the order of using the three applications. Before starting the test, each user filled out an anonymous questionnaire aimed at understanding the level of familiarity with mobile devices and their personal attitudes.

As we shall see in the following sections, for each of the environment considered, the test was divided into three consecutive parts: a first training phase, a subsequent phase of tasks execution, carried out by using the think aloud technique and recorded in audiovisual format, and a questionnaire. Once finished, the users' general impressions have been collected in a final questionnaire in which it was required to make judgments on a 1 to 5 scale regarding the three overall applications tested, and provide any comments.

The final stage of the evaluation was carried out by analyzing the quantitative data (number of users who completed the tasks, performance time, etc. .. ) and qualitative information (comments, suggestions, etc. .. ) contained in records and collected through questionnaires.

The versions of the applications used in the test were: version 1.2.6 for Atooma, version 5.0 for Locale, and version 4.2 for Tasker.

Training

Before running the test, a short learning phase was necessary in order to allow the users to understand the purpose of the test and the general functioning of the three Android environments. The learning phase was composed of three steps: 1. Brief verbal explanation of the conditions / actions model implemented by the context sensitive applications. 2. A video tutorial that shows the creation of the following mini-application example:

 From 8 to 18 hours (condition)  If the battery level falls below 20% (event)  Show me a notification with a message such as "low battery" (action)

3. Two minutes of free use of the application in question to become familiar with its interface.

Tasks

Once they finished the learning phase, the users were asked to perform two tasks consecutively using the interfaces just introduced. As mentioned before, the order in which the environments have been proposed to the users depended on the group to which they were assigned in order to balance the learning effect. The two tasks were always accomplished in ascending order of difficulty for each environment. The first was to specify an application composed of one event and one action, the second application included an event, a condition and two actions, in particular they were:

1. When I'm home (condition) -> Activate Bluetooth (action)

2 When I insert earphones (event), if the device is oriented vertically (condition ) -> launch the application " Tuneln Radio" -installed in the device (Action 1) and decrease the brightness of the screen (Action 2).

The users were asked to think aloud during the task performance, and their interactions with the three interfaces were recorded by using the Android app SCR Screen Recorder in order to collect further data (quantitative and qualitative) on which to perform the evaluation. The quantitative data we obtained include:

 the average time to perform the task  the number of users who performed the task correctly  the number of users who failed the task  the number of suggestions offered to complete the tasks.

A person familiar with the environments was always present during the test sessions. Such person also provided suggestions, when requested. The suggestions were divided according to the type of difficulty encountered:  serious misunderstanding of the trigger / actions model or complete misinterpretation of the application interface (in terms of the correspondence between conditions and actions and their logical structure, and how to obtain it in the environment). Such suggestions were associated with unsuccessful task performance because without them the users would not have been able to complete their tasks.  medium, they were linked to poor interpretation of items and categories (they needed suggestions related how to understand the contents of the possible contexts and categories).  negligible, if related to language difficulties (English translation of terms unknown to the user).

Users

The participants were 18 (8 females), their age was between 19 and 35 (average was 26). The majority of them (15 out of 18) possessed an Android device and used various kinds of interactive applications more than 5 times per day. The messaging application WhatsApp was found to be the most utilized; 16 out of 18 users said to use it on a daily basis. Facebook was in second place (12 users), followed by applications for browsing and e-mail, in particular Google browser (12 users) and GMail (8 users). The mobile applications used by the fewest participants were Youtube, Messenger, Instagram, weather applications, geolocalization and navigation applications such as FourSquare and Google Maps.

Task Performance

Considering both the first and the second task performance (which means a total of 36 tasks for each environment), the applications that yielded the greatest and the lowest number of successful task performance were respectively Atooma (32, or 88.8%), and Tasker (28, i.e. 77.8%). Locale is between these two values (30, 83.3 %).

The suggestions of medium entity, which derived from misunderstandings related to the interface (misinterpretations of the elements, the content of the categories, etc. ..), are significant for our purposes, as they allow us to understand which types of representations were unclear.

One participant who requested the medium suggestion was performing the second task proposed by the Tasker environment and was highly uncertain about the function of Contexts. With Tasker, creating a mini-application starts in fact from the choice of one of the six Contexts offered (Application, Location, Time, Day, State, Event). The difference between the roles of the State and Event contexts made it more difficult for the user to find the condition corresponding to the insertion of the earphones. He was therefore advised to focus on the type of condition to be set, abstracting the meaning and trying to identify which of the two contexts could contain the required functionality. After about a minute the user was able to understand that the element of interest was to be found in the State context, since the coupling of the earphones refers to the state of that particular hardware device.

As mentioned before, all serious misunderstanding suggestions were provided when the user did not understand the mechanism conditions / actions or, to be more precise, in cases where because of this misunderstanding users failed to grasp the overall functioning of the application interface and therefore entered an action in place of a condition or vice versa. Thus, without such help the users were not able to complete the task, so they were associated with task failures.

In some cases, even when the users were able to perform a task successfully, their navigation within the application interface followed incorrect paths, a problem which was then corrected autonomously during the course of the test.

Atooma

There were three unsuccessful performances of the first task with Atooma (one user received support to complete and two did not complete the task correctly). In an attempt to set the condition for localization (when at home), two users selected the GPS element, setting it to ON, rather than using the Location attribute. In the questionnaire the two users commented on the error stating that their device requires activation before you can indicate a GPS location.

As for the second task, the main mistake in navigation was related to the setting of the actions, and concerned finding the Radio application to open upon insertion of the earphones. Almost all the users looked for it within the macrocategory Apps, since the label gave them the idea of being able to access all the applications installed on the phone.

Locale

For the first task there was an error in which the user selected a wrong action (notification instead of Bluetooth). For the second task, five users selected the item Screen Orientation Up, thinking that it was equivalent to the condition "if the device is in a vertical position." The error was to proceed immediately to the Orientation element, in an attempt to set the condition on the vertical position of the device.

Tasker

For the first task three users made the same mistake: they set the Bluetooth Voice attribute (instead of Bluetooth), after having found it in the Settings category (rather than in the NET category). Even users who were able to perform the task had some initial concerns about which was the category in which to find the Bluetooth element, and therefore explored most of the categories relying more on reading the labels of the elements rather than the criteria of the logical categorization.

Performance Times

In the calculation of the average performance times we have considered only the tasks that were performed successfully.

First Task

With Locale the mean time of the first task execution was about half than Atooma. We can therefore easily infer that, as regards the performance of the first task, Locale was found to be more intuitive and understandable. In Atooma and Tasker the number of task successes and failures is absolutely identical (15 and 3). Comparing the respective average times, however, the average time for the execution of the first task with Tasker (3'50") was almost a minute longer than Atooma (2'52"). The time difference derives essentially from the fact that Tasker has a much higher number of categories and items than Atooma. Users spent more time searching the attributes necessary to complete the task and, in some cases, the abundance of categories meant that they committed errors whose correction increased the execution time of the task. In particular, twelve users were not able to immediately identify the NET category, which included the Bluetooth element, but explored almost all the categories (especially the Phone and Settings categories). While the minimum time in Atooma (1'27'') and Tasker (1'21'') is similar, the difference between their respective maximum time is around a minute (5'41'' vs 6'44''). Locale shows the most interesting results: it not only has a smaller number of errors and a lower average execution time (1'29") than the other applications, but also the minimum (0'42'') and maximum (3'24'') times are much lower than those obtained with the other environments. Locale results to have the smallest value (0'42'') also with regard to the standard deviation vs Atooma (1'17') and Tasker (1'34''). This means that the differences between the times taken by participants to successfully perform the first task was not very high and that users were able to complete the task using roughly the same amount of time. In contrast, the standard deviation of Tasker and Atooma are much higher than that of Locale, showing extreme variability in the times achieved by the users.

Second Task.

In the second task, the application that required less average execution time was once again Locale (3'35'') followed by Atooma (4'00'') and Tasker (5'14''). The difference between the average time between the latter two even in this case is about one minute. The fact that Locale has obtained the lowest average times in both the first and the second task is due to the greater simplicity of its internal structure. The elements of conditions and actions are grouped into a well-defined, compact set of categories, each one with a few parameters, and this feature makes it easier to search for the relevant element. Regarding the minimum and maximum times, those of Locale (2'29'' and 5'34'') appear once again to be lower than those of the other applications, but unlike the first task, in this case the difference between the minimum and maximum times of Atooma and Tasker is much wider: Tasker min time (3'15'') is almost a minute higher than Atooma (2'44''), while the maximum time (10'27'') exceeds it by almost five minutes (5'45''). The maximum time obtained with Tasker is a clear indication of how complex is to specify more structured adaptation rules through it, also for the abundance of categories for selecting an element. The data related to the standard deviation of the times in the second task are in line with those achieved in the first task, but reveal additional information. The fact that the standard deviation of Locale is lower in the first than in the second task (0'53'') suggests that its value increases with the number of conditions and actions to be set. Atooma, on the contrary, obtained a standard deviation lower in the second (1'01'') as compared to the first task and this suggests that, although the number of conditions and actions to be selected was greater, the execution time depended mainly on the user's familiarity with the interface. The difference between the standard deviation for Atooma and Tasker is greatly increased in the second task. Tasker proves once again to be the application with the most variation in execution times (1'43''), mainly due to the time spent navigating between available contexts and categories.

Discussion

The analysis of the data collected from the test allows us to obtain useful information on which to base our conclusions on the design of the considered environments, and formulate hypotheses for improvements. Atooma obtained the highest number of successful performances (88.8 %) and the sum of the average execution times of the two tasks was 6 minutes and 52 seconds.

The two main mistakes in the first task involved the setting of the current location because users did not notice the presence of the Position element and they immediately headed to the GPS element. This oversight is mainly due to the users being accustomed to dealing with the localization settings of their Android devices requiring prior activation of the sensor. Among the most frequent navigation errors there was a tendency to think that the opening of the Radio application could be done through the APPS category, rather than the Mobile. However, exploration of the Atooma interface, which was for many users enjoyable and fun, meant that users were able to correct their errors independently and without too much difficulty.

Here are some of the considerations expressed by the users: "The logical mechanism is very simple " ; " The graphics are intuitive and the dial reminds me of the old phones "; " IF and DO are easy to understand, the display is clear, you are aware of what you are doing " ; " Once you understand, the mechanism is simple to use and visually intuitive" ; " There are not too many categories and they are well organized ."

The criticisms to the interface were as follows :

"The dial can be confusing because there are a lot of elements in the Mobile category, the dial hides some of them and it is difficult to understand that the hidden elements are more numerous than expected" ; and again: "it is easy to use but the spinning dial hides elements and raises the doubt whether there are further elements in that category ." "The only flaw is that the elements with icons are not in alphabetical order"; " The colours of the major categories are too bright and distracting."

Of the 18 users, 50% said they had received a high level of satisfaction from the use of the application; 33.3% an average satisfaction level, and 16.6% a very high level of satisfaction. The icons and bright colours of the application were particularly appreciated.

Locale scored a good overall percentage of successes (83.3%) and to successfully complete the two tasks users employed an overall average of 5 minutes and 4 seconds. There was no need for serious suggestions. This indicates that the application interface appeared so simple to use that users did not need to ask for external aid. Indeed, the error committed by the users who failed the task (we refer to the second proposed task) was to think that Screen Up corresponded to a vertical position. An oversight which, as users explained, was derived from the fact that inside the Orientation category that was the only sensible choice. Locale, as evidenced by its level of expressiveness, has a limited number of features, especially if we consider only those integrated into the application and not provided by the appropriate plugin.

The comments were mostly positive about Locale :

" There is a clearer distinction between conditions and settings " ; " The button to add conditions and settings is on the same screen, there is the confirmation button and then the items are listed for easy identification " ; "All the elements are in sight because you select from a list " ;

"It has an intuitive interface because the structure is simple and it is not possible to get lost " ; "The elements are arranged in a list with colour icons whose level differs greatly" ; 55.5% of users expressed a high degree of satisfaction; 16.6% an average level and 27.7% a very high level of satisfaction. Locale was positively assessed also for the size and contrast of the icons on the dark background of its interface, which were immediately visible. All 18 users stated that they would recommend it to anyone using the app for its extreme ease of use.

Tasker obtained a total of 77.8% of successful performance, the lowest percentage.

The overall mean time to carry out the two tasks was 9 minutes and 4 seconds. There was a need for four main suggestions and three users carried out errors. Such errors were caused by a misinterpretation of the categories. In particular, the three users in question were highly uncertain about which category contained the Bluetooth element.

What created the most problems to the users was the high number of categories, with many elements within them often represented with the same icon; the presence of Contexts (States and Events) with doubtful meaning; and unclear limitations on how to specify sequence of events/conditions and actions. Indeed, in Tasker after indicating one event it was not possible to immediately specify further events but users had then to indicate the corresponding actions and only afterwards could add further events.

The positive comments on the Tasker interface were limited:

" Not very simple and intuitive, however, it is highly functional and well categorized"; " Fairly intuitive ."

Users provided more negative opinions : "The difficulty is not so much the functions but the whole program" ; " Having to put the action immediately after the first condition makes it difficult to use " ; "It was difficult because it is not clear that I have first to set a condition and after the actions; if I had a profile already created by another person I would not understand anything " ; " The graphics are poor and do not facilitate the use of the app " ; " There are many categories and the elements have the same icon as the parent category " ;

Various users (38.8 %) said they had received an average satisfaction after testing the application; 22.2% , however, expressed a low level of satisfaction. 11.1 % said they were frustrated by the use of the app (level of satisfaction very poor), the same num-ber, on the contrary, said they got a high degree of satisfaction . 16.6% gave a very high level of satisfaction.

Eight of the respondents (44.4%) also indicated that, because of the complexity of Tasker due to the huge amount of categories and items, they would not recommend the application to a friend. All others indicated that they would recommend it to friends only with a minimum of technological experience.

The last question was about which environment the user would use. 44.4% of users chose Locale, 33.3% of them Atooma and only 22.2%, attracted by the expressive potential of Tasker, chose it even at expense of ease of use.

Conclusions and Future Work

This study has provided useful insights on the main features that an environment for end-user development of context-sensitive applications should have. One first issue is associated with the lack of consistent terminology, each environment provides different names for similar concepts, which does not help users to immediately understand them.

We have seen how the most expressive environment (Tasker) is also the one that was found most difficult to use (highest performance time, error numbers, and unsuccessful performance numbers). This provides some interesting indications of the conflict between expressiveness and usability. Thus, there is a need for novel solutions that are able to support high expressiveness as well as usability. It is clear that with the increasing number of categories for grouping the relevant concepts, there is also an increasing risk of misunderstandings unless familiar classifications, icons and metaphors are proposed to represent and manage such concepts. In addition, it is important to improve the user experience in this type of environment, since too much effort in learning and understanding the relevant concepts discourages its use.

The elements that can characterise a novel solution able to improve the user experience in authoring end user development of context dependent applications include: the choice of elements terms and icons immediately understandable without ambiguity; since there are many possible elements they should be structured according to intuitive logical categories that match the mental representation of mobile users; the ordering in specifying events, conditions, and actions should be flexible without artificial constraints; usability should not be at the expense of expressiveness, thus it should be important to still allow users to easily indicate flexible events, conditions and related actions in which the elements can be composed according to various logical and temporal operators, without any particular limitation on the number of events and actions to compose. Future work will be dedicated to better understanding how users classify the concepts that characterise context-dependent applications using a card sorting technique, and then to design a new environment for smartphone able to take into account user mental models and support the possibility of specifying context-dependent applications through an expressive language, such as the AAL-DL (Advanced Adaptation Logic Description Language) [START_REF] Paternò | Serenoa EU Project, AAL-DL: Semantics, Syntaxes and Stylistics[END_REF], in such a way to allow even end-users to exploit it.

Fig. 2 .

 2 Fig. 2. Example of Atooma User Interface

  Figure for Atoom cations su many trig supports actions, a

Fig. 6 .

 6 Fig. 6. Comparison of triggers (event / conditions) supported by type

Fig. 7 .

 7 Fig. 7. Comparison of actions supported by type