Skip to Content

Wiki source code of Interaction Design Patterns

Version 7.1 by Sneha Lodha on 2022/03/23 22:40
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 //Notion of the validity (e.g., empirically tested)//
13 When Pepper is playing music this can clearly be heard by the PwD, and other evaluators around hence this IDP is empirically testable.
14
15 )))
16 |(((
17 **DESIGN PROBLEM (what)**
18
19
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 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…)**
27
28
29 )))|(((
30 //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)**
39
40
41 )))|(((
42 //Essential characteristics of the design 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)**
49
50
51 )))|(((
52 //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…)**
58
59
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 TBD (should we include or not?)
64 )))
65
66
67 == IDP02==
68 {{html}}
69 <img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp2.jpg?rev=1.1" alt="IDP02" width="350"/>
70 {{/html}}
71
72 |(((
73 **RANKING/ validation**
74
75
76 )))|(((
77 //Notion of the validity (e.g., empirically tested)//
78 This can be empirically tested as the PwD, and other evaluators around can hear Pepper asking this question.
79
80 )))
81 |(((
82 **DESIGN PROBLEM (what)**
83
84
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 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…)**
92
93
94 )))|(((
95 //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)**
104
105
106 )))|(((
107 //Essential characteristics of the design 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.
110
111 )))
112 |(((
113 **DESIGN RATIONALE (why)**
114
115
116 )))|(((
117 //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.
120
121 )))
122 |(((
123 **EXAMPLES (as seen on…)**
124
125
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 TBD (should we include or not?)
130 )))
131
132
133 == IDP03==
134 {{html}}
135 <img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp3.jpg?rev=1.1" alt="IDP03" width="350"/>
136 {{/html}}
137
138 |(((
139 **RANKING/ validation**
140
141
142 )))|(((
143 //Notion of the validity (e.g., empirically tested)//
144 This can be empirically tested as the PwD, and other evaluators around can hear Pepper reminding the PwD to do the task.
145
146 )))
147 |(((
148 **DESIGN PROBLEM (what)**
149
150
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 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 )))
156 |(((
157 **CONTEXT (use when…)**
158
159
160 )))|(((
161 //Contextual characteristics that are significant for the applicability of the pattern.//
162
163 This IDP can be used in the following contexts:
164 * Reminding the PwD to take medication if they have not done so already
165 * Reminding the PwD to eat food if they have not done so already
166 The list can be further expanded as more crucial task usecases are added.
167 )))
168 |(((
169 **DESIGN SOLUTION (how)**
170
171
172 )))|(((
173 //Essential characteristics of the design solution that express the interaction intention.//
174
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 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 )))
177 |(((
178 **DESIGN RATIONALE (why)**
179
180
181 )))|(((
182 //Argumentation that resulted in the chosen design solution.//
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's as a physical being there might encourage the PwD to take such reminders with higher importance than a simple notification.
184
185 )))
186 |(((
187 **EXAMPLES (as seen on…)**
188
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 TBD (should we include or not?)
193 )))
194
195
196 == IDP04==
197 {{html}}
198 <img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp4.jpg?rev=1.1" alt="IDP04" width="350"/>
199 {{/html}}
200
201 |(((
202 **RANKING/ validation**
203
204
205 )))|(((
206 //Notion of the validity (e.g., empirically tested)//
207 This can be empirically tested as the PwD, and other evaluators around can hear Pepper asking the PwD for confirmation.
208
209 )))
210 |(((
211 **DESIGN PROBLEM (what)**
212
213
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 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 )))
219 |(((
220
221 **CONTEXT (use when…)**
222
223 )))|(((
224 //Contextual characteristics that are significant for the applicability of the pattern.//
225
226 This IDP can be used in the following contexts:
227 * Asking for confirmation of having taken medication
228 * Asking for confirmation of having eaten a meal
229 * Asking for confirmation of having done an activity step
230 The list can be further expanded as more crucial task usecases are added.
231 )))
232 |(((
233 **DESIGN SOLUTION (how)**
234
235
236 )))|(((
237 //Essential characteristics of the design solution that express the interaction intention.//
238
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 )))
241 |(((
242 **DESIGN RATIONALE (why)**
243
244
245 )))|(((
246 //Argumentation that resulted in the chosen design solution.//
247
248 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.
249
250 )))
251 |(((
252 **EXAMPLES (as seen on…)**
253
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 TBD (should we include or not?)
258 )))
259
260
261 == IDP05==
262 {{html}}
263 <img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp5.jpg?rev=1.1" alt="IDP05" width="350"/>
264 {{/html}}
265
266 |(((
267 **RANKING/ validation**
268
269
270 )))|(((
271 //Notion of the validity (e.g., empirically tested)//
272 This can be empirically tested as the PwD, and other evaluators around can hear Pepper asking the PwD for confirmation.
273
274 )))
275 |(((
276 **DESIGN PROBLEM (what)**
277
278
279 )))|(((
280 //Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
281
282 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.
283 )))
284 |(((
285
286 **CONTEXT (use when…)**
287
288 )))|(((
289 //Contextual characteristics that are significant for the applicability of the pattern.//
290
291 This IDP can be used in the following contexts:
292 * Asking for confirmation of having taken medication
293 * Asking for confirmation of having eaten a meal
294 * Asking for confirmation of having done an activity step
295 The list can be further expanded as more crucial task usecases are added.
296 )))
297 |(((
298 **DESIGN SOLUTION (how)**
299
300
301 )))|(((
302 //Essential characteristics of the design solution that express the interaction intention.//
303
304 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.
305 )))
306 |(((
307 **DESIGN RATIONALE (why)**
308
309
310 )))|(((
311 //Argumentation that resulted in the chosen design solution.//
312
313 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.
314
315 )))
316 |(((
317 **EXAMPLES (as seen on…)**
318
319 )))|(((
320 //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.//
321
322 TBD (should we include or not?)
323 )))
324
325