Reducing Stress Factors in User Interfaces

Govert-Jan Slob

May 2012 Student number: 3219615 Mentor: dr. R.M. van Eijk

Contents
Reducing Stress Factors in User Interfaces ................................................................................ 1 Contents ...................................................................................................................................... 2 Introduction ................................................................................................................................ 4 1. Contemporary computer usage............................................................................................... 5 2. Stress ...................................................................................................................................... 6 2.1 Stress on a physiological level.......................................................................................... 6 2.2 The relaxation response .................................................................................................... 7 2.3 Stressor characteristics ..................................................................................................... 7 2.4 Additional stressor characteristics .................................................................................... 9 2.5 The relativity of stressors ................................................................................................. 9 2.6 Towards stress-less software .......................................................................................... 10 3. Calming technologies ........................................................................................................... 10 3.1 Stress-less design heuristics............................................................................................ 10 3.1.1 Not offering visible ability to control interruptions..................................................... 11 3.1.2 Inducing the feeling of being overwhelmed. ............................................................... 12 3.1.3 Giving an uncertain image of time passing by. ........................................................... 12 3.1.4 Using inappropriate tone and emotion......................................................................... 13 3.1.5 Not providing positive feedback to user input and events ........................................... 16 3.1.6 Encouraging prosocial interaction ............................................................................... 16 3.1.7 Inducing time-pressure ................................................................................................ 17 3.1.8 Using naturally calming elements ............................................................................... 17 3.1.9 Not acknowledging reasonable user actions ................................................................ 18 3.1.10 A mystified interface. ................................................................................................ 19 4. Designing a test environment ............................................................................................... 19 4.1 Measuring stress responses ............................................................................................. 20 4.2 Experiment Task ............................................................................................................. 20 4.3 Testing heuristic 1: Reveal ability to control interruptions ............................................ 22 4.4 Testing heuristic 2: Reduce feelings over being overwhelmed ...................................... 23 4.5 Testing heuristic 3: Acknowledge human interpretations of time passing by ................ 25 4.6 Testing heuristic 4: Use appropriate human tone and emotion ...................................... 26 4.7 Testing heuristic 5: Provide positive feedback to user input and events ........................ 28
2

4.8 Testing heuristic 6: Encourage prosocial interaction ..................................................... 30 4.9 Testing heuristic 7: Relieve time-pressure ..................................................................... 31 4.10 Testing heuristic 8: Choose naturally calming elements .............................................. 32 4.11 Testing heuristic 9: Acknowledge reasonable user actions .......................................... 33 4.12 Testing heuristic 10: Demystify the interface............................................................... 34 4.13 Towards a good set of heuristics .................................................................................. 35 5. Conclusion ............................................................................................................................ 36 References ................................................................................................................................ 38

Introduction
Stress is an often used term in our society, and most people will admit to suffer from stress on a regular basis. Job stress, emotions running high at home, and time pressure are some instances of stress that come to mind. Apart from the occasional frustration caused by malfunctioning hardware or software, stress is not often related to the use of computers. However, stress invoked through the use of non user friendly software can certainly be influential, because computers play an important part in our lives, and people use them for extended periods of time on a daily basis. People interact with computers through the user interface of the software. It could be beneficial to know how stress can occur through interaction with user interfaces, which principles are at the root of the cause, and how invoking stress can be avoided. By gaining knowledge of these subjects, we can make steps towards developing software that is more user friendly, because it invokes a minimal amount of stress. Would it not be most pleasant to be able to send e-mails, use your word processor and browse the web while remaining in a calm state of mind and body? At Stanford Universitys Calming Technology Lab Neema Moraveji and Charlton Soesanto have laid the basis for the interest in stress in relation to user interfaces. They have written the CHI 12 paper Towards Stress-less User Interfaces: 10 Heuristics Based on the Psychophysiology of Stress, in which they describe ten guidelines to develop software that provokes a minimum of stress in users. This paper will form the basis of this thesis. The goal of this thesis is to discover which factors in user interfaces can induce stress or calm, and to find out if we can adequately translate these findings into valid heuristics. To achieve this goal, I have done an examination of the literature on stress and relaxation, human computer interaction and calming technology. After introducing the reader to the concept of stress, I will discuss which properties of user interfaces can invoke stress in users, and why. Then I will review the heuristics that Moraveji and Soesanto (2012) developed to guide the development of stress-less user interfaces. Because these heuristics are brand new, I will finish with a description of a design for an experiment to test the heuristics for effectiveness.

1. Contemporary computer usage

Computers have become an important part of our everyday lives and so has the software running on the computer devices. What used to be a desktop device dedicated to business and office applications has turned into much more than that, and computers have become an integral part of our lives. Most people spend hours browsing the web, playing games, listening to music and engaging in social interaction through the use of computers every day. The term computer does no longer solely refer to a desktop model: computers have also taken the form of small mobile devices like netbooks and tablets, and even smartphones can be seen as small computers. The fact that computers have become so mobile and are being used in so many aspects of our lives means that computers and software are becoming ubiquitous: they are everywhere. The right term for this phenomenon is ubiquitous computing: the seamless integration of computers into everyday objects and activities (Weiser, 1991). According to Weiser, we will in the future be surrounded by hundreds of computers in every room, which we will use unconsciously to complete our tasks (Weiser, 1991). Although we do not yet live in a world of ubiquitous computing, we are rapidly moving towards it. Because people now use computers and software on such a frequent basis, and will be doing even more so in the near future, computers have a large impact on our daily lives. The increasing impact that computers have on our lives calls for increased attention to usability of software and the effects that the use of software has on people. The better the usability of the software applications is, the more control software developers have over impacting the users of software in a desired way. If software is, for example, easy and maybe even fun to use, users will be inclined to use the software more often. Computer scientists in the fields of usability engineering and interaction design have devoted their time and effort to developing methods for designing and evaluating software to obtain maximum usability. Jacob Nielsen is probably the best known scientist involved in usability engineering. The design heuristics he has developed are the leading source for software developers looking to design user friendly software and have set the definition of usability. Nielsen's best known heuristics are the 10 he published in 1994: Visibility of system status, Match between system and the real world, User control and freedom, Consistency and standards, Error prevention, Recognition rather than recall, Flexibility and efficiency of use, Aesthetic and minimalistic design, Help users recognize, diagnose, and recover from errors, and Help and documentation (Nielsen, 2005). Because of the available knowledge on usability and the user experience, most software applications nowadays are expected to have a certain degree of usability. What contemporary software design and evaluation guidelines do not incorporate are means to make sure a software product does not induce feelings of stress.

2. Stress
Stress, simply defined, is the nonspecific response of the body to any demand made upon it (Selye, 1973, p. 692). In the case of stress, our bodies respond with biochemical changes to cope with the extra demands of the situation. When talking about stress, it is important to discern between the stressor and the stress response. The stressor, is the event or stimulus causing stress in someone, an earthquake for example. The stress response is the bodys response to the event (Selye, as cited by Lupien, Maheu, Tu, Fiocco & Schramek, 2007). In this thesis I use stress and stress response to refer to the same phenomenon. The situation that produces the stressor, is not necessarily unpleasant: an athlete running 400 meters also experiences the bodys reaction to the demands placed upon his body by the situation (Selye, 1973). Stressors can be relative or absolute: an absolute stressor is a stressor that induces a stress response in every person, such as being in an accident. Because of the aversive nature of an absolute stressor, a stress response will be incited because ones survival and/or wellbeing is at stake. A relative stressor is a stressor that induces a stress response in only part of the population, such as a public speech. This is because relative stressors require a cognitive interpretation, called appraisal, and the outcome of this interpretation decides the degree in which a stress response will occur (Lupien, Maheu, Tu, Fiocco & Schramek, 2007). A relative stressor therefore, is of a psychological nature. Large variations between individuals in the stress response to psychological challenges have been frequently reported by researchers. (Lupien et al., 2007) This means that people experience stimuli in a different manner, and a stimulus that causes a stress response in one individual may not cause a stress response in the next person. In our society, relative stressors are far more common than absolute stressors, and the focus of this writing will therefore be on relative (psychological) stressors.

2.1 Stress on a physiological level

On a physiological level the stress response is often, but not always, characterized by the secretion of stress hormones. When a situation is interpreted as being stressful, our hypothalamus releases a hormone called corticotropin (CRH) which in turn triggers the release of another hormone called adrenocorticotropin (ACTH) from the pituitary gland, which is also a brain structure (Lupien et al., 2007). ACTH travels in the blood and reaches the adrenal glands, located above our kidneys, which then secrete the so-called stress hormones glucocorticoids (called cortisol) and cathecholamines (called adrenaline). The glucocorticoids and cathecholamines make sure our bodies are able to meet the increased metabolic demands. The secretion of these two stress hormones constitutes the start of the stress response where one would, for instance, experience an increase in heart rate and blood pressure to better cope with a situation (Lupien et al., 2007). However, not all events that are perceived as stressful lead to the secretion of the stress hormones glucocorticoids and cathecholamines (Anisman & Merali, 1999; Dickerson & Kemeny, 2004). Stress hormone levels therefore cannot function well enough as an index of the stress response. Furthermore glucocorticoids can also be released in response to positive, non stress evoking stimuli. Another factor complicating stress measurement are the individual differences in the perception and appraisal of a stimulus as being stressful (Anisman &
6

Merali, 1999). These interpersonal differences make reliably measuring stress responses difficult. The stress response that our bodies give when faced with a stressor of some kind is a necessity, and it is not necessarily bad. The altered physiological state of our body in the face of stressors helps us survive and perform better. It is only when the stress response would continue chronically or when it is elicited very frequently that our bodies are in danger of being impacted by the negative aspects of the stress response (Stefano & Esch, 2006). One can also experience positive stress: stress related to positive experiences like getting a promotion, watching a scary movie or engaging in a challenge. Hans Selye (as cited in Lupien 2007) used the terms distress and eustress to differentiate between harmless positive stress and possibly harmful negative stress responses. In this writing I focus on distress in relation to user interfaces. There are many domains on which stress can have a negative impact. Stress has, been empirically connected with cognitive performance and memory (de Quervain, D. J., Henke, K., Aerni, A., Treyer, V., McGaugh, J. L., Bertold, T., et al., 2003; Kopell, Wittner, Lunde, Warrick & Edwards, 1970), depression, neurotic impairment, and other psychological symptomatology (Smyth, Ockenfels, Porter, Kirschbaum, Hellhammer & Stone, 1998) as well as increased susceptibility to infectious disease (Lupien et al, 2007).

