Cueing arrow behavior/design for Distribute Screen

[marlitas]

This is related to https://github.com/phetsims/mean-share-and-balance/issues/207 and https://github.com/phetsims/mean-share-and-balance/issues/141.

We recently added the yellow cueing arrows to the Distribute screen to match the cueing arrows used for the fulcrum in the Balance Point Screen.

However in the Distribute Screen these cueing arrows also need to be part of the larger conversation surrounding keyboard cueing. For the "groupSortInteraction" we are using the below cues for mouse and keyboard:

There are also specific cueing behavior questions that need to be answered:

• When switching between keyboard and mouse, should the cue follow keyboard focus, or follow different logic for it's placement?
• Are we using two different cues for mouse and keyboard or the same?
• When candy bars are added and removed how do we want to handle the placement of the cueing arrow? For example currently the cueing arrow appears on the first stack as soon as that plate has any candy bars. However, this can be jarring if it had previously lived on a different stack.

I believe a synchronous meeting with @amanda-phet and @jbphet will be most helpful in answering these questions.

[marlitas]

Meeting 4/29:

• @amanda-phet suggested that we place the cueing arrow on the tallest stack. We like that, let's do it.
• Unless... there was keyboard focus, then we follow that.
• Use the same yellow mouse cueing arrows for the keyboard interaction.
• For Balance Point, keep the cue visible after all 7 balls have been kicked and as long as there is at least one visible ball on the field.

[marlitas]

I addressed the above recommendations. Over to @amanda-phet and @jbphet for review.

[amanda-phet]

All looks good to me!

[jbphet]

Based on some feedback from the recent interviews and subsequent design discussions, we're revisiting how to improve the cues to make them more effective. Assigning to @amanda-phet.

[marlitas]

I updated the cueing arrow in the Distribute screen to match some of what we've talked about in design meetings. It's not fully working with keyboard yet, but it's up on main for you to take a look and see what you think @amanda-phet.

[amanda-phet]

Thanks Marla!

1. I don't really like the arrowhead above, but I'm fine using it if it's just a package deal. I thought we were trying not to use an arrow because that cue isn't super obvious, and technically you can't move it both directions you can only move it to the right.

2. Most importantly, and this is not a new issue I just haven't had a chance to make an issue for it-- the cue stays behind once you move the candy bar. As soon as you move it, I think the cue needs to go away.

3. There is a bug, in case you didn't know about this. If you go down to one person, this happens:

[marlitas]

Yeah there's some bugginess I definitely still need to fix. But if you like the concept then I can go ahead and address those scenarios.

[marlitas]

I believe the bugs have been addressed and this is now ready for design and code review.

[amanda-phet]

This is working for me. Thanks!

[jbphet]

Code looks good. Closing.

[amanda-phet]

I discovered this behavior recently and wanted to share it here. I'm sure QA would have found it too. Should we do something about this?

[marlitas]

Hmmm. Yeah that doesn't seem ideal, but I'm not sure how to fix it... Right now the logic we have is that the cue will appear on the tallest stack. We can switch that to the lowest stack, but that feels a bit odd with what the cue is trying to accomplish.

[KatieWoe]

Things look pretty good in dev-lite

[amanda-phet]

@KatieWoe you think it's ok to have the cue cover the text?

[KatieWoe]

I don't like it very much, but since it was brought up in this issue and so was known, I didn't have anything to add to it. Sorry, better to say that I have nothing new to add to this issue

[amanda-phet]

I'm making another issue for this and will close this one. I know what to do.