allow minimum rows to go to "1" and address dependency on current minimum of "5"

[amanda-phet]

One of our collaborators who observed sims in the classroom this summer had the suggestion to allow the board to go down to a single peg. I agree with him that it would really emphasize the concept of binary probability, and would allow teachers to more flexibly teach this concept (when they are usually teaching it with coins that don't have an adjustable probability).

Is the code structured in a way that allows you to change the number of rows easily? I understand that a single row would probably scale the peg to be very large, but it seems worth it.

[pixelzoom]

I'm sorry to report that very bad things happen if I change the minimum number of rows to 1. Some examples:

First, the size of the pegs and placement of their shadows is mess up. Here's what the "Intro" screen looks like at startup ("Lab" screen is similar):

Here's what the "Lab" screen looks like when rows is set to 1. Both the peg and its shadow are not properly positioned, and (I believe) the peg should be larger:

Next is the issue of ball size. With rows=1, here's what you get when the Lab screen is dispensing continuous balls:

I poked around, and there's no easy fix for any of these problems. And some of them (like setting a maximum ball size) would require a design meeting or two to work out.

@amanda-phet How do you want to proceed?

[pixelzoom]

If you want this change, I'd estimate somewhere in the neighborhood of 20-30 hours to ferret out all of the problems, decide how to address them, and adjust the implementation. And we should stop dev testing immediately.

[pixelzoom]

Btw... The problems with the size and location of pegs and their shadows occurs for any number of rows !== 5. So there's something in the implementation (multiple somethings, actually) that are dependent on the value '5'. This is a bad thing, and would be nontrivial to fix. I'll add a note in the code so that someone doesn't step on this landmine.

[amanda-phet]

OK, that is a bummer... it is probably not worth 20-30 hours at this point!

@ariel-phet @kathy-phet do you agree?

[ariel-phet]

@amanda-phet I don't think this would be appropriate at this time considering @pixelzoom's schedule

However, having the code written in a way that depends on the minimum value of 5 is problematic and we should address. I think this would be something we could consider for Jesse once he is done Pendulum Lab (which is next for him after he finishes GAO). He appreciates "smallish" projects.

At worse case, we could have Martin and his team rework things next summer for a 2.0 release

[amanda-phet]

Sounds good to me.

Unassigning.

[ariel-phet]

@pixelzoom thanks for the prompt investigation

[kathy-phet]

Thanks for investigating. And I agree - defer, but we should probably log a future issue too, to refine the code regardless. Jesse sounds like a good candidate at some point if it seems good to him.

[pixelzoom]

@kathy-phet said:

we should probably log a future issue too, to refine the code regardless.

This issue will suffice.

[kathy-phet]

ok

[pixelzoom]

9/15/16 dev meeting: Make a note in the code review checklist to monkey around constants during review, to check for this kind of issue. Target constants that are likely candidates for being changed in the future.

[EDIT: Done, see https://github.com/phetsims/phet-info/issues/29]