Respect the device

Apps and services for mobile aren't reformatted desktop apps. They need to take into account a host of different issues, from battery life to signal.

What we learned in the research

  • Many developers believe battery life and signal to be vital to end-users

  • How vital battery is depends on the type of user and their context

  • Users viewed battery and signal strength as important but only when it could be a problem

  • Battery is less and less of an issue as they get better and external battery packs become more popular

  • Offline-first design is a growing trend that requires special sensitivity to the user knowing when they are on and off line

Patterns

Notify the user something might not finish because of the battery level

Battery life is an obvious and constant issue with all mobile users in any demographic. Battery life is less of an issue as smartphone batteries improve. But many user actions such as video and downloads can affect this.

Battery life is especially an issue with IPFS and P2P in general. The default of P2P is to connect to more and more peers. This, however, means there is a greater than average power drain.

Assume the user will at some point have issues with these.

✅ Do

🚫 Don't

Show a notification if the user is trying to transfer data and the battery is low

Indicate battery life issues with transfers and other actions to the user all the time

Show helpful, occasional and out of the way information to the user about their actions and affects on the battery

Show successive warnings

Check if the phone is on a power source already so connecting to a number of peers won't be an issue

Detect the battery level in the background all the time to notify the user

If possible, allow the user to choose how much battery drain is acceptable in exchange for peer connections

Set the app to automatically connect to as many peers as possible

Notify the user when things might not work

Show that actions like file sharing might take a long time or not work at all if there is not much signal

Signal is often thought of as not an issue until it's not there and apps built on IPFS can support this. It can provide and indicate offline capabilities as well as support data persistence. Apps that use IPFS should provide reassurance for the user for what is going on and what is possible. Thus, signal and mobile bandwidth should address for the specific context.

It should be noted that P2P technologies often try to create as many connections to peers as possible. This requires more bandwidth and more battery use. IPFS in mobile apps should be tuned to use fewer direct connections, and re-use high quality connections.

✅ Do

🚫 Don't

Indicate the user is offline

Notify the user that they need to go online for it to work

If on low bandwidth, show that a large file will take longer

Suggest offline capabilities so that the user needs to always be aware

If possible, allow the user to set bandwidth minimum amount and maximum peer count settings for transfers

Have default and unchangeable settings which favour maximum amounts of peers

It is good to tell users they are offline so they will be aware of how the app will continue to work in a different manner

If the user is on a data connection think about how to suggest time and cost involved

When a user wishes to transfer a large amount of files or data, they can't always rely on wifi. This is depsite being pervasive in many contexts.

Many advanced users have very high or no data limits on their monthly mobile data tariffs. But, many people still buy smaller and finite amounts of data at a time. With mobile apps using IPFS, the designer should be aware of technical and monetary restraints the user may have.

✅ Do

🚫 Don't

Detect the type of connection to provide support to the user

Show time to finish which may be inaccurate

Show a large amount of data might cost a lot to transfer

Force the user to switch modes of connection

Allow the user to pause and resume transfers

Hide the reason a transfer of data might have failed

Display estimated time to finish downloads when possible

Show progress bars without file size or time to finish information

When they don't have full capacity, help the user understand the implications