Toggle (Mobile View)

[DanGenuardi]

Problem statement

Enhance ToggleSwitch with upgraded functionality and design to make it more usable while accommodating business needs

Recommendation

Enhance existing ToggleSwitch component with more features like: loading state, adding optional tooltip, moving label to the left

Design intent

Toggle switches are digital on/off switches. They prompt users to choose between two mutually exclusive options and always have a default value. Toggles should provide immediate results. They are best used for changing the state of system functionalities and preferences.

Designs

Design reference: https://telus.invisionapp.com/share/T5SFO08PCWF#/screens
Source working file: https://invis.io/a/ZC5LFDEMB9Q6

Acceptance criteria

Given I am displaying the ToggleSwitch Component

  When browser renders ToggleSwitch
  Then it should present label on the left side from toggle switch
  And toggle switch is displayed at the far right of the container with a left margin of 16px
  And toggle switch white circle button must have a shadow (`0px 0px 2px 0 #000`) around it according to new design

  When I supply optional tooltip
  Then the tooltip should render to the right of the label with left margin of 8px

  When I supply `isLoading` prop to ToggleSwitch component
  Then the small green spinner should be displayed on top of the toggle switch only

Given a user is interacting with the ToggleSwitch

  When a user clicks the toggle
  Then toggle animates (but stays grey)
  And spinner appears
  And async action completes
  And spinner disappears
  And toggle turns green

Accessibility

  When browser renders ToggleSwitch
  Then semantically it should be presented as a `<button role="switch" aria-checked="false" aria-labelledby="xxx">`
  And the styles for `on` and `off` states should be dictated by `aria-checked` state

Example for styling:

[role="switch"][aria-checked="true"] {
  ...styles for "on" state...
}
[role="switch"][aria-checked="false"] {
  ...styles for "off" state...
}

More details about this accessibility decision can be found through this article: Building Inclusive Toggle Buttons

Meta

• Include component name and version: vX.Y.Z
• Willing to design solution: Yes/No
• Willing to develop solution: Yes/No
• Has workaround: Yes/No
• Do any similar components already exist in TDS (core or community): Yes/No (link)
• Which teams/applications do you think would use this improvement?
• High impact: Yes/No

[varunj90]

@Berjesty to chat with @DanGenuardi regarding the design and bring back to dpa!

[Berjesty]

@DanGenuardi Moving the toggle to the right side for ease of usability perspective is great however to promote clarity of the status of the toggle, it should be in close proximity. My suggestion is to move the status closer to the toggle to prevent confusion.

[DanGenuardi]

I have spoken to @owestinTelus about the accessibility about this updated mobile toggle.

[owestinTelus]

The proposed solution does not have any negative accessibility concerns.

• moving the trigger to the near right on a mobile screen (as opposed to below) is still reasonably discoverable
• the toggle design is consistent with what we use elsewhere on the site and the visible state is understandable

The text state of the toggle may be more clear if it was closer to the toggle itself but I don't think that's required. The terms 'disabled' vs 'on' can be misleading if they are associated with an on/off toggle

If the text label is specific to the 'Data Access' and 'Overage protection' then it could be immediately to the right of the text or below it.

[theetrain]

This is related to #29 and #113

Once we have an approved design, we can enhance the yet-released community-toggle component.

[jesdavpet]

I have a couple of considerations that I want to introduce regarding this proposed layout, from a development perspective.

1. The toggle form control is not logically grouped adjacent to it's label:
   • the code for HTML forms has very specific semantics of grouping form controls with labels
   • this layout doesn't seem to be readily compatible with HTML form markup semantics
   • this layout may be difficult to accomplish with the layout tools available in TDS
2. The treatment differs significantly from existing TDS form components:
   • TDS checkboxes do not have this treatment for mobile views
   • how would this design fit into the existing design & component vocabulary we use for forms at TELUS?

[DanGenuardi]

We are already using toggles within the desktop and tablet layouts. We are not planning on switching to checkboxes for when a customer views this portion of the site on a mobile device. Is there a way we can set up a meeting to discuss this?

[DanGenuardi]

Does this explain it differently on how it's supposed to work?

[DanGenuardi]

or does this fix the problem?

[jesdavpet]

Hey @DanGenuardi I think it may be more clear to continue this conversation in person, and just follow up with the consensus here on GitHub afterwards. I'll reach out to schedule some time with you, and @Berjesty as well.

[DanGenuardi]

I had the discussion with @jesdavpet about a possible fix for this mobile toggle experience we came to the conclusion that this approach would work best.

[jesdavpet]

Thanks for following up @DanGenuardi !

This design iteration resolves the technical considerations I had raised above. Simplifying the scope in this way makes it a minor layout variant of the existing @tds/community-toggle-switch component, which has already been created.

@lucylist @Berjesty @DougTelus I think it's down to the design review process on this one now.

[DougTelus]

I like this iteration. It gives an extra bit of visual clarity.
👍 Dan, nicely done.

[Berjesty]

Thanks Dan! I'm all good with this version as well all. @lucylist thoughts?

[lucylist]

yes! lots of thoughts :)

sorry i didn't see this until enrico showed me. here are some of my thoughts…

I think we need to build the component so it allows for flexibility. we will have to build it so that the toggle has the option of adding a label and without a label (the last two screenshots @DanGenuardi attached)

Thinking we need to align on the naming of the pieces so i can explain my thoughts…

