User request: speedometer to Net Force, disable "Red/Blue Wins"

[oliver-phet]

I'm writing about a feature request in the force basics tug of war html5 sim. I use it on day 2 of my forces unit to make a connection between balanced/unbalanced force and constant/changing motion.

Two requests are: Can there be a speedometer option in the tug of war? Students argue about whether the cart reaches a constant speed when one guy is pulling, and it's hard to isolate the evidence to suggest that the cart keeps changing motion.

Any way to turn off the "Red/Blue Wins" outcome, and just see the cart move off screen? Students point to the stopped cart as evidence that the cart has slowed down (with no one pulling) and I end up having to repeat over and over that the simulations stops being useful when one team wins.

[ariel-phet]

@arouinfar I know we keep refining this sim....but these are interesting suggestions on the first screen. The more I chew on this it seems like having some way to indicate acceleration or constant speed seems valuable. A speedometer seems fairly natural, but on this screen if we had one it would definitely need to be qualitative since we have no masses listed.

I also do not think it would be a huge deal to have the blue/red wins come up but have the cart continue to move (they can always press the return button).

Thoughts? If you agree, we should consider mocking something up.

[oliver-phet]

Additional email from user:

I've attached the main document I use with students on the Tug of War rollout - though we come back to it again and again...

This handout is written to correspond to Eugenia Etkina's ISLE cycle - we're using the tug of war to perform observation experiments, look for patterns, then to test specific ideas by making predictions.

BFM_2TugOfWarPDF.pdf

[arouinfar]

@ariel-phet I think the user makes a really good point. I don't see the "Red/Blue Wins" banner as the culprit, however. I think allowing pullers to continue off-screen would be sufficient to address the user's request. I can also see how a qualitative speedometer would be a very useful tool here. I'll go ahead and create some mockups.

[arouinfar]

Screens 2-4 have the speedometer located at the exact same place in the play area. This positioning won't work on the first screen, as there will be some overlap with the Sum of Forces vector.

Scaling the speedometer down to 75% (keeping top-center position the same) will allow the speedometer to clear the Sum of Forces vector.

Scaling the speedometer down 70% provides a bit more negative space. This looks about right to me. Thoughts @ariel-phet?

[arouinfar]

A few more thoughts:

• The mockups display the instant where the "Blue Wins" flag would appear. The cart would continue moving to the left, rather than stopping.
• I've pasted the max length Sum of Forces vectors into the last two mockups to see how the Speedometer would look when there's a large net force.
• The Sum of Forces arrowhead will still come pretty close to the Speedometer, so it should probably be moved down ~10 px.

Updated mockup with Sum of Forces moved down 10px and Speedometer scaled to 70%:

[ariel-phet]

@arouinfar a few thoughts...

My first instinct would be to put the speedometer centered top. I feel like centering the speedometer is important (this is just my instinct) to feel like it is measuring the speed of the whole system. I know that seems obvious, but biasing it to one side feels odd. It seems the "Sum of Forces" label and arrow can move down a bit. Perhaps the flag could appear in the upper left of the sim? Or on the cart?

Another whacky idea would be to put the speedometer on the cart itself (it moves pretty slowly even at max acceleration) and we don't do the whole "ground moving to cause the illusion of movement" here, so I think that could also work . Students are likely focused on what the cart is doing anyhow, and it might be a convenient representation to just plop on it.

[arouinfar]

Thanks for the suggestions @ariel-phet. I think having the speedometer centered would be a nice touch, though I'm not sure I agree that it's necessary.

Moving the speedometer onto the cart itself or centering it at the top of the screen requires the speedometer to be quite a bit smaller -- 55% of its current size. However, I think the speedometer still seems big enough. I wouldn't make it any smaller, though.

Placing the speedometer on the cart doesn't actually feel too whacky!

Centering the speedometer at the top of the screen causes some awkwardness with the flag, however. I think placing the flag onto the cart is the most reasonable option.

Placing the flag on the top left looks a bit strange if the speedometer is off or if Red wins.

We could also keep the flags a bit closer to the center and show it to the left or right of the speedometer, depending on the winner. I think this option is a bit worse than keeping the flag to the left.

We could also obscure the pullers with the flag. At that point, the tug-of-war is technically over, so I don't find it particularly bothersome to obscure the pullers. Turning off the speedometer doesn't make the flag seem off-balance, either.

Back to you @ariel-phet.

[jessegreenberg]

@arouinfar is the speedometer value readout large enough when scaled down to that size? It does look nice on the cart!

[arouinfar]

@jessegreenberg the speedometer would just be qualitative, so there wouldn't be a value. I think the needle would still be readable at that size. Do you have any other thoughts about the layout changes?

[ariel-phet]

@arouinfar I am kind of liking the speedometer on the cart

1. One problem with putting the red/blue wins flag over the pullers is you would still be able to interact with the pullers

2. Part of me would also be OK with removing the "wins" flag altogether. We no longer call this screen "tug of war" and it is sort of obvious which side "wins". If we let the cart continue to go off screen, we could get some weirdness with the "wins" flag...for instance lets say you just have a blue puller on a press go...The "Blue Wins!" flag comes up but the cart is still moving and then you decide to load red pullers on, and get it going the other way. It could become confusing.