2.2 The relaxation response

In a stressful situation our bodys stress response helps us to better handle the demands posited by the situation. When the situation no longer demands extra performance, our body does not need to allocate extra resources to certain areas anymore, and we can enter a state of relaxation. The state of relaxation is reached via the relaxation response: a physiological response characterized by decreased arousal, diminished heart rate, respiratory rate and blood pressure (Benson, 1983). The relaxation responses terminates other physiological processes normally associated with stress (Stefano, Fricchione & Esch, 2006). Once stimulated, the relaxation response induces positive effects for the person invoking the process (Stefano et al., 2006) and this calm state can even help the recovery from many illnesses (Benson, 1983). Factors that evoke the relaxation response are called calmors. Like stressors calmors can be relative or absolute, and the relaxation response depends on the interpretation of the individual receiving the calmor (Moraveji et al., 2011b).

2.3 Stressor characteristics

As I stated earlier, a stressor is often relative, meaning that the stress response is dependent on the interpretation of the stressor, or absolute, meaning that the presence of a stress response is a given fact. But what decides the outcome of the interpretation of the stressor? When will a stimulus or event be interpreted as stressful or not? To answer this question, we turn to the vast literature on stress and the influence of stressors on the hypothalamic-pituitary-adrenal (HPA) axis. John Mason was a physician who spent many years measuring the effects of various conditions - that he thought were stressful - on the levels of stress hormones in human subjects. Mason's studies resulted in three main psychological determinant factors that would cause a stress response in any individual
7

exposed to them (Lupien et al., 2007). He concluded that when a situation feels novel and/or unpredictable and/or gives the feeling that he or she does not have control over the situation, a stress response can occur. Dickerson and Kemeny (2004) measured cortisol responses and found support for the fact that tasks in which an individual experiences outcome uncontrollability correlated with higher cortisol values. However, the experience of loss of control had to occur in the context of motivated performance tasks, in which a certain (important) goal was threatened, to elicit cortisol changes. Uncontrollable contexts can include impossible tasks, time constraints, false feedback of poor performance, and harassment (Dickerson & Kemeny, 2004). The authors argue that uncontrollability may be intertwined with novelty, because situations are often uncontrollable because they are new to a person. They also added that tasks in which performance could be negatively judged by others, thus creating a social-evaluative threat, provoke more cortisol changes than stressors without these particular threats. Videotaping as a form of social evaluation also elevated cortisol responses, but real time presence of evaluative others caused greater cortisol elevations. However, in self-reports of distress, participants in the experiments did not associate social-evaluative threat with greater increases of distress. Dickerson and Kemeny (2004) showed that revealing negative aspects of the self in an anonymous or confidential setting does not elevate cortisol levels" (p. 387). According to Lazarus (1999) a situation will be appraised as being stressful when it is viewed as a threat and has the potential to cause harm or loss (to a friendship, health or self-esteem). Moraveji and Soesanto (2012) have added ones self or associated objects, living things, or property (p. 2) to the list of possible things that are subject to harm or loss. From the literature mentioned above and other literature, Moraveji and Soesanto (2012) abstracted the following four characteristics of stressors that can lead to a psychological stress response in humans. According to them software can invoke stress if it: Feels unpredictable, uncertain, or unfamiliar. Evokes the perception of losing control. Has potential to cause harm or loss to one's self or associated objects, living things, or property. Is perceived as judgment or social evaluative threat including threats to one's identity or self-esteem.

It is worth noting that the above stressor characteristics have been abstracted from research, but have not all been empirically tested. For example, I could not find reports of experiments that were dedicated to testing whether unpredictability indeed invokes stress responses. Moreover, there is little known about the impact that specific psychological stressors have on humans, because most research stems from experiments with animals. There is however evidence to back the claims that perception of losing control and social evaluative threats cause stress (Dickerson & Kemeny, 2004).

2.4 Additional stressor characteristics

According to Lazarus, emotions and stress go hand in hand. When an individual appraises the fate of his goals or values in a situation, emotions arise. (Lazarus, 1999). Each emotion that is experienced has a meaning, and knowing that meaning gives you information about how that individual has appraised a situation. For example, if someone is angry, you know he is demeaned or slighted by the situation. If emotions can be linked to their cause, they might be useful to measure effects of possible stressors in user interfaces. Frustration is a good example of an emotion that can often be related to a stressful situation. When a person has become frustrated, it is clear that a stress response has been provoked by a certain stimulus. Another feature with which a possible stressor could be identified, but that was not included by Moraveji and Soesanto, is violating or endangering important goals or expectations. Lazarus (1999) argues that a persons relationship with the environment becomes stressful when what happens defeats or endangers important goal commitments and situational intentions, or violates highly valued expectations (p. 60). If a certain situation endangers important goals or violates highly valued expectations, it might be a stressor.

2.5 The relativity of stressors

It might seem that a stressor containing any of the above characteristics will always cause stress in a person that is subject to the stressor. It is of course not that simple. As I already explained, almost all stimuli are subject to the appraisal by the individual receiving the stimuli, before that stressor induces are stress response. Lazarus (1999, p. 60) argues for a relational meaning approach to deal with individual differences in appraisal. In this approach, a persons resources that can be allocated to cope with the situation determine whether the relation with the environment is stressful or not. But more important, individual differences in the significance of a persons appraisal are included to deal with the subjectivity of stress. According to Anisman and Merali (1999) the stress response can be mitigated by certain factors in the context of the stressor. Characteristics of stressors that influence the impact of stress response should be taken into consideration when appraising a stressor for its possible impact on the user of the interface. The characteristics of stressors that can influence the stress-induced effects are: the degree to which stress can be mitigated or eliminated by an appropriate response, the predictability of onset of the stressor, the duration or chronicity of exposure, and the timing and frequency of exposure (Anisman & Merali, 1999). It is very difficult and perhaps impossible to predict the impact of stressors using the stressor characteristics, which may severely limit their value. As I have stated earlier, stressor impact depends not only on the stressors characteristics, but also on how an individual appraises the situation that constitutes the stressor, and how that person copes with it. Furthermore, the stressor characteristics are quite generic, and may need to be made more specific in order to better identify stressors. For example, a definition of uncontrollable or threat is not provided, so these terms can be interpreted in many ways.

2.6 Towards stress-less software

In the above chapter I have explained what stress is and how the body reacts to the demands of stressors. I also listed some stressor characteristics which, according to Moraveji and Soesanto (2012), can induce stress responses. However, these stressors are relative and are subject to interpretation: not everyone experiences a situation as unpredictable. Furthermore, these characteristics are still very generic. When, exactly, can a situation be characterized as a threat to self-esteem or as evoking the perception of losing control ? It seems important that these terms are made more specific, preferably by user testing. I also mentioned some extra characteristics with which stressors can be identified, namely the presence of emotion and the violation or endangering of important goals or expectations. Knowing these topics is good, but how can this knowledge of stress and relaxation be useful to developers of software products? That is what the next chapter is about.

3. Calming technologies
There is growing attention for the subject of stress among computer scientists worldwide. At Stanford University, members of the Calming Technology Lab (CTL) have coined the term 'Calming Technology' to define "systems that induce cognitive, physiological and/or affective states of calm for their users" (Moraveji, Opezzo, Habif & Pea, 2011b p.1). In other words, Calming Technologies are (information) systems that are aimed at providing the user with triggers to self-initiate calmors. A calmor, Moraveji, Oshidary, Pea and Fogg (2011) state, is a source causing calm, like a stressor is a source causing stress. The people at CLT distinguish two fundamental types of calming technology, namely calmdedicated systems and calm-augmented systems. Calm-dedicated systems are systems created explicitly and solely for calming purposes (Moraveji et al., 2011b). An example of a calmdedicated system is an iPhone application that provides the user with meditation techniques. Calm-augmented systems on the other hand, are meant for a primary function but include calming elements (Moraveji et al., 2011b). An example of a calm-augmented system is a word processor with a minimalistic user interface and relaxing background music. Calming technology can reduce stress in 2 ways: they can reduce the presence of factors that are interpreted as stressors, or they can enhance the relaxation response. Calm-augmented software is best suited for the first, and calm-dedicated for the second way. This thesis mainly focuses on calm-augmented systems. I believe that these are the systems for which it is most important that they are developed to induce the smallest amount of psychological stress possible. These are the systems that we use the most frequently and that are of the most importance to us.

3.1 Stress-less design heuristics

To develop stress-less user interfaces, designers need to know exactly how to make a user interface that is built to minimize stress provocation. What factors introduce or help omit stressors and how can user interface elements be implemented accordingly? Design guidelines

10

can help to provide answers to these questions and form a standard for designing stress-less user interfaces. Heuristics to achieve usability of software products already exist, and there may appear to be some overlap between these, and the new stress reduction heuristics. The stress reduction heuristics therefore are a complementation to the existing usability guidelines, and were not created to reinvent the wheel say Moraveji and Soesanto (2012). Usability guidelines were created to ensure usability, but not to reduce stress, and although the guidelines may overlap, good usability might not ensure a stress-less user experience. On the other hand, a user interface that adheres to the usability guidelines will most likely be easy to learn and remember, efficient and satisfactory and provoke a minimum of errors. An interface that is easy to learn and remember and that provokes little error will probably reduce the presence of stressors like unpredictability and uncontrollability. However, adhering to stress reduction guidelines that are specifically created to reduce stress should ensure an even more stress-less user experience. The following 10 heuristics were created by Moraveji and Soesanto (2012). They were made with the aim to reduce the likelihood of an interface containing a known stressor. Because the focus of this writing is on identifying stressors and calmors in software, I reversed most of the heuristics to point out elements that a user interface should not have, in order to reduce the likelihood of an interface containing a stressor. Heuristics 6 and 8 seemed better off not being reversed, so they should be interpreted as elements that a user interface should have to induce calm. I have also expanded the heuristics to contain more theoretical background and I have tried to offer an explanation as to why a certain reversed heuristic will likely cause stress. Finally, I attempted to suggest how certain stressors can be avoided or mitigated.

