search

telus / tds-community

TELUS Design System Community Components
https://tds.telus.com/community/index.html
MIT License
26 stars 7 forks source link

Toggle (Mobile View) #112

Closed DanGenuardi closed 4 years ago

DanGenuardi commented 5 years ago

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

toggle-switch-design

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

varunj90 commented 5 years ago

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

Berjesty commented 5 years ago

@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 commented 5 years ago

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

owestinTelus commented 5 years ago

The proposed solution does not have any negative accessibility concerns.

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 commented 5 years ago

This is related to #29 and #113

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

jesdavpet commented 5 years ago

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:
DanGenuardi commented 5 years ago

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 commented 5 years ago

screen shot 2018-10-03 at 11 41 45 am Does this explain it differently on how it's supposed to work?

DanGenuardi commented 5 years ago

screen shot 2018-10-03 at 11 50 55 am

or does this fix the problem?

jesdavpet commented 5 years ago

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 commented 5 years ago

screen shot 2018-10-04 at 3 00 27 pm

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 commented 5 years ago

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 commented 5 years ago

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

Berjesty commented 5 years ago

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

lucylist commented 5 years ago

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… 46422712-ed4e6500-c702-11e8-9646-68c10a4afb98

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 commented 5 years ago

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:

image

lucylist commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Berjesty commented 5 years ago

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

invalidred commented 5 years ago

@DJDA will talk with @Berjesty about the designs above as he has some concerns about designs 1 and 2 above and accessibility. @DJDA will also have a more broader/ general discussion with the team about aria-roles and toggle component from his perspective, hopefully in our Monday meeting. We need to address inconsistencies with how toggle is displayed in mobile and desktop views and how toggle looks different in my-telus-bill-format and usage page.

varunj90 commented 5 years ago

Toggle Mobile View design with David, Abdul and Berjesty w.r.t accessibility

Next steps

Berjesty commented 5 years ago

Updated designs and context (usage criteria) in TDS Community Library based on the feedback and discussion around accessibility concerns. This issue has been addressed from design perspective.

Definition: 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.

Usage criteria They are best used for changing the state of system functionalities and preferences. Toggles may replace two radio buttons or a single checkbox to allow users to choose between two opposing states. Toggle must be always used with a descriptive Label and can be Toggle can be placed on the right or left side of the value label but must be in line with it.

TDS Style examples Option 1: Always start with Label (Display name/header) Add the Toggle icon Add a default state For ex: on/off or Enabled/Disabled or custom text that differentiates the on/off state mutually exclusive

Option 2 (mobile only): Always start with Label (Display name/header) Add the Toggle icon right aligned Add a default state For ex: on/off or Enabled/Disabled or custom text that differentiates the on/off state mutually exclusive

invalidred commented 5 years ago

So had a discussion with @Apurv Ray and here is a summary

ToggleSwitch

  1. We will have a label on left side of the ToggleSwitch that will never change that talks about what the ToggleSwitch represents example: (Do you want paper bill ?)
  2. We will show a value/description string that will be right below the label that talks about current status of the operation (Paper bill enabled, paper bill disabled)
  3. The ToggleSwitch will be inline with value/description string. @Apurv Ray suggested that it should NOT be inline with label as this will allow for longer labels without colliding into the ToggleSwitch 3a. value/description and ToggleSwitch should have a max-width set to limit how far apart they can stretch.
  4. We will address accessibility using <A11yContent /> component like so 
    <ToggleSwitch 
id="42" 
name="paperBill" 
value="paperBill"
checked={true}
label="wifi setting" 
currentState={<Text>enabled<AllyContent>wifi settings: wifi is enabled</AllyContent></Text>}
/>
donnavitan commented 5 years ago

As per our touch base with @owestinTelus @invalidred, we need to realign on the problem we're trying to solve. I'm just capturing some notes for reference:

Furthering reading references, a couple mentioned previously in threads: https://www.nngroup.com/articles/toggle-switch-guidelines/ https://scottaohara.github.io/aria-switch-button/ https://www.smashingmagazine.com/2017/09/building-inclusive-toggle-buttons/ https://www.sarasoueidan.com/blog/toggle-switch-design/

Related toggle issues/discussions: https://github.com/telus/tds-community/issues/182 https://github.com/telus/tds-community/issues/153 https://github.com/telus/tds-community/issues/112 https://github.com/telus/tds-community/issues/29 https://github.com/telus/tds-community/pull/113

jesdavpet commented 5 years ago

Question: if the toggle UI component is so difficult for customers to decipher visually, that we need to resort to text hints to describe it as "on" / "off" ... isn't the UX of a toggle already pretty clearly broken? What value does a toggle provide that a checkbox does not?

donnavitan commented 5 years ago

As per my discussions with Apurv and @invalidred, we've agreed to the following:

Next steps:

donnavitan commented 5 years ago

