Responsive Design - Options
- Jonas Bergmeier
This topic was discussed in several rounds lately. There was no final conclusion from the team yet on how to handle different devices in the Sandbox but there were proposals and thoughts that found encouragement.
Generally, it can be said after reviewing first drafts of the more complex application parts, that it would be extremely difficult to provide good user experiences on small devices due to the high amount of information we need to show at a time. Without this contextual information the main purpose of explaining Govstack in a practical manner can not be fulfilled. Additionally, there is a necessity to demonstrate the UIs of our main use cases on desktop devices which also counterarguments a Sandbox fully optimised for mobile devices.
Ruling out building the scenarios/use cases full responsive leaves us with the questions:
What to do with users accessing the sandbox on mobile devices that don’t have access to desktop (ad-hoc or at all)?
How to handle responsiveness in other application parts of the Sandbox?
Data
We can’t tell for sure how high the percentage of mobile users would be on initial contact with Govstack and its Sandbox. We can’t also tell for sure how many of those users would consider revisiting it on another device if they would be told to do so because of a possibly better experience. We can only assume that at least half of new users would access Govstack on their Mobile device.
Options
| Responsive Option | Description | Effort | High level UX implications | Comments |
|---|---|---|---|---|---|
A | Restrict access |
| Low | Bad | @Jonas Bergmeier this is generally bad, we as we would exclude approx. 50%+ of first time visitors from the start, therefore I would like to avoid this option |
B | Core app not responsive |
| Medium | ok | @Jonas Bergmeier would be my preferred option of a fallback if doubts arise regarding responsibility when working out dashboard etc. |
C | Full responsive except for use case scenarios |
| High | Good | @Jonas Bergmeier Of course this is still not defined in detail but I would argue this make sense. Most of the application will be fully responsive and we can “whitelist” a good experience on mobile devices for the scenarios. Even if it’s just one of three options I guess that would be okay for the scope of the MVP. Desktop versions should be usable on mobile too, but at least it should be prominently stated that it should be used on desktop if possible. |
D | Sandbox Mobile Teaser | The issue is bigger. There are three obstacles for the scenario “someone quickly checks GovStack while visiting a presentation”: 1. Login 2. Deployment Time (possibly) 3. Mobile friendliness. Before accessing the sandbox, the user gets to choose between:
The Sandbox Mobile Teaser is a fully responsive but light click through which does not require login or deployment. It shows just a few screens of the USCT use case (later on a second use case to be added) from citizen and civil servant and the BB involvment/Interaction. And help. At the end, it prompts to enter e-mail for desktop access. If a persons access the Desktop version, through e.g. a direct link, the user gets a notification that it can only be viewed in desktop. Link to mobile teaser. | Medium/High | ok | @Jonas Bergmeier Could be feasible, on the other hand it might be a better option to follow option C and have a mobile scenario in place, nevertheless this is also touching marketing pages before the actual sandbox @Jonas Bergmeier Currently it looks like there would be no deployment needed for new users accessing the web version generally. Of course this is still depending on the way the BBs are fledging out in the coming weeks. This takes a bit of reasoning for a special mobile journey away IMO @Jonas Bergmeier I would like to take this proposal up to share the thought on having a short demo video on the landing page, quickly demonstrating what’s going on in the sandbox. |
Recommendation Jan 10, 2023 @Jonas Bergmeier
onboarding, signup/login and dashboard are very common SaaS application parts and patterns, that’s nothing extraordinary, therefore I wouldn’t even think about NOT making them fully responsive according to latest standards → this excludes options A and B
our current technical understanding is that there’s no need to have a proper deployment or any other waiting time in place when signing up and entering the open sandbox (web) initially
assuming we are serving the application responsive (except for some scenarios) the proposed “mobile teaser” of option D should be one explicitly shown mobile-optimized scenario, more can be added on in the future
this leaves option c - a fully responsive sandbox except for scenarios/use cases
mobile optimized scenarios should be explicitly marked/whitelisted
the journey on mobile devices must be an easy and approachable walkthrough until reaching the dashboard, with a lacking UX on mobile comparing to desktop I would doubt if this is the way to go, therefore I would recommend to review and possibly test this as a prototype soon