PeerPEP Management App

1 Login Screen
If a user is not yet authenticated or if their login session has expired, they will be
navigated to the login screen. Here they can provider their username (email) and
password to authenticate with our API. Initially both all fields will be empty.

1.1 Validation

Both the username and password field must adhere to some validations. The
username for example must be an email address and must thus be formatted as
such. Both validation for the username and password field will be provided by the
multiplatform library. Documentation on how to use the multiplatform library can be
found elsewhere.

Like previously mentioned, initially both fields are empty. This means they aren’t
considered as valid, but no errors are shown (Figure 1). Once a user starts inputs a
key in one of the fields, the field validation error should be shown (Figure 2). The
multiplatform library has methods to achieve this behavior.

Figure 1 Initially fields are invalid Figure 2 Email and password Figure 3 Both email and password
but no errors are shown have validation error(s) fields pass validations

1
1.2 Screen states

The login screen can be in a couple of states throughout its lifecycle. Initially it will be
in an invalid state. As mentioned in the previous subchapter the email and
password field should conform to certain validations, if they do not meet these
validation requirements the screen will be in the invalid state. While the screen is in
this state the user should not be able to use the login button. This can be done either
by completely disabling the login button while in this state, or by showing the
validation error messages below the email and password field (if they are not shown
yet).

Once the user enters a valid username and password, they will enter the valid state.
During this state the user should be able to press the login button normally and it will
trigger the login request to the backend.

As soon as the user initiates the login procedure by pressing the login button the
screen will enter the loading state. The user should not be able to modify the
username and password fields, nor should he be able to press the login button again
while in the loading state. It must also be clearly indicated to the user that the screen
is in this state, for instance by using a circular progress indicator.

If the login request failed the screen will be in the error state. A login failure could be
because of several things. The most common cause for error is the user inputting an
invalid username and/or password. This should be communicated to the user either
by text on the screen or through some popup message. Any other error can for now
be grouped together as “unknown errors” and should also be communicated to the
user but only requires a simple “Unknown error” message.

Lastly, if the login request was successful the screen’s lifecycle is complete and the
app will navigate to the provider screen.

2 Provider Screen
Once the user is authenticated (or already was) the user will be navigated to the
provider screen. The purpose of this screen is for the user to select the outdoor
provider that they want to manage the devices of.

An outdoor provider is usually a company providing outdoor equipment at specific

places for people to use. A QR-code will be attached to the devices which people
can scan to view videos demonstrating exercises that they can do on the device.

Before people can scan these QR-codes, however, the device first needs to be set
up in our system, this is the purpose of the management app. The first step therefore
is to select the provider you will be managing the devices of.

2
In case there are many outdoor providers it might be hard quickly find the provider
you’re searching for. Because of this reason a search field must be added. The user
can input (parts of) the provider’s name and only providers matching the input will be
shown in the user interface (Figure 5). The actual filtering of the efforts using the
search query is done by the shared library and thus doesn’t need to be implemented
separately on iOS and Android.

2.1 Screen states

Initially the state of the screen will be empty/uninitialized. Once the screen becomes
active the library attempts to retrieve a list of all outdoor providers from our backend.
While the data is being retrieved, the screen will be in the loading state, and this
should be shown clearly to the user by showing some progress indicating (a circular
progress indicator, for instance)

If the data has been successfully retrieved from the backend the screen is in the
success state. The providers will be shown in the list, and you can filter through
them using the search field. By pressing one of the providers in the list you will be
navigated to the scan screen.

In the case that there were any errors retrieving the data, the screen will be in an
error state. It should be clearly indicated to the user that an error occurred, either by
some permanent error message on the screen, or through a more temporary means
of communication like a popup.

Figure 4 Full list of outdoor providers Figure 5 Filtered list of outdoor providers

3
3 Scan Screen
The scan screen provides the user with a way to easily setup new outdoor devices or
update existing ones. The goal is for the user to scan the QR code attached to a
device with their camera using a QR-code scanner that is inside the management
app. The data inside the QR-codes is formatted in such a way that we can easily find
the id of the device.

The format of the data inside the QR codes attached to the devices is:
- https://home.peerpep.com/outdoor/device/<device-id>

3.1 Screen states

If the data inside the QR-code scanned is not formatted like an outdoor device the
screen will be in the invalid code state. The user should be shown a quick popup
indicating that the QR code they scanned is not a valid outdoor device QR-code.
Scanning can resume normally during this state, but to prevent confusion it is
important to let the user know they scanned an invalid QR-code.

4 Device screen
After successfully scanning a QR-Code of an outdoor you will be navigated to the
outdoor device screen. The purpose of this screen is for a user of the management
app to be able to set up and/or configure an outdoor device. If a QR-Code of an
existing device was scanned, the screen will automatically be filled with the current
information of the device, and the user can then modify this information.

4.1 Device type screen

Pressing the select device type button should navigate you to the device type
selection screen. Each outdoor provider can create multiple device types that should
correspond to the physical device in the outdoor gym. These device types include all
the exercise videos and other information about the physical device. For the person
using the device to get the correct exercise videos, the outdoor device must be
linked to the correct device type.

Initially the device type (sub)screen will be in the loading state and the outdoor
provider’s device types will be retrieved from the backend. It should be clear to the
user that the data is being loaded, for instance using some loading indicator.

If the data was successfully retrieved from the backend the screen will be in the
success state. The list of the device types should be shown on the screen. The user
can use the search field to filter out unwanted/irrelevant device types.

4
Alternatively, if there was an error while retrieving the data from the backend, the
screen will be in an error state. It should be clearly indicated to the user that an
error occurred through, for instance, an error message or some popup.

Figure 6 Device screen with select device type button Figure 7 Device type selection screen
highlighted

4.2 Validations

The longitude and latitude field are required to be (decimal) numbers. For this
reason, validation has been added to these fields ensuring that the user enters a
valid (decimal) number in these fields.

If there is an error while validating one of these two fields, the validation error
message should be shown below the field, and a red border should around the field
should be visible, just like in Figure 2.

4.3 Images

A user should be able to link images to the device. By pressing the plus button, the
user must be able to either select an existing image from their gallery or use their
camera to capture a new image.

Any image selected by the user should be shown on the screen as can be seen in
Figure 8. An image should also be able to be removed from the list of images for the
device. Pressing on one of the images should open an enlarged view of the images
so the user can see the picture better, as shown in Figure 10.

5
While the user is in the enlarged picture view, they should be able to navigate
through all the pictures of the device, by swiping horizontally (just like a normal
picture viewer, if you swipe left/right you go to the next/previous image)

Figure 8 Two images were Figure 9 One image was removed Figure 10 Enlarged image after
selected pressing on it

4.4 Screen states

Initially the screen will be in the empty state. This indicates that the screen was just
initialized, and nothing has happened yet. The user should be able to modify all the
fields in the screen and be able to add and remove images from the device.

Once the user is done creating or modifying the device, the user can press the save
button to attempt to save the device to the backend. The screen will be in the
loading state after the save button was pressed and will remain in this state while
the request is being made to the backend.

If the save request succeeded, the screen will be in the success state. The screen
should automatically navigate back to the previous screen (the QR-Code scanner in
this case) once this state is reached. This is done automatically in the common
library if the provided router is used.

If the save request failed for any reason, the screen will be in the error state. The
user should be notified that an error occurred through a notification or some text to
the screen. The user should be able to press the save button during this state, which
will retry the request to the backend.