Changes for page Interaction Design Patterns

Last modified by Mathieu Jung-Muller on 2022/04/04 13:55

From 6.1 to 7.1 From 8.1 to 9.1

From version

7.1

edited by Sneha Lodha
on 2022/03/23 22:40

Change comment: There is no comment for this version

To version

8.1

edited by Sneha Lodha
on 2022/03/23 23:43

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -269,8 +269,7 @@
  )))|(((
  //Notion of the validity (e.g., empirically tested)//
--This can be empirically tested as the PwD, and other evaluators around can hear Pepper asking the PwD for confirmation.
--
++This can be empirically tested as the PwD, and other evaluators around can hear Pepper congratulating the PwD.
  )))
  |(((
  **DESIGN PROBLEM (what)**
@@ -279,7 +279,7 @@
  )))|(((
  //Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
--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.
++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.
  )))
  |(((
@@ -289,10 +289,10 @@
  //Contextual characteristics that are significant for the applicability of the pattern.//
  This IDP can be used in the following contexts:
--* Asking for confirmation of having taken medication
--* Asking for confirmation of having eaten a meal
--* Asking for confirmation of having done an activity step
--The list can be further expanded as more crucial task usecases are added.
++* Congratulate the PwD for having taken medication
++* Congratulate the PwD for having eaten medication
++* Congratulate the PwD for doing a particular activity completely
++The list can be further expanded as more task usecases are added.
  )))
  |(((
  **DESIGN SOLUTION (how)**
@@ -301,7 +301,7 @@
  )))|(((
  //Essential characteristics of the design solution that express the interaction intention.//
--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.
++This IDP is quite basic and simply pre-programmed into Pepper. Simply congratulating the PwD for finishing a certain task or activity is sufficient.
  )))
  |(((
  **DESIGN RATIONALE (why)**
@@ -309,9 +309,8 @@
  )))|(((
  //Argumentation that resulted in the chosen design solution.//
++ 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.
--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.
--
  )))
  |(((
  **EXAMPLES (as seen on…)**
@@ -323,4 +323,64 @@
  )))
++== IDP06==
++{{html}}
++<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp6.jpg?rev=1.1" alt="IDP06s" width="350"/>
++{{/html}}
++|(((
++**RANKING/ validation**
++
++
++)))|(((
++//Notion of the validity (e.g., empirically tested)//
++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.
++)))
++|(((
++**DESIGN PROBLEM (what)**
++
++
++)))|(((
++//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
++
++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.
++)))
++|(((
++
++**CONTEXT (use when…)**
++
++)))|(((
++//Contextual characteristics that are significant for the applicability of the pattern.//
++
++This IDP can be used in the following contexts:
++* PwD wants to perform a new activity
++* Pepper is not yet personalized to the particular PwD
++)))
++|(((
++**DESIGN SOLUTION (how)**
++
++
++)))|(((
++//Essential characteristics of the design solution that express the interaction intention.//
++
++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.
++)))
++|(((
++**DESIGN RATIONALE (why)**
++
++
++)))|(((
++//Argumentation that resulted in the chosen design solution.//
++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.
++
++)))
++|(((
++**EXAMPLES (as seen on…)**
++
++)))|(((
++//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.//
++
++TBD (should we include or not?)
++)))
++
++