search

phetsims / vegas

Reusable game components for PhET simulations.
MIT License
1 stars 4 forks source link

Define focus behavior for Game transitions #90

Closed pixelzoom closed 2 years ago

pixelzoom commented 3 years ago

This came up in the context of Fourier, but is relevant to sims that have a game screen.

A game screen is sort of like multiple screens in one. It as a Node that shows level-selection buttons, and a Node for each level. See example screenshots from Fourier below. Pressing one of the level-selection buttons does an animated transition (usually a left-to-right wipe) to that level Node. Pressing the Back button on a level does an animated transition (right-to-left wipe) to the level-selection buttons.

TransitionNode (which lives in twixt) is responsible for the transition --- it's a general class, and does animated transitions between any 2 Nodes, not just game components. In Fourier (and probably other sims), after transitioning from level-selection buttons to a level, nothing has focus. And pressing tab moves focus to the navbar - which seems wrong.

How should this behave? Should something have focus after a transition?

screenshot_1004 screenshot_1005
pixelzoom commented 3 years ago

Slack discusion with @jessegreenberg:

Slack discussion Chris Malley 1:13 PM In typical game screens, there’s a set of level-selection buttons. Press one of them, and the screen does an animated transition (usually a left-to-right wipe) to that level. TransitionNode is responsible for that transition. In Fourier (and probably other sims), after that transition occurs, nothing for the level has focus. And pressing tab takes me to the navbar. Thoughts on what the behavior should be, and how to make it so? 1:16 The first element in pDomOrder for the level is the Back button in the status bar. (Upper left corner of screen) 1:17 After pressing the level-selection button, if I press Shift-Tab, focus moves to the element that is LAST in the pDomOrder for the level — the “New Waveform” button. Jesse Greenberg 1:19 PM I am not certain where focus is after the transition, but my guess would be the document based on how you describe it. Probably the default browser behavior because the element that had focus was removed from the document. It seems like focus should remain on screen in this case, and at the end of the transition maybe TransitionNode could move focus to whatever element seems most appropriate? Jesse Greenberg 1:20 PM Putting focus on the "Back" button would be very intuitive for me. Chris Malley 1:21 PM Yes, I was thinking that TransitionNode (common code) probably needs to set focus. But I’m unclear on whether setting focus is OK, or whether the user should have to press tab in the level (like when they go to a screen). (edited) 1:22 Should this work like a screen, where there’s some description for the level, and the user needs to press tab to move focus to the first element (the Back button)? Jesse Greenberg 1:23 PM Its a lot like a Screen change, probably for the screen reader reasons we decided there we would want to put focus on the

again. Chris Malley 1:23 PM Similar problem when pressing the back button — what happens when we go back to the level-selection UI? Is there a description, like a screen? Does something get focus? 1:23 Game screens are kind of like multiple screens in one. And most games are like this. 1:24 There’s the level-selection “screen”, and a “screen” for each level. 1:24 … and we transition between them. Jesse Greenberg 1:25 PM That

is part of the ScreenView, but it is private, there isn't a way to request focus be moved to it. Chris Malley 1:25 PM I suspect that scenes (used in many sims) may require a similar discussion. Or maybe you’ve had that discussion already… Jesse Greenberg 1:25 PM No, this is the first time weve thought about this for scenes like this. Chris Malley 1:26 PM So… What do you recommend? Should TransitionNode just move focus to the first element in the pDomOrder for the Node that it is transitioning to? (edited) Jesse Greenberg 1:26 PM What if we added a function to ScreenView that requested DOM focus be moved back to the top. Would be called when the Screen changes and could be called whenever a scene or other game thing changes. Would you have access to the ScreenView to call such a function? Chris Malley 1:27 PM I guess that would work. But do you really want to describe the Wave Game screen, or do you want to describe the UI that is currently visible (and that we have transitioned to) ? Jesse Greenberg 1:29 PM Likely what has been transitioned to, perhaps not the

