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

Summary

Details

Icon Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.Mathieu
1 +XWiki.PierreBongrand
Content
... ... @@ -9,9 +9,7 @@
9 9  **RANKING/ validation**
10 10  
11 11  )))|(((
12 -//Notion of the validity (e.g., empirically tested)//
13 13  When Pepper is playing music this can clearly be heard by the PwD, and other evaluators around, so this IDP is empirically testable.
14 -
15 15  )))
16 16  |(((
17 17  **DESIGN PROBLEM (what)**
... ... @@ -18,8 +18,6 @@
18 18  
19 19  
20 20  )))|(((
21 -//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
22 -
23 23  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 24  )))
25 25  |(((
... ... @@ -27,7 +27,6 @@
27 27  
28 28  
29 29  )))|(((
30 -//Contextual characteristics that are significant for the applicability of the pattern.//
31 31  This IDP can be used in the following contexts:
32 32  * Alert the PwD before an interaction takes place
33 33  * Wake up reminder for PwD
... ... @@ -39,8 +39,6 @@
39 39  
40 40  
41 41  )))|(((
42 -//Essential characteristics of the design solution that express the interaction intention.//
43 -
44 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 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 46  )))
... ... @@ -49,8 +49,6 @@
49 49  
50 50  
51 51  )))|(((
52 -//Argumentation that resulted in the chosen design solution.//
53 -
54 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 55  )))
56 56  |(((
... ... @@ -58,8 +58,6 @@
58 58  
59 59  
60 60  )))|(((
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 -
63 63  TBD (should we include or not?)
64 64  )))
65 65  
... ... @@ -74,7 +74,6 @@
74 74  
75 75  
76 76  )))|(((
77 -//Notion of the validity (e.g., empirically tested)//
78 78  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper asking this question.
79 79  
80 80  )))
... ... @@ -83,8 +83,6 @@
83 83  
84 84  
85 85  )))|(((
86 -//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
87 -
88 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 89  )))
90 90  |(((
... ... @@ -92,8 +92,6 @@
92 92  
93 93  
94 94  )))|(((
95 -//Contextual characteristics that are significant for the applicability of the pattern.//
96 -
97 97  This IDP can be used in the following contexts:
98 98  * Understanding whether the PwD has taken medication before reminding them
99 99  * Understanding whether the PwD has eaten a meal before reminding them
... ... @@ -104,8 +104,6 @@
104 104  
105 105  
106 106  )))|(((
107 -//Essential characteristics of the design solution that express the interaction intention.//
108 -
109 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.
110 110  
111 111  )))
... ... @@ -114,8 +114,6 @@
114 114  
115 115  
116 116  )))|(((
117 -//Argumentation that resulted in the chosen design solution.//
118 -
119 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.
120 120  
121 121  )))
... ... @@ -124,8 +124,6 @@
124 124  
125 125  
126 126  )))|(((
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 -
129 129  TBD (should we include or not?)
130 130  )))
131 131  
... ... @@ -140,7 +140,6 @@
140 140  
141 141  
142 142  )))|(((
143 -//Notion of the validity (e.g., empirically tested)//
144 144  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper reminding the PwD to do the task.
145 145  
146 146  )))
... ... @@ -149,8 +149,6 @@
149 149  
150 150  
151 151  )))|(((
152 -//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
153 -
154 154  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.
155 155  )))
156 156  |(((
... ... @@ -158,8 +158,6 @@
158 158  
159 159  
160 160  )))|(((
161 -//Contextual characteristics that are significant for the applicability of the pattern.//
162 -
163 163  This IDP can be used in the following contexts:
164 164  * Reminding the PwD to take medication if they have not done so already
165 165  * Reminding the PwD to eat food if they have not done so already
... ... @@ -170,8 +170,6 @@
170 170  
171 171  
172 172  )))|(((
173 -//Essential characteristics of the design solution that express the interaction intention.//
174 -
175 175  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.
176 176  )))
177 177  |(((
... ... @@ -179,7 +179,6 @@
179 179  
180 180  
181 181  )))|(((
182 -//Argumentation that resulted in the chosen design solution.//
183 183  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.
184 184  
185 185  )))
... ... @@ -187,8 +187,6 @@
187 187  **EXAMPLES (as seen on…)**
188 188  
189 189  )))|(((
190 -//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.//
191 -
192 192  TBD (should we include or not?)
193 193  )))
194 194  
... ... @@ -203,7 +203,6 @@
203 203  
204 204  
205 205  )))|(((
206 -//Notion of the validity (e.g., empirically tested)//
207 207  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper asking the PwD for confirmation.
208 208  
209 209  )))
... ... @@ -212,8 +212,6 @@
212 212  
213 213  
214 214  )))|(((
215 -//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
216 -
217 217  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.
218 218  )))
219 219  |(((
... ... @@ -221,8 +221,6 @@
221 221  **CONTEXT (use when…)**
222 222  
223 223  )))|(((
224 -//Contextual characteristics that are significant for the applicability of the pattern.//
225 -
226 226  This IDP can be used in the following contexts:
227 227  * Asking for confirmation of having taken medication
228 228  * Asking for confirmation of having eaten a meal
... ... @@ -234,8 +234,6 @@
234 234  
235 235  
236 236  )))|(((
237 -//Essential characteristics of the design solution that express the interaction intention.//
238 -
239 239  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.
240 240  )))
241 241  |(((
... ... @@ -243,8 +243,6 @@
243 243  
244 244  
245 245  )))|(((
246 -//Argumentation that resulted in the chosen design solution.//
247 -
248 248  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.
249 249  
250 250  )))
... ... @@ -252,8 +252,6 @@
252 252  **EXAMPLES (as seen on…)**
253 253  
254 254  )))|(((
255 -//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.//
256 -
257 257  TBD (should we include or not?)
258 258  )))
259 259  
... ... @@ -268,7 +268,6 @@
268 268  
269 269  
270 270  )))|(((
271 -//Notion of the validity (e.g., empirically tested)//
272 272  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper congratulating the PwD.
273 273  )))
274 274  |(((
... ... @@ -276,8 +276,6 @@
276 276  
277 277  
278 278  )))|(((
279 -//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
280 -
281 281  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.
282 282  )))
283 283  |(((
... ... @@ -285,8 +285,6 @@
285 285  **CONTEXT (use when…)**
286 286  
287 287  )))|(((
288 -//Contextual characteristics that are significant for the applicability of the pattern.//
289 -
290 290  This IDP can be used in the following contexts:
291 291  * Congratulate the PwD for having taken medication
292 292  * Congratulate the PwD for having eaten medication
... ... @@ -298,8 +298,6 @@
298 298  
299 299  
300 300  )))|(((
301 -//Essential characteristics of the design solution that express the interaction intention.//
302 -
303 303  This IDP is quite basic and simply pre-programmed into Pepper. Simply congratulating the PwD for finishing a certain task or activity is sufficient.
304 304  )))
305 305  |(((
... ... @@ -315,8 +315,6 @@
315 315  **EXAMPLES (as seen on…)**
316 316  
317 317  )))|(((
318 -//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.//
319 -
320 320  TBD (should we include or not?)
321 321  )))
322 322  
... ... @@ -331,7 +331,6 @@
331 331  
332 332  
333 333  )))|(((
334 -//Notion of the validity (e.g., empirically tested)//
335 335  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.
336 336  )))
337 337  |(((
... ... @@ -339,8 +339,6 @@
339 339  
340 340  
341 341  )))|(((
342 -//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
343 -
344 344  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.
345 345  )))
346 346  |(((
... ... @@ -348,8 +348,6 @@
348 348  **CONTEXT (use when…)**
349 349  
350 350  )))|(((
351 -//Contextual characteristics that are significant for the applicability of the pattern.//
352 -
353 353  This IDP can be used in the following contexts:
354 354  * PwD wants to perform a new activity
355 355  * Pepper is not yet personalized to the particular PwD
... ... @@ -359,8 +359,6 @@
359 359  
360 360  
361 361  )))|(((
362 -//Essential characteristics of the design solution that express the interaction intention.//
363 -
364 364  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.
365 365  )))
366 366  |(((
... ... @@ -368,7 +368,6 @@
368 368  
369 369  
370 370  )))|(((
371 -//Argumentation that resulted in the chosen design solution.//
372 372  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.
373 373  
374 374  )))
... ... @@ -376,8 +376,6 @@
376 376  **EXAMPLES (as seen on…)**
377 377  
378 378  )))|(((
379 -//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.//
380 -
381 381  TBD (should we include or not?)
382 382  )))
383 383  
... ... @@ -392,7 +392,6 @@
392 392  
393 393  
394 394  )))|(((
395 -//Notion of the validity (e.g., empirically tested)//
396 396  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper saying a step to the PwD.
397 397  
398 398  )))
... ... @@ -401,8 +401,6 @@
401 401  
402 402  
403 403  )))|(((
404 -//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
405 -
406 406  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.
407 407  )))
408 408  |(((
... ... @@ -410,8 +410,6 @@
410 410  **CONTEXT (use when…)**
411 411  
412 412  )))|(((
413 -//Contextual characteristics that are significant for the applicability of the pattern.//
414 -
415 415  This IDP can be used in the following contexts:
416 416  * PwD needs the next step for a gardening activity
417 417  * PwD needs the next step for making a paper plane
... ... @@ -421,7 +421,6 @@
421 421  
422 422  
423 423  )))|(((
424 -//Essential characteristics of the design solution that express the interaction intention.//
425 425  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.
426 426  )))
427 427  |(((
... ... @@ -429,7 +429,6 @@
429 429  
430 430  
431 431  )))|(((
432 -//Argumentation that resulted in the chosen design solution.//
433 433  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.
434 434  )))
435 435  |(((
... ... @@ -436,8 +436,6 @@
436 436  **EXAMPLES (as seen on…)**
437 437  
438 438  )))|(((
439 -//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.//
440 -
441 441  TBD (should we include or not?)
442 442  )))
443 443