Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete constrainValue from AccessibleValueHandler #837

Open
zepumph opened this issue Mar 17, 2023 · 8 comments
Open

Delete constrainValue from AccessibleValueHandler #837

zepumph opened this issue Mar 17, 2023 · 8 comments
Assignees

Comments

@zepumph
Copy link
Member

zepumph commented Mar 17, 2023

From #698 and #350

A subset of phetsims/scenery#1298

@samreid and @jessegreenberg and I have just had a large conversation about how constrainValue is being used in My Solar System over in phetsims/my-solar-system#105, and have come to the conclusion that as it interfaces with the step values, it is really really confusing. We recommend deleting it, and keeping constrainValue specific to mouse/touch in Slider, and the following as the API for AccessibleValueHandler:

  • keyboardStep
  • shiftKeyboardStep
  • pageKeyboardStep
  • a11yMapValue
  • a11yMapPDOMValue (for the PDOM-facing attributes only)

By having different APIs, we provide the least confusion and most ability to support the unique design cases that we have continually wanted for these two different interactions.

Tagging @pixelzoom, especially since I hope he will likely feel similarly, especially as it pertains to his most recent comment on the topic: #698 (comment)

@zepumph
Copy link
Member Author

zepumph commented Mar 17, 2023

A large portion of this issue is going to be teasing out potential regressions in current code. Right now, in my-solar-system, because of the use of keyboardStep (25) + constrainValue (map to nearest 25), you can be at 24, press keyup, and then end at 50. If a designer considers that a "feature" than it will be a regression to just have keyboardStep (which will result in a final value of 49). It isn't clear that is a regression to me, so we will likely want to be careful about how we review sims effected by this change.

@kathy-phet
Copy link

kathy-phet commented Mar 18, 2023

@arouinfar @terracoda - tagging you because am curious what you think. My instinct would be that design wise it would be more important for keyboard that hitting next "arrow" would just to a clean next value. But I could see having different constrain values for keyboard and mouse. Clean numbers seems pedagogically useful

@terracoda
Copy link
Contributor

Here's what I said over in #703

@zepumph and @samreid will #837 support iOS VoiceOver users who double tap and hold to activate a slider and then drag the slider thumb (without lifting their finger) to change the value of the activated slider? A similar gesture would be desirable in our own custom gesture input that was designed/prototyped for haptic research in JT and GFLB.

People, especially those with low vision, do not use a single forms of input. They mix it up switching between discrete focus-based input (e.g., the keyboard) and non-discrete pointer-based input (e.g., mouse and touch).

Some forms of input are focus based (e.g., keyboard, iOS VoiceOver taps and swipes, switch) and some forms of input are pointer based (e.g., mouse, touch, joy stick, head pointer, camera input=hands for RaP and Quad).

Some forms of focus-based alternative input can have a mode that allows for non-discrete/pointer-like exploration (e.g., iOS VoiceOver's double tap-hold-drag, and our own custom gesture for JT and GFLB).

If we can generalize input without comprising customizable options for output, I think that would be really nice. For example, people using a mouse do not need the same Voicing output as people using a keyboard.

@terracoda
Copy link
Contributor

terracoda commented Mar 18, 2023

In OL and RIAW, we rounded to clean numbers when using keyboard. I agree, clean numbers are pedagogically useful. I think we wrote about this in this 2018 HCII paper https://dl.acm.org/doi/abs/10.1007/978-3-319-92049-8_28

Maybe this link is better: https://link-springer-com.colorado.idm.oclc.org/chapter/10.1007/978-3-319-92049-8_28

@arouinfar
Copy link
Contributor

I don't think I fully follow what's going on here @zepumph, but if the result is that constrainValue and keyboardStep will independently always take you to nice, round values, I'm all for it.

@arouinfar @terracoda - tagging you because am curious what you think. My instinct would be that design wise it would be more important for keyboard that hitting next "arrow" would just to a clean next value.

Agree!

But I could see having different constrain values for keyboard and mouse.

I would argue that 99% of the time we want constrainValue and keyboardStep to be exactly the same. In the sims I've designed with alt input, I've made sure to specify the same interval for both. If it's important to encounter the values in increments of 10, it shouldn't matter how you are using the slider.

Clean numbers seems pedagogically useful

Agree! We should prioritize clean numbers in all input forms.

@zepumph
Copy link
Member Author

zepumph commented Mar 20, 2023

This feels like backburner alt-input work that I won't have time for now and may need more discussion before proceeding, but is good to recognize as a potential step forward.

We have already mentioned this in phetsims/scenery#1298, and I think that will be where this work get's scheduled next, unassigning.

@zepumph zepumph removed their assignment Mar 20, 2023
@samreid
Copy link
Member

samreid commented Mar 20, 2023

We confirmed the behavior in My Solar System is correctly quantizing as desired. So I don't have other planned work on this issue at the moment. Self-unassigning.

@samreid samreid removed their assignment Mar 20, 2023
@jessegreenberg
Copy link
Contributor

This came up for us again in greenhouse-effect. We tried constrainValue, found that it did not work for the shift key because of the workaround. We tried using a11yMapValue and it worked great. I would like to work on this next so that it doesn't cost more time in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants