Usability of "Add a Mate", "Play", and "Start Over" button group

[pixelzoom]

Related to the "Add a Mate", "Play", and "Start Over" button group...

From #54 (comment):

There's still a bit of a usability problem here. When I press "Start Over", the "Add a Mate" or "Play" button appears in it's place. The buttons are all the same color, and they appear in the same place. So it's easy not to notice that the "Start Over" button was replaced, and you have to click another button to continue. This is especially the case with a touch device, where your finger covers the "Start Over" button.

Before making any changes, @amanda-phet said that she'd "like to interview on this first to see if it is in fact a usability concern."

[amanda-phet]

There didn't seem to be any concerns with this button group during interviews. Students easily used "Add a Mate" and "Start Over."

[pixelzoom]

Reopening.

Since "Start Over" is not (and cannot be) immediate, I expressed concern about the user clicking the "Start Over" button twice, and ending up unintentionally clicking the "Add a Mate" button.

In #60 (comment), @KatieWoe encountered this usability issue on 8/25/2020:

Note that the bug where clicking "Start Over" twice skips the button to add a friend. This seems like it would be relatively easy to do on even a faster moving device.

This is not the first time she's experienced or reported this. She also reported in #60 (comment) on 4/21/2020:

Larger problem was actually the Start Over button. It could take a few seconds on ChromeOS and was slower than expected on all platforms. I thought I had misclicked on ChromeOS and clicked again, and that seemed to register as Add a Mate, which seems problimatic.

Assigning to @amanda-phet to re-evaluate.

[amanda-phet]

@KatieWoe So, to be clear, you clicked Start Over, waited, clicked it again, and then it added a mate (without you seeing the "Add a Mate" button), is that right?

I suppose we should consider a different location for the "Start Over" and "Play" buttons. @pixelzoom didn't we have them more in the center of the play area at one time? Can we put them there, but leave the "Add a Mate" button toward the bottom?

[amanda-phet]

Since this is a usability issue, assigning to @ariel-phet as well.

[pixelzoom]

I sort of hate to move the buttons at this point, since the seem to be generally working well. So something else I'd like to investigate here... See if the "Add a Mate" button can ignore events like the extra click that @KatieWoe is doing. And I should see when the "Add a Mate" button is being made visible, whether changing it's pickability might help, etc.

[KatieWoe]

@amanda-phet @pixelzoom, yes that is what I am doing. It can either happen if you try to click the button again when the start over is loading, or if you double click instead of single click it will also happen.

[amanda-phet]

@pixelzoom said

So something else I'd like to investigate here... See if the "Add a Mate" button can ignore events like the extra click that @KatieWoe is doing. And I should see when the "Add a Mate" button is being made visible, whether changing it's pickability might help, etc.

That's great if you have other ideas to investigate! Please feel free to explore any and all of your ideas. I like the idea of the "Add a Mate" button being not pickable until it's visible, if that might help.

[pixelzoom]

I consulted with @jonathanolson on this, since it involves scenery input processing. Using timer to make the 'Add a Mate' (or 'Play') button visible in the next frame sounded like a reasonable solution. It prevents unwanted presses from getting to the button, and the delay in making the button visible is imperceptible.

To verify, compare the behavior of these dev versions.

Before the change, in 1.1.0-dev.16, I can double-click on the "Start Over" button and cause the "Add a Mate" button to fire, so that I don't even see the "Add a Mate" button, even on my fast MacBook Pro.

After the change, in 1.1.0-dev.17, a double-click on the "Start Over" button does not reach the "Add a Mate" button.

@amanda-phet please verify in the dev versions above.

@KatieWoe could you also please verify that this fixes the usability problem that you reported?

Feel free to use ?secondsPerGeneration=1 to speed up your testing.

[KatieWoe]

Things look pretty good, even on ChromeOS. May actually work a bit better on the slower device actually.

[amanda-phet]

@KatieWoe can you elaborate on this comment:

May actually work a bit better on the slower device actually.

What works better? How is it better on a slow device?

@pixelzoom
I tested both versions and I can't seem to double-click fast enough to notice a different between the two versions. Can I trust that @KatieWoe 's improved experience is enough to wrap this up?

[KatieWoe]

With a slower device I was able to see the fix better. The double click seemed like it might still be happening on the fast devices, but that was because the new button was up by the time the second click came. Mostly I just mean it worked better for my testing. Sorry for the confusion.

[pixelzoom]

Yeah! Very happy that this works. Thanks for testing @KatieWoe.

@amanda-phet if this looks OK to you, feel free to close.

[amanda-phet]

Thanks @KatieWoe that makes sense. Since I don't have a slow device this is tricky for me to reproduce, but it sounds like the original usability issue pertaining to slower devices is fixed! Thanks for testing, and thanks @pixelzoom for coming up with a good solution to this.

[pixelzoom]

Reopening. This unfortunately introduced a PhET-iO state problem in #211. So I'll need to revert and find another way. Pretty sure I can use the same approach (timer) and still make PhET-iO happy. We'll be publishing the prototype with the current implementation.

[pixelzoom]

I've moved the Start Over button problem to its own issue, #217, where it will be easier to track, regression test, etc.

So re-closing this issue.