3.1.1 Not offering visible ability to control interruptions.

The first factor in software that is capable of causing stress is interrupting tasks. Users can be interrupted by pop-ups, dialog boxes, or by distractions that draw the attention of the user away from their primary task. According to Moraveji and Soesanto (2012) it is important to have an interface show choices or settings to block, control or temporarily disable interruptions during tasks that require large amounts of attention. When a user is interrupted he or she may experience a loss of control over focus and task performance, because one cannot continue working for some time. Interruptions may also give a user the feeling of unpredictability, when interrupted with an unexpected message. To help users control interruptions, user interface developers should provide easy to find and use options to let the users specify if they want to be interrupted and if so, how and how often. McFarlane (2002) found that interruptions of a primary computer task had profound negative effects on task performance, which dropped by 36% in the interrupted state. The subject matter of the interruption can alter the effects of the interruption on task performance. When relevancy between the matter of interruption and the primary task is high, the negative effect of the interruption is moderated (Cutrell, Czerwinski & Horvitz, 2000). Iqbal and Horvitz (2007) found that users lose context with the interrupted task, and that they take longer to resume the task when there is no visual indicator that helps users remind the
11

suspended task. To battle the loss of context, the authors propose to save the context of the primary task as a whole, so it can be quickly recovered which helps resuming the primary task. This helps users retaining control over their tasks. Sometimes unimportant messages that are shown to the user in the form of pop-ups or balloons, are displayed in such a way that they seem important even though they are not. For example, in Windows XP a balloon pops up telling the user there are unused desktop icons. Besides interrupting the user, this might give the user the feeling of uncertainty as to whether the messages are important or not and if not executing the response that is asked for could cause harm to the user's system. In Windows 7, User Account Control (UAC) dims the screen and makes actions impossible until one has clicked yes or no. This interrupts tasks, causing the user to lose his focus on the primary task. It also creates uncertainty as to whether the product for which the UAC interrupts the task will cause harm to ones computer or not if clicked yes or no. The availability to control these interruptions is hidden in another part of Windows.

3.1.2 Inducing the feeling of being overwhelmed.

The second heuristic of Moraveji and Soesanto (2012, p. 2) begins with the assertion that large datasets are very common in applications that have many users and social elements or use datasets on the web. Examples are web pages showing search results, menus with a lot of breadth and a minimum of depth and sites like Facebook where users often feel they are incapable of keeping up with the myriad of status updates. According to Moraveji and Soesanto (2012) such interfaces can shape the possibility of introducing stressors by making the users feel that they cannot control the amount of information or that they will never be finished using the application (p. 2). They also argue that a persons self-identity can be compromised because a user may feel he or she is not engaging enough with the application, is not keeping up with other users or has not added sufficient input (p. 2). User interfaces that contain many visual elements of the same or different types can also induce feelings of being overwhelmed. Visual clutter makes it harder for a user to quickly scan the field and find what he or she is looking for. A cluttered interface puts a bigger information load on the user and might invoke the perception of losing control. According to this heuristic, user interfaces should offer simple, conveniently laid out screens and must offer the possibility of specifying what interface elements should be shown or hidden from view. Certainly in the early stages of learning how to use new software, overwhelming the users is a realistic danger, because the amount of new information is the largest. One could tackle this risk, by implementing a training feature that blocks certain features from being accessed through the user interface, thus eliminating possible sources of overwhelm.

3.1.3 Giving an uncertain image of time passing by.

According to Moraveji and Soesanto (2012) the progress indicators seen in current software products do not match the way humans interpret time passing by. A progress bar displays the
12

progress of a system task from the systems perspective. Humans have a different perspective on progress because they do not perceive time purely linearly, but experience time as slower the longer one waits (Harrison, Amento, Kuznetsova & Bell, 2007). Harrison et al. (2007) found that users experience time as being longer when looking at a progress bar in which progress was visually slowed down near the end of the process. They perceived time as going faster when progress was visually accelerated near the end of the progress, even if the total time was the same. Harrison et al. (2007) abstracted from this that users are less tolerant to negative progress behavior near the end of the line. Moraveji and Soesanto (2012) thus argue that progress bars that slow down near the end can induce stress by creating unpredictability about when the task finishes or a lack of control over when one can use the system (p. 2). A linear function will give an accurate and effective display of progress for tasks with static completion conditions. These tasks are often not affected by progress slow-downs, and other negative progress behavior. For tasks with completion conditions that can change on the fly, and have inaccurate time estimates, progress bars can be augmented to give a representation of progress that better deals with a user's perception of time. Software developers should therefore not use linear progress bar functions for dynamic processes if they want their users to feel more calm. Instead, progres bars that intelligently distribute progress should be used. These can, for example, help to reduce stress by caching progress at the start of the task, so progress does not have to be visually slowed down near the end of the task. Hogan (1978) suggests that an inverted u-shape can be applied to the relation between perception of time duration and stimulus complexity, meaning that time is experienced as longer when stimulus complexity is very low or very high. In practice, stimuli that bore us or are too complex for us, cause time to be perceived as longer. Stimuli of average complexity help time to be perceived as shorter. User interface designers may be able to use this principle by presenting appropriate stimulus complexity when users are waiting for a system process to finish.

3.1.4 Using inappropriate tone and emotion.

Moraveji and Soesanto (2012) claim that stress can be induced because users engage computers with over learned social behaviors such as politeness and reciprocity (p. 2). Users seem to apply social rules and expectations to computers. If systems do not regard these communication expectations that users have, stressors might be introduced because users are unpleasantly surprised by inappropriate tone and emotion. The authors put forward that designers should introduce human tone and conversational emotion when appropriate (p. 2). A computer is not a person that expresses emotions of its own and is not aware of a users emotions. A computer does not refer to itself as I, and it has no human-like attributes. In pre-experimental interviews, users have acknowledged that computers should not be understood in human terms and should not be treated as a person. Despite the above, users still mindlessly apply social rules and expectations to computers (Nass and Moon, 2000). According to Nass and Moon (2000) individuals overuse human social categories, apply gender stereotypes to computers and ethnically identify with computer agents. For example, users find a male computer voice more friendly when used for evaluating a users
13

performance. Users also prefer male voices to handle masculine topics, and a female voice to handle feminine topics. Concerning ethnicity, users identify more with computer agents of the same ethnicity as their own. Moraveji and Soesanto (2012) argue that users engage computers with politeness, and that this should be taken into account when developing software. Reeves and Nass (1996) conducted experiments in which participants communicated with computers and where asked to evaluate a computers performance afterwards. Their conclusions where that computers are social actors, and get the same treatment as people: users were polite towards computers, and reciprocally, also expected the computer to be polite to them. Whether a computer presented itself using text or voice did not make a difference. Reeves and Nass (1996) also argue that when a technology (or a person) violates a politeness rule, the violation is viewed as social incompetence and it is offensive (p. 29), so it is of major importance that a user interface is polite. The findings by Reeves and Nass (1996) that people treat media as they treat people, were called the Media Equation theory. Other research by Nass and Moon (2000) also showed that users expect and execute reciprocity: if a computer was helpful towards the users, they showed more helpfulness towards the computers too. Goldstein, Alsi and Werdenhoff (2002) criticized the findings of Reeves and Nass that people are polite to computers. They conducted an experiment similar to that of Reeves and Nass (1996), but could not reproduce the results that Reeves and Nass found in their experiment. They also argued that the experiment by Reeves and Nass (1996) was not set up thoroughly enough to warrant reliable results. Goldstein et al. (2002) concluded from their experiment that people are not polite towards small handheld computers, and that the Media Equation theory should perhaps only be applied to desktop computers. Shechtman and Horowitz (2003) also criticized the Media Equation, because they found significant differences between the behavior of participants towards computers and their behavior towards humans. Like Goldstein et al. (2002), Shechtman and Horowitz argued that the phenomenon of politeness towards computers should be further investigated before it can be applied to user interface design. The politeness theory created by Brown and Levinson in 1987 can be used to investigate the role of politeness in user interfaces. According to this theory, politeness is about attenuating threats to anothers face: a self-image someone wants to project. Two types of faces exist: the positive face concerns desires to be liked, admired, ratified and related to positively, while the negative face is about peoples freedom to act and not be imposed upon. The threats are carried by face threatening acts: communication acts that damage ones face. A threat to ones negative face is when an interlocutors freedom of action is obstructed. A threat to the positive face occurs when the speaker does not care about someones feelings and desires. Examples of face threatening acts are: expressions of disapproval, contradictions, disagreements, interruptions and more (Brown and Levinson, as cited by Wikipedia, 2012). To attenuate these face threatening acts, people apply certain politeness strategies. User interfaces can also apply these tactics, to relieve stress caused by face-threatening acts. Techniques to be polite include: indirect wording, the use of euphemisms, minimizing imposition and interruptions, apologetic wording and compliments.
14

