Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Responsive Option

Description

Effort

Mobile High level UX implications

Comments

A

Restrict access

  • restrict access to sandbox to desktop, show info on mobile devices and option to send invitation to it via mail or similar (to bridge the gap to desktop)

Status
colourGreen
titleLow

Status
colourRed
titleBad

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

  • state directly on login/signup that this is best to be experienced on desktop

  • build at least landing pages (like pre-product) and login flow full responsive

  • info on login page for mobile users that this is optimized for desktop

  • from dashboard onwards desktop only

Status
colourYellow
titleMedium

Status
colourYellow
titleok

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

  • everything “until” and incl. dashboard accessible full responsive

  • mark specific and feasible scenarios as mobile-friendly, such as AUTH+CONSENT and try to squeeze everything there as shown below

Status
colourRed
titleHigh

Status
colourGreen
titleGood

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:

  • Sandbox Mobile Teaser

  • Sandbox Desktop Full version

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.
The full version shows citizen in mobile version. Civil servant in desktop.

Status
colourYellow
titleMedium
/
Status
colourRed
titleHigh

Status
colourYellow
titleok

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 (warning)(question)

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.