dasanra
commented
2 years ago Just to mention, some of the devices that use the web interface seen as "mobile" they could be tablets/iPads, as I've teste the application on those and it's working really nice.
It should be considered when working on this problem statement not to break the interface on this devices
Part 1: Define the problem
What problem are you trying to solve?
The current version of the web interface is unusable with a mobile phone as it lacks basic responsiveness. Especially for users with an Android phone, offering a responsive mobile version as an alternative for not updating the Android App is relevant.
What is your hypothesis?
If we achieve basic responsiveness, mostly Android but also other users without the mobile app have a mobile alternative to interact with their Safe.
What value does this bring to our customer and/or our mission? What is the goal?
Mobile responsiveness is one of our strategic goals for the web interface to offer the most decentralized access to our interfaces not controlled by central gatekeepers such as Apple. Furthermore, we want to provide a certain degree of accessibility to our web application on all devices.
How do we measure it?
4.28% of our users access gnosis-safe.io via iOS and from these users roughly 25% access the web application as the starting page (GA last 30 days user flow data) 3.03% of our users access gnosis-safe.io via Android and from these users roughly 50% access the web application as the starting page (GA last 30 days user flow data)
Links:
Part 2: Shaping the problem
Problem Owner
@johannesmoormann
Non Goal(s)
It is not a goal to provide mobile responsiveness for the whole web application but only for key components and functionalities.
Solution
Solution 1
This item was not included in the shaping phase but introduced later and therefore will require shaping once the development phase started. The primary goal is to first identify optimizations that are easily achievable in the short term and that represent key blockers in the usage of mobile devices. Second is the identification, prioritization and estimation of other key components and functionalities that require responsiveness.
Key blockers
Core components and functionality to be made responsive
Priority list TBD:
Risk(s), Key Trade Offs & Decisions
The no. of users who are using their mobile device to access the web application is below 10% of our user base. Enabling mobile responsiveness therefore initially only reaches a smaller amount of users. The low percentage however could be heavily affected by not being mobile responsive in the first place.
Alternative solutions & ideas
Open Questions