Interaction Design Patterns

RANKING/ validation
 

Notion of the validity (e.g., empirically tested)

TBD

DESIGN PROBLEM (what)

Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).

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. 

CONTEXT (use when…)

References to a list of the 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 
• Entertainment for PwD
• Useful for associating certain activities to certain musical sounds

DESIGN SOLUTION (how)

Description of the essential characteristics of the 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. 

DESIGN RATIONALE (why)

Argumentation that resulted in the chosen design solution.

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.

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?)

RANKING/ validation

Notion of the validity (e.g., empirically tested)

TBD

DESIGN PROBLEM (what)

Concise description of the intended interaction (effect on the user and/or user interaction with the system and/or other parties).

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.

CONTEXT (use when…)

Contextual characteristics that are significant for the applicability of the pattern.

This IDP can be used in the following contexts:

• Understanding whether the PwD has taken medication before reminding them 
• Understanding whether the PwD has eaten a meal before reminding them
  The list can be further expanded as more crucial task usecases are added.

DESIGN SOLUTION (how)

Description of the essential characteristics of the 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.
 

DESIGN RATIONALE (why)

Trade-offs and the 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. 

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?)

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.

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).

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.

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).

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.

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).

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.

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).

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.

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).