Another way to ensure that interaction with the user interface conforms to the expectations of the users, such as politeness, is applying Grices Maxims. These are four basic principles that constitute the rules of polite interaction (Reeves & Nass, 1996, p. 29). The principle of quality says that speakers should always tell the truth, and preferably in an accurate way. User interfaces usually tell the truth, but are not always accurate. For example, a user interface that lets users know they are at step 3 of the process may be true, but is not very accurate if step 4 is 10 times more work than step 1. Quantity is about not contributing too little or too much to the conversation. User interfaces frequently violate this rule, for example by giving rather short and abstract error messages. The third maxim is that of relevance. According to this rule, what one says should clearly relate to the purpose of the conversation (Reeves & Nass, 1996, p. 30). An example is disabling features or choices in menus, depending on the context of the situation. The last maxim is clarity, and holds that contributions to an interaction should not be obscure (p. 30). In user interface design, avoiding ambiguity in messages is a form of clarity. However, one must be careful when trading ambiguity for precision, because precision in the form of technical language can be hard to understand. An important point of Grices maxims is that when a speaker, or user interface in this case, violates any of the rules, users think of it as a violation of social conduct and will ascribe this to failure of the user interface (Reeves & Nass, 1996). In an experiment aimed at discovering if a polite computer tutor helps to take student affective goals into account, Wang, Johnson, Rizzo, Shaw and Mayer (2005) implemented the politeness theory of Brown and Levinson. They discovered that a polite computer agent had a positive effect on self-efficacy and performance, but surprisingly the direct tutor agent was rated as friendlier than the polite agent. These results can be valuable when designing user interfaces, certainly when designing for human-tutor interaction. Attributing human tone and conversational emotion to computers, or anthropomorphism, as Moraveji and Soesanto (2012) seem to prescribe, might not create a solely positive experience for users. Shneidermann (as cited in Sharp, Rogers & Preece, 2007) argues that attributing human qualities to computer systems can make people feel anxious and make users feel inferior or stupid. This is particularly true for those that use first-person dialog and screen characters. The most heard complaint against computers that pretend to have human qualities, is that people find them very annoying. On the other hand, Reeves and Nass (1996) reported that human-like systems that praised and flattered users had a positive effect on how users felt about themselves. Nevertheless, numerous other studies (Sharp, Rogers & Preece, 2007) have shown that making interfaces more human is counterproductive. This is largely because users expect the systems to be more human-like than they really are, and become disappointed when they find out the systems are not that intelligent and affectively capable. Implementing human tone and conversational emotion in user interfaces could help reduce users perceiving unpredictability and threats to their self-esteem. Making software polite and reciprocal towards users and taking gender and ethnicity into consideration could very well help users feel more at ease while using the software. However, developers also need to be aware of the negative effects that human-like interface agents might have, and that being overly polite can make users feel annoyed.
15

3.1.5 Not providing positive feedback to user input and events

The fifth design heuristic of Moraveji and Soesanto (2012) put forward posits negative feedback as a stressor, and positive feedback as a calmor. This heuristic states that negative feedback that is given by the system when users have, for example, entered invalid input or tried to activate an unavailable feature, can induce stress. The system's negative response can threaten one's self-esteem or trigger the feeling that users cannot control exactly how to provide the information that is required. With regard to the fourth heuristic, Moraveji and Soesanto (2012) say that negative feedback can also "violate expected norms of conversational interaction with social agents, further increasing stress by being unpredictable" (p. 2). The authors also argue that by acknowledging successes and simplifying tasks, interfaces can build confidence and resilience to stress in their users. In other words, positive messages that acknowledge successes can be used to induce a calming effect. Negative feedback should be omitted or rephrased more positive. Finally they propose that by pointing out mistakes that are common, users can realize they are not the only one that makes mistakes, and thus feel less threat to their self-esteem. By providing positive feedback to user input and events, user interfaces may help reduce stressors. Designers have to be wary though, that users are not treated in a way that might seem childish or overly simplified, as they might feel they are not taken seriously by the system. While acknowledging successes, it seems important that an interface's messages are not interpreted as a means to condition the user towards a desired behavior, for this may make users feel annoyed or not taken serious. A message like Well done, you are doing great! may be interpreted as patronizing by the users on the long term, which may threaten self-esteem.

3.1.6 Encouraging prosocial interaction

A very common context in which stressors often appear, is the context of social interaction. When an individual is afraid that his or her task performance can be negatively judged by others, a stress response may occur (Dickerson & Kemeny, 2004). These stressors are most likely to occur in a group context, a situation where software usage plays a trivial role. However, even when used in a non group context, software applications can have a large impact on maintaining our social lives. E-mail, Facebook and Twitter are the most obvious examples of influential services that are enabled through a user interface. Instances where a user thinks he fails at presenting himself to others in a desired way, are situations where stressors may occur. According to Moraveji and Soesanto (2012), "applications with social components have greater potential for stress as users manage selfpreservation" (p. 3). They argue that software that facilitates an dencourages prosocial interaction can make the chance of social stressors occurring smaller, by integrating simple ways of communicating prosocial interaction. An example of a software feature that is useful for this purpose is spelling control, which makes the users feel more secure about the way they present themselves to the outside world, because spelling is checked by a computer. Other examples are likes and +1s which make communicating with others simple and lowers the risk of making an unwanted impression.
16

3.1.7 Inducing time-pressure

Time pressure sometimes occurs during software usage, after having downloaded updates for example. Moraveji and Soesanto (2012) argue that time pressure during interaction with software can invoke stress responses. The reasons, according to the authors, are that "users may feel a lack of control when they are pressured for time or even be worried about how they appear in a competitive sense if the time they took to complete a task feels too long". Relieving users from time pressure, by leaving out countdown timers from user interfaces and not forcing users to take action within a certain time frame seems the appropriate counter to this stressor. Putting time pressure on people is known to cause stress responses when people appraise it difficult to maintain their task goals (Maule and Hockey, as cited in Maule, Hockey and Bdzola, 2000). Maule and Hockey found that participants that had to make decisions were more anxious and energetic when presented with a deadline. The increase in anxiety and being more energetic is accounted for by the awareness of the need to work harder when completion time is restricted, the authors argue. Long periods of continuous time-pressure however, may just lead to increased fatigue say Maule, Hockey and Bdzola (2000). An example of time pressure can be found in Windows Vista. It is known to put time pressure on users after having installed an update. In Vista, the user is sometimes confronted with a small window in which a small progress bar shows the time until the system will reboot to finish the installation of a certain update that was automatically downloaded. This might give user the feeling they are not in control of the time at which they want to reboot their system, because the window puts time pressure on the users. Nowadays, most user interfaces do not impose time pressure on users anymore, possibly making this heuristic slightly superfluous.

3.1.8 Using naturally calming elements

The eighth design heuristic brought forward by Moraveji and Soesanto (2012) is the use of naturally calming elements to reduce stress. Integrating natural elements into user interfaces and interactions should improve calmness in users. According to Ulrich et al. (1991), who did research on stress recovery during exposure to natural environments, exposure to natural elements can provide a shift towards a more positively-toned emotional state, positive changes in physiological activity levels, and that these changes are accompanied by sustained attention/intake (p. 201). The researchers showed that short exposure to (artificial) elements of natural environments has an important function in facilitating recovery from stressors as daily hassles and annoyances. Additionally, individuals exposed to natural settings reported improved feeling states and showed lower stress levels in physiological indicators. Participants exposed to natural settings showed much greater restoration in positive affects, anger/aggression and fear. On a physiological level, participants exposed to nature settings showed greater restoration from the stress indicators: muscle tension, heart pulse transit time and skin conductance. Japanese researchers found that allowing patients comforting background music during anaesthesia, increases the acceptability of the experience of anaesthesia. Patients presented with calming background music also showed significantly lower blood pressure and heart rate
17

during the recovery phases from anaesthesia (Tsuchiya et al., 2003). Swedish researchers showed that music may decrease postoperative pain, and that postoperative music therapy may reduce anxiety, pain and morphine consumption (Nilsson, Unosson & Rawal, 2005, p. 96). It appeared that slow and flowing music with 60 to 80 beats per second had positive outcomes on relaxation and pain relief. Literature has suggested that music for therapeutic use should have the following characteristics: be non-lyrical, consist predominantly of low tones, comprise mostly strings with minimal brass or percussion (Nilsson, as cited by Nilsson, 2008), and have a maximum volume level at 60 dB (Staum and Brotons, as cited by Nilsson, 2008). This research raises the question if natural elements and music may also have a positive influence on the unconsciousness of humans in other settings, like software usage. Because the mentioned experiments were not conducted with the use of computers, it remains unclear if natural elements and music that are incorporated in user interfaces will have the same positive effects on stress reduction during software usage. However, the results of the research mentioned above certainly suggest the possibility.

3.1.9 Not acknowledging reasonable user actions

According to Moraveji and Soesanto (2012) a stress response can be triggered when a user expects to take an action that is not available through the user interface. If the unavailable action does not become available on short term, the stress response can grow. On any screen or dialog, there exist a number of reasonable actions that users may want to take. Even if those actions are disallowed by the system, they should be acknowledged or guided in some way, the authors say. Not acknowledging these actions may lead to stress because users can perceive these situations as unpredictable or uncertain and as a loss of control. Some user actions might not seem necessary from a developers point of view, but from a users perspective they might be needed to ensure stress-less interaction with the software. For example, users may find it important to have an undo action available at all times, so they can easily recover from mistakes. Developers, unlikely to make mistakes, might not see the importance of this action in many occasions. Not acknowledging user actions may evoke the perception of losing control because a user can feel limited in his actions when reasonable user actions are not sufficiently acknowledged. It may also introduce uncertainty and/or unpredictability in some cases. However, it might not always be a good idea to offer all the actions that the users expect. There is even a usability principle, called constraints, that tells designers to restrict interaction that can take place at a given moment (Sharp, Rogers & Preece, 2007). Consequently, a balance between constraints and availability of actions is important when seeking to reduce stress with this heuristic.

18

3.1.10 A mystified interface.

The final design heuristic of Moraveji and Soesanto (2012) states that a user interface should be demystified, meaning that one should not be presented with an interface that offers tens of options of which the intended use is not directly clear. In other words: a user interface should be self explanatory. An example of a mystical user interface is one in which buttons are not accompanied by a title that explains their function, or one that uses very generic appearance for the buttons. Unknown tokens and symbols can also counteract the principle of this heuristic. A mystified interface may cause stress because it introduces uncertainty and unpredictability, caused by unknown interface elements. It might also affect a users selfesteem when he or she is forced to consult the manual or ask for help, when confronted with a mystical interface element. This heuristic seems to interact with the second heuristic of Moraveji and Soesanto (2012) reducing the feelings of being overwhelmed, because a mystical interface is probably more likely to appear overwhelming as more cognitive processing is required before things become clear. On the other hand, a lack of important interface elements may cause a more minimalistic interface, which can be less overwhelming. For example: a user interface that has mystical interface elements such as buttons without a title or description, requires more thinking from the user, but contains fewer stimuli to overwhelm someone. The effect of a mystified interface on being overwhelming is not yet clear and may need to be tested.