• Value should reflect its on/off state (i.e. Data enabled, Data disabled)
• the option of the Label and value being on the left or right of the switch should be an option as well as be responsive
• Label can be optional: i think we need to have the option of label still because i can foresee having a toggle groups.. (eg. preferences as the label and a series of toggles below)

here's some good guidelines
https://www.nngroup.com/articles/toggle-switch-guidelines/
http://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

we should incorporate these guidelines in our docs!

[DJDA]

Hi all,

Some thoughts for all on this - I implemented elements of this design on the new RA Usage page for Family Manager aka "Data Manager 2".

In the reference mentioned above (https://www.nngroup.com/articles/toggle-switch-guidelines/), what has been termed "value" by @lucylist is here defined as "state descriptor". I've ben describing it as "toggle context", or perhaps more formally, it can be thought of having the role of "aria-describedby"(in fact, that's how it's implemented for accessibility in RA Usage).

In essence, "describedby" text provides additional context to what "ON" and "OFF" mean for the toggle. It’s only required when on/off are not unambiguous based on the constant label text alone.

Take Nutella's usage project an example - for the toggle labelled "Data Access"; ON always has "describedby" of “ON”, but OFF can represent multiple block states (billcycle blocked, data manager blocked, WCC blocked, …). We need this additional "describedby" text to give context to what "OFF" means in this situation for the customer.

In my view, an ideal design does not require "describedby" text - ideally the label and the on/off boolean toggle state should give enough context. Furthermore, for accessibility and clarity, I would argue that the toggle label should be mandatory and not change when the toggle is flipped. This is supported by the Apple human interface design guidelines for Switches, which specify that for toggles, "Switches are either on or off. Providing labels that describe these states is redundant and clutters the interface". I'd advocate for this advice above being included in our design guidelines: consistency between mobile web and native helps reduce friction for our customers.

In summary:

I support the idea that we should have:

• toggles that are in a pure two column table layout in mobile, with text to the left and the switch to the right, and nothing more
• the left text be defined the "label", for consistency with HTML5 and accessibility, and also that it be constant (i.e. it not change when the toggle is flipped)
• in the less desirable case that we need to provide additional context to "ON" and "OFF", we could have secondary "describedby" text that changes when the toggle is flipped to provide additional context
• regardless of the optional inclusion of "describedby" text, the toggle is always in line with the label text. See image below (and apologies in advance for it's rudimentary look and feel - I can only get so far with "Preview" on Mac 😬 )

[lucylist]

The Digital Platform Ambassadors met today and have discussed the toggle switch enhancements. Rather than have this issue focus on the naming etc. the main focus of this ticket is to make sure that left/right label/context is available for the swtich. we need to build this enhancement into the community component.

the design leads have agreed that the switch needs to align with context/value text

[invalidred]

I believe this issue seems to be lost in process as there seems to be no action items against it, there is no clear next steps as I cannot find it the Project board.

To summaries all the concerns raised above we need:

1. contextLabel: which will be in sync with aria-describedBy, so if switch is on:state it will show some text and if it's off:state it will show some other text. Also this contextLabel can be shown/hidden
2. Label: shown right next to the toggle needs to be hard coded text that does not change.
3. The Label and toggle needs to be aligned with each other.
4. There is a needs for tooltip next to the Label giving describing the purpose of the toggle, or in other words giving more details.

@DJDA @lucylist do you agree with the ^^^ points raised?

[DJDA]

Hi @invalidred - I'm on-board with your summary ! Thanks.

[Berjesty]

This component is added to DSM library with definition, usage criteria and style examples.

[agorovyi]

@sketchidea and I updated the story and it needs to be reviewed by a designer and moved to Dev queue if approved.

cc: @donnavitan @apurvray @varunj90

[donnavitan]

@sketchidea @agorovyi @apurvray @varu @Christina-Lo

Made the following change:

• From "When I supply isLoading prop to ToggleSwitch component
  Then the toggle switch should be blurred and the spinner should be displayed on top of it"
• To "When I supply isLoading prop to ToggleSwitch component
  Then the small green spinner should be displayed on top of the toggle switch only"

No blurring please. Thanks!

[agorovyi]

@nicmak I've added an Accessibility section to the Acceptance Criteria that will require some refactoring. Moved this back to dev.

[donnavitan]

• Updated description to include content for documentation to add/update in the TDS Community code component section.
• Also added the implementation content for reference

[varunj90]

This has been released in code and DSM.
Release notes: https://github.com/telus/tds-community/releases/tag/%40tds%2Fcommunity-toggle-switch%402.0.0
DSM: v1.0.5: https://telus.invisionapp.com/dsm/telus/tds-community/releases
Docs: https://tds.telus.com/community/index.html#toggleswitch

[donnavitan]

v1.0.5 TDS Community DSM is released: https://telus.invisionapp.com/dsm/telus/tds-community/releases

ToggleSwitch is now officially available in design and code
Toggle switches are digital on/off switches. They prompt users to choose between two mutually exclusive options and always have adefault value. Toggles should provide immediate results. They are best used for changing the state of system functionalities and preferences.

• Updated design name in alignment with code
• Available as a single ToggleSwitch or a group ToggleSwitches
• Also available with inline Tooltip (must manually align)
• Thank you Apurv for providing designs
• https://tds.telus.com/community/index.html#toggleswitch