Changes for page Graphical User Interface

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.PierreBongrand
	1	+XWiki.Mathieu

Content

...	...	@@ -1,56 +1,45 @@
1	1	= Motivation =
2		-
3	3	As explained in the section [[Humanoid Robot>>https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/view/Foundation/Technology/Humanoid%20Robot/]], Pepper can interact with the PwD, its relatives and the healthcare professional using 3 communication channels:
4	4	1. Voice
5	5	1. Tablet
6	6	1. Gestures.
7	7
8		-The tablet is used for redundancy of information (i.e., audio impaired patient) and for ease of interaction between Pepper and any human. Pepper's tablet however is only used for display.
	7	+For both redundancy of information (i.e. audio impaired patient) and for ease of interaction between Pepper and any human we believe that making use of the tablet could be useful.
9	9
10		-However, it would be nice to have an interface where a HCP or a relative can enter data. For this purpose, creating a mobile app (or another similar solution) would be very useful. As it is often done nowadays, the HCP and relatives could use this app from a mobile phone or a tablet. In this section, we will detail visuals for a tablet display.
	9	+This section describes a first iteration of a graphical user interface that could be used on the tablet of Pepper.
11	11
12		-NB1: This GUI has not been implemented, as it would require using external resources (Android app for instance) and would be way beyond the scope of this course. It is simply here to reflect the amount of thinking that went into the graphical user interface. For a prototype to effectively work without hard-coding the information as we did, the interface would need to be implemented. Moreover, we believe that it would be great future work to both think of new designs and implement them on Pepper. This section describes a first iteration of a graphical user interface that could be implemented.
	11	+Please note that this section has not been implemented in the prototype and is simply here to reflect the amount of thinking that went into the graphical user interface. For a prototype to effectively work without hard-coding the information as we did, the interface would need to be implemented. Moreover, we believe that it would be great future work to both think of new designs and implement them on Pepper.
13	13
14		-NB2: In this section, tablet will refer to the usual device, and not Pepper's tablet.
15		-
16		-
17	17	= High level description =
	14	+In an ideal setup Pepper's tablet would be tactile and humans could either talk to Pepper or use the tablet to interactive with it. However, as the tablet of Pepper is not tactile in its current version, we made some design choices thinking that the tablet is mainly a visual support for the person interacting with Pepper to be aware of the possible actions to do.
18	18
19	19	Our design choices are based on Nielsen's heuristics [1]. Below is the list of design choices we performed:
20	20	* The design of the visual is extremely simplistic as it needs to be used by users that are unfamiliar with technology. This is based on the 8th principle: Aesthetic and minimalist design.
21		-* Moreover, we tried to use rather large font so that again it would be easier to read for any type of user that might have a need for glasses (for instance, the spouse of the PwD). This is based on the 2nd principle: Match between system and the real world.
22		-* Every page is consistent with the others and has some specific standards. This is based on the 4th principle: Consistency and standards.
	18	+* Moreover, we tried to use rather large font so that again it would be easier to read for any type of patient that might have a need for glasses. This is based on the 2nd principle: Match between system and the real world.
	19	+* Every page is consistent with the others and have some specific standards. This is based on the 4th principle: Consistency and standards.
23	23
24		-This is the list of features for each page:
	21	+This is the list of feature that has a page:
25	25	1. Neutral colour background
26	26	1. A title page, that provides confirmation to the user that they are on the correct page. This is based on the 1st principle: Visibility of system status.
27	27	1. Multiple coloured boxes that refers to either activities or setting up.
28	28	1. An emergency button, in case an external help is needed.
29	29
30		-The pages below can be seen as an example, and they could be adapted to each patient's needs. The activities can be tuned for the patient's needs as well.
31		-
32		-
33		-
34		-
35		-
36		-
37		-
38		-== Landing Page ==
39		-There is first a connection page. When opening the app, the user is required to pick their role, as shown in the picture below. Then, they log in with their credentials (log in page not shown).
40		-
	27	+Of course, the pages below can be seen as example, but they could be adapted to each patient's need. The activities can be tuned for the patient's need.
	28	+= Landing Page =
	29	+This landing page has for objective to be shown when Pepper is waking up. Once the user see that page, Pepper should ask the identity of the person interacting with her and the visuals should propose different answer proposition. The visual below are generic role, however, they could be tuned to first names so that Pepper seem more friendly and human.
41	41	[[image:homepage.png||width="1000" height="560"]]
42	42
43		-== Patient Page ==
44		-This page has for objective to display every potential interaction that the PwD could make use of when communicating with Pepper. In case the PwD wants to directly start an activity with Pepper, they can also see them from the app. This also allows for checking which activities are currently implemented on Pepper for the specific PwD.
45		-We defined the first row as potential activities for the PwD to do, and the second row as potential use cases where the PwD may need Pepper's help.
	32	+= Patient Page =
	33	+This page has for objective to display every potential interaction that the PwD could make use of when communicating with Pepper. As discussed in the [[Humanoid Robot>>https://xwiki.ewi.tudelft.nl/xwiki/wiki/sce2022group04/view/Foundation/Technology/Humanoid%20Robot/]] section, Pepper vocal system works using keywords. Therefore, we believe that by displaying the keyword for which Pepper has been precoded to respond to, it will encourage the user to employ the appropriate keyword that has been predefined.
	34	+We defined the first row as potential activities for the PwD to do, and the second row as potential use cases where the PwD needs Pepper help.
46	46	[[image:patientux.png||width="1000" height="560"]]
47	47
48		-== Patient's relative Page ==
49		-This page has for objective to display every potential interaction that the patient's relative could make use of regarding Pepper.
	37	+= Patient's relative Page =
	38	+This page has for objective to display every potential interaction that the patient's relative could make use of when communicating with Pepper.
50	50	[[image:patientrelativeux.png||width="1000" height="560"]]
51	51
52		-== Healthcare professional Page ==
53		-This page has for objective to display every potential interaction that the patient's relatives could make use of regarding Pepper. Most interactions of the HCP are about editing the patient's information or preferences.
	41	+= Health care professional Page =
	42	+This page has for objective to display every potential interaction that the patient's relative could make use of when communicating with Pepper. Most interactions of the HCP are about editing the patient's information or preferences. As the health care professional might not be trained to make some changes in the code of Pepper, if a separate website/online platform is not provided to the HCP, we believe that making use of Pepper for helping the HCP to modify some information could be useful.
54	54	[[image:hcpux.png||width="1000" height="560"]]
55	55
56	56	[1]: Molich, R., & Nielsen, J. (1990). Improving a human-computer dialogue. Communications of the ACM, 33(3), 338-348.