XWiki - Interaction Design Patterns - Interaction Design Patterns

Here the interaction intention of the IDP is to gently remind/alert the PwD about the presence of Pepper around the room. This is in order not to startle the PwD by directly talking to them, but rather providing a gentle musical reminder of interaction about to take place. Sometimes the PwD might want to listen to some music for entertainment purposes and this IDP can also be applied in that scenario.

24

)))

25

|(((

26

**CONTEXT (use when…)**

)))|(((

//References to a list of the contextual characteristics that are significant for the applicability of the pattern.//

31

This IDP can be used in the following contexts:

32

* Alert the PwD before an interaction takes place

33

* Wake up reminder for PwD

34

* Entertainment for PwD

35

* Useful for associating certain activities to certain musical sounds

36

)))

37

|(((

38

**DESIGN SOLUTION (how)**

)))|(((

//Description of the essential characteristics of the solution that express the interaction intention.//

43

44

This IDP contains minimal interaction, and only consists of Pepper playing music. The musical tone that will play in a specific scenario is pre-programmed for each activity. Hence the solution for gentle reminders for interaction about to happen for PwD, is to simply play some gentle reminder music.

45

In the case where this IDP is used for the entertainment of the PwD (external usecase), a list of songs that the PwD enjoys can be programmed into Pepper and played when the usecase is activated.

46

)))

47

|(((

48

**DESIGN RATIONALE (why)**

)))|(((

//Argumentation that resulted in the chosen design solution.//

53

54

According to many studies music has shown to have a dramatic effect on people with dementia in terms of improving recollection and making them feel more calm overall. (Citations needed) Due to these researches we decided to incorporate it not only for entertainment purposes, but also for some gentle reminder purposes.

55

)))

56

|(((

57

**EXAMPLES (as seen on…)**

)))|(((

//Illustration (eg. picture, screenshot, animated graphic, video etc.) of an implementation of the design solution in a ‘real-life’ application, and include a short explanation describing the context of use.//

62

63

TBD (should we include or not?)

)))

== IDP002==

|(((

**RANKING/ validation**

)))|(((

//Notion of the validity (e.g., empirically tested)//

TBD

)))

|(((

**DESIGN PROBLEM (what)**

)))|(((

//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//

87

88

It is important to understand whether the PwD did a particular task or not. Tasks such as taking medicine or eating a meal are crucial, and understanding whether the PwD has successfully done this is an important first step to many reminder tasks.

89

)))

90

|(((

91

**CONTEXT (use when…)**

)))|(((

//Contextual characteristics that are significant for the applicability of the pattern.//

96

97

This IDP can be used in the following contexts:

98

* Understanding whether the PwD has taken medication before reminding them

99

* Understanding whether the PwD has eaten a meal before reminding them

100

The list can be further expanded as more crucial task usecases are added.

101

)))

102

|(((

103

**DESIGN SOLUTION (how)**

)))|(((

//Description of the essential characteristics of the solution that express the interaction intention.//

108

109

The solution consists of explicitly asking the PwD whether they have already performed a particular task. The response from PwD can either be yes or no, and depending on that Pepper proceeds with the next step. Simply asking the PwD whether they have performed a task is the best way to ensure a clear and concise reply which is understandable.

)))

|(((

**DESIGN RATIONALE (why)**

)))|(((

//Trade-offs and the argumentation that resulted in the chosen design solution.//

118

119

Here instead of assessing from visual cues whether the PwD has conducted a particular task, a verbal approach is taken. This is due to Pepper's limitations in constantly being around the PwD. Although simply verbally asking whether the PwD performed a certain task might seem too straightforward, it ensures that important information is conveyed in the most explicit manner.

)))

|(((

**EXAMPLES (as seen on…)**

)))|(((

//Illustration (eg. picture, screenshot, animated graphic, video etc.) of an implementation of the design solution in a ‘real-life’ application, and include a short explanation describing the context of use.//

128

129

TBD (should we include or not?)

)))

== IDP003==

|(((

**RANKING/ validation**

)))|(((

//Provide a notion of the validity (e.g., empirically tested)//

144

145

The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).

)))

|(((

**DESIGN PROBLEM (what)**

)))|(((

//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//

155

156

The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.

)))

|(((

**CONTEXT (use when…)**

)))|(((

//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//

166

167

The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable

168

169

The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.

)))

|(((

**DESIGN SOLUTION (how)**

)))|(((

//Provide a description of the essential characteristics of the design solution that express the interaction intention.//

179

180

The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.

)))

|(((

**DESIGN RATIONALE (why)**

)))|(((

//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//

190

191

The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.

)))

