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
Last updated
