Hotkeys for moving magnet and pickup coil horizontally.

[pixelzoom]

Originally discussed in #25 ...

From #25 (comment)

In Slack#DM, @terracoda mentioned that faradays-law has keyboard shortcuts for moving the bar magnet horizontally. See keyboard help below. The magnet must first be grabbed, using the grad-release interaction (space). Pressing 1, 2, or 3 then makes the magnet automatically slide horizontally. Pressing 1, 2, or 3 again changes direction. I have not figured out how to stop the auto-slide -- I tried space, return, tabbing away -- and this seems like a bug or oversight.

This feature might be useful in FEL. We'd need to work out the bugs, and make it work with collision detection. Would we use if for the bar magnet only, or also the electromagnet and pickup coils? It also involves the grab-release interaction, which we had not planned to use for this sim.

From #25 (comment):

• Try adding the 1/2/3 hotkey feature (ala faradays-law MagnetAutoSlideKeyboardListener) but without the Grab-Release interaction. Since there are no plans to add description to this sim yet, and all other draggable objects (compass, meter,...) will not be using Grab-Release, it seems inconsistent and potentially confusing to use Grab-Release for only magnets and coils. This is a "nice to have" feature. If it turns into a lot of work, bring back to the team for reconsideration.

[pixelzoom]

Now that #25 is implemented, I'm wondering if these hotkeys are necessary. It seems like we could tune dragVelocity and shiftDragVelocity (KeyboardDragListener options) to provide 2 speeds that have similar functionality, and perhaps 2 speeds is sufficient. Labeling for discussion at design meeting.

[pixelzoom]

1/25/2024 design meeting: @arouinfar @kathy-phet @ariel-phet @pixelzoom:

The 1/2/3 hotkeys would be relatively expensive to implement, and would not add significantly to what we can accomplish with KeyboardDragListener dragVelocity and shiftDragVelocity. @arouinfar and I will work on tuning those values.

It would be nice to have a 3rd speed, like what's available for Slider. @pixelzoom will investigate what it would take to add a 3rd speed (pageDragVelocity?) to KeyboardDragListener. But if that's not possible, or not a priority, we can certainly live with 2 speeds. As @ariel-phet pointed out, what's important is to show that dragging faster induces more current. And that can be accomplished with 2 speeds. (EDIT: Tracking in phetsims/scenery#1601.)

[pixelzoom]

For tuning drag speeds, I added query parameter dragVelocity (default 500) and shiftVelocity (default 250). Since they affect all draggable objects, they should be used to tune one object at a time.

We should wait to tune these values until we determine whether KeyboardDragListener will be getting a 3rd speed, see phetsims/scenery#1601. Until then, this issue is on hold.

[terracoda]

The 1-2-3 auto-slide interaction was designed by an expert in inclusive design (Jon Hung at the IDRC) who thought deeply about making an inclusive and generally useful interaction. That pattern makes it possible for learners who have dexterity issues to easily accomplish comparable experiments with velocity without multiple key presses and without requiring them to hold a key down, and without requiring them to make extra Tab key presses to go lock or unlock the magnet's sliding path.

The auto-slide pattern accomplishes 2 important goals identified by the design team:

1. a fixed horizontal glide
2. multiple velocities

I do not understand how a lock interaction would contribute to a more efficient keyboard experience.

It would be really nice to have a better understanding of why the pattern already designed for the bar magnet in Faraday's Law is not something that can be copied or re-used in this sim. I am not sure the design team fully understands the benefits of this interaction pattern.

[terracoda]

And the 1-2-3 keys are likely only appropriate for draggable objects that need to explore differences in velocity.

[pixelzoom]

And the 1-2-3 keys are likely only appropriate for draggable objects that need to explore differences in velocity.

In FEL, that would be the bar magnet, electromagnet, and pickup coil.

One clarification: In FEL (and Faraday's Law?), we are exploring changes in speed (a scalar), not velocity (a vector). Perpendicular to the pickup coil, moving the magnet (or pickup coil) at larger speed results in larger induced EMF.

(I'm not mentioning the difference between velocity and speed to be pedantic, but because it was recently a problem with the options for KeyboardDragListener, see phetsims/scenery#1603, and has caused confusion in past design discussions.)

[arouinfar]

The 1-2-3 interaction pattern is generalizable from a design sense, but unfortunately, its implementation is not at all general. There are many important design differences between Faraday's Law and Faraday's Electromagnetic Lab, despite the overlap in physics content.

• FEL has a PlayPauseButton to pause the dynamics and facilitate experimental setup/prediction making. From my understanding, the 1-2-3 implementation in Faraday's Law leverages the time step to generate the animation. Modifying the implementation of the 1-2-3 interaction to work in a sim with a PlayPauseButton would be a significant lift.
• The speed of the (electro)magnet and pickup coil is related to the learning goal of only 2 screens (Pickup Coil & Transformer), so the 1-2-3 hotkey would only be relevant those 2 screens, creating an inconsistent experience. If we try to include it on ALL screens, the implementation will need to be flexible enough to handle the vertical movement when displaying the Earth graphic over the bar magnet. (Note this is a sim preference that is off by default in FEL, but on by default in the "Magnet and Compass" and "Magnets and Electromagnets" sims in the FEL suite.)
  
• FEL has 5 different draggable objects, and it seems helpful to use the same keyboard controls for all of them. This simplifies the keyboard help dialog and makes it easier for users to remember the controls.

I'd also like to note that the Lock to Axis feature is not a requirement for alt input users to conduct successful experiments It assists mouse/touch users to drag in a perfectly horizontal line (like pressing left/right keys). When "Lock to Axis" is checked, it returns the experimental equipment to the default positions and limits movement to be only horizontal.

[pixelzoom]

I've been the scribe for design meeting about this issue, and admittedly have not recorded very detail. So to fill in some info from various discussions that has not been captured in this issue, so that we're all on the same page...

@arouinfar said:

From my understanding, the 1-2-3 implementation in Faraday's Law leverages the time step to generate the animation.

1-2-3 is implemented in faradays-law's MagnetAutoSlideKeyboardListener. It uses stepTimer, which is not general enough to meet the needs of all sims. When generalized, 1-2-3 should use Animation, which provides a choice of how the animation can be stepped (see option stepEmitter). Making 1-2-3 available in common code is likely a rewrite, not factoring a few bits of code out of faradays-law.

@arouinfar said:

There are many important design differences between Faraday's Law and Faraday's Electromagnetic Lab, despite the overlap in physics content.

A few more differences, previously discussed in FEL design team meetings, or in meetings that @arouinfar and I have had:

(1) Faraday's Law has 1 screen, with fixed pickup coil(s) and a movable magnet. FEL has 5 screens, and only involves a movable magnet and coil on 2 screens (Pickup Coil, Transformer). The other 3 screens have no pedagogical need to animate the magnet/coil.

(2) Related to (1), various screens from FEL are broken out into their own sims. For example, the Magnet and Compass sim is just the Bar Magnet screen from FEL. That sim therefore has no pickup coil, and no way to induce current, so no need to animate the magnet. It seems odd to have 1-2-3 hotkeys in a sim where they serve no pedagocial need.

(3) We could omit 1-2-3 in FEL screens where animation is not relevant. It would certainly complicate the implementation. It would result in an inconsistent UX for the bar magnet, electromagnet, and pickup coil. And it could make the 1-2-3 keys more difficult to discover -- if a user's first experience with (for example) a bar magnet is in the Bar Magnet screen where there are no 1-2-3 hotkeys, they may not think to look at keyboard help for other screens to discover which screens support 1-2-3.

(4) The compromise that we're making in omitting 1-2-3 is that the user will need to use a modifier key (Shift) to slow the drag speed. Not deal for users who have dexterity issues. But that compromise is already being made for other PhET components (Sliders, KeyboardDragListener, ... ) and is the current PhET standard/convention.

@terracoda said in #54 (comment):

The 1-2-3 auto-slide interaction was designed by an expert in inclusive design (Jon Hung at the IDRC) who thought deeply about making an inclusive and generally useful interaction.

Good to know. Where can we learn about the design and design history? Is it documented somewhere?

It is certainly under-documented in the faradays-law repo. MagnetAutoSlideKeyboardListener.js has sparse comments and offers no insights. The sim's implementation-notes.md has this sole mention of accessibility considerations: "This simulation is instrumented for PhET-iO and accessibility, and is involved in experimental sonification work (in a branch)."

@terracoda said :

I am not sure the design team fully understands the benefits of this interaction pattern.

We're happy to discuss further, in case we're missing something. But here's what we've done so far:

The FEL team played with the 1-2-3 feature in Faraday's Law, and discussed it in FEL design meetings. Some of the FEL team were also involved in the development of Faraday's Law, and were aware of 1-2-3.

Speaking for myself, I feel like I have a solid understanding of both the 1-2-3 pattern and its implementation. I've spent a lot of time playing with Faraday's Law, and I evaluated the 1-2-3 code (which was broken when I first encountered it, see phetsims/faradays-law#226)

So to summarize what the FEL team has decided so far ...

Based on our understanding of the 1-2-3 pattern, our understanding of the requirements for FEL, and our understanding of how FEL differs from Faraday's Law, the FEL design team decided not to include the 1-2-3 pattern in FEL - see #54 (comment)).

As we understand it, the advantages of that decision are:
(1) We can avoid some costly design issues (enumerated herein) related to how to fit 1-2-3 into FEL.
(2) We can avoid significant additional development costs for generalizing and integrating the 1-2-3 implementation.
(3) We can get the 2 drag speeds that we need for free with KeyboardDragListener, with no additional development effort.

The disadvantages of that decision are:
(1) In contexts involving a magnet and coil, FEL and Faraday's Law sims will not have identical keyboard behavior. Since they are very different sims, we feel like this is acceptable.
(2) In FEL, the Shift key is needed to access the slower drag speed. This is not ideal for users who have dexterity issues, but it is a compromise that has already been made for other PhET UI components.

Hopefully that catches everyone up on where this issue currently stands. Happy to continue the discussion. Labeling to revisit at our next FEL design meeting.

[terracoda]

Thanks for the summary, @pixelzoom. It's indeed very helpful.

I personally see slider interactions as quite different from freely draggable objects. Slider interactions are native HTML elements, input type range, and freely draggable objects are not and require ARIA web-application role, and other ARIA attributes and keyboard handling. I find it difficult to compare them.

I do agree with the following statement:

It seems odd to have 1-2-3 hotkeys in a sim where they serve no pedagogical need.

I was under the impression that moving the magnet at different speeds (consistent different speeds) was pedagogically important.

Looking forward to design meeting.

[pixelzoom]

I was under the impression that moving the magnet at different speeds (consistent different speeds) was pedagogically important.

It's pedagogically important in 2 of 5 screens. And it's not just the magnet -- it's the bar magnet, the electromagnet, and the pickup coil.

[kathy-phet]

I've reviewed this issue, and discussed with @terracoda, @arouinfar, and @pixelzoom.

With full acknowledgement of the additional access the "1,2,3" pattern can provide for individuals who have trouble holding down a key press, given all the complex considerations for the specific design of this sim and the development costs mentioned above, we will use the arrow interactions to meet the learning goals for this sim.

Thanks all. Closing.

[phet-dev]

Reopening because there is a TODO marked for this issue.

[arouinfar]

My guess is that the remaining TODO referenced above is being tracked in #79, but assigning to @pixelzoom to review.