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 15.1 Icon
edited by Pierre Bongrand
on 2022/03/30 00:51
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -6,22 +6,17 @@
6 6  {{/html}}
7 7  
8 8  |(((
9 -**RANKING/ validation**
10 -
9 +**RANKING/ validation**
11 11  )))|(((
12 12  When Pepper is playing music this can clearly be heard by the PwD, and other evaluators around, so this IDP is empirically testable.
13 13  )))
14 14  |(((
15 -**DESIGN PROBLEM (what)**
16 -
17 -
14 +**DESIGN PROBLEM (what)**
18 18  )))|(((
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  |(((
22 22  **CONTEXT (use when…)**
23 -
24 -
25 25  )))|(((
26 26  This IDP can be used in the following contexts:
27 27  * Alert the PwD before an interaction takes place
... ... @@ -31,8 +31,6 @@
31 31  )))
32 32  |(((
33 33  **DESIGN SOLUTION (how)**
34 -
35 -
36 36  )))|(((
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,15 +39,11 @@
39 39  )))
40 40  |(((
41 41  **DESIGN RATIONALE (why)**
42 -
43 -
44 44  )))|(((
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  |(((
48 48  **EXAMPLES (as seen on…)**
49 -
50 -
51 51  )))|(((
52 52  TBD (should we include or not?)
53 53  )))
... ... @@ -60,23 +60,16 @@
60 60  
61 61  |(((
62 62  **RANKING/ validation**
63 -
64 -
65 65  )))|(((
66 66  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper asking this question.
67 -
68 68  )))
69 69  |(((
70 70  **DESIGN PROBLEM (what)**
71 -
72 -
73 73  )))|(((
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  |(((
77 -**CONTEXT (use when…)**
78 -
79 -
61 +**CONTEXT (use when…)**
80 80  )))|(((
81 81  This IDP can be used in the following contexts:
82 82  * Understanding whether the PwD has taken medication before reminding them
... ... @@ -84,25 +84,17 @@
84 84  The list can be further expanded as more crucial task usecases are added.
85 85  )))
86 86  |(((
87 -**DESIGN SOLUTION (how)**
88 -
89 -
69 +**DESIGN SOLUTION (how)**
90 90  )))|(((
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 -
71 +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.
93 93  )))
94 94  |(((
95 95  **DESIGN RATIONALE (why)**
96 -
97 -
98 98  )))|(((
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 -
101 101  )))
102 102  |(((
103 103  **EXAMPLES (as seen on…)**
104 -
105 -
106 106  )))|(((
107 107  TBD (should we include or not?)
108 108  )))
... ... @@ -115,23 +115,16 @@
115 115  
116 116  |(((
117 117  **RANKING/ validation**
118 -
119 -
120 120  )))|(((
121 121  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper reminding the PwD to do the task.
122 -
123 123  )))
124 124  |(((
125 -**DESIGN PROBLEM (what)**
126 -
127 -
96 +**DESIGN PROBLEM (what)**
128 128  )))|(((
129 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.
130 130  )))
131 131  |(((
132 132  **CONTEXT (use when…)**
133 -
134 -
135 135  )))|(((
136 136  This IDP can be used in the following contexts:
137 137  * Reminding the PwD to take medication if they have not done so already
... ... @@ -140,22 +140,16 @@
140 140  )))
141 141  |(((
142 142  **DESIGN SOLUTION (how)**
143 -
144 -
145 145  )))|(((
146 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.
147 147  )))
148 148  |(((
149 149  **DESIGN RATIONALE (why)**
150 -
151 -
152 152  )))|(((
153 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.
154 -
155 155  )))
156 156  |(((
157 157  **EXAMPLES (as seen on…)**
158 -
159 159  )))|(((
160 160  TBD (should we include or not?)
161 161  )))
... ... @@ -168,23 +168,16 @@
168 168  
169 169  |(((
170 170  **RANKING/ validation**
171 -
172 -
173 173  )))|(((
174 174  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper asking the PwD for confirmation.
175 -
176 176  )))
177 177  |(((
178 178  **DESIGN PROBLEM (what)**
179 -
180 -
181 181  )))|(((
182 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.
183 183  )))
184 184  |(((
185 -
186 186  **CONTEXT (use when…)**
187 -
188 188  )))|(((
189 189  This IDP can be used in the following contexts:
190 190  * Asking for confirmation of having taken medication
... ... @@ -194,22 +194,16 @@
194 194  )))
195 195  |(((
196 196  **DESIGN SOLUTION (how)**
197 -
198 -
199 199  )))|(((
200 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.
201 201  )))
202 202  |(((
203 203  **DESIGN RATIONALE (why)**
204 -
205 -
206 206  )))|(((
207 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.
208 -
209 209  )))
210 210  |(((
211 211  **EXAMPLES (as seen on…)**
212 -
213 213  )))|(((
214 214  TBD (should we include or not?)
215 215  )))
... ... @@ -221,23 +221,17 @@
221 221  {{/html}}
222 222  
223 223  |(((
224 -**RANKING/ validation**
225 -
226 -
172 +**RANKING/ validation**
227 227  )))|(((
228 228  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper congratulating the PwD.
229 229  )))
230 230  |(((
231 231  **DESIGN PROBLEM (what)**
232 -
233 -
234 234  )))|(((
235 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.
236 236  )))
237 237  |(((
238 -
239 239  **CONTEXT (use when…)**
240 -
241 241  )))|(((
242 242  This IDP can be used in the following contexts:
243 243  * Congratulate the PwD for having taken medication
... ... @@ -247,23 +247,17 @@
247 247  )))
248 248  |(((
249 249  **DESIGN SOLUTION (how)**
250 -
251 -
252 252  )))|(((
253 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.
254 254  )))
255 255  |(((
256 256  **DESIGN RATIONALE (why)**
257 -
258 -
259 259  )))|(((
260 260  //Argumentation that resulted in the chosen design solution.//
261 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.
262 -
263 263  )))
264 264  |(((
265 265  **EXAMPLES (as seen on…)**
266 -
267 267  )))|(((
268 268  TBD (should we include or not?)
269 269  )))
... ... @@ -276,22 +276,16 @@
276 276  
277 277  |(((
278 278  **RANKING/ validation**
279 -
280 -
281 281  )))|(((
282 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.
283 283  )))
284 284  |(((
285 285  **DESIGN PROBLEM (what)**
286 -
287 -
288 288  )))|(((
289 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.
290 290  )))
291 291  |(((
292 -
293 293  **CONTEXT (use when…)**
294 -
295 295  )))|(((
296 296  This IDP can be used in the following contexts:
297 297  * PwD wants to perform a new activity
... ... @@ -299,22 +299,16 @@
299 299  )))
300 300  |(((
301 301  **DESIGN SOLUTION (how)**
302 -
303 -
304 304  )))|(((
305 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.
306 306  )))
307 307  |(((
308 308  **DESIGN RATIONALE (why)**
309 -
310 -
311 311  )))|(((
312 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.
313 -
314 314  )))
315 315  |(((
316 316  **EXAMPLES (as seen on…)**
317 -
318 318  )))|(((
319 319  TBD (should we include or not?)
320 320  )))
... ... @@ -327,23 +327,16 @@
327 327  
328 328  |(((
329 329  **RANKING/ validation**
330 -
331 -
332 332  )))|(((
333 333  This can be empirically tested as the PwD, and other evaluators around, can hear Pepper saying a step to the PwD.
334 -
335 335  )))
336 336  |(((
337 337  **DESIGN PROBLEM (what)**
338 -
339 -
340 340  )))|(((
341 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.
342 342  )))
343 343  |(((
344 -
345 345  **CONTEXT (use when…)**
346 -
347 347  )))|(((
348 348  This IDP can be used in the following contexts:
349 349  * PwD needs the next step for a gardening activity
... ... @@ -351,21 +351,16 @@
351 351  )))
352 352  |(((
353 353  **DESIGN SOLUTION (how)**
354 -
355 -
356 356  )))|(((
357 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.
358 358  )))
359 359  |(((
360 360  **DESIGN RATIONALE (why)**
361 -
362 -
363 363  )))|(((
364 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.
365 365  )))
366 366  |(((
367 367  **EXAMPLES (as seen on…)**
368 -
369 369  )))|(((
370 370  TBD (should we include or not?)
371 371  )))