4. Designing a test environment

Thus far I have listed and explained several design heuristics that can be used to produce stress-less user interfaces. When a user interface is being developed according to these guidelines, it should offer a user experience that is characterized by a minimum of stressors capable of invoking stress responses. At least in theory it should. To be able to determine if the design heuristics are valid, and really achieve what they propose, the heuristics need to be put to the test. In the following section I have prepared a plan for developing a test and research environment (TRE) that is aimed at testing the heuristics for legibility. The test environment will be a software program that is able to reproduce several different conditions, by activating or deactivating the implementation of the heuristics. By doing this, researchers can assess the differences in the stress responses elicited by the users while they use the software. The most obvious use of the test and research program is testing the effects of a stressful condition, in which a heuristic is not taken into account or is implemented in the opposite way (thus containing more stressors), versus a presumed stress-less condition in which a heuristic is correctly implemented. If a heuristic does not seem to have a significant effect on stress responses, it will need to be reviewed and adjusted.

19

4.1 Measuring stress responses

Depending on the method, researchers can measure the levels of stress in the individuals during, or after letting participants interact with the softwares user interface. Some methods of measuring stress are: measuring cortisol levels through blood or saliva, measuring peoples emotions, appraisals and other symptoms through questionnaires, and even measuring blood pressure, heart rate variability and vagal tone. Many scientists in the heretofore mentioned literature have used cortisol as an index for the stress response. For the purpose of discovering what factors can make the use of software stressful, it seems necessary to drop cortisol response as a measurement tool of stress. As I stated in chapter one, not all events that are perceived as stressful lead to the secretion of the stress hormones, and these hormones can also be released in response to positive, non stress evoking stimuli. Another complicating factor, is the relatively mild nature of the stressors present in user interfaces. Things like overwhelming interfaces and inappropriate tone and emotion are unlikely to produce significant changes in levels of stress hormones, because the stakes during computer usage are not very high. However I believe it can cause stress that is not directly followed by a physiological response. Software usage, when causing stress, is a relative stressor and the induced stress will be determined by the appraisal and coping style of the user. Because of the interpersonal differences in appraisal of stressors, the interpersonal differences in coping abilities and the unreliability of cortisol as an index of stress levels, stress responses can be difficult to measure. A very accurate measurement tool may therefore be necessary. Perhaps, a combined approach of the mentioned methods can be an effective means to measure levels of stress in people working with user interfaces. Experts on stress measurement should be conducted to develop an accurate method.

4.2 Experiment Task

To be able to create an effective experiment using the TRE, it is necessary that the software is dedicated to performing a specific task that would also be carried out in daily life. I have chosen for the TRE to be a word processor. Word processing is a common task that many perform frequently, making it an important environment where the effects of design heuristics can have a real impact. Naturally, the users need a purpose for using the TRE, a task to fulfill while they participate in the experiment. Giving the user a task to perform will help create a setting in which resembles the way users normally use software. It is important that the task facilitates testing all the heuristics, and thus meets all the requirements listed on the coming pages, and some general requirements mentioned below. An example of what an experiment task could look like is a task that is made of several different subtasks. The subtasks are all different, which helps to provide sufficient diversity in interaction with the user interface. In the experiment task, the participant is presented with several documents that contain small assignments that the user is asked to fulfill. After completing each assignment, the user is asked to save the document using a given filename
20

format and close it. During the execution of these subtasks, the user makes use of different features of the TRE to complete the assignments. The assignments should be as follows. In the first task the users must change the color of the text in the first document to a custom color they have created using the built in color picker. In the second task, the users have to insert a table that has 15 rows and 5 columns, and insert data into the fields. In the third task, users must insert a diagram, and fill it with data from the table they created in the second document. They have to re-open the document from the second task to complete this task. In the fourth task the users use the menu to navigate to, and insert a photograph that is located on the hard drive. Extra assignments can be added to the experiment if this is deemed necessary. General requirements: The TRE features a general settings menu in which all features mentioned on the following pages can be set up. o Tick boxes to enable or disable features. o Text boxes for entering parameters. The TRE must contain the basic features of word processing software. The user interface of the TRE must be designed according to contemporary usability guidelines, so the enabling or disabling of the stress reduction heuristics is the main variable influencing tress responses.

21

4.3 Testing heuristic 1: Reveal ability to control interruptions

In the case of heuristic 1, the goal is to test if having control over the frequency with which certain interruptions are allowed to appear, helps the users remain less stressed. The following features are required in the TRE to perform a successful test: Functional requirements: An interrupting (pop-up) window must be able to appear and interrupt the user. After the first appearance, the user must be able to set the frequency with which a certain interruption is allowed to appear. The user must be able to escape/postpone the interruption.

Nonfunctional requirements: The ability to control interruptions must be accomplishable in only a few simple steps. The interruption must be clearly visible and impossible to ignore on first appearance.

To test if revealing or hiding the ability to control interruptions has an effect on a users stress experience, users will need to perform the experiment task using the TRE. While performing that task, the TRE must interrupt the user in such a way that they will be forced to shift their attention away from their primary task, towards the interrupting interface element. The interrupting interface element should block the desired visual field and so disrupt the users work flow. The interruption should be a prominent but small window or box that pops up in front of the main window that the user was viewing. The window or box must contain some message or visual or auditory representation. When the user is interrupted for the first time, they must be given the option to indicate how often the interruption is allowed to be shown again in the future. This option must be available to the user in a clearly visible and easy to operate manner, and it should be placed in the same window that comes with the interruption. The option to disable or enable interruption possibilities should be incorporated in the general settings menu of the software. With these features, researchers can compare two conditions. One in which a user is confronted with an interruption of which the frequency with which it appears cannot be controlled. And a condition in which an interruption occurs along with the option to indicate whether it should re-appear at all, and if so, how often.
Figure 1: Limited possibility to control interruptions

To properly test this heuristic, it is important to test the effect of being able to control the appearance of interruptions as opposed to testing the effect of the interruption itself, which is not the goal of this heuristic and is something that has already been researched by others (McFarlane et al., 2002; Iqbal & Horvitz., 2007) It seems rather complex to distinguish between testing the effect of interruptions and testing the effect of the ability to control
22

interruptions, because the first is needed to accomplish the second. I therefore suggest that both be tested in conjunction. An example of a TRE test situation: After having worked for 5 minutes the users are presented a small window that appears in the middle of the users view and interrupts their workflow. In the small window is a drop down menu in which are several options that change the frequency with which this interruption will appear: set frequency to 60 minutes, 120 minutes, daily and an option to postpone the current interruption. There also are 2 buttons: ignore, which will change nothing in the frequency of appearance, and OK, which will confirm the selected option.

4.4 Testing heuristic 2: Reduce feelings over being overwhelmed

To experience if reducing the amount of information and reducing the amount of features and options in user interfaces really makes the user experience less stressful, a test is required. Again, the users must engage in performing the experiment task using the TRE, and these features are needed: Functional requirements: The researcher must be able to select which interface elements must appear or not. The TREs user interface must be able to show a large number of interface elements. The interface elements must surround the workspace.

Nonfunctional requirements: The interface must look overwhelming when all elements are enabled. The interface must be able to offer simple conveniently laid out screens.

The TRE must be able to present the users with a user interface that is filled with data, information, features, tools, bars, menus and buttons. Due to these elements, the user interface will appear overwhelming. This will make the users feel they have insufficient control over the amount of information on display and makes it harder for them to focus in their primary task. The TRE must also offer the possibility to change the appearance of the user interface by changing it into a tidy, simplistic user interface. To do this, researchers must have access to a settings menu in which they can choose to enable or disable certain interface elements to create a non-overwhelming interface. In the TRE, the interface elements must be visible on all four sides of the workspace when enabled. With the help of the features described above, researchers can create 2 conditions to which participants can be exposed. The first condition involves presenting an overwhelming interface, enabling many interface elements. The second condition is the opposite of the first, and here all interface elements are tuned to create a non-overwhelming interface. One must be cautious not to disable too many interface elements, because an interface that is nonoverwhelming but also non-realistic might then be created. An example of a TRE test situation: The user is presented with an interface that contains many buttons, bars, windows and information. The workspace is surrounded by those
23

elements, and the visual field is filled with information, making the user feel overwhelmed with stimuli.

Figure 2: A user interface containing many elements.

Figure 3: A user interface containing few interface elements. Figure 4: A user interface containing almost no interface elements.

24

Above, I have provided three screenshots to illustrate the possible gradations of designing an interface to reduce feelings of being overwhelmed. The first two screenshots are from Microsofts Word 2007, the first using the standard user interface, the second using a user interface adapted to the demands of this heuristic. The third screenshot is from OmmWriter Dana, an example of calm-augmented calming technology. The OmmWriter user interface is very minimalistic, and offers no visual distractions, possibly making concentrating on the task easier.

4.5 Testing heuristic 3: Acknowledge human interpretations of time passing by

To see if this heuristic is valid, one should test if acknowledging a human interpretation of time passing by, and distracting users while they have to wait, makes users feel less stressed. The requirements for this test are: Functional requirements: The TRE must be able to (seem to) perform a dynamic system task. The user interface must be able to show a progress bar. 2 types of progress indicators: o one that displays progress according to actual progress. o one that displays progress with an acceleration near the end. The user must be able to set the type of indicator to be enabled. The system must incorporate a means to distract the user while displaying the progress bar. The distraction must not obscure the progress bar.

Nonfunctional requirements: The distraction must make time seem faster. The distraction must be interesting to the user. Distracting stimuli should be of average complexity.

