Skip to Content
Last modified by Mathieu Jung-Muller on 2022/04/04 13:55
From version Icon 14.1 Icon
edited by Pierre Bongrand
on 2022/03/30 00:47
Change comment: There is no comment for this version
To version Icon 3.1 Icon
edited by Sneha Lodha
on 2022/03/23 20:19
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.PierreBongrand
1 +XWiki.snehalodha
Content
... ... @@ -1,8 +1,8 @@
1 1  (% style="background-color:#ffffff; font-size:14px" %)
2 2  
3 -== IDP01==
3 +== IDP001==
4 4  {{html}}
5 -<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp1.jpg?rev=1.1" alt="IDP01" width="350"/>
5 +<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp1.jpg?rev=1.1" alt="IDP001" width="350"/>
6 6  {{/html}}
7 7  
8 8  |(((
... ... @@ -9,7 +9,9 @@
9 9  **RANKING/ validation**
10 10  
11 11  )))|(((
12 -When Pepper is playing music this can clearly be heard by the PwD, and other evaluators around, so this IDP is empirically testable.
12 +//Notion of the validity (e.g., empirically tested)//
13 +
14 +TBD
13 13  )))
14 14  |(((
15 15  **DESIGN PROBLEM (what)**
... ... @@ -16,6 +16,8 @@
16 16  
17 17  
18 18  )))|(((
21 +//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
22 +
19 19  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.
20 20  )))
21 21  |(((
... ... @@ -23,6 +23,7 @@
23 23  
24 24  
25 25  )))|(((
30 +//References to a list of the contextual characteristics that are significant for the applicability of the pattern.//
26 26  This IDP can be used in the following contexts:
27 27  * Alert the PwD before an interaction takes place
28 28  * Wake up reminder for PwD
... ... @@ -34,6 +34,8 @@
34 34  
35 35  
36 36  )))|(((
42 +//Description of the essential characteristics of the solution that express the interaction intention.//
43 +
37 37  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.
38 38  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.
39 39  )))
... ... @@ -42,6 +42,8 @@
42 42  
43 43  
44 44  )))|(((
52 +//Argumentation that resulted in the chosen design solution.//
53 +
45 45  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.
46 46  )))
47 47  |(((
... ... @@ -49,13 +49,15 @@
49 49  
50 50  
51 51  )))|(((
61 +//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 +
52 52  TBD (should we include or not?)
53 53  )))
54 54  
55 55  
56 -== IDP02==
67 +== IDP002==
57 57  {{html}}
58 -<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp2.jpg?rev=1.1" alt="IDP02" width="350"/>
69 +<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp2.jpg?rev=1.1" alt="IDP002" width="500"/>
59 59  {{/html}}
60 60  
61 61  |(((
... ... @@ -63,8 +63,9 @@
63 63  
64 64  
65 65  )))|(((
66 -This can be empirically tested as the PwD, and other evaluators around, can hear Pepper asking this question.
77 +//Notion of the validity (e.g., empirically tested)//
67 67  
79 +TBD
68 68  )))
69 69  |(((
70 70  **DESIGN PROBLEM (what)**
... ... @@ -71,6 +71,8 @@
71 71  
72 72  
73 73  )))|(((
86 +//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
87 +
74 74  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.
75 75  )))
76 76  |(((
... ... @@ -78,6 +78,8 @@
78 78  
79 79  
80 80  )))|(((
95 +//Contextual characteristics that are significant for the applicability of the pattern.//
96 +
81 81  This IDP can be used in the following contexts:
82 82  * Understanding whether the PwD has taken medication before reminding them
83 83  * Understanding whether the PwD has eaten a meal before reminding them
... ... @@ -88,6 +88,8 @@
88 88  
89 89  
90 90  )))|(((
107 +//Description of the essential characteristics of the solution that express the interaction intention.//
108 +
91 91  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.
92 92  
93 93  )))
... ... @@ -96,6 +96,8 @@
96 96  
97 97  
98 98  )))|(((
117 +//Trade-offs and the argumentation that resulted in the chosen design solution.//
118 +
99 99  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.
100 100  
101 101  )))
... ... @@ -104,13 +104,15 @@
104 104  
105 105  
106 106  )))|(((
127 +//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 +
107 107  TBD (should we include or not?)
108 108  )))
109 109  
110 110  
111 -== IDP03==
133 +== IDP003==
112 112  {{html}}
113 -<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp3.jpg?rev=1.1" alt="IDP03" width="350"/>
135 +<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp3.jpg?rev=1.1" alt="IDP003" width="350"/>
114 114  {{/html}}
115 115  
116 116  |(((
... ... @@ -118,8 +118,11 @@
118 118  
119 119  
120 120  )))|(((
121 -This can be empirically tested as the PwD, and other evaluators around, can hear Pepper reminding the PwD to do the task.
143 +//Provide a notion of the validity (e.g., empirically tested)//
122 122  
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).
146 +
147 +
123 123  )))
124 124  |(((
125 125  **DESIGN PROBLEM (what)**
... ... @@ -126,7 +126,11 @@
126 126  
127 127  
128 128  )))|(((
129 -The idea of this design pattern is to verbally remind the PwD of an upcoming task. Such tasks can include medicine reminders, meal reminders etc. The intended effect on the user would be that they are reminded to do this particular task if they have not done it already. It also takes some of the burden away from primary caregivers and partners to do such a reminding job constantly.
154 +//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.
157 +
158 +
130 130  )))
131 131  |(((
132 132  **CONTEXT (use when…)**
... ... @@ -133,10 +133,13 @@
133 133  
134 134  
135 135  )))|(((
136 -This IDP can be used in the following contexts:
137 -* Reminding the PwD to take medication if they have not done so already
138 -* Reminding the PwD to eat food if they have not done so already
139 -The list can be further expanded as more crucial task usecases are added.
165 +//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.
170 +
171 +
140 140  )))
141 141  |(((
142 142  **DESIGN SOLUTION (how)**
... ... @@ -143,7 +143,11 @@
143 143  
144 144  
145 145  )))|(((
146 -The design solution consists of Pepper reminding the PwD to do a particular task if they have not done it already. We ensure this reminder is only activated when the PwD has not performed the task in order not to overwhelm them with something they have already done. The goal of the pattern is to successfully remind and encourage the PwD to perform an essential task they should do.
178 +//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.
181 +
182 +
147 147  )))
148 148  |(((
149 149  **DESIGN RATIONALE (why)**
... ... @@ -150,20 +150,30 @@
150 150  
151 151  
152 152  )))|(((
153 -A verbal reminder here works better than a simple reminder on the phone, as would happen commonly these days. Also we believe that having Pepper as a physical being there might encourage the PwD to take such reminders with higher importance than a simple notification. On top of that, phone reminders would mean that the PwD is familiar with this kind of technology, which is not necessarily the case.
189 +//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
154 154  
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.
192 +
193 +
155 155  )))
156 156  |(((
157 157  **EXAMPLES (as seen on…)**
158 158  
198 +
159 159  )))|(((
160 -TBD (should we include or not?)
200 +//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.
161 161  )))
204 +|**RELATED PATTERNS**|(((
205 +//Provide the names and/or links of related patterns.//
162 162  
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).
208 +)))
163 163  
164 -== IDP04==
210 +== IDP004==
165 165  {{html}}
166 -<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp4.jpg?rev=1.1" alt="IDP04" width="350"/>
212 +<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp4.jpg?rev=1.1" alt="IDP004" width="500"/>
167 167  {{/html}}
168 168  
169 169  |(((
... ... @@ -171,8 +171,11 @@
171 171  
172 172  
173 173  )))|(((
174 -This can be empirically tested as the PwD, and other evaluators around, can hear Pepper asking the PwD for confirmation.
220 +//Provide a notion of the validity (e.g., empirically tested)//
175 175  
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).
223 +
224 +
176 176  )))
177 177  |(((
178 178  **DESIGN PROBLEM (what)**
... ... @@ -179,18 +179,24 @@
179 179  
180 180  
181 181  )))|(((
182 -This design pattern occurs hand in hand with Pepper just having told the PwD to do a certain task or activity step. The intention is to understand whether this task was successfully done by the PwD. This ensures the PwD had indeed successfully completed a certain task, which in some case may be crucial.
231 +//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.
234 +
235 +
183 183  )))
184 184  |(((
185 -
186 186  **CONTEXT (use when…)**
239 +
187 187  
188 188  )))|(((
189 -This IDP can be used in the following contexts:
190 -* Asking for confirmation of having taken medication
191 -* Asking for confirmation of having eaten a meal
192 -* Asking for confirmation of having done an activity step
193 -The list can be further expanded as more crucial task usecases are added.
242 +//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.
247 +
248 +
194 194  )))
195 195  |(((
196 196  **DESIGN SOLUTION (how)**
... ... @@ -197,7 +197,11 @@
197 197  
198 198  
199 199  )))|(((
200 -The design solution consists of Pepper asking for a verbal confirmation of having done a task. The user is prompted with a closed question such as "have you done it?," and is expected to reply in a truthful manner. Pepper will not move on unless a positive confirmation is given, in order to ensure successful completion of crucial tasks.
255 +//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.
258 +
259 +
201 201  )))
202 202  |(((
203 203  **DESIGN RATIONALE (why)**
... ... @@ -204,20 +204,30 @@
204 204  
205 205  
206 206  )))|(((
207 -The solution consists of explicitly asking the PwD whether they have already performed a particular task. The response from PwD can either be positive or negative, 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.
266 +//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
208 208  
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.
269 +
270 +
209 209  )))
210 210  |(((
211 211  **EXAMPLES (as seen on…)**
212 212  
275 +
213 213  )))|(((
214 -TBD (should we include or not?)
277 +//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.
215 215  )))
281 +|**RELATED PATTERNS**|(((
282 +//Provide the names and/or links of related patterns.//
216 216  
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).
285 +)))
217 217  
218 -== IDP05==
287 +== IDP005==
219 219  {{html}}
220 -<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp5.jpg?rev=1.1" alt="IDP05" width="350"/>
289 +<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp5.jpg?rev=1.1" alt="IDP005" width="500"/>
221 221  {{/html}}
222 222  
223 223  |(((
... ... @@ -225,7 +225,11 @@
225 225  
226 226  
227 227  )))|(((
228 -This can be empirically tested as the PwD, and other evaluators around, can hear Pepper congratulating the PwD.
297 +//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).
300 +
301 +
229 229  )))
230 230  |(((
231 231  **DESIGN PROBLEM (what)**
... ... @@ -232,18 +232,24 @@
232 232  
233 233  
234 234  )))|(((
235 -This design pattern is used to verbally congratulate the PwD, and make them feel about about a task that they just accomplished. This is to lift the spirits of the PwD and make them enjoy and want to do certain tasks.
308 +//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.
311 +
312 +
236 236  )))
237 237  |(((
238 -
239 239  **CONTEXT (use when…)**
316 +
240 240  
241 241  )))|(((
242 -This IDP can be used in the following contexts:
243 -* Congratulate the PwD for having taken medication
244 -* Congratulate the PwD for having eaten medication
245 -* Congratulate the PwD for doing a particular activity completely
246 -The list can be further expanded as more task usecases are added.
319 +//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.
324 +
325 +
247 247  )))
248 248  |(((
249 249  **DESIGN SOLUTION (how)**
... ... @@ -250,7 +250,11 @@
250 250  
251 251  
252 252  )))|(((
253 -This IDP is quite basic and simply pre-programmed into Pepper. Simply congratulating the PwD for finishing a certain task or activity is sufficient.
332 +//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.
335 +
336 +
254 254  )))
255 255  |(((
256 256  **DESIGN RATIONALE (why)**
... ... @@ -257,21 +257,30 @@
257 257  
258 258  
259 259  )))|(((
260 -//Argumentation that resulted in the chosen design solution.//
261 -This IDP was added in order to give the PwD a feeling of accomplishment after doing a task that might have been challenging for them. Giving some encouragement can aid in finding enjoyment in and remembering such tasks.
343 +//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
262 262  
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.
346 +
347 +
263 263  )))
264 264  |(((
265 265  **EXAMPLES (as seen on…)**
266 266  
352 +
267 267  )))|(((
268 -TBD (should we include or not?)
354 +//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.
269 269  )))
358 +|**RELATED PATTERNS**|(((
359 +//Provide the names and/or links of related patterns.//
270 270  
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).
362 +)))
271 271  
272 -== IDP06==
364 +== IDP006==
273 273  {{html}}
274 -<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp6.jpg?rev=1.1" alt="IDP06s" width="350"/>
366 +<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp6.jpg?rev=1.1" alt="IDP006" width="500"/>
275 275  {{/html}}
276 276  
277 277  |(((
... ... @@ -279,7 +279,11 @@
279 279  
280 280  
281 281  )))|(((
282 -This can be tested by performing some other IDPs, which refer to utilizing the breakdown of a particular activity. Since this is for now hard-coded into Pepper, it is not empirically testable.
374 +//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).
377 +
378 +
283 283  )))
284 284  |(((
285 285  **DESIGN PROBLEM (what)**
... ... @@ -286,16 +286,24 @@
286 286  
287 287  
288 288  )))|(((
289 -This design pattern is used by the HCP (or a relative) to enter some activities into Pepper, that the PwD might personally enjoy. This is so that Pepper's system contains the breakdown to certain desired activities.
385 +//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.
388 +
389 +
290 290  )))
291 291  |(((
292 -
293 293  **CONTEXT (use when…)**
393 +
294 294  
295 295  )))|(((
296 -This IDP can be used in the following contexts:
297 -* PwD wants to perform a new activity
298 -* Pepper is not yet personalized to the particular PwD
396 +//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.
401 +
402 +
299 299  )))
300 300  |(((
301 301  **DESIGN SOLUTION (how)**
... ... @@ -302,7 +302,11 @@
302 302  
303 303  
304 304  )))|(((
305 -The interface has not been implemented. Ideally, the interface designed is easy to use, HCP and relatives are not required to have very high technical knowledge.
409 +//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.
412 +
413 +
306 306  )))
307 307  |(((
308 308  **DESIGN RATIONALE (why)**
... ... @@ -309,20 +309,30 @@
309 309  
310 310  
311 311  )))|(((
312 -We allow the HCP to provide steps as they are the ones that have spent a significant amount of time with the PwD and know about their likes and dislikes. In this case, they can also provide the steps in the complexity they think the PwD will understand, rather than simply having some arbitrary steps from the internet.
420 +//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
313 313  
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.
423 +
424 +
314 314  )))
315 315  |(((
316 316  **EXAMPLES (as seen on…)**
317 317  
429 +
318 318  )))|(((
319 -TBD (should we include or not?)
431 +//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.
320 320  )))
435 +|**RELATED PATTERNS**|(((
436 +//Provide the names and/or links of related patterns.//
321 321  
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).
439 +)))
322 322  
323 -== IDP07==
441 +== IDP007==
324 324  {{html}}
325 -<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp7.jpg?rev=1.1" alt="IDP07" width="350"/>
443 +<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp7.jpg?rev=1.1" alt="IDP007" width="350"/>
326 326  {{/html}}
327 327  
328 328  |(((
... ... @@ -330,8 +330,11 @@
330 330  
331 331  
332 332  )))|(((
333 -This can be empirically tested as the PwD, and other evaluators around, can hear Pepper saying a step to the PwD.
451 +//Provide a notion of the validity (e.g., empirically tested)//
334 334  
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).
454 +
455 +
335 335  )))
336 336  |(((
337 337  **DESIGN PROBLEM (what)**
... ... @@ -338,16 +338,24 @@
338 338  
339 339  
340 340  )))|(((
341 -This design pattern is used to tell the PwD the next step in a certain activity breakdown. This activity can be anything, and the steps are added by the HCP into Pepper's system as a prerequisite.
462 +//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.
465 +
466 +
342 342  )))
343 343  |(((
344 -
345 345  **CONTEXT (use when…)**
470 +
346 346  
347 347  )))|(((
348 -This IDP can be used in the following contexts:
349 -* PwD needs the next step for a gardening activity
350 -* PwD needs the next step for making a paper plane
473 +//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.
478 +
479 +
351 351  )))
352 352  |(((
353 353  **DESIGN SOLUTION (how)**
... ... @@ -354,7 +354,11 @@
354 354  
355 355  
356 356  )))|(((
357 -Here, already having the activity broken down into certain steps is very crucial. Also Pepper needs to say these steps verbally so the user can hear and act appropriately.
486 +//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.
489 +
490 +
358 358  )))
359 359  |(((
360 360  **DESIGN RATIONALE (why)**
... ... @@ -361,13 +361,23 @@
361 361  
362 362  
363 363  )))|(((
364 -A verbal step here works better than merely following steps from a website, as would happen commonly these days. Also we believe that having Pepper as a physical being there might encourage the PwD to perform activities they used to enjoy, with higher frequency as Pepper would come up to them and ask them if they want to take part in an activity they enjoy.
497 +//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.
500 +
501 +
365 365  )))
366 366  |(((
367 367  **EXAMPLES (as seen on…)**
368 368  
506 +
369 369  )))|(((
370 -TBD (should we include or not?)
508 +//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.
371 371  )))
512 +|**RELATED PATTERNS**|(((
513 +//Provide the names and/or links of related patterns.//
372 372  
373 -
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 +)))