Changes for page Graphical User Interface

Summary

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

Details

Page properties

Content

...	...	@@ -13,11 +13,11 @@
13	13	= High level description =
14	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.
15	15
16		-Our design choices are based on Nielsen's heuristics [1].
17		-Below is the list of design choices we performed:
	16	+Our design choices are based on Nielsen's heuristics [1]. Below is the list of design choices we performed:
18	18	* 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.
19	19	* 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.
20	20	* Every page is consistent with the others and have some specific standards. This is based on the 4th principle: Consistency and standards.
	20	+
21	21	This is the list of feature that has a page:
22	22	1. Neutral colour background
23	23	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.
...	...	@@ -26,17 +26,20 @@
26	26
27	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	28	= Landing Page =
29		-This landing page has for objective to be shown when Pepper is waking up. Once the user see that page, we believe that Pepper could that The current user would have
	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.
30	30	[[image:homepage.png||width="1000" height="560"]]
31	31
32	32	= Patient Page =
33	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.
34	34	[[image:patientux.png||width="1000" height="560"]]
35	35
36	36	= 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.
37	37	[[image:patientrelativeux.png||width="1000" height="560"]]
38	38
39	39	= 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.
40	40	[[image:hcpux.png||width="1000" height="560"]]
41	41
42	42	[1]: Molich, R., & Nielsen, J. (1990). Improving a human-computer dialogue. Communications of the ACM, 33(3), 338-348.