Pepper Applications vs. Android Applications

Important differences you should know between regular applications with Android and those made for Pepper
Pepper Applications vs. Android Applications

Technically, applications for Pepper QiSDK are Android applications, but if you make an application for Pepper the way you would make one for a smartphone or a tablet, the user experience will not be very good.

Let’s go over the important differences, and how they translate to design and implementation.

1. Differences in the interaction flow

An interaction is “one user uses the application”; how that plays out depends on the situation.

1.1 On a smartphone: one user, many applications

The typical flow for a smartphone application is:

  • The user launches the application by clicking on its icon on the launcher
  • The user then interacts with the application, mainly through the touchscreen
  • The user stops using the application either by returning to the home screen, putting his phone/tablet in rest, or switching to another application
  • Even once “outside” the application, the user may receive notifications from it

Example: a smartphone "Android Bus Schedule" app, that you can use it to check when a bus is coming soon, at what time the last bus is, etc.

It is possible to use Pepper with a “Launcher-and-applications” model, for example, a Pepper used by developers will typically only have the default Android launcher, on which various applications can be installed; that is convenient for doing a lot of quick tests.

But most of the time, a different model will be used:

1.2 On Pepper: one application, many users

Here, typically, a single application is running on Pepper all the time, and:

  • The user comes near Pepper
  • Either the user or Pepper “starts the interaction” (Pepper starts talking to the user, or the user says something or touches the tablet)
  • The user may talk to Pepper
  • The user walks away

Example: Pepper Timetable is standing in the waiting room for a bus terminal, and anybody there can ask Pepper when the next Bus is coming, what the next Bus to a specific city is, etc. Note how from the users' point of view, they're just talking to Pepper.

This model is not exclusive to Pepper, it is also what you will find on Kiosks or large touchscreens, that may be running Android underneath.

To prevent developers from having the “Launcher-and-applications” model in mind, we sometimes talk of “solutions” instead of “applications” (more broadly, a “solution” can also encompass a server-side part etc. but that’s a different topic).

1.3 Consequences for design and implementation

In Android, the application lifecycle (onCreate, onStart etc.) maps closely to the user interaction flow. Not so on Pepper, where a single application will keep the focus for a long time; and often Pepper is setup so that random users can’t quit the current application.

The immediate consequences:

  • There should often be an “idle state” when Pepper is alone
  • The start of the interaction needs to be planned as part of the application: for example, Pepper could say something when a user approaches, or could show a call to action on the tablet
  • Similarly, the end of the interaction needs to be anticipated: Pepper could detect that the user left, and add a timeout to that, before returning to the idle state

Example: Pepper Timetable will have to be aware of people standing nearby, and react if they come here and leave. In addition, when Pepper is idle and a bus is arriving soon, Pepper could announce that bus.

There are also some more indirect consequences when it comes to what the user knows and expects:

  • You can’t assume the user wants to interact with Pepper, he might just happen to be standing there
  • You can’t assume that the user knows what Pepper is supposed to do (unlike with a player who just clicked on the “play music” app icon)
  • A typical user does not spend a lot of time interacting with the application, and can’t be expected to learn how it works.

Example: Someone clicking on an app called "Android Bus Schedule" knows what he's getting into. But someone seeing a robot standing around in a bus terminal can't be assumed to know what that robot is there for, so it needs to be made more explicit (typically: on the Idle screen). An additional difference is that an Android app can be expected to have some customisation (favorite bus lines, common destinations); whereas Pepper Timetable shouldn't involve any customisation by end-users (there should probably be, however, some way to configure Pepper for a specific Bus terminal!).

2. Differences in interaction modalities

Another way Pepper differs from a typical phone or tablet, is that the interaction is about talking to a robot, not touching buttons on a screen.

More specifically:

  • The user is further away from the screen than he is on a tablet
  • The user will be paying more attention to the robot as a whole rather than just the screen
  • It is more difficult for the user to touch the screen accurately (on a normal phone or tablet, the user is holding it with his other hand) - typing is especially awkward.
  • Sound, and especially speech, is a reliable way of presenting information (whereas usually Android applications aim to be usable with the sound off)
  • The user may speak to the robot (especially if Pepper spoke first)

Therefore, when making apps:

  • Speech, and not buttons, should be the “primary” way of interacting with the robot
  • The content shown should be easy to understand from one meter away - with few content, and large text
  • When there are buttons, they should also be large and easy to click
  • Do not rely on the notification bar - it is too small to be seen well, and is usually hidden

Example: Pepper Timetable should have a few simple buttons or suggested voice commands. Android Bus Schedule may have a scrollable list of destinations, whereas Pepper Timetable would rely on dialogue, and only allow manually typing in the destination as a last-resort.

Here is a template we something use for designing GUIs on Pepper, for recommended minimal sizes:

screen guidelines
screen guidelines

A more subtle point is that as the robot does not look like an Android device, and as such, some interaction patterns (small burger menus, swiping from the sides) will not come as naturally to users.

Overall, your GUI for Pepper should be considerably simpler than one for an Android device; not only should there be less buttons, but you also don’t have to worry about supporting different screen sizes and orientations.

Wrapping up

In conclusion, so while yes, applications for Pepper QiSDK are technically Android applications, there are many things you have to learn or unlearn before making them. Fortunately, a lot of those differences point towards making your application simpler: complex menus are hard to see and use at a distance, especially for users who only interact with Pepper once or twice.