Hello @jesdavpet, we do find value in having a toggle as it provides a better UX experience. The biggest UX value is having an instantaneous response to user action. Visually, the toggle is "switched on" and the expectation is that user action has been applied.

Addressing prior comments, we've agreed to take up some of the suggestions. As for the other comments, we'll provide better documentation and usage criteria as to how/when to use a toggle which we hope will mitigate any further confusion.

Further reading:

As always, design is ever changing and while we try to build our components as robust/reusable as possible, they're open to improvement.

donnavitan commented 5 years ago

As per discussions and a11y considerations, we've agreed to the following:

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.

Usage criteria

Implementation

TDS-Community-112_Toggle_20190416

jesdavpet commented 5 years ago

"...we do find value in having a toggle as it provides a better UX experience"

Thanks for the clarification @donnavitan.

BTW, I really like the consideration that's been put into the component-level design you posted! 🔥🔥🔥

Regarding this requirement ...

Implementation:

  • Programmatically use the checkbox element

@invalidred Do you think from a code perspective it would make more sense to consider this component as a button element, rather than a form input element?

In retrospect, I feel like a lot of the confusion around the first iteration of this component has stemmed from it being considered a form input, which carries certain semantics and constraints that are at odds with the stated design intent.

If the component is a button (in code, but styled to look like a toggle), and it completes an action as soon as it is pressed (and not waiting until a form is submitted) then that makes total sense semantically. But, if the component is a checkbox, then it's state should not be processed until the whole form is submitted.

By requiring this to be implemented as a checkbox, wouldn't we essentially be creating a form without a submit button? This seems at odds with best practices for semantic markup, and kind of an "HTML 101" level misunderstanding to me.

See: https://www.w3.org/TR/WCAG-TECHS/H32

invalidred commented 5 years ago

@jesdavpet i think you are correct, a button makes perfect sense since one of the design intents is:

Toggles should provide immediate results.

So an <input type="checkbox"/> does not innately provide immediate result, it needs to be wrapped in a form with a <button type="submit" /> to make the change happen; as you've correct identified.

BTW I did some research and found:

  1. Inclusive Design Component ToggleButton uses a <button /> to represent a <ToggleSwitch /> like component.
  2. Ant Design switches use <buttons /> as can been seen in the screen shot below

Screen Shot 2019-04-18 at 8 48 04 AM

Now the issue we will face (if we choose to use a <button /> as our source of <ToggleSwitch/>) is grouping <ToggleSwitches/>. Previously we were thinking of grouping <ToggleSwitch/> in a fieldset, I am unclear if we can use that. I believe I will need to talk with @donnavitan & @apurvray about this, and probably setup a meeting with you in it, if you are up for it @jesdavpet ?

invalidred commented 5 years ago

Implementation details revisited:

  1. Use <button /> with role="switch", aria-checked="true|false" and aria-labelledby="element" attributes instead of <input /> <button role="switch" aria-checked="true" aria-labelledby="notify-email">
  2. Use a <span> instead of a <label> to label the <ToggleSwitch/> as labels are used for input elements only. Let the parent specify a unique id.
  3. Group <ToggleSwitch/> in plain old <ul>/<li> instead of a <fieldset /> elements as screen readers already know how to group items when they are in a list. Also _fieldset_ only group form elements. Add code example in docs for how to group
  4. We can use a <heading/> above a grouped <ToggleSwitches/> to name the group instead of <fieldset/> and <legend/>.
  5. Add loading prop/state to <ToggleSwitch /> component. Lets look at @DJDA existing designs and see if we can use something from it, else we need to come up with new designs around loading state.

@donnavitan should the <ToggleSwitch /> button should be bigger? Should clicking the label toggle the <ToggleSwitch />?

donnavitan commented 5 years ago

Thank @invalidred and @jesdavpet for thorough addressing of concerns! As per our discussion and as noted, we'll have to take the following back to design review. Expanding the two designs concerns further:

We'll look into it!

donnavitan commented 5 years ago

As per discussion with @apurvray and Ani, we're working on enhancing TDS core spinner component to allow use on smaller interactive elements beyond the button element. It can be used for toggle to indicate loading state.

varunj90 commented 5 years ago

@invalidred hey abdul what is the latest on this?

@apurvray can you share the final designs

this is now design approved and can move to story writing

donnavitan commented 5 years ago

As per discussion with @apurvray and @Christina-Lo, I'll be updating this with designs.

donnavitan commented 5 years ago

Updated the designs to include the loading states which will use the spinner component.

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.

Usage criteria

Implementation

image

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

agorovyi commented 5 years ago

@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 commented 5 years ago

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

Made the following change:

No blurring please. Thanks!

agorovyi commented 5 years ago

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

donnavitan commented 5 years ago
varunj90 commented 4 years ago

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 commented 4 years ago

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.