Closed jessegreenberg closed 7 months ago
Some notes about CAV's specific implemnetation for group based grabDrag:
I started on a first pass of factoring out GroupSortInteractionModel, and it got a bit messy. I need to better understand why CAVDragIndicatorModel was needed as a subtype, and how best to support the subtyping with the modularity.
Lots of good progress today. We now have a model and view type. Commits are on branches, and there are 26 TODOs. I don't think it will be too too much to clean this up from here and push to main, but I expect that another conversation with @marlitas will be needed about the view type (we only went through the model type).
Lots of good progress today. Still there are 30 TODOs, but the main work is to pull CAV and soccer-common logic out of GroupSortInteractionView. I have a meeting set up with @jessegreenberg tomorrow to help me design the best system I can. I'll also try to come back to this this evening.
Alright. Here is a report on progress from the above commits:
These classes have been untangled from soccer common and CAV. There are subclasses and options implemented to help support this.
These now live in scenery-phet. This was done without deleting the git history.
PhET-iO api and migration rules updated
[ ] 20 TODOs still exist in the issue. Most of this cleanup is (in my opinion) is pretty important to finishing this project. Some of them will need a bit of input with @marlitas and a designer.
[ ] I noticed a bit of a bug where the median indicator doesn't update when the drag indicator is hidden below it.
[ ] I believe it would be very very good of us to use this outside of soccer balls before calling this sprint done. Perhaps we can work on the chocolate bars in MSaB, and maybe the interactive cards would work well.
We are down to 14 TODOs, which are really just questions for MS and a designer. Many are simple and straight forward, so I'd say not too much more work here to unblock MSaB. Yay!
Lots of good progress here today! I believe there are only four things left for this issue:
@jessegreenberg and I will meet up tomorrow to see if the two mouse/keyboard workarounds can be added to common code.
isKeyboardFocusedProperty-> usingKeyboardProperty
Good conversation with @terracoda today. I'm going to confirm the sound behavior with JB and AM and then we can move forward from here.
Everything is done here except for a single TODO, that is blocked by https://github.com/phetsims/scenery/issues/1602. I'm meeting @jessegreenberg about it tomorrow. Marking on hold and removing high priority label.
@zepumph, I couldn't find anything in the ARIA Practices Guide, so I sent an email to the W3C-WAI Interest Group, basically asking:
Should the ball keep moving when a non-required modifier key is pressed at the same time the Arrow key is pressed? I’m thinking no, and that our implementation is fine, but I wanted to hear what others thought about this.
We'll see if we get a response.
FYI, I did notice that in a typical rearrangeable listbox implementation that ALT+Arrow is the key combination to create a shortcut to move the selected item up and down within the list without requiring the use of the Action buttons. But since our group sort does not use Action buttons that would require a change in focus, this shortcut is irrelevant.
Example here: https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-rearrangeable/
By the way the group sort with number hotkeys and the WASD alternatives seems really robust in my opinion.
Excellent! Let's pick up this conversation more generally in https://github.com/phetsims/scenery/issues/1597.
Ok, the last TODO was handled now that https://github.com/phetsims/scenery/issues/1597 was handled. This is behaving really well, and it ended up being quite simple. The only weird thing was that you get into cases where you really notice the visible threshold for showing highlights again:
But that is not a problem that we need to solve here in GroupSortInteraction. All of other TODOs have been handled. We are ready to close this, and the changes will be more thoroughly reviewed over in #841. Closing
https://github.com/phetsims/center-and-variability/issues/459, we would like GrabDragInteraction to work well with groups. Currently, it was designed with a single target Node in mind. For example, input listeners are added to the target Node like this
https://github.com/phetsims/scenery-phet/blob/db713ca794457e00cc4e3d5e58563456f1800227/js/accessibility/GrabDragInteraction.js#L545-L546
That caused problems when adding GrabDragInteraction to the group. In https://github.com/phetsims/center-and-variability/issues/459, we tried to add the listener to the parent of the group items but this PressListener made the GrabDragInteraction switch states to "grabbed" when the parent received a press.
We also saw that mouse/touch highlights activated in unexpected ways.
We thought about adding a GrabDragInteraction to every item in the group, but that would have required more focus management logic than we wanted to implement.
Maybe we want to change GrabDragInteraction, or maybe we want a new "interaction" type for groups.