To test the effectiveness of this heuristic, one should have users perform a task, and while performing the task, the user must come to a point where one needs to wait for the system that is busy with some task that requires completing. The initiation and the progress of the system task should be visualized on the screen, so the use of a progress bar is required here. The progress bar for the system task in the TRE must be able to display the progress of tasks with dynamic completion conditions in two ways, so two conditions can be compared with one another. First, the progress indicator must be able to display progress for tasks with dynamic completion conditions in accordance to the actual progress made. Second, a progress bar that is intelligent enough to make it look like progress of dynamic tasks is speeded up at the end of the process, should be available. This may help reduce stress because people get more sensitive to delays the longer they wait. It is not important that the progress bar in the TRE is really linked to task progress, as long as the users think it is. The researcher must be
25

able to set the progress bar to display either linear progress or nonlinear progress in a settings menu. In future commercial software, the new to develop progress bar should display progress for dynamic tasks. Processes with static completion conditions can be visualized accurately enough by regular progress bars, so this heuristic has no added value for them (Harrison et al., 2007). An example of a dynamic task is copying a batch of files that greatly differ in size. Because bigger files will be transferred more efficiently than smaller files, and an unexpected amount of smaller files in the batch can cause a slower filling of the progress bar near the end. We need to test if deploying intelligent progress indicators can help reduce stress in these situations. Another technique that should be implemented is that of distraction. The TRE must offer a distraction for the users while they wait. The distraction must take away the focus from the progress indicator, making time appear to go faster. Examples of distractions are exercises showed on screen, or a small slideshow of images that a user has on his hard disk. Hogans (1978) conclusion that stimulus complexity affects perception of time duration can be applied by making distractions of appropriate complexity. Multiple conditions can be created. In one condition, the progress bar displays linear progress with or without a distraction. In another condition, the indicator displays progress nonlinearly with or without adding a distracting. By comparing these conditions researchers will be able to find out if acknowledging human interpretations of time passing by, and distracting user while they wait, really helps to reduce stress. When users are seeing an intelligent progress bar which speeds up near the end- implementing a distraction might be ineffective. For this progress bar, it is more important to be watched, and the effect of making time seem go faster might be diminished when users do not pay attention to the progress bar due to a distraction. An example of a TRE test situation: The user uploads a document that was edited with the TRE to a web server and is showed a progress visualization of the upload task in the form of a horizontal bar that fills up. The user must wait for the task to be completed, and watches the progress bar, which seems to speed up noticeably near the end of the bar. While the user wait for the system task to complete, an interesting distraction is shown in the form of a slideshow of photographs that the users have saved on their hard drives.

4.6 Testing heuristic 4: Use appropriate human tone and emotion

Does using appropriate human tone and emotion help to reduce stress? Reeves and Nass (1996) already found that users act polite towards user interfaces and expect reciprocity. According to Moraveji and Soesanto (2012) apologetic and funny messages, and using polite requests instead of demands should also have a positive effect on how users feel about the interaction with the interface. To find out if these interface behaviors really help reduce stress, researchers need to test the use of humor versus of pragmatics and polite requests versus demands. For a proper test, the user interface of the TRE must satisfy these requirements:

26

Functional requirements: The user interface must be able to: o Provide pragmatic and polite acknowledgements. o Provide pragmatic and funny acknowledgements. o Provide pragmatic and apologetic acknowledgements. Optional: The user interface should be able to act reciprocal. o It must be able to provide useful output to the user.

Nonfunctional requirements: Politeness theory should be used to avoid threats to the face. The interface should communicate while obeying Grices maxims of Quality, Quantity, Relevance and Clarity in the polite condition.

To test if applying appropriate human tone and emotion to user interfaces, helps to reduce stress responses, polite, funny and apologetic conditions should be tested. The politeness theory, the media equation theory and Grices Maxims (see p. 13-15) can be applied to create the right conditions for testing this heuristic. To test the effects of politeness, one must be able to choose between showing the polite type of wording, or the normal, more pragmatic type. This option will facilitate the creation of the conditions that can be compared with each other. In the polite condition, all dialogs, help functions and menus should contain polite wording. The polite type of wording should make use of the politeness theory and Grices Maxims, and could resemble the following style: "Please provide a name for this document before saving it", "We are very sorry for the inconvenience but the application has crashed previously", " It seems you forgot to specify the file type, please try again". In the pragmatic condition, the type of wording could resemble this style: "You have not provided a name for this document", "The application has crashed, an error report has been sent", "Specify a file type before saving". Testing the effects of using apologetic messages can be done creating a condition in which feedback messages use apologetic text, making the user feel like they were not the ones making a mistake. In this condition, the system uses wording like I am sorry, but that action is not available right now. In the opposite condition, messages are pragmatic: This action is not available. The effect of using apologetic wording partially overlaps using the polite condition mentioned earlier, because apologizing can be considered a form of politeness. The test for the effects of funniness is similar to that for politeness. Fun is defined as what provides amusement or enjoyment (Merriam Webster Dictionary, 2012). Although fun is a fuzzy concept, and is subject to interpretation, it should not be hard to induce feelings of amusement or enjoyment in users through user interfaces. When a message is displayed by the TRE in the funny condition, the wording should be something that causes amusement. An example of a funny message is one that YouTube has used: Sorry, something went wrong. A team of highly trained monkeys has been dispatched to deal with this situation. Or when a
27

user saves a document: Brilliant! You saved the document! or Good! You just saved another rainforest! It is important to pay attention to the fact that messages that are intended to be funny can become annoying after seeing them several times. This risk should be assimilated into the test of this heuristic. Again, researchers can select to display either funny or normal wording in a general settings menu. Two conditions can then be compared: a condition with funny worded messages versus one with more pragmatic wording. Designing a proper test for reciprocity in a word processor like the TRE, is difficult. Implementing reciprocity requires features that are capable of making the interface provide the user with valuable outcomes, which is not something a word processor is built for. I have provided an outline for a test, that can be done separate from the TRE to test the reciprocity part of this heuristic. To test the effects of enabling or disabling reciprocity, a task is needed in which participation of both the user and system is needed. Furthermore, researchers must be able create situations where users feels like they are of service to the system. At the same time, the software that is used for this test must be able to offer a situation in which the system can do something worthwhile for the user as well. Conditions in which the interface does not act reciprocal and conditions in which it does can then be compared. An example of a test for the effects of reciprocity on stress levels: Users are asked to free space on their hard drives by finding files that can be deleted, so the system can perform an effective defragmentation of the hard drive. When the users have done this, they return to the defragmentation screen and start the defragmentation. Here, the system will perform a successful defragmentation and says that system has been made 20% faster. Or, the system does not adhere to the principle of reciprocity and performs the defragmentation, but after being completed lets the users know that it was not able to achieve any performance improvements. In this case the users have acted reciprocally, but the system has not, which violates expectations users have. It is important to explain to the users what the advantage of defragmentation is in order to create an incentive to start this process.

4.7 Testing heuristic 5: Provide positive feedback to user input and events
The fifth heuristic concerns giving positive feedback when a user successfully completes a part of the interaction with the user interface. When the user interface interacts with the user on a more positive tone, the user should feel less stressed. Key here is to refrain from giving feedback on negative events, such as failures, and to provide positive feedback on (small) successes. Functional requirements: The user interface must be able to display short positive messages when a user successfully completes a small task. o The positive messages must be short and encouraging. Researchers must be able to omit negative user feedback from the user interface.

28

Nonfunctional requirements: The positive messages must have a positive effect on the users self-esteem, enhance the feeling of control and acknowledge conversational norms. The positive messages should not become patronizing or annoying and should not violate the politeness theory. Negative feedback must be phrased as positive as possible.

To create a setting in which the user interface provides positive feedback, the TRE must be fitted with positive messages that are shown when the user succeeds in successfully completing a (sub)task, such inserting data into a table or submitting a document to a web server. The positive messages should resemble these wordings: Good job on completing Well done! Thank you for. These acknowledgements should be given every time a user successfully completes a certain subtask, but designers must beware of including these statements in every interaction with the user interface, as this may seem patronizing and become annoying to users. Making these acknowledgements appear for a very brief period may help to reduce the chance of being patronizing or annoying. Furthermore, negative feedback such as Invalid filename! and Unable to. must be omitted from the user interface as much as possible, or be rephrased positively. Again, the TRE must also feature the option to enable or disable the positive and negative messages in a general settings menu. To test the effects of omitting or rephrasing negative feedback, and increasing the amount of positive feedback, different conditions must be compared. A condition in which negative messages are left out and positive messages on success are shown, versus a condition in which negative messages are present and no positive messages are shown on success. Because it is hard to know which variable causes a certain effect, it may be necessary to separate the omitting or rephrasing of negative feedback from increasing positive feedback. This can be done by showing or hiding negative feedback on failures in a certain condition. While preparing for a test, it is important to realize that rephrasing negative feedback in a more positive form may overlap with the fourth heuristic, using appropriate human tone and emotion. An example of a TRE test situation: When a user clicks Save to save the document to the hard drive, the system replies with you successfully saved your document and this message disappears after a very brief period. When the user specifies an inappropriate file format while saving the document, the user interface politely displays please select another file format. In the opposite condition, there is no document successfully saved message, and when specifying a wrong file format, the message wrong file format is shown.

29

4.8 Testing heuristic 6: Encourage prosocial interaction

Testing the effects of encouraging prosocial interaction is about seeing if features that assist users in their interaction with others help to reduce stress. Requirements are: Functional requirements: A like-button, spell checker and remove feature must be present to be enabled or disabled.

Nonfunctional requirements: The features that assist in prosocial interaction must be help the users communicate their opinion. The features for prosocial interaction must make portraying the users desired selfimage easy and low risk.

Features to encourage prosocial interaction usually are not found in word processors such as the TRE, and integrating these in the TRE might be difficult. Testing for the effects of encouraging prosocial interaction may be more fruitful when done using an existing (online) word processing solution like Google Documents or Office 365. Nevertheless, I have provided an outline for a test below. A critical note is that, prosocial interaction as a term is a bit vague, which makes it hard to grasp in a test. For this heuristic to reach adulthood, the term prosocial interaction needs to be more clearly defined. To perform a good experiment, the test environment must incorporate a feature to which prosocial interaction can be applied. For example, a collaboration feature that allows users to comment and work on shared documents can be used. The collaboration feature involves a like-button to comment on someones work, a spell checker to help users with their grammatical performance and the option to edit or remove ones feedback on work. These features can then be enabled or disabled, to create two conditions of which the effects on stress levels can be compared. In the first condition, prosocial interaction is encouraged by enabling the mentioned features: it is possible to add and remove feedback to a document, the spell checker checks a users comments and the like-button creates a low barrier to commenting on someones work. In the other condition, prosocial interaction is not augmented by any means, and the spell checker, like-button and option to remove comments are not available. An example of a TRE test situation: A user sees that a collaborating user has uploaded a document, and decides to read and comment on it. A like-button is present below the documents title to provide an easy method of acknowledging the document. Under the documents title, a field for comments is shown. Once a user starts entering comments in box, a small green light lets the user know that the text is grammatically correct. A remove button is also present, letting the user know that their comments are not irreversible.

30

4.9 Testing heuristic 7: Relieve time-pressure

According to this heuristic, time pressure that is imposed by the user interface induces stress in users because they experience a lack of control. Time pressure is known to cause stress in human judgment and decision making, but is it a cause of stress in interactive systems? Testing this heuristic will hopefully provide an answer to this question. To test this heuristic, the TRE must satisfy the following requirements: Functional requirements: The TREs user interface must contain a means to induce time pressure o The time pressure must apply to the experiment task o The time pressure must be visualized while the task is being performed The TRE must have an option to postpone, skip and disable the element that is imposing time pressure The user must be notified by a message about what happens when the countdown reaches zero.

Nonfunctional requirements: The time limit must be shorter than the time needed to complete the task at hand.

To test the validity of heuristic 7, the TRE must contain a means to induce time pressure on the users while they perform their tasks. This will make the users aware of a certain limitation to the way they perform their task. The time left should be visualized by a countdown timer or a progress bar that is filled, to clarify that time to perform the task is limited. When the time constraint is disclosed, the user should be notified on what happens when the remaining time is up. This can be done by showing a small pop-up window that displays the message along with the countdown timer. Making sure that the user interface gives users the option to control when and how time pressure is allowed to occur is another important aspect of this heuristic. It is this feature that helps to relieve time pressure. One can measure the effects of relieving time pressure on stress levels by creating a condition in which, using the method mentioned above, time pressure is applied while the user performs a task. The effects of this condition can then be compared to those of a condition that does not contain elements to relieve time pressure. It is important to make the amount of time available smaller than the amount that is needed to complete the task. This will make sure limited time is really a form of pressure. An example of a TRE test situation: While the users are performing the third experiment task in which they are asked to insert a diagram, they are confronted with a small window on the right side of the work field. The small window displays the message your computer will automatically restart in 10 minutes. Along with that message, a timer with the remaining time until the system restarts is displayed. The timer runs down and when it reaches zero, the TRE is closed and the computer is restarted.

31

4.10 Testing heuristic 8: Choose naturally calming elements

This heuristic prescribes the use of elements from nature that should cause a more positivelytoned emotional state, positive changes in physiological levels (Ulrich et al., 1991). To test this heuristic, the TRE must satisfy the following requirements: Functional requirements: The user interface should incorporate soothing background music, that must: o be non-lyrical. o consist predominantly of low tones. o comprise mostly strings with minimal brass or percussion. o have a maximum volume level at 60 dB. The user interface must offer a natural background image.

Nonfunctional requirements: The background music should be played at a very low volume.

To be able to test the effects of this heuristic, the TRE must be fitted with naturally calming elements. These are images and sounds from nature that are supposed to have a calming effect on users. First, soothing background music should be implemented in the TRE. The music must be instrumental and may not contain lyrics as they would only distract the users from their task. The volume of the music should be low, because the music is intended to be peripheral. The music must further be non-lyrical, consist predominantly of low tones, and comprise mostly strings with minimal bass or percussion (Nilsson, 2003). The TRE should also contain images of natural settings that are incorporated in the background of all the important windows in the user interface. The images must contain views of nature or natural materials and should be easy to the eye. In practice, this means the images should not contain large contrasts, and small elements that are repeatedly shown in the image, such as leaves, must be avoided. Large contrasts and large amounts of small objects in an image can make it seem very crowded, drawing attention to it making it and harder for the user to maintain focus on the work field. Using implementations of the above requirements, researchers can create two conditions of which the effects on stress levels in users can be compared. The first condition is one with all the natural elements activated in the user interface, while the second condition provides a user interface in which no natural sounds and backgrounds are used. An example of a TRE test situation is: While the users are working with the TRE, soft music is playing in the background. It is comprised of non-lyrical sounds of water, flutes and violins. The background image of the TRE is an image of a green Scottish landscape with pastures and some trees. The image does not form a distraction and does not make the interface any more overwhelming.
32

4.11 Testing heuristic 9: Acknowledge reasonable user actions

The guidelines presented by heuristic 9 are about acknowledging and providing actions that users expect. If a certain action that a user expects is not available, a stress response can occur (Moraveji & Soesanto, 2012). User interfaces should offer actions that users expect, while at the same time not overwhelming the user. If certain actions are made unavailable to the user, the system must explain why and suggest what to do next, so the user is never in a state of uncertainty. Functional requirements: The TRE must be fit with a means to enable and disable availability of certain user actions. Interface elements for unavailable user actions should be visible but inoperable. The TRE must be able to explain why a certain interface behavior is impossible at some point. The TRE must be able to guide users by advising them what actions can be executed next.

Nonfunctional requirements: The disabled user actions must be actions that users expect to be available but are not available for a good reason.

With the mentioned requirements, two conditions can be created to test the validity of the heuristic. In the first condition, the researcher enables all the features to acknowledge reasonable interface behavior. In this condition, all interaction a user expects can be made, and unavailable interactions are accompanied by a tooltip explanation as to why they are unavailable and what a next possible action is. The other condition, the opposite of the first condition, is characterized by the absence of acknowledging these user actions. There are no explanations for the unavailability of certain actions, and not all reasonable user behavior is acknowledged. By comparing the effects on stress of these conditions, researchers can test the effects of acknowledging reasonable user actions. Making actions that users expect available is a natural goal when designing user interfaces. Indeed software developers want users to be able to use the software for the purpose it was designed for, so reasonable user actions are mostly already made available from that perspective. Testing the effect of making as many reasonable user actions available also seems rather difficult, because it may not always be clear what reasonable user actions are. Furthermore, whether a user action should be acknowledged may also be situational. I therefore propose that this heuristic be developed further and made more concrete. An example of a TRE test situation: A user is executing the second assignment of the experiment, inserting a table into the document. When the user tries to click on the menu item that says insert table, nothing happens and the button is grey. However when the user hovers the mouse over the grey button, a small tooltip appears. The tooltip contains an explanation of why the action of inserting a table is currently unavailable: You cannot insert
33

a table right now, because you have not selected a target location yet and place the cursor on a white space to insert the table.

4.12 Testing heuristic 10: Demystify the interface

The last heuristic discussed in this writing is about demystifying the interface: making sure all the interface elements' functions are obvious. To test the effectiveness of this heuristic, one must test if using user interface elements of which the intended use is not clear, makes for a more stressful experience than using elements that are obvious and are accompanied by an explanation of their function. A term that comes to mind when thinking about demystifying an interface, is affordance. Affordance is a usability principle that is about designing objects in such a way, that they allow people to easily infer how to use them (Sharp, Rogers & Preece, 2007). For example, a button that has a small shadow makes it stand out, and gives away that it can be clicked on. Creating good affordance helps demystifying a user interface. The demystify the interface heuristic therefore seems to have a lot in common with the usability principle of affordance. Because most user interface designers adhere to usability principles, we can already expect user interfaces to have affordance, limiting this heuristics added value. Therefore, I suggest this heuristic is further investigated, clarifying its use and differentiating it from the principle of affordance. To test this heuristic, I suggest the creation of two conditions. In the first condition, it must be unclear what the functions of the interface elements are. Buttons have no title, or have a title but no visual identifier like an image, and affordance is lacking so that it is hard to see if something can be clicked on or not. In the other condition, buttons have a title and a visual identifier making their intended use obvious, and affordance is created by giving the buttons a small shadow to make it clear they can be clicked on. A good example of a user interface that contains some mystified elements can be found in of OmmWriter Dana. The buttons shown in figure 4, are the buttons that activate the main functions in OmmWriter. Most of the symbols are rather mystical because they do not easily give away their intended use. Especially the little arrows that belong to the save, save as, and open functions, are mystified. Even when hovering over them, there is no additional explanation of their function. An example of a TRE test situation: A user is working on the experiment assignment in which a diagram must be inserted. Figure 5. Mystical buttons When the user looks for a function to insert a diagram the user discovers a small icon of bar diagram. The image does not really look like a button because it does not look like it can be clicked on. When the user hovers over the image, nothing changes.

34

Functional requirements: The TRE must be fit with a means to enable and disable mystical elements. Elements that are mystical: o Have no tooltip explanation when hovered over. o Have no title that describes their function.

Nonfunctional requirements: It must be hard to discover the function of the mystical elements.

4.13 Towards a good set of heuristics

The 10 heuristics of Moraveji and Soesanto are now ready to be tested in the test and research environment, using the recommendations listed in this chapter. The heuristics as a whole look like a good tool to reduce the amount of stressors in software user interfaces. However, some of the heuristics should probably be reinvestigated to see if they can be improved. The heuristics can be improved by reducing existing overlap between the heuristics and existing usability guidelines, as well as making the heuristics more detailed. Making sure the heuristics do not conflict with usability principles, which may be the case for acknowledging reasonable user actions, can also help improve their quality. Testing will likely bring up other ways to improve the heuristics. Moraveji en Soesantos list of heuristics is not exhaustive, and other heuristics aimed to reduce stressors in software can be added to the list. Inefficient interaction with a user interface is one example of a possible new heuristic. This heuristic concerns the question if certain effects like animations that are shown during interaction with the software can act as stressors, and how they can be avoided. Another example of a new heuristic is reducing attention stress through attentive user interfaces. Attentive User Interfaces (AUIs) are designed to measure and model the focus and priorities of their users attention. They structure information in such a way that the limited resource of user attention is allocated optimally across the users tasks. AUIs can enhance information presented in areas where users focus their attention, while they attenuate peripheral detail (Vertegaal, 2003, p. 32). By applying AUIs, information load on users can be decreased which can positively influence stress levels. Finally, because more and more applications such as e-mail and office suites are made to run in web browsers, the development of heuristics targeted at web applications may be worth wile. The current heuristics are targeted at conventional software, but web applications may require different tactics to reduce stress. This is something that should be investigated in the near future.

35

5. Conclusion
Because people use software so often, and in so many ways, a stressful user experience can have profound effects on users. It is therefore important not only to make user interfaces usable, but also stress-less. Stress-less user interfaces are better user interfaces. To guide the development of stress-less user interfaces, it is important to know what factors are capable of invoking a stress response, and what guidelines for user interface development can be produced accordingly. Stress, or the nonspecific response of the body to any demand made upon it (Selye, 1973, p. 692), can have negative effects on an individual. However, a stress response is subject to ones appraisal and coping style. This makes stress hard to predict. Measuring stress is not straightforward either. Cortisol cannot be regarded as a reliable measurement tool, and interpersonal differences in coping and appraisal make stress responses diverse. Furthermore, the kind of stress provoked by user interfaces will likely be of a relative mild nature. A few specific characteristics can be a attributed to stressors: situations that involve unpredictability, uncertainty, and unfamiliarity are known to invoke stress responses. Situations that invoke the perception of losing control or situations that have the potential to cause harm or loss are also known to be stress provoking. Lastly, there is evidence that situations that are perceived as judgments or social evaluative threats can provoke stress. I added that situations that endanger important goals or violate expectations can be stressor characteristics, and that emotions can be signs of the presence of stressors. However, most of the characteristics have not been tested, are still very generic, and may need additional specification to be useful as stressor identifiers. Furthermore, a stress response cannot be predicted just by looking at the stressor characteristics, because of individual difference in appraisal and coping. According to Moraveji and Soesanto (2012) factors that can provoke a stress response in users of software are: no visible ability to control interruptions, inducing the feeling of being overwhelmed, giving an uncertain image of time passing by, using inappropriate tone and emotion, providing too much negative feedback, not encouraging prosocial interaction, inducing time pressure, not using naturally calming elements, not acknowledging reasonable user actions and mystifying an interface. Most of the heuristics look promising, but some of them, like relieving time pressure, may not be very valuable, or in the case of demystifying an interface, are partially covered by usability principles. The stress reduction heuristics seem to have much in common with the concept of usability, and some of the heuristics overlap with usability guidelines. When an interface scores high on usability, it is unlikely to contain many stressors because many usability principles concern avoiding the characteristics of stressors. Another reason for curbing enthusiasm, is that stress responses provoked by user interfaces will probably be of mild nature, reducing the need for stress reduction guidelines. Before the heuristics can be put to use, they need to be tested. Testing the heuristics should show if they are indeed effective at reducing stressors in user interfaces. This can be done
36

using my recommendations for the test and research environment (TRE), with which the heuristics can be applied or disabled to test their effects on users of the TRE. I also recommend that it be tested whether user interfaces designed according to the stress reduction heuristics, score better on user stress levels, than user interfaces that have been designed according to usability heuristics only.

37

References
Anisman, H. & Merali, Z. (1999). Understanding Stress: Characteristics and Caveats. Alcohol Research and Health, 23(4), 241-249. Benson, H. (1983). The relaxation response: Its subjective and objective historical precedents and physiology. Trends in Neurosciences, 6(7), 281-284. Cutrell, E. B., Czerwinski, M., & Horvitz, E. (2000). Effects of instant messaging interruptions on computing tasks. In Extended Abstracts of the Conference on Human Factors in Computing Systems 2000 (pp. 99-100). De Quervain, D. J., Henke, K., Aerni, A., Treyer, V., McGaugh, J. L., Bertold, T., . . . Hock, C. (2003). Glucocorticoid-induced impairment of declarative memory retrieval is assoiciated with reduced blood flow in the medial temporal lobe. European Journal of Neuroscience, 17(6), 1296-1302. Folkman, S. Lazarus, R. S. (1985). If it changes it must be a process: Study of emotion and coping during three stages of a college examination. Journal of Personality and Social Psychology, 48(1), 150-170. Goldstein, M., Alsi, G., & Werdenhoff, J. (2002). The media equation does not always apply: People are not polite towards small computers. Personal Ubiquitous Computing, 6, 87-96. Harrison, C., Amento, B., Kuznetsov, S., & Bell, R. (2007). Rethinking the Progress Bar. In Proceedings of the 20th annual ACM Symposium on User Interface Software and Technology (pp.115-118). Hogan, W. H. (1978). A theoretical reconciliation of competing views of time perception. The American Journal of Psychology, 91(3), 417-428. Iqbal, S.T., Horvitz, E. (2007). Disruption and recovery of computing tasks: Field study, analysis, and directions. In Proceedings of the Conference on Human Factors in Computing Systems 2007 (pp.677-686). Kopell, B., Wittner, W. K., Lunde, D., Warrick, G. & Edwards, D. (1970). Cortisol effects on averaged evoke potentials, alpha-rhythm, time estimation, and two-flash fusion threshold. Psychosomatic Medicine, 32(1), 39-49. Lazarus, R. S. (1999). Psychological stress and appraisal. In Helen Song (Ed.). Stress and Emotion (pp. 49-86). New York, United States: Springer Publishing Company Inc. Lupien, S. J., Maheu, M., Tu, M., Fiocco, A., & Schramek, T.E. (2007). The effects of stress and stress hormones on human cognition: Implications for the field of brain an cognition. Brain and Cognition, 65, 209-237.

38

Maule, A. J., Hockey, G. R. J., & Bdzola, L. (2000). Effects of time pressure on decision making under uncertainty: Changes in affective state and information processing strategy. Acta Psychologica, 104, 283-301. McFarlane, D. C. (2002). Comparison of four primary methods for coordinating the interruption of people in human-computer interaction. Human-Computer Interaction, 17 (1), 63-139. Merriam Webster Online. (2012). Retrieved from http://www.merriam-webster.com/ Moraveji, N., Oshidary, N., Pea, R., & Fogg, B.J. (2011). Calming Technologies. Paper presented at the Conference on Human Factors in Computing Systems 2011, Vancouver BC, Canada. Moraveji, N., Oppezzo, M., Habif, S., & Pea, R. (2011b). A theoretical model of calming technology: Designing to mitigate stress and increase calm. Workshop on Interactive Systems in Healthcare (AMIA WISH 2011). Washington, DC. Moraveji, N. & Soesanto, C. (2012). Towards stress-less user interfaces: 10 heuristics based on the psychophysiology of stress. Extended abstracts of ACM CHI 2012. Austin, TX. Nass, C., & Moon, Y. (2000). Machines and mindlessness: Social responses to computers. Journal of Social Issues, 56(1), 82-103. Nielsen, J. (2005). Ten Usability Heuristics. Retrieved from: http://www.useit.com/papers/heuristic/heuristic_list.html Nilsson, U., Unosson, M., & Rawal, N. (2005). Stress reduction and analgesia in patients exposed to calming music postoperatively: a randomized controlled trial. European Journal of Anaesthesiology, 22 , 96-102. Nilsson, U. (2008). The anxiety- and pain-reducing effects of music interventions: A systematic review. Association of periOperative Registered Nurses Journal, 87(4), 780-807. OmmWriter. (2011). Ommwriter Homepage. Retrieved from http://www.ommwriter.com. Reeves, B., & Nass, C. (1996). The media equation: How people treat computers, television, and new media like real people and places. New York, USA: Cambridge University Press. Selye, H. (1973). Evolution of the Stress Concept: The originator of the concept traces its developmentfrom the discovery in 1936 of the alarm reaction to modern therapeutic applications ofsyntoxic and catatoxic hormones. American Scientist, 61(6), 692-699. Sharp, H., Rogers, Y., & Preece, J. (2007). Interaction Design: Beyond Human Computer Interaction (2nd ed.). Chichester, England: John Wiley and Sons.
39

Shechtman, N., & Horowitz, L. M. (2003). Media inequality in conversation: How people behave differently when interacting with Computers and People. In Proceedings of the Conference on Human Factors in Computing Systems 2003 (pp. 281-288). Smyth, J., Ockenfels, M.C., Porter, L., Kirschbaum, C., Hellhammer, D.H., & Stone, A.A. (1998). Stressors and mood measured on a momentary basis are associated with salivary cortisol secretion. Psychoneuroendocrinology, 23(4), 353-370. Staum M. J., Brotons, M. (2000). The effect of music amplitude on the relaxation response. Journal of Music Therapy, 37(1), 22-39. Stefano, G. B., Fricchione, G. L., Esch, T. (2006). Relaxation: Molecular and physiological significance. Medical Science Monitor, 12(9), 21-31. Tsuchiya, M., Asasa, A., Ryo, K., Noda, K., Hashino, Y., Sato, Y., Sato, E. F., & Inoue, M. (2003). Relaxing intraoperative natural sound blunts haemodynamic change at the emergence from propofol general anaesthesia and increases the acceptability of anaesthesia to the patient. Acta Anaesthesiologica Scandinavia, 47, 939-943. Ulrich, R. S., Simons, R. F., Losito, B. D., Fiorito, E., Miles, M. A., Zelson, M. (1991). Stress recovery during exposure to natural and urban environments. Journal of Environmental Psychology, 11, 201-230. Vertegaal, R. (2003). Attentive User Interfaces. Communications of the ACM, 46 (3), 30-33. Weiser, M. (1991). The Computer for the 21st Century. Retrieved from http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html. Wikipedia. (2012). Politeness Theory. Retrieved from http://en.wikipedia.org/wiki/Politeness_theory

40