|(((

**EXAMPLES (as seen on…)**

)))|(((

//Provide an illustration (eg. picture, screenshot, animated graphic, video etc.) of an implementation of the design solution in a ‘real-life’ application, and include a short explanation describing the context of use.//

201

202

The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.

203

)))

204

|**RELATED PATTERNS**|(((

205

//Provide the names and/or links of related patterns.//

206

207

Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).

)))

== IDP004==

|(((

**RANKING/ validation**

)))|(((

//Provide a notion of the validity (e.g., empirically tested)//

221

222

The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).

)))

|(((

**DESIGN PROBLEM (what)**

)))|(((

//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//

232

233

The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.

)))

|(((

**CONTEXT (use when…)**

)))|(((

//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//

243

244

The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable

245

246

The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.

)))

|(((

**DESIGN SOLUTION (how)**

)))|(((

//Provide a description of the essential characteristics of the design solution that express the interaction intention.//

256

257

The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.

)))

|(((

**DESIGN RATIONALE (why)**

)))|(((

//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//

267

268

The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.

)))

|(((

**EXAMPLES (as seen on…)**

)))|(((

//Provide an illustration (eg. picture, screenshot, animated graphic, video etc.) of an implementation of the design solution in a ‘real-life’ application, and include a short explanation describing the context of use.//

278

279

The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.

280

)))

281

|**RELATED PATTERNS**|(((

282

//Provide the names and/or links of related patterns.//

283

284

Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).

)))

== IDP005==

|(((

**RANKING/ validation**

)))|(((

//Provide a notion of the validity (e.g., empirically tested)//

298

299

The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).

)))

|(((

**DESIGN PROBLEM (what)**

)))|(((

//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//

309

310

The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.

)))

|(((

**CONTEXT (use when…)**

)))|(((

//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//

320

321

The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable

322

323

The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.

)))

|(((

**DESIGN SOLUTION (how)**

)))|(((

//Provide a description of the essential characteristics of the design solution that express the interaction intention.//

333

334

The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.

)))

|(((

**DESIGN RATIONALE (why)**

)))|(((

//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//

344

345

The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.

)))

|(((

**EXAMPLES (as seen on…)**

)))|(((

//Provide an illustration (eg. picture, screenshot, animated graphic, video etc.) of an implementation of the design solution in a ‘real-life’ application, and include a short explanation describing the context of use.//

355

356

The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.

357

)))

358

|**RELATED PATTERNS**|(((

359

//Provide the names and/or links of related patterns.//

360

361

Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).

)))

== IDP006==

|(((

**RANKING/ validation**

)))|(((

//Provide a notion of the validity (e.g., empirically tested)//

375

376

The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).

)))

|(((

**DESIGN PROBLEM (what)**

)))|(((

//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//

386

387

The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.

)))

|(((

**CONTEXT (use when…)**

)))|(((

//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//

397

398

The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable

399

400

The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.

)))

|(((

**DESIGN SOLUTION (how)**

)))|(((

//Provide a description of the essential characteristics of the design solution that express the interaction intention.//

410

411

The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.

)))

|(((

**DESIGN RATIONALE (why)**

)))|(((

//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//

421

422

The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.

)))

|(((

**EXAMPLES (as seen on…)**

)))|(((

//Provide an illustration (eg. picture, screenshot, animated graphic, video etc.) of an implementation of the design solution in a ‘real-life’ application, and include a short explanation describing the context of use.//

432

433

The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.

434

)))

435

|**RELATED PATTERNS**|(((

436

//Provide the names and/or links of related patterns.//

437

438

Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).

)))

== IDP007==

|(((

**RANKING/ validation**

)))|(((

//Provide a notion of the validity (e.g., empirically tested)//

452

453

The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).

)))

|(((

**DESIGN PROBLEM (what)**

)))|(((

//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//

463

464

The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.

)))

|(((

**CONTEXT (use when…)**

)))|(((

//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//

474

475

The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable

476

477

The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.

)))

|(((

**DESIGN SOLUTION (how)**

)))|(((

//Provide a description of the essential characteristics of the design solution that express the interaction intention.//

487

488

The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.

)))

|(((

**DESIGN RATIONALE (why)**

)))|(((

//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//

498

499

The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.

)))

|(((

**EXAMPLES (as seen on…)**

)))|(((

//Provide an illustration (eg. picture, screenshot, animated graphic, video etc.) of an implementation of the design solution in a ‘real-life’ application, and include a short explanation describing the context of use.//

509

510

The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.

511

)))

512

|**RELATED PATTERNS**|(((

513

//Provide the names and/or links of related patterns.//

514

515

Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).

516

)))

Wiki source code of Interaction Design Patterns