Skip to Content

Wiki source code of Interaction Design Patterns

Version 14.1 by Pierre Bongrand on 2022/03/30 00:47
Show last authors
1 (% style="background-color:#ffffff; font-size:14px" %)
2
3 == IDP01==
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"/>
6 {{/html}}
7
8 |(((
9 **RANKING/ validation**
10
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.
13 )))
14 |(((
15 **DESIGN PROBLEM (what)**
16
17
18 )))|(((
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 )))
21 |(((
22 **CONTEXT (use when…)**
23
24
25 )))|(((
26 This IDP can be used in the following contexts:
27 * Alert the PwD before an interaction takes place
28 * Wake up reminder for PwD
29 * Entertainment for PwD
30 * Useful for associating certain activities to certain musical sounds
31 )))
32 |(((
33 **DESIGN SOLUTION (how)**
34
35
36 )))|(((
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 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 )))
40 |(((
41 **DESIGN RATIONALE (why)**
42
43
44 )))|(((
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 )))
47 |(((
48 **EXAMPLES (as seen on…)**
49
50
51 )))|(((
52 TBD (should we include or not?)
53 )))
54
55
56 == IDP02==
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"/>
59 {{/html}}
60
61 |(((
62 **RANKING/ validation**
63
64
65 )))|(((
66 This can be empirically tested as the PwD, and other evaluators around, can hear Pepper asking this question.
67
68 )))
69 |(((
70 **DESIGN PROBLEM (what)**
71
72
73 )))|(((
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 )))
76 |(((
77 **CONTEXT (use when…)**
78
79
80 )))|(((
81 This IDP can be used in the following contexts:
82 * Understanding whether the PwD has taken medication before reminding them
83 * Understanding whether the PwD has eaten a meal before reminding them
84 The list can be further expanded as more crucial task usecases are added.
85 )))
86 |(((
87 **DESIGN SOLUTION (how)**
88
89
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
93 )))
94 |(((
95 **DESIGN RATIONALE (why)**
96
97
98 )))|(((
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 )))
102 |(((
103 **EXAMPLES (as seen on…)**
104
105
106 )))|(((
107 TBD (should we include or not?)
108 )))
109
110
111 == IDP03==
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"/>
114 {{/html}}
115
116 |(((
117 **RANKING/ validation**
118
119
120 )))|(((
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 )))
124 |(((
125 **DESIGN PROBLEM (what)**
126
127
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.
130 )))
131 |(((
132 **CONTEXT (use when…)**
133
134
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.
140 )))
141 |(((
142 **DESIGN SOLUTION (how)**
143
144
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.
147 )))
148 |(((
149 **DESIGN RATIONALE (why)**
150
151
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.
154
155 )))
156 |(((
157 **EXAMPLES (as seen on…)**
158
159 )))|(((
160 TBD (should we include or not?)
161 )))
162
163
164 == IDP04==
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"/>
167 {{/html}}
168
169 |(((
170 **RANKING/ validation**
171
172
173 )))|(((
174 This can be empirically tested as the PwD, and other evaluators around, can hear Pepper asking the PwD for confirmation.
175
176 )))
177 |(((
178 **DESIGN PROBLEM (what)**
179
180
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.
183 )))
184 |(((
185
186 **CONTEXT (use when…)**
187
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.
194 )))
195 |(((
196 **DESIGN SOLUTION (how)**
197
198
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.
201 )))
202 |(((
203 **DESIGN RATIONALE (why)**
204
205
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.
208
209 )))
210 |(((
211 **EXAMPLES (as seen on…)**
212
213 )))|(((
214 TBD (should we include or not?)
215 )))
216
217
218 == IDP05==
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"/>
221 {{/html}}
222
223 |(((
224 **RANKING/ validation**
225
226
227 )))|(((
228 This can be empirically tested as the PwD, and other evaluators around, can hear Pepper congratulating the PwD.
229 )))
230 |(((
231 **DESIGN PROBLEM (what)**
232
233
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.
236 )))
237 |(((
238
239 **CONTEXT (use when…)**
240
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.
247 )))
248 |(((
249 **DESIGN SOLUTION (how)**
250
251
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.
254 )))
255 |(((
256 **DESIGN RATIONALE (why)**
257
258
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.
262
263 )))
264 |(((
265 **EXAMPLES (as seen on…)**
266
267 )))|(((
268 TBD (should we include or not?)
269 )))
270
271
272 == IDP06==
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"/>
275 {{/html}}
276
277 |(((
278 **RANKING/ validation**
279
280
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.
283 )))
284 |(((
285 **DESIGN PROBLEM (what)**
286
287
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.
290 )))
291 |(((
292
293 **CONTEXT (use when…)**
294
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
299 )))
300 |(((
301 **DESIGN SOLUTION (how)**
302
303
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.
306 )))
307 |(((
308 **DESIGN RATIONALE (why)**
309
310
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.
313
314 )))
315 |(((
316 **EXAMPLES (as seen on…)**
317
318 )))|(((
319 TBD (should we include or not?)
320 )))
321
322
323 == IDP07==
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"/>
326 {{/html}}
327
328 |(((
329 **RANKING/ validation**
330
331
332 )))|(((
333 This can be empirically tested as the PwD, and other evaluators around, can hear Pepper saying a step to the PwD.
334
335 )))
336 |(((
337 **DESIGN PROBLEM (what)**
338
339
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.
342 )))
343 |(((
344
345 **CONTEXT (use when…)**
346
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
351 )))
352 |(((
353 **DESIGN SOLUTION (how)**
354
355
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.
358 )))
359 |(((
360 **DESIGN RATIONALE (why)**
361
362
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.
365 )))
366 |(((
367 **EXAMPLES (as seen on…)**
368
369 )))|(((
370 TBD (should we include or not?)
371 )))
372