for the ScreenView then Chris Malley 1:29 PM For example, each level in a game is currently described in the Info dialog on the level-selection UI. And there’s also a message line in the level’s status bar that typically provides instructions for that level. Is that important to read to the user? (edited) 1:31 Since this hasn’t come up before, and Games are new…. Do we need a design meeting to discuss this with the team? Jesse Greenberg 1:31 PM It is, though those things will be added when we instrument with state description. 1:31 Yea, that sounds like a good idea. Chris Malley 1:32 PM How should we get that rolling? A GitHub issue?… Jesse Greenberg 1:32 PM I think where DOM focus goes could depend on what the PDOM looks like when state description is designed for the game scenes, and until that is done I think putting focus on the "Back" button after transition would make a lot of sense. 1:33 Yea, a github issue sounds great, either in the sim or in vegas I suppose Chris Malley 1:34 PM OK. So in the meantime, I’ll modify TransitionNode to move focus to the first element in pDomOrder for the Node that it has transitioned to. For Fourier, that’s the Back button for a level, and the “Level 1” button for the level-selection UI. Jesse Greenberg 1:35 PM Yea, that sounds good, thanks! pdomOrder may be null for a lot of cases if the Node doesn't have one set or hasn't been instrumented yet. Chris Malley 1:36 PM I’ll create the issue in vegas, even though vegas is unlikely to provide direct support, and TransitionNode lives in twixt. Jesse Greenberg 1:36 PM Ah OK, good to know Chris Malley 1:36 PM Right — if pDomOrder is null, it will of course do nothing. Jesse Greenberg 1:36 PM Sounds good

pixelzoom commented 3 years ago

This probably needs to be ironed out before Fourier 1.0 is published. The current milestones for Fourier are listed in https://github.com/phetsims/fourier-making-waves/issues/43.

In the meantime, the plan was described in the above Slack thread:

So in the meantime, I’ll modify TransitionNode to move focus to the first element in pDomOrder for the Node that it has transitioned to. For Fourier, that’s the Back button for a level, and the “Level 1” button for the level-selection UI.

jessegreenberg commented 3 years ago

@arouinfar (and @terracoda if you have time) can we schedule a brief design meeting about this? We will want to decide what the long term behavior should be and what the behavior should be for Fourier 1.0 (if we need to defer this).

EDIT: I reached out over slack to schedule a design meeting.

jessegreenberg commented 3 years ago

Discussed today with @terracoda and @arouinfar:

The behavior should be like this:

pixelzoom commented 3 years ago

That sounds nice. Some implementation notes for myself and @jessegreenberg:

  • After transitioning from level selection to a level scene, focus should move to the first focusable element in the level scene.

This seems to be handled nicely by the TransitionNode change that @jessegreenberg suggested in https://github.com/phetsims/twixt/issues/30#issuecomment-852662036.

  • After transitioning from the level scene to the level selection scene, focus should be on the button for the level that we just left.

This is NOT handled by the TransitionNode change that @jessegreenberg suggested in https://github.com/phetsims/twixt/issues/30#issuecomment-852662036. Focus returns to the first focusable item on the level-selection UI, which is typically the first level-selection button. So we'll need some way to dynamically tell TransitionNode where to put focus for each Node that it's managing. Maybe a getFocus option for each Node?

  • When switching to the game screen from navigation bar or home screen focus should be on the h1 of the screen, which matches focus behavior for all screens.

Looks like there's nothing to do here, it seems to be working as desired.

pixelzoom commented 3 years ago
  • After transitioning from the level scene to the level selection scene, focus should be on the button for the level that we just left.

This pattern was taken from the Home screen.

pixelzoom commented 3 years ago

Over in https://github.com/phetsims/twixt/issues/30, @jessegreenberg and I agreed that this funtionality does not belong in TransitionNode -- it's much too general, and used for things other than games.

It might be the case that we could build support for this behavior (and the UI framework) into vegas. But that's a big project, better tackled after we have more a11y experience with game screens.

So for the time being, I've implemented this behavior in Fourier-specific code, see the above commit. @arouinfar please verify that the behavior matches https://github.com/phetsims/vegas/issues/90#issuecomment-854034816. You can close this issue if it looks OK.

arouinfar commented 2 years ago

I remember reviewing the focus order and keyboard nav behavior in general throughout the design process for Fourier: Making Waves, but it looks like this issue slipped through the cracks. That said, the published sim does have the behavior outlined in https://github.com/phetsims/vegas/issues/90#issuecomment-854034816, so closing.