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

Constrain movement of ruler? #104

Closed
terracoda opened this issue Sep 6, 2018 · 15 comments
Closed

Constrain movement of ruler? #104

terracoda opened this issue Sep 6, 2018 · 15 comments

Comments

@terracoda
Copy link
Contributor

I am just looking at the accessibility of this sim, and I would like to ask if we could consider putting useful constraints on the movement of the ruler to simplify description. For example, preventing it from going off screen, or under the controls?

Question is not high priority, but just want to put it out there.

@arouinfar
Copy link

arouinfar commented Sep 6, 2018

@terracoda there are already limits on how far the ruler can be moved. Are you proposing tighter restrictions?

gfl_ruler

Allowing for the ruler to go a bit off the left/right side of the screen is helpful for these sorts of situations:
image

The ruler probably doesn't need to go behind the panels, but it is easily retrievable in this state. Does it propose a challenge for a11y?

image

We could be more restrictive on its y-coordinate so it doesn't go below the top of the panels.
image

@arouinfar arouinfar assigned terracoda and unassigned arouinfar Sep 6, 2018
@terracoda
Copy link
Contributor Author

I was thinking of tighter constraints, like not off the screen to the left or right, maybe even not beyond the edge of the robots, and not below the panels.

It may not be an issue for a11y, but it might simplify the movement of the ruler.

I would think that keeping the ruler above the panels would make it easier to grab for students with upper body dexterity issues, so restriction in the y-coordinates could be beneficial there.

@terracoda
Copy link
Contributor Author

terracoda commented Sep 6, 2018

It is not priority at the moment. Maybe we should return to this once I am working on the ruler alerts?

@terracoda terracoda assigned arouinfar and unassigned terracoda Sep 6, 2018
@arouinfar
Copy link

Thanks @terracoda! Since I've got GFL on my mind, I'll go ahead and add my thoughts here, but I'm always happy to pick this discussion back up later.

I think it's helpful to allow for some portion of the ruler to go off the left/right side. That would give users a bit more freedom to line up the 0 or 10 tick mark with one of the masses.

As for vertical movement, I think we can limit the ruler to the region above the panels. We'll want to give enough freedom to students to move the ruler out of the way.

For keyboard users, it may be useful to have some sort of shortcut keys (like the jump keys for the balloon in BASE) to quickly align the ruler. One potentially useful shortcut would be to align mass 1 with the 0-mark on the ruler. This would currently work when mass 1 on the far left side of the screen, but the current ruler bounds wouldn't allow this for when mass 1 is on the far right side of the screen.
image
image

@arouinfar arouinfar removed their assignment Sep 6, 2018
@terracoda
Copy link
Contributor Author

@arouinfar, that's a very good point. We definitely would not want to constrain the end of the rule, but perhaps rather the zero mark if we constrain the left-right movement any further.

Thanks for these thoughts. They are helpful.

@terracoda
Copy link
Contributor Author

I am marking this onhold until I am directly working on the ruler.

@terracoda
Copy link
Contributor Author

This issue is related to issue #138
When the new Keyboard Shortcuts are implemented the constraints on the ruler's movement will need updating.

@terracoda
Copy link
Contributor Author

@zepumph, we can discuss this issue when it comes time to work on #138.

@zepumph
Copy link
Member

zepumph commented Nov 5, 2019

Pinging this issue again. It seems like we are moving forward with the full range of the ruler as movement bounds. Should we re-evaluate that, close this issue, or do something else?

@zepumph
Copy link
Member

zepumph commented Nov 11, 2019

Over in #195, our life would be easier if you couldn't move the ruler to be fully underneath the mass controls. Does it seem reasonable to change the drag bounds for the ruler to be bottom bounded just above the controls, something like the picture below. For a solution for #195 we would just need to make sure that the center point of the ruler could never get behind the control panels.

image

@arouinfar
Copy link

@zepumph I'm a bit out of the loop on the latest decisions for this sim. If the current spec is allow the ruler to have full range, this issue is likely moot, but it would be good for @terracoda to confirm.

our life would be easier if you couldn't move the ruler to be fully underneath the mass controls. Does it seem reasonable to change the drag bounds for the ruler to be bottom bounded just above the controls, something like the picture below.

That sounds reasonable to me @zepumph.

@arouinfar arouinfar removed their assignment Nov 13, 2019
@terracoda
Copy link
Contributor Author

@arouinfar, on a11y mobile it is very difficult to grab the ruler when it ends up behind the masses. It serves no purpose for the ruler to go there, so I think it is fine to restrict the movement, so it is always easy to grab the ruler on mobile a11y.

For accessibility, the ruler is totally optional, but users can still use it.

@zepumph
Copy link
Member

zepumph commented Nov 18, 2019

This was implemented above. Please review in GFL and CL. Assigning to both designers.

@arouinfar
Copy link

@zepumph the ruler's stopping point behind the mass/charge controls is looking good. This issue seems safe to close, but not sure, so back to @zepumph

@arouinfar arouinfar assigned zepumph and unassigned terracoda and arouinfar Nov 19, 2019
@zepumph
Copy link
Member

zepumph commented Nov 19, 2019

Great thanks!

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

3 participants