Changes for page Interaction Design Patterns

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

From 3.1 to 4.1 From 6.1 to 7.1

From version

4.1

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

Change comment: There is no comment for this version

To version

6.1

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

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -1,8 +1,8 @@
  (% style="background-color:#ffffff; font-size:14px" %)
--== IDP001==
++== IDP01==
  {{html}}
--<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp1.jpg?rev=1.1" alt="IDP001" width="350"/>
++<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp1.jpg?rev=1.1" alt="IDP01" width="350"/>
  {{/html}}
  |(((
@@ -10,8 +10,8 @@
  )))|(((
  //Notion of the validity (e.g., empirically tested)//
++When Pepper is playing music this can clearly be heard by the PwD, and other evaluators around hence this IDP is empirically testable.
--TBD
  )))
  |(((
  **DESIGN PROBLEM (what)**
@@ -27,7 +27,7 @@
  )))|(((
--//References to a list of the contextual characteristics that are significant for the applicability of the pattern.//
++//Contextual characteristics that are significant for the applicability of the pattern.//
  This IDP can be used in the following contexts:
  * Alert the PwD before an interaction takes place
  * Wake up reminder for PwD
@@ -39,7 +39,7 @@
  )))|(((
--//Description of the essential characteristics of the solution that express the interaction intention.//
++//Essential characteristics of the design solution that express the interaction intention.//
  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.
  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.
@@ -64,9 +64,9 @@
  )))
--== IDP002==
++== IDP02==
  {{html}}
--<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp2.jpg?rev=1.1" alt="IDP002" width="350"/>
++<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp2.jpg?rev=1.1" alt="IDP02" width="350"/>
  {{/html}}
  |(((
@@ -75,8 +75,8 @@
  )))|(((
  //Notion of the validity (e.g., empirically tested)//
++This can be empirically tested as the PwD, and other evaluators around can hear Pepper asking this question.
--TBD
  )))
  |(((
  **DESIGN PROBLEM (what)**
@@ -104,7 +104,7 @@
  )))|(((
--//Description of the essential characteristics of the solution that express the interaction intention.//
++//Essential characteristics of the design solution that express the interaction intention.//
  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.
@@ -114,7 +114,7 @@
  )))|(((
--//Trade-offs and the argumentation that resulted in the chosen design solution.//
++//Argumentation that resulted in the chosen design solution.//
  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.
@@ -130,9 +130,9 @@
  )))
--== IDP003==
++== IDP03==
  {{html}}
--<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp3.jpg?rev=1.1" alt="IDP003" width="350"/>
++<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp3.jpg?rev=1.1" alt="IDP03" width="350"/>
  {{/html}}
  |(((
@@ -140,11 +140,9 @@
  )))|(((
--//Provide a notion of the validity (e.g., empirically tested)//
++//Notion of the validity (e.g., empirically tested)//
++This can be empirically tested as the PwD, and other evaluators around can hear Pepper reminding the PwD to do the task.
--The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).
--
--
  )))
  |(((
  **DESIGN PROBLEM (what)**
@@ -151,11 +151,9 @@
  )))|(((
--//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
++//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
--The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.
--
--
++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.
  )))
  |(((
  **CONTEXT (use when…)**
@@ -162,13 +162,12 @@
  )))|(((
--//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//
++//Contextual characteristics that are significant for the applicability of the pattern.//
--The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable
--
--The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.
--
--
++This IDP can be used in the following contexts:
++* Reminding the PwD to take medication if they have not done so already
++* Reminding the PwD to eat food if they have not done so already
++The list can be further expanded as more crucial task usecases are added.
  )))
  |(((
  **DESIGN SOLUTION (how)**
@@ -175,11 +175,9 @@
  )))|(((
--//Provide a description of the essential characteristics of the design solution that express the interaction intention.//
++//Essential characteristics of the design solution that express the interaction intention.//
--The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.
--
--
++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.
  )))
  |(((
  **DESIGN RATIONALE (why)**
@@ -186,30 +186,23 @@
  )))|(((
--//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
++//Argumentation that resulted in the chosen design solution.//
++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.
--The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.
--
--
  )))
  |(((
  **EXAMPLES (as seen on…)**
--
  )))|(((
--//Provide an 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.//
++//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.//
--The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.
++TBD (should we include or not?)
  )))
--|**RELATED PATTERNS**|(((
--//Provide the names and/or links of related patterns.//
--Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).
--)))
--== IDP004==
++== IDP04==
  {{html}}
--<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp4.jpg?rev=1.1" alt="IDP004" width="350"/>
++<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp4.jpg?rev=1.1" alt="IDP04" width="350"/>
  {{/html}}
  |(((
@@ -217,11 +217,9 @@
  )))|(((
--//Provide a notion of the validity (e.g., empirically tested)//
++//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.
--The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).
--
--
  )))
  |(((
  **DESIGN PROBLEM (what)**
@@ -228,101 +228,22 @@
  )))|(((
--//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
++//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
--The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.
--
--
++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.
  )))
  |(((
--**CONTEXT (use when…)**
--
--)))|(((
--//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//
--
--The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable
--
--The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.
--
--
--)))
--|(((
--**DESIGN SOLUTION (how)**
--
--
--)))|(((
--//Provide a description of the essential characteristics of the design solution that express the interaction intention.//
--
--The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.
--
--
--)))
--|(((
--**DESIGN RATIONALE (why)**
--
--
--)))|(((
--//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
--
--The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.
--
--
--)))
--|(((
--**EXAMPLES (as seen on…)**
--
--
--)))|(((
--//Provide an 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.//
--
--The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.
--)))
--|**RELATED PATTERNS**|(((
--//Provide the names and/or links of related patterns.//
--
--Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).
--)))
--
--== IDP005==
--{{html}}
--<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp5.jpg?rev=1.1" alt="IDP005" width="350"/>
--{{/html}}
--
--|(((
--**RANKING/ validation**
--
--
--)))|(((
--//Provide a notion of the validity (e.g., empirically tested)//
--
--The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).
--
--
--)))
--|(((
--**DESIGN PROBLEM (what)**
--
--
--)))|(((
--//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
--
--The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.
--
--
--)))
--|(((
  **CONTEXT (use when…)**
--
  )))|(((
--//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//
++//Contextual characteristics that are significant for the applicability of the pattern.//
--The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable
--
--The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.
--
--
++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.
  )))
  |(((
  **DESIGN SOLUTION (how)**
@@ -329,11 +329,9 @@
  )))|(((
--//Provide a description of the essential characteristics of the design solution that express the interaction intention.//
++//Essential characteristics of the design solution that express the interaction intention.//
--The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.
--
--
++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.
  )))
  |(((
  **DESIGN RATIONALE (why)**
@@ -340,30 +340,24 @@
  )))|(((
--//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
++//Argumentation that resulted in the chosen design solution.//
--The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.
++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…)**
--
  )))|(((
--//Provide an 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.//
++//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.//
--The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.
++TBD (should we include or not?)
  )))
--|**RELATED PATTERNS**|(((
--//Provide the names and/or links of related patterns.//
--Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).
--)))
--== IDP006==
++== IDP05==
  {{html}}
--<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp6.jpg?rev=1.1" alt="IDP006" width="350"/>
++<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp5.jpg?rev=1.1" alt="IDP05" width="350"/>
  {{/html}}
  |(((
@@ -371,11 +371,9 @@
  )))|(((
--//Provide a notion of the validity (e.g., empirically tested)//
++//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.
--The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).
--
--
  )))
  |(((
  **DESIGN PROBLEM (what)**
@@ -382,24 +382,22 @@
  )))|(((
--//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
++//Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
--The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.
--
--
++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.
  )))
  |(((
--**CONTEXT (use when…)**
++**CONTEXT (use when…)**
  )))|(((
--//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//
++//Contextual characteristics that are significant for the applicability of the pattern.//
--The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable
--
--The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.
--
--
++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.
  )))
  |(((
  **DESIGN SOLUTION (how)**
@@ -406,11 +406,9 @@
  )))|(((
--//Provide a description of the essential characteristics of the design solution that express the interaction intention.//
++//Essential characteristics of the design solution that express the interaction intention.//
--The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.
--
--
++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.
  )))
  |(((
  **DESIGN RATIONALE (why)**
@@ -417,100 +417,19 @@
  )))|(((
--//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
++//Argumentation that resulted in the chosen design solution.//
--The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.
++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…)**
--
  )))|(((
--//Provide an 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.//
++//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.//
--The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.
++TBD (should we include or not?)
  )))
--|**RELATED PATTERNS**|(((
--//Provide the names and/or links of related patterns.//
--Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).
--)))
--== IDP007==
--{{html}}
--<img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/idp7.jpg?rev=1.1" alt="IDP007" width="350"/>
--{{/html}}
--|(((
--**RANKING/ validation**
--
--
--)))|(((
--//Provide a notion of the validity (e.g., empirically tested)//
--
--The ranking should indicate the validity of the patterns premise. It can help the reader to distinguish early pattern ideas from patterns confirmed in practice (Borchers, 2001b).
--
--
--)))
--|(((
--**DESIGN PROBLEM (what)**
--
--
--)))|(((
--//Provide a concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).//
--
--The design problem describes the design problem in terms of the interaction intention. The intention of an interaction can be extracted from the user requirements. For the example of praise (the ePartner shall provide and/or facilitate situated praise) this could be to give the user a feeling of appraisal. If the requirement were about conducting small talk, the interaction intention would be something in line with making the user feel at ease with the ePartner.
--
--
--)))
--|(((
--**CONTEXT (use when…)**
--
--
--)))|(((
--//Provide a reference to the relevant use case(s) and a list of the contextual characteristics that are significant for the applicability of the pattern.//
--
--The context describes the characteristics of the tasks, the users, and the environment for which the pattern can be applied. This should provide the designer insight in when the design pattern can be used, and when the design pattern is less suitable
--
--The use cases already provide the situational factors (e.g., dialogue partner(s), physical and social context, interaction platform, and dialogue context) that influence the design solution (specific embodiment of the dialogue). The design pattern should only list the contextual characteristics that determine in what situation the design solution can be applied.
--
--
--)))
--|(((
--**DESIGN SOLUTION (how)**
--
--
--)))|(((
--//Provide a description of the essential characteristics of the design solution that express the interaction intention.//
--
--The design solution provides a concrete description of the solution for the design problem. This encompasses the specific shape of the dialogue by describing what characteristics express the intended interaction within the given context. So what verbal and non-verbal communication should be used, what dialogue rules should be followed etc. Only the core of the solution should be described, references to other relevant patterns can be used.
--
--
--)))
--|(((
--**DESIGN RATIONALE (why)**
--
--
--)))|(((
--//Provide the considered trade-offs and the argumentation that resulted in the chosen design solution.//
--
--The rationale provides insight in how the design pattern works, why it works and how it is based on underlying principles and mechanisms (Van Welie et al., 2000). It provides a convincing argumentation on the effects of the chosen design solution, including trade-offs. It includes premises that may need empirical validation.
--
--
--)))
--|(((
--**EXAMPLES (as seen on…)**
--
--
--)))|(((
--//Provide an 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.//
--
--The examples should show successful uses of the pattern (e.g. best practices, as seen on….). It shows how the pattern can manifest itself differently in various ‘real-life’ applications.
--)))
--|**RELATED PATTERNS**|(((
--//Provide the names and/or links of related patterns.//
--
--Links to any related patterns should be mentioned here. For example, a parent pattern (similar interaction intention, higher in the abstraction hierarchy), sister pattern (similar interaction intention, same abstraction level) and/or other relating patterns (different interaction intention, but in another way related to context and/or product characteristics of the design solution).
--)))