Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design keyboard interaction for ratio #29

Closed
zepumph opened this issue Apr 22, 2020 · 3 comments
Closed

Design keyboard interaction for ratio #29

zepumph opened this issue Apr 22, 2020 · 3 comments

Comments

@zepumph
Copy link
Member

zepumph commented Apr 22, 2020

From tangible research meeting today, we should add some more design time to this interaction.

Instead of having focus only on one of the ratio halves at a time, it would be good to be able to adjust both at the same time. This is pedagogically vital, just like in tangible-land.

Main considerations to me:

  • Ability to control both at the same time.
  • Likely we only need control in one dimension (up and down)
  • the "speeds" feel very important to me. If learning takes place by recognizing that they have to move at different speeds, perhaps having each ratio have a way to have up/down keys for different sorts of speeds, and have one ratio half have a potentially different speed from the other.

Over to designers.

@brettfiedler
Copy link
Member

brettfiedler commented Apr 22, 2020

@emily-phet This issue came out of discussion about the nature of the focus-based input interaction with the simulation. Since we are early in development, I thought it would be a good time to have this discussion and a great time to potentially rethink focus-based interaction as it pertains to the pedagogical goals of the simulation. Or rule it out completely. I recall you mentioning that in some ways, keyboard interaction is a tangible, embodied interaction and I'd like to see if we can take advantage of that :)

The way focus is handled in PhET sims, in general, does not enable simultaneous manipulation of elements (objects?) and, much like pointer interaction, means we can only manipulate one object at a time relative to the other (i.e. I can move the left object relative to the right object, or vice versa).

I see (at least) two tracks:

1.) We proceed with the keyboard navigation as Michael has implemented it and make adjustments to try to optimize the interaction in context of the simulation as it evolves and the interactive description.

2.) We explore how the interaction can be implemented at stage 1 to better serve the pedagogical goals. My initial idea was to take advantage of the physical layout of the keyboard and enable simultaneous bimanual input, such that two pairs of hotkeys control the vertical motion of the left and right object respectively. I recognize that there are myriad problems this introduces especially when it comes to reading out description and interference with screen reader software, but that is why I think it's worth a discussion early!

@emily-phet
Copy link

@zepumph @BLFiedler Thanks for bringing this up! Let's hold off on this for this week (and probably next). This will allow us to focus attention on bigger picture scaffolding issues, and then once we see what (if any) design changes we need to make to support a good sequence of interactions with the sim we'll be in a better position (I think) to consider keyboard access. We'll want to loop Taliesin in on this when we're ready for a discussion...there are a number of constraints here that she's familiar with.

Let's assign Taliesin when we're ready to schedule that discussion.

@emily-phet
Copy link

We discussed different variations last week, and are continuing this discussion in #44. Closing this issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants