Wiki source code of Interaction Design Patterns

Version 11.1 by Mathieu Jung-Muller on 2022/03/30 00:28

version	line-number	content
2.1	1	(% style="background-color:#ffffff; font-size:14px" %)
	2
6.1	3	== IDP01==
2.1	4	{{html}}
6.1	5	<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp1.jpg?rev=1.1" alt="IDP01" width="350"/>
2.1	6	{{/html}}
	7
	8	\|(((
	9	RANKING/ validation
	10
	11	)))\|(((
	12	//Notion of the validity (e.g., empirically tested)//
10.1	13	When Pepper is playing music this can clearly be heard by the PwD, and other evaluators around so this IDP is empirically testable.
2.1	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	)))\|(((
5.1	30	//Contextual characteristics that are significant for the applicability of the pattern.//
2.1	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	)))\|(((
5.1	42	//Essential characteristics of the design solution that express the interaction intention.//
2.1	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
6.1	67	== IDP02==
2.1	68	{{html}}
6.1	69	<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp2.jpg?rev=1.1" alt="IDP02" width="350"/>
2.1	70	{{/html}}
	71
	72	\|(((
	73	RANKING/ validation
	74
	75
	76	)))\|(((
	77	//Notion of the validity (e.g., empirically tested)//
5.1	78	This can be empirically tested as the PwD, and other evaluators around can hear Pepper asking this question.
2.1	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	)))\|(((
5.1	107	//Essential characteristics of the design solution that express the interaction intention.//
2.1	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	)))\|(((
5.1	117	//Argumentation that resulted in the chosen design solution.//
2.1	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
6.1	133	== IDP03==
2.1	134	{{html}}
6.1	135	<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp3.jpg?rev=1.1" alt="IDP03" width="350"/>
2.1	136	{{/html}}
	137
	138	\|(((
	139	RANKING/ validation
	140
	141
	142	)))\|(((
5.1	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.
2.1	145
	146	)))
	147	\|(((
	148	DESIGN PROBLEM (what)
	149
	150
	151	)))\|(((
5.1	152	//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
2.1	153
5.1	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.
2.1	155	)))
	156	\|(((
	157	CONTEXT (use when…)
	158
	159
	160	)))\|(((
5.1	161	//Contextual characteristics that are significant for the applicability of the pattern.//
2.1	162
5.1	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.
2.1	167	)))
	168	\|(((
	169	DESIGN SOLUTION (how)
	170
	171
	172	)))\|(((
5.1	173	//Essential characteristics of the design solution that express the interaction intention.//
2.1	174
11.1	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.
2.1	176	)))
	177	\|(((
	178	DESIGN RATIONALE (why)
	179
	180
	181	)))\|(((
5.1	182	//Argumentation that resulted in the chosen design solution.//
11.1	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.
2.1	184
	185	)))
	186	\|(((
	187	EXAMPLES (as seen on…)
	188
	189	)))\|(((
5.1	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.//
2.1	191
5.1	192	TBD (should we include or not?)
2.1	193	)))
	194
	195
6.1	196	== IDP04==
2.1	197	{{html}}
6.1	198	<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp4.jpg?rev=1.1" alt="IDP04" width="350"/>
2.1	199	{{/html}}
	200
	201	\|(((
	202	RANKING/ validation
	203
	204
	205	)))\|(((
5.1	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.
2.1	208
	209	)))
	210	\|(((
	211	DESIGN PROBLEM (what)
	212
	213
	214	)))\|(((
5.1	215	//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
2.1	216
5.1	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.
2.1	218	)))
	219	\|(((
	220
	221	CONTEXT (use when…)
	222
	223	)))\|(((
5.1	224	//Contextual characteristics that are significant for the applicability of the pattern.//
2.1	225
5.1	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.
2.1	231	)))
	232	\|(((
	233	DESIGN SOLUTION (how)
	234
	235
	236	)))\|(((
5.1	237	//Essential characteristics of the design solution that express the interaction intention.//
2.1	238
5.1	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.
2.1	240	)))
	241	\|(((
	242	DESIGN RATIONALE (why)
	243
	244
	245	)))\|(((
5.1	246	//Argumentation that resulted in the chosen design solution.//
2.1	247
5.1	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.
2.1	249
	250	)))
	251	\|(((
	252	EXAMPLES (as seen on…)
	253
	254	)))\|(((
5.1	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.//
2.1	256
5.1	257	TBD (should we include or not?)
2.1	258	)))
	259
	260
6.1	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)//
8.1	272	This can be empirically tested as the PwD, and other evaluators around can hear Pepper congratulating the PwD.
6.1	273	)))
	274	\|(((
	275	DESIGN PROBLEM (what)
	276
	277
	278	)))\|(((
	279	//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
	280
8.1	281	This design pattern is used to verbally congratulate the PwD, and make the feel about about a task that they just accomplished. This is to lift the spirits of the PwD and make the enjoy and want to do certain tasks.
6.1	282	)))
	283	\|(((
	284
	285	CONTEXT (use when…)
	286
	287	)))\|(((
	288	//Contextual characteristics that are significant for the applicability of the pattern.//
	289
	290	This IDP can be used in the following contexts:
8.1	291	* Congratulate the PwD for having taken medication
	292	* Congratulate the PwD for having eaten medication
	293	* Congratulate the PwD for doing a particular activity completely
	294	The list can be further expanded as more task usecases are added.
6.1	295	)))
	296	\|(((
	297	DESIGN SOLUTION (how)
	298
	299
	300	)))\|(((
	301	//Essential characteristics of the design solution that express the interaction intention.//
	302
8.1	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.
6.1	304	)))
	305	\|(((
	306	DESIGN RATIONALE (why)
	307
	308
	309	)))\|(((
	310	//Argumentation that resulted in the chosen design solution.//
8.1	311	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.
6.1	312
8.1	313	)))
	314	\|(((
	315	EXAMPLES (as seen on…)
6.1	316
8.1	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	TBD (should we include or not?)
6.1	321	)))
8.1	322
	323
	324	== IDP06==
	325	{{html}}
	326	<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp6.jpg?rev=1.1" alt="IDP06s" width="350"/>
	327	{{/html}}
	328
6.1	329	\|(((
8.1	330	RANKING/ validation
	331
	332
	333	)))\|(((
	334	//Notion of the validity (e.g., empirically tested)//
	335	This can be tested by performing some other IDPs, which refer to utilizing the breakdown of a particular activity. Since this some programmed into Pepper, it is not empirically testable.
	336	)))
	337	\|(((
	338	DESIGN PROBLEM (what)
	339
	340
	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	This design pattern is used by the HPC inorder to enter some activities into Pepper, that that the PwD might personally enjoy. This is so that Pepper's system contains the breakdown to certain desired activities.
	345	)))
	346	\|(((
	347
	348	CONTEXT (use when…)
	349
	350	)))\|(((
	351	//Contextual characteristics that are significant for the applicability of the pattern.//
	352
	353	This IDP can be used in the following contexts:
	354	* PwD wants to perform a new activity
	355	* Pepper is not yet personalized to the particular PwD
	356	)))
	357	\|(((
	358	DESIGN SOLUTION (how)
	359
	360
	361	)))\|(((
	362	//Essential characteristics of the design solution that express the interaction intention.//
	363
	364	Here in order to easy configuration of Pepper, we will utilize the tablet feature where the HPC can enter activity steps. This is so that the caregiver also has some autonomy over Pepper rather than just the developers. The interface designed is easy to use as, HCPs are not required to have very high technical knowledge.
	365	)))
	366	\|(((
	367	DESIGN RATIONALE (why)
	368
	369
	370	)))\|(((
	371	//Argumentation that resulted in the chosen design solution.//
	372	We allow the HPC to provide steps has they are they 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 having some arbitrary step up of steps from the internet.
	373
	374	)))
	375	\|(((
6.1	376	EXAMPLES (as seen on…)
	377
	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	TBD (should we include or not?)
	382	)))
	383
	384
9.1	385	== IDP07==
	386	{{html}}
	387	<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp7.jpg?rev=1.1" alt="IDP07" width="350"/>
	388	{{/html}}
	389
	390	\|(((
	391	RANKING/ validation
	392
	393
	394	)))\|(((
	395	//Notion of the validity (e.g., empirically tested)//
	396	This can be empirically tested as the PwD, and other evaluators around can hear Pepper saying a step to the PwD.
	397
	398	)))
	399	\|(((
	400	DESIGN PROBLEM (what)
	401
	402
	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	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	)))
	408	\|(((
	409
	410	CONTEXT (use when…)
	411
	412	)))\|(((
	413	//Contextual characteristics that are significant for the applicability of the pattern.//
	414
	415	This IDP can be used in the following contexts:
	416	* PwD needs the next step for a gardening activity
	417	* PwD needs the next step for making a paper plane
	418	)))
	419	\|(((
	420	DESIGN SOLUTION (how)
	421
	422
	423	)))\|(((
	424	//Essential characteristics of the design solution that express the interaction intention.//
	425	Here already having the activity broken down into certain steps is very crucial. Also Pepper needs to stay these steps verbally so the user can hear and act appropriately.
	426	)))
	427	\|(((
	428	DESIGN RATIONALE (why)
	429
	430
	431	)))\|(((
	432	//Argumentation that resulted in the chosen design solution.//
	433	A verbal step here works better than a simply following steps from a website, as would happen commonly these days. Also we believe that having Pepper's 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 in they want to take part in an activity they enjoy.
	434	)))
	435	\|(((
	436	EXAMPLES (as seen on…)
	437
	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	TBD (should we include or not?)
	442	)))
	443
	444