Graphical User Interface
Motivation
As explained in the section Humanoid Robot, Pepper can interact with the PwD, its relatives and the healthcare professional using 3 communication channels:
- Voice
- Tablet
- Gestures.
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.
This section describes a first iteration of a graphical user interface that could be used on the tablet of Pepper.
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.
High level description
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.
Our design choices are based on Nielsen's heuristics [1]. Below is the list of design choices we performed:
- 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.
- 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.
- Every page is consistent with the others and have some specific standards. This is based on the 4th principle: Consistency and standards.
This is the list of feature that has a page:
- Neutral colour background
- 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.
- Multiple coloured boxes that refers to either activities or setting up.
- An emergency button, in case an external help is needed.
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.
Landing Page
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.
Patient Page
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 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.
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.
Patient's relative Page
This page has for objective to display every potential interaction that the patient's relative could make use of when communicating with Pepper.
Health care professional Page
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.
[1]: Molich, R., & Nielsen, J. (1990). Improving a human-computer dialogue. Communications of the ACM, 33(3), 338-348.