[arouinfar]

@arouinfar I am kind of liking the speedometer on the cart

Agreed. If we decide to re-locate the speedometer on the first screen, I think the cart is the best place.

One problem with putting the red/blue wins flag over the pullers is you would still be able to interact with the pullers

Very true. This would require the users to return the cart before setting up a new experiment, which I hadn't thought about.

Part of me would also be OK with removing the "wins" flag altogether.

Me too, actually, but I think removing it could get complicated. I wonder what implications this would have for the wrappers we've built for FAMB. I'm pretty sure the wrapper AH worked on used a screenshot of the flag in the data table.

The "Blue Wins!" flag comes up but the cart is still moving and then you decide to load red pullers on, and get it going the other way.

Could the flag disappear if more pullers are added on and the direction of the net force changes? Say blue wins, but more red pullers are added to tip the net force towards red. The flag would disappear until a blue puller reaches the midpoint of the screen.

[ariel-phet]

@arouinfar I kind of like the flag disappearing if more interaction occurs that could change the result, that will require adding some logic.

@jessegreenberg thoughts on the difficulty of that sort of logic/interaction?

[jessegreenberg]

@ariel-phet @arouinfar it would be very straight forward to implement that kind of thing.

[jessegreenberg]

@arouinfar @ariel-phet something like this: http://www.colorado.edu/physics/phet/dev/html/forces-and-motion-basics/2.1.7-no-end-game.3/forces-and-motion-basics_en.html

We probably would want to stop disabling the "Pause" button.

[jessegreenberg]

Ah, I think I misunderstood - in the above version, the team needs to have the largest force (or there should be a tie) to win, . But we want the game to continue only when a puller is added/removed correct? So it should be possible for the blue team to win even if there is more force from the read team.

[jessegreenberg]

Ok, something like this: http://www.colorado.edu/physics/phet/dev/html/forces-and-motion-basics/2.1.7-no-end-game.4/forces-and-motion-basics_en.html

This doesn't include layout changes.

[ariel-phet]

@jessegreenberg that looks good! Would it be a ton of work to slap a speedometer on the cart? If not too much work it would be great to make a dev version and then discuss with Kathy

[jessegreenberg]

It should be pretty simple to add the speedometer.

[jessegreenberg]

Here is a version with the speedometer added (with the panel checkbox): http://www.colorado.edu/physics/phet/dev/html/forces-and-motion-basics/2.1.7-no-end-game.6/forces-and-motion-basics_en.html

Thoughts @ariel-phet and @arouinfar?

[jessegreenberg]

scenery-phet's GaugeNode wasn't intended to be this small, it doesn't support changing size off the label text and the ticks, I will take a look at that.

[arouinfar]

@jessegreenberg thanks for creating these dev versions! Aside from what you've pointed out in https://github.com/phetsims/forces-and-motion-basics/issues/220#issuecomment-287163214, I think the speedometer is looking great.

@jessegreenberg @ariel-phet in general, I like the off-screen movement, but I think there can be problematic situations where the cart can get be off-screen for quite a long time, like in the situation below. The behavior is physically correct, but I think it's a bit too advanced for the younger audience that this screen targets.

Chatting with @kathy-phet we thought of a few options:

1. Adding pullers after the flag appears could reset the cart.
2. Pullers could become unpickable when the flag appears, meaning the cart must be reset before adding pullers.
3. Instead of letting the cart continue off-screen forever, we could add a physical barrier to the ground that pullers can cross, but would stop the cart once the wheel touches.

A few other thoughts

• It's useful for the cart to have a definite stopping point for PhET-iO.
• Allowing the cart to move off-screen forever may negatively impact performance.

I'm leaning towards option 3. I can mock it up later this afternoon.

[jessegreenberg]

I also like 3, that seems most clear and handles the issue brought up in this user request.

[ariel-phet]

@jessegreenberg @arouinfar I think the cart stopping at the edge of the screen would be fine, and I think I am liking the speedometer on the cart, it seems to work quite well, especially when the cart is in motion, accelerating, and you add another puller to balance the forces (so a constant speed is achieved) - it is immediately obvious.

[jessegreenberg]

@arouinfar can you please provide a mock up that shows what the barrier should look like?

[arouinfar]

@jessegreenberg @ariel-phet I've mocked up a few options, but they all feel pretty heavy, save for this one:

The stopper doesn't look too obtrusive. The pullers would pass it with ease (and should be layered above the stopper).

Here are a few other options, in decreasing order of my preference

[kathy-phet]

I like this one, but would suggest making the stopper a steel grey, like metal.

[kathy-phet]

I'd like to keep the blue/red "wins" flag. Is that the plan?

[arouinfar]

Something like this @kathy-phet?

[arouinfar]

And, yes, we'll be keeping the flag.

[jessegreenberg]

https://github.com/phetsims/forces-and-motion-basics/issues/220#issuecomment-288842615

