Motivation

As explained in the section Humanoid Robot, Pepper can interact with the PwD, its relatives and the healthcare professional using 3 communication channels:

1. Voice
2. Tablet
3. Gestures.

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.

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.

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.

NB2: In this section, tablet will refer to the usual device, and not Pepper's tablet.

High level description

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 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.
• Every page is consistent with the others and has some specific standards. This is based on the 4th principle: Consistency and standards.

This is the list of features for each page:

1. Neutral colour background
2. 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.
3. Multiple coloured boxes that refers to either activities or setting up.
4. An emergency button, in case an external help is needed.

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.

Landing Page

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

Patient Page

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

Patient's relative Page

This page has for objective to display every potential interaction that the patient's relative could make use of regarding Pepper.

Healthcare professional Page

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.

[1]: Molich, R., & Nielsen, J. (1990). Improving a human-computer dialogue. Communications of the ACM, 33(3), 338-348.