openui / open-ui

Maintain an open standard for UI and promote its adherence and adoption.
https://open-ui.org
Other
3.57k stars 191 forks source link

[switch] Should the switch element support swipe actions? #1045

Open gfellerph opened 6 months ago

gfellerph commented 6 months ago

A question that came up while doing research on the switch element. In the Material 3 Switch Accessibility documentation, it's stated that a dragging movement should toggle the switch. This feature is rarely implemented in other Design Systems. What should the explainer recommend?

scottaohara commented 6 months ago

without rational as to why dragging was included as a way to toggle, it seems unnecessary/out of place, imo. the hit area of a switch is generally so small, that i question how often someone would even want to drag - especially if the control needs to also support click/tap. dragging is more effort (for implementation and as a user)... why even do that?

gregwhitworth commented 6 months ago

@scottaohara is the original "Swipe to Unlock" paradigm a switch, button, other? image

Visually it represents a switch and I would denote that it is a bool that has an indeterminate state akin to "not lifting" on the invoking input (eg: spacebar up, mouse button up) remove focus/hit testing. That said, I don't think that the events are actually bound to that but the usecase above has either "Locked" or "Unlocked" and is using a switch to handle this.

scottaohara commented 6 months ago

I wouldn’t consider that a switch. I cant recall ever seeing one of those implemented as a switch.

A button or some sort of custom slider is typically what I remember seeing these implemented as. Even thr “good” ones often had a11y issues in not providing someone an alternative to sliding/dragging to activate.

brechtDR commented 6 months ago

This feature is rarely implemented in other Design Systems. What should the explainer recommend?

@gfellerph As you stated... it's something so rare. I personally never had the intention to swipe these kind of controls. I haven't seen it as well. I think it's safe to say that most authors won't have a need for it and those that do, will probably want to create such a custom action that it requires some extra scripting anyway.

css-meeting-bot commented 6 months ago

The Open UI Community Group just discussed [switch] Should the switch element support swipe actions?, and agreed to the following:

The full IRC log of that discussion <bkardell_> Proposed Resolution: no
<brecht_dr> gregwhitworth: Should the toggle support gestures?
<brecht_dr> q+
<masonf> q+
<bkardell_> s/Proposed Resolution: no/I think no
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: I commented on that, I've personally never seen this behavior and I think it's special and I don't think it's something that should be standardized
<gregwhitworth> brecht_dr: if someone desires this they'll implement it themselves already
<gregwhitworth> q+
<gregwhitworth> ack masonf
<keithamus> q+
<brecht_dr> masonf: My soft opinion, is i agree with that. The one example I wonder about was the example of the iPhone unlock, but the question is if this is actually a switch to begin with.
<brecht_dr> gregwhitworth: I used that example because that during the switch conversations, we had a bunch of "range discussions". Because these are pretty similar
<flackr> q+
<brecht_dr> gregwhitworth: On switch, i'm not super passionate about it, one way or the other. But for a "range" example, i think it should support gestures
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack keithamus
<brecht_dr> keithamus: I just tried this out on iOs and you can drag it, or even hold it
<brecht_dr> keithamus: Might not be default UX, but seems to work there
<scotto> q+
<gregwhitworth> ack flackr
<brecht_dr> gregwhitworth: Not on android, there it is just click
<gregwhitworth> nm, I'm incorrect. Androis OS does, I had tested a different app that used it's own toggle that didn't
<masonf> q+
<gregwhitworth> s/Adrois/Android
<bkardell_> just because we don't specify it doesn't mean browsers can't implement it, right?
<brecht_dr> flackr: I know there are concerns about gesture, we expose some things on a higher level. I don't think there will be a problem with a higher level thing. There are many examples with universal gestures such as long press for context info
<gregwhitworth> ack scotto
<brecht_dr> scotto Thanks for pointing that out, keithamus. I'm not a fan of the interaction. But after holding it just goes to the next state, which seems odd, you can't undo it.
<gregwhitworth> ack masonf
<brecht_dr> masonf: You can drag continiously back and forth on IOs, it makes it feel more like a range. So maybe the right way should be to treat it as a range?
<brecht_dr> gregwhitworth: The issue is about dragging movement, are we talking about dragging in HTML
<scotto> q+
<brecht_dr> flackr: dragging in HTML is something completely different.
<gregwhitworth> ack scotto
<flackr> q+
<brecht_dr> scotto: It was in the accessibiliyt secion of material 3, I don't really understand what the reason for that is. There are some specific accessiility rules about dragging
<gregwhitworth> ack flackr
<masonf> +1 to click and keyboard activation needing to also work.
<brecht_dr> scotto: It feels more like a gimmick than a feature, and we need to be careful about that
<gregwhitworth> Proposed Resolution: Switch should support gesture support akin to the range control; normative text to be defined at a later point
<brecht_dr> flackr: It could be like "panning" on a switch. This is a gesture we have a term for
<bkardell_> q+
<gregwhitworth> ack bkardell_
<gregwhitworth> q+
<gregwhitworth> ack gregwhitworth
<brecht_dr> bkardell_: Because switch is going to be part of input and by default, input uses platform conventions (based on the OS). Wouldn't it take the convention of the platform (such as focus, colours, etc)
<masonf> q+
<brecht_dr> bkardell_: Can we even specify that?
<gregwhitworth> ack masonf
<brecht_dr> masonf: one question is " what is in the spec", and you're right, absolutely nothing, it's based on the OS as you stated
<brecht_dr> masonf: But, I'm hoping we can break out of that, so that users know what to expect
<gregwhitworth> q?
<gregwhitworth> Proposed Resolution: Switch should support gesture support akin to the range control; normative text to be defined at a later point
<brecht_dr> masonf: Because we're making new tings
<masonf> I'm always trying to make new tings.
<masonf> +1
<keithamus> +1
<brecht_dr> +1
<Travis_> +1
<gregwhitworth> RESOLVED: Switch should support gesture support akin to the range control; normative text to be defined at a later point
<brecht_dr> masonf: Correction: Because we're making new things*
yisibl commented 5 months ago

The Switch in iOS is draggable, which I think is a very desirable interaction.

lukewarlow commented 5 months ago

Fwiw the switch on android is draggable too. I think it feels semi natural for a touch input. I'd probably find it odd if it was with a mouse though?