That looks good to me @arouinfar! Are the grey "stoppers" at the edge of the dev bounds? In the current version, the game is over when the cart gets to about half way from center to dev bounds. Just making sure, its easy to change.

[ariel-phet]

@arouinfar @jessegreenberg that looks good (I think we would want to layer the pullers above the stoppers)

[arouinfar]

Are the grey "stoppers" at the edge of the dev bounds?

@jessegreenberg I have placed the outer edge of the stopper at the dev boundary, which would roughly place the edge of the cart at the dev boundary.

(I think we would want to layer the pullers above the stoppers)

Agreed @ariel-phet!

[kathy-phet]

Looks good to me!

Sent from my iPhone

On Mar 23, 2017, at 4:37 PM, Amy Rouinfar notifications@github.com<mailto:notifications@github.com> wrote:

Are the grey "stoppers" at the edge of the dev bounds?

@jessegreenberghttps://github.com/jessegreenberg I have placed the outer edge of the stopper at the dev boundary, which would roughly place the edge of the cart at the dev boundary.

(I think we would want to layer the pullers above the stoppers)

Agreed @ariel-phethttps://github.com/ariel-phet!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/phetsims/forces-and-motion-basics/issues/220#issuecomment-288881658, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AE3FZKkxFA5nmyupw8SFgREHjqZcNtUKks5rovQZgaJpZM4MNggP.

[ariel-phet]

@jessegreenberg any movement on this issue?

[jessegreenberg]

Sorry, no, but this should be pretty quick, I will work on it today.

[jessegreenberg]

@ariel-phet @arouinfar @kathy-phet here is a version with these changes:

http://www.colorado.edu/physics/phet/dev/html/forces-and-motion-basics/2.1.7-dev.4/forces-and-motion-basics_en.html

What do you think?

[ariel-phet]

I think that is all looking quite nice, working quite well @jessegreenberg!

To me, now there remains one issue...when the race is finished we may need to stop showing the force arrows. When the cart hits the "hard-stop" and one of the flags appears declaring the winner, the stop is actually providing a force. So it might be easiest to just hide all forces once the cart hits the stop. Or perhaps we have all the pullers "stand up" when the cart hits the stop. I think hiding forces would be the easiest because then we avoid sticky questions about the net force applied to instantaneously stop the cart etc.

Thoughts @arouinfar and @kathy-phet?

[arouinfar]

@jessegreenberg I like the stoppers quite a bit! I completely agree with @ariel-phet in regards to the force vectors -- we shouldn't continue to show them once the cart stops.

At minimum, the vectors should be hidden. I do really like @ariel-phet's suggestion for the pullers to "stand up" (like they do before Go is pressed) once the cart stops, but I don't know how feasible it would be. Feel free to veto it @jessegreenberg.

[jessegreenberg]

Making the pullers stand up at the end of the game is a trivial change, here it is in a dev version:

http://www.colorado.edu/physics/phet/dev/html/forces-and-motion-basics/2.1.7-dev.5/forces-and-motion-basics_en.html

Reassigning to @arouinfar and @ariel-phet.

[ariel-phet]

@jessegreenberg I think that looks good/works well. Probably we also want to hide the force vectors when everything stops (since the pullers stand up now). So then we should have all vectors hide once the "round" of pulling is over.

[jessegreenberg]

@ariel-phet just to clarify, the force vectors are visible while the pullers are standing before pressing "Go!", so why should they be invisible when the game ends? A dotted stroke around the arrows already indicates that the forces are not active on the cart, and is used to represent this while pulling is paused and before pulling starts.

[ariel-phet]

@jessegreenberg good point! I am little fuzzy today, and I don't think I was paying much attention to the beginning. That does seem consistent.

[arouinfar]

Looks great @jessegreenberg!

A dotted stroke around the arrows already indicates that the forces are not active on the cart, and is used to represent this while pulling is paused and before pulling starts.

I also overlooked this detail (guess it's a case of the Mondays?), but it is indeed consistent.

[ariel-phet]

@jessegreenberg I think it would be good to have @kathy-phet take a look before we publish. Can you plan to bring up at the next status meeting (2 weeks I believe)

[jessegreenberg]

Wil do.

[jessegreenberg]

We discussed this in status meeting 11/4/17. @kathy-phet and the team approved of the changes, but @kathy-phet said she wanted to play with the latest version before proceeding with the redeploy. @jessegreenberg sent it to her in an email.

[kathy-phet]

Looks great to me.

@samreid - Seems like it should be decided as to whether to update the PhET-iO version with these changes. I would vote yes -- as they are nice improvements.

[arouinfar]

@kathy-phet if @samreid updates the PhET-iO version, we may want to consider what effect it would have on the wrapper @amyh-phet worked on.

[kathy-phet]

The wrapper points to a static version, so it would be OK. It would be for our current clients like BrainPop use.

[samreid]

It seems good to get in the pattern of testing/republishing PhET-iO versions when the PhET versions change. @jessegreenberg is this something you can do? I forget how familiar you are with the instrumentation process (I recall we started on a sim together, but I think we got distracted).