First Screen: Speed up the "win"

[kathy-phet]

@samreid @jessegreenberg - Not quite sure who might take a look at this.

With the wrapper, Amy and I are both feeling like the "win" on the first tab takes a painfully long time. I checked versus the Java sim and it does take more than 50% longer to win on the HTML5 version. It seems like there is no design reason why it should be longer.

Is it hard to try speeding it up (by reducing the modeled weight of the candy) so it takes about 3.5 seconds to win if all pullers on one side but no opposing pullers? On my computer this scenario currently takes about 5 seconds.

[kathy-phet]

@amyh-phet - I made an issue. @arouinfar - Can you also weigh in here since you've been most recent lead on design?

[ariel-phet]

@kathy-phet it does give time for interaction, which depending on the use can be an advantage

[phet-steele]

it does give time for interaction, which depending on the use can be an advantage

Agreed. However, I'm sure @kathy-phet brought this up while having fun in the classroom activity wrapper for this sim (I know I'm sure having fun!). In that wrapper, interaction is not allowed while the cart is in motion (in most scenarios). It might be entirely possible, depending on how the source code is written, to customize the mass of the cart in just the wrapper while leaving the phet brand sim untouched.

[arouinfar]

It might be entirely possible, depending on how the source code is written, to customize the mass of the cart in just the wrapper while leaving the phet brand sim untouched.

I like @phet-steele's suggestion. Is it possible to customize the cart mass in the wrapper? I think this would be preferable to changing the sim, as I tend to agree with @ariel-phet about the time for interaction.

[kathy-phet]

True, but right now it is substantially slower than the java sim which was already slow enough to do that. It seems we could/should at least try to bring speed up to match java sim. Kathy

Sent from my iPhone

On Nov 2, 2016, at 3:57 PM, Ariel Paul notifications@github.com<mailto:notifications@github.com> wrote:

@kathy-phethttps://github.com/kathy-phet it does give time for interaction, which depending on the use can be an advantage

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/210#issuecomment-258010578, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AE3FZEJnHdOKBiujhjnTjIkRXlv0J_exks5q6QYvgaJpZM4KnxzI.

[kathy-phet]

Bigger change. Could we have choice between small cart and a large cart?

Sent from my iPhone

On Nov 2, 2016, at 4:06 PM, Amy Rouinfar notifications@github.com<mailto:notifications@github.com> wrote:

It might be entirely possible, depending on how the source code is written, to customize the mass of the cart in just the wrapper while leaving the phet brand sim untouched.

I like @phet-steelehttps://github.com/phet-steele's suggestion. Is it possible to customize the cart mass in the wrapper? I think this would be preferable to changing the sim, as I tend to agree with @ariel-phethttps://github.com/ariel-phet about the time for interaction.

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/210#issuecomment-258013988, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AE3FZEoFeYoH_UnI7R_DyM1Soo2RGRsVks5q6QlEgaJpZM4KnxzI.

[ariel-phet]

@kathy-phet can you give the learning goal behind having a small and a large cart here?

Remember, one of the reasons to have a a big massive mass in the center is to avoid complaints about equating this situation with a "tug of war" since in a tug of war both sides basically have equal forces (due to Newton's third law) and it is the frictional force between the ground and the feet that allow the win. Making the mass small takes you more towards that situation, we want to avoid that in this sim. With a large mass we can have different forces on each side and not get into some of the complicating issues.

[kathy-phet]

Same net force on smaller mass wins faster. Similar to having all the masses on the next screen but here it is just small and large and a different measure of how fast something speeds up.

K

Sent from my iPhone

On Nov 2, 2016, at 5:19 PM, Ariel Paul notifications@github.com<mailto:notifications@github.com> wrote:

@kathy-phethttps://github.com/kathy-phet can you give the learning goal behind having a small and a large cart here?

Remember, one of the reasons to have a a big massive mass in the center is to avoid complaints about equating this situation with a "tug of war" since in a tug of war both sides basically have equal forces (due to Newton's third law) and it is the frictional force between the ground and the feet that allow the win. Making the mass small takes you more towards that situation, we want to avoid that in this sim. With a large mass we can have different forces on each side and not get into some of the complicating issues.

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/210#issuecomment-258028851, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AE3FZNYV76Hpx8L2E87865mkxhSd2Vczks5q6RqPgaJpZM4KnxzI.

[jessegreenberg]

For what it is worth, it looks like a 'win' in version 1.0.0 took about the same time as the Java sim. http://www.colorado.edu/physics/phet/dev/html/forces-and-motion-basics/1.0.0/forces-and-motion-basics_en.html

For version 1.1.0, commit e3aacf75e7e604599a552c923c3b898f86147f96 slowed things down a bit and includes the comment

// Make the simulation run fast enough when only one puller, but slow enough when 4 pullers.

[kathy-phet]

I much prefer the 1.0.0 sim speed. It takes more than 12 seconds (on my computer) for the 1.1.0 version of the sim to win in a basic 1 puller vs the other puller scenario (50 N difference) which is a common set up in activities. The 1.0.0 version takes about 6 seconds - which is still quite a while to wait and to play while in motion.

[amyh-phet]

I agree with @kathy-phet in preferring the 1.0.0 sim speed, especially for the FAMB wrapper. When doing multiple tests, each 12 s or so wait seems to get more annoying. I recognize the use case is a bit different as we are preventing students from interacting with the sim until the trial finishes and they have a chance to record their data.

[kathy-phet]

While I think the wrapper has brought to light this behavior, I think we do want students to finish their trials in the main sim. I think we want to allow for interaction during a trial but I see that as a secondary learning goal to comparing different starting scenarios. Interaction during motion becomes a bigger learning goal for screen 2. If students are getting frustrated with how long it takes to complete a trial, then interaction during a trial could become the dominant behavior. I play with v1 and feel like I can interact during a trial and that I learn some good lessons about how larger forces will turn a cart around faster.

I also imagine teachers creating wrappers like ours.

Sent from my iPhone

On Nov 3, 2016, at 6:55 AM, amyh-phet notifications@github.com<mailto:notifications@github.com> wrote:

I agree with @kathy-phethttps://github.com/kathy-phet in preferring the 1.0.0 sim speed, especially for the FAMB wrapper. When doing multiple tests, each 12 s or so wait seems to get more annoying. I recognize the use case is a bit different as we are preventing students from interacting with the sim until the trial finishes and they have a chance to record their data.

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/210#issuecomment-258134500, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AE3FZBQ1QWtruQax-MPGRLYD5aCBiOpVks5q6dnMgaJpZM4KnxzI.

[ariel-phet]

@jessegreenberg please go ahead and make the change to match the speed of the Java sim, but no other work at this time. It might be worth making that change and republishing the latest RC, since not much testing has taken place yet. That way we will have this change worked into the published version soon.

[jessegreenberg]

Sounds good.

[amyh-phet]

@jessegreenberg Can you update with an time frame for implementing this? We will need to get an instrumented version of this in the FAMB wrapper that @zepumph and @mattpen are working on. Also mentioning @andrewadare as he has been handling the instrumentation piece for the wrapper.

[jessegreenberg]

Pretty quickly @amyh-phet this should be a one line change. However, would you like to match speed of the Java or the speed of 1.0.0 (html5)? The 1.0.0 release of the html5 version is a bit faster than the Java.

[amyh-phet]

@jessegreenberg I was thinking the 1.0.0 version of HTML5.

Sent from my T-Mobile 4G LTE Device

-------- Original message -------- From: Jesse Greenberg notifications@github.com Date: 11/3/2016 5:01 PM (GMT-07:00) To: phetsims/forces-and-motion-basics forces-and-motion-basics@noreply.github.com Cc: Amy Hanson Amy.J.Hanson@Colorado.EDU, Mention mention@noreply.github.com Subject: Re: [phetsims/forces-and-motion-basics] First Screen: Speed up the "win" (#210)

Pretty quickly @amyh-phethttps://github.com/amyh-phet this should be a one line change. However, would you like to match speed of the Java or the speed of 1.0.0 (html5)? The 1.0.0 release of the html5 version is a bit faster than the Java.

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/210#issuecomment-258298763, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANBJBH9V7HDJ86F7quPH17QVuz0Gn3_lks5q6maxgaJpZM4KnxzI.

[jessegreenberg]

Thanks @amyh-phet, speed matches 1.0.0 version with the commit above. @zepumph @mattpen @andrewadare commit made to master, I am not sure if it needs to be merged to other branches for the wrapper.

[jessegreenberg]

@amyh-phet @zepumph is there anything else that needs to be done for this issue?

[zepumph]

@jessegreenberg not for me, thanks though.

[amyh-phet]

Nothing more from me, so closing.