Skip to end of metadata
Go to start of metadata

Overview

  • Implement responsive/mobile design

  • Unify desktop and mobile

    • Overall layout / findability

    • Vertical vs. horizontal panel scroll/swipe

    • Left side / right side (desktop)

    • Flexibilty? (integrators may choose a layout?)

  • Previously discussed adjuster redesign based on user feedback

    • Consistency of adjusters (check boxes vs on/off)

    • Accessibility of sliders

    • Naming/language

  • Note: no GPII integration at this time

  • Style - total redesign?

Meeting Notes

Mockups

Tab order expectation

  • Would be better to keep the “show preferences” tab on top of the panel area

    • Then focus moves from tab to first panel as expected (this is clearer in the vertical panel, where the tab stays on top)

    • In current design, focus moves from “show display prefs” tab to page content

    • Not good practice to push focus into panel / doesn’t follow panel structure/order

    • How to best design for horizontal layout in desktop in this way?

      • Open from the left?

Mobile

Vertical vs horizontal

    • Prefer horizontal layout

    • Vertical breadcrumb throws balance off

    • Might expect down arrow to  open more of the panel (i.e. to increase panel size)

    • Up arrow looks like it could collapse the panel

    • Previously had vertical panel scrolling in mobile in order to avoid interefering with contrast scrolling


  • How to take up less screen real estate in mobile?

    • Currently the header bar at the top takes up too much space

    • Also when user is in reader mode - will remove everything outside the content including UIO

      • Preferences may not apply to reader mode

    • Touch the screen anywhere - opens menu - accessibility?

    • Have it at top of page only?

    • Blend into page menu?


  • For ease of implementation - consistency between mobile and desktop - i.e.  vertical vs horizontal

ON/OFF toggle

  • Keyboard interaction? enter/space toggles state

    • Arrow keys? Would need to focus on each state separately - Probably not best

  • Touch/mouse interaction?

    • Touch/click specific state to change state, i.e. must touch or click ON to turn on (not just anywhere on the toggle itself, like in iOS)

  • Toggles are built as check boxes (so screen-reader experience is that of a check box)

    • New ARIA spec may include a switch label - Lisa will look into it

  • Consider the appearance of the focus state and how this might look too similar to current state button/box/border - don’t want to confuse the two

Emphasis preference

  • Replaced 2 check boxes (1. Links 2. Other inputs (buttons etc)) with one ON/OFF toggle

  • ON/OFF toggle used for consistency

  • If we want to keep links and other inputs separate, we could have 2 panels

  • Note that when we integrate with GPII, we will likely need more granularity - this will apply to multiple preferences

  • What do we want this preference to affect? Consider wording of “other inputs” - are there other inputs that it affects?

  • No labels