-
Notifications
You must be signed in to change notification settings - Fork 8
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
Add option for force values #90
Comments
@arouinfar curious on your thoughts here -- since we will have several people volunteering with the project coming up, doing some minor improvements to this sim might be some nice bite size chunks of work, and this seems like it would be a fairly simple change (see my thoughts above) |
I think the goal of adding a weight readout would be to better facilitate the calculation of the torque. While I don't think there's currently a significant barrier to calculating torque, I can understand why some teachers may want this feature. While displaying the weight would be a straightforward change for a developer, it's less clear how we would do this in the design. If we want to think of these values as "force values" they should be tied to the force vectors. The most appropriate way to turn on these values would then be a nested checkbox under "Forces from Objects" (which I don't love). Alternatively, we could change "Mass Labels" to "Values" which would display both the mass and force value (my preference). If we add labels to the force vectors, I think the best place for them would be below the vector. For the most part, the labels won't overlap, but we would need to shift the labels for the largest masses. Even with an opaque background, the values will be challenging to read when the ruler is on. Given that the goal is to make the torque easier to calculate, it's not ideal for the force to obscure the ruler. Alternatively, if we think of values as the weight, it's not necessary to tie them to the force vectors. We could choose to display the weight instead of the mass, and have radio options to view the mass, weight, or nothing. Since the strings are longer, we should probably put the value and unit on separate lines, which I've done for the people. With this arrangement, there aren't any occlusion issues with displaying both the weight and the distance. Visually, I think the weight readout is the cleanest, but it would muddy up the panel UI a bit, and the extra height would push the panels into the grass. @ariel-phet thoughts? |
@arouinfar I think the more I see this, it seems that in terms of design and the age group we are targeting, this feature is just likely to add clutter and confusion. Younger students are going to have no idea what Newtons are, so I think the right place to put labels would be on the force vectors, but the really gets incredibly cluttered. I also think if we going to go into "weight mode" we would want to use nice round numbers for everything. It really seems that one day what we most need is a sim that is devoted to torque, where as this sim is really more focused on a younger audience learning about some basic ideas and proportional reasoning. I am going to mark this one deferred and we can potentially revisit if we get further teacher requests. |
Discussed 12/7/23 and we'd like to close this issue. We have the documentation here and haven't received more requests. This request is not appropriate for this age group, and a sim on torque would be more appropriate. |
@RVieyra shared a user request for this feature over Slack:
|
I'll tag this for design meeting since we've received a new user request on this topic.
This would work well as a Preference to switch between Mass and Weight labels. In 'Weight' mode, the checkbox becomes 'Weight Labels' and we would display the weights instead of the masses. To accommodate the longer string, we should break the label onto two lines, as we currently do for the brick masses.
@ariel-phet also affirmed that using round numbers for weight is desirable:
The simulation currently uses g = 9.8 m/s2 in MassForceVector.js. We could choose to instead use g = 10 m/s2, and I think that would be an appropriate approximation for the target audience of this simulation. However, we would likely get pushback for this modification. I see a few possible options if we want to move forward with this request.
For the target audience of Balancing Act, I think (2) is most appropriate. If the team does not want to make changes to g, I recommend closing this issue and deferring until we create a sim about torque. |
A user wrote to phethelp:
I replied
The text was updated successfully, but these errors were encountered: