Skip to Content

Wiki source code of Team Design Patterns

Last modified by Mathieu Jung-Muller on 2022/04/04 13:54
Show last authors
1 = Graphical Language Definition =
2 In order to define our design pattern we needed to work from a graphical language baseline. Our graphical language definition is coming from J van Diggelen and M Johnson work [1].
3
4 == Nature of the agent: ==
5 In our case, the agent interacting in our environment can be of two different nature:
6 * Human
7 * Robot
8
9 (% style="text-align:center" %)
10 [[image:agentdp.png||width="400" height="350"]]
11 Figure 1: Depiction of human and robot in our design patterns
12 == Type of work: ==
13 The language model of van Diggelen et al. emphasises two important aspect of work, wether it is tangible or intangible work and how much it is related to the team goal. Below are the definition of both these concepts as they are explained in their paper [1].
14
15 **Physical and Cognitive work:**
16 * //Physical work// is any type of work that relates to manipulating tangible objects in the world. It is represented by the agent holding an object being filled.
17 * //Cognitive work// is any type work that consists of mental or information processing activities. It is represented by the head of the agent being filled.
18
19 **Direct, Indirect and Off-task work:**
20 * //Direct work// is any type of work that aims at reducing the distance to the team goal. It is represented by the colour of either the object or the agent's head is dark red.
21 * //Indirect work// is any type of work that aims at making the team more effective or efficient at achieving the team goal, but does not move the team closer to its goal. It is represented by the colour of either the object or the agent's head is pale red.
22 * //Off-task work// is any type of work that is unrelated to achieving the team goal and does not have the intention of improving team effectiveness. It is represented by the colour of either the object or the agent's head is dark grey.
23
24 (% style="text-align:center" %)
25 [[image:directdp.png||width="400" height="350"]]
26 Figure 2: Types of work and their depictions in design patterns
27 == Scalability: ==
28 The image below shows that both cognitive and physical work can be quantified.
29 Moreover, even though it is not shown on the image, a quantified amount of cognitive or physical work can still be contributing directly, indirectly to the team goal or even being off-task.
30
31 (% style="text-align:center" %)
32 [[image:scalabledp.png||width="400" height="350"]]
33 Figure 3: Tasks and their scalability in as seen in design patterns
34 == Type of communication: ==
35 van Diggelen et al. propose three different level of communication:
36 * Supervision, it is represented by a dotted line between both agents and an arrow indicating who is supervising who. In the image below, the agent on the left supervises the agent on the right.
37 * Open communication channel, it it is represented by a dotted line between both agents.
38 * No communication, it is represented by the lack of dotted line between both agents.
39
40 (% style="text-align:center" %)
41 [[image:comm2dp.png||width="400" height="350"]]
42 Figure 4: Depiction of communication channels in design patterns
43 = General Reminder Design Pattern =
44 **Overview**
45 The general reminder design pattern depicts the flow of interactions between Pepper and the PwD in reminder related usecases. This TDP contains the overarching generalizations of the medication, nutrition and calendar event reminders as mentioned in the use cases (UC01, UC02, UC03). Below we describe this TDP in further detail.
46 |
47 **Purpose**
48 The purpose of this TDP is to demonstrate the flow of how a reminder interaction would take place. Reminders are an essential purpose of Pepper in our design, due to their necessity in PwD's daily life. Taking the correct medicine at precise times is crucial for the PwD's well-being, and once this information is available to Pepper, daily (or multiple times a day) reminders can be configured to ensure this is not forgotten. The same applies to meal reminder, although this in some cases is less crucial than taking medicine. Finally, another instance of this can also be calendar event reminders, which aids the PwD by reminding them of special events upcoming in their calendars i.e. grandchild's birthday party.
49 |
50 **Steps Breakdown**
51 Although each of the IDPs contained in this TDP is described in great detail in Interactive Design Patterns section, below is a short overview:
52 * Pepper initially plays some music to gain the attention of the PwD. This is mainly done in order to not suddenly startle the PwD by the robots presence.
53 * Now having gained the attention of the PwD, Pepper asks whether the PwD has already performed the task that the reminder is set for. If the answer is yes, then this is where the DP ends, because the reminder would serve no purpose.
54 * If the answer to the previous step was no, then Pepper proceeds by reminding the user to do the task in question.
55 * Now Pepper will wait for a confirmation of the user having done the task in question. The waiting times are different for different use cases, as taking medicine for example takes less time that eating a meal.
56 * Finally after receiving the confirmation, Pepper congratulates the the PwD and the DP comes to an end.
57 |
58 {{html}}
59 <img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/TDP_generalreminder.jpg?rev=1.1" alt="Design Pattern Calendar" width="1000"/>
60 {{/html}}
61
62 = Activity Breakdown Design Pattern =
63 **Overview**
64 The general activity breakdown design pattern depicts the flow of interactions between Pepper and the PwD with respect to the breakdown of any activity that has been entered in Pepper's system. With respect to the usecases present, this TDP applies to the wake-up routine. Below we describe the TDP in further detail.
65 |
66 **Purpose**
67 The purpose of this TDP is to demonstrate the flow of how a activity interaction would take place. Often times it becomes challenging for patients to perform basic and complex activities. These might be essential life activities such as having a pleasurable wake-up routine, or more complex activities such as gardening or cooking. We see assisting the PwD with such activities as a meaningful addition to their daily life. The aim is to have Pepper guide the PwD through the steps of an activity and stop at each step to analyze whether everything went smoothly.
68 |
69 **Steps Breakdown**
70 Although each of the IDPs contained in this TDP is described in great detail in Interactive Design Patterns section, below is a short overview:
71 * As a prerequisite, the health care professional (HCP) needs to initially enter the activity breakdown into Pepper's system.
72 * Pepper initially plays some music to gain the attention of the PwD. This is mainly done in order to not suddenly startle the PwD by the robots presence.
73 * Pepper then asks the PwD whether they would like to do an activity and if the PwD responds positively, the Pepper starts the activity breakdown.
74 * For each step, the robot presents the step to the PwD, and waits for the PwD to complete the step in question and tell so to the robot.
75 * Once all the steps have been successfully completed, Pepper congratulates the PwD.
76 |
77
78 {{html}}
79 <img src="https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/download/Main/WebHome/TDP_generalactivity.jpg?rev=1.1" alt="Design Pattern Calendar" width="1000"/>
80 {{/html}}
81
82
83 = References =
84 [1]: van Diggelen, J., & Johnson, M. (2019, September). Team design patterns. In Proceedings of the 7th International Conference on Human-Agent Interaction (pp. 118-126).
85