phetsims / area-model-common Goto Github PK

BooleanProperty, NumberProperty, etc.

For instance, if it's entering a constant, the x^2 and x buttons should not be used for a correct answer. Should these be visible, or is it too much of a "hint" if they are not there?

It may be a good cue to put a border around the readout while editing a polynomial, like the readouts while editing a term.

Current appearance:

Ideally, I want a RectangularPushButton to call handle() on the Scenery event when the listener is fired, so that it won't trigger listeners underneath.

Is there a convenient way to access the Scenery event from the listener callback, or should I rely (in this case) on the fact that my "button operation" is idempotent?

http://www.colorado.edu/physics/phet/dev/html/area-model-multiplication/1.0.0-dev.3/area-model-multiplication_en.html should be (mostly) feature complete, so I was wondering if you could check the area-calculation lines to make sure they look as expected and that the proper lines are shown.

I ended up with the following lines and visibilities:

• "totals" line, always visible: shows the product of simplified width and height sums.
• "expanded" line, visible if different from the totals line: expands the width and height to the ordered sum of partitions
• "distribution" line, visible if there is more than one partition for either width or height: distributes the terms
• "multiplied" line, visible if the distribution line is visible AND it is different from the final total line: multiplies width/height terms together, wrapping negatives in parentheses
• "ordered" line, visible if the multiplied line is visible AND it needs reordering (but hidden if the ordered line would be the same as the total sum line, counting "wrapped in parentheses" as different): Reorders the "multiplied" line so that exponents are in order.
• "minuses" line, visible if the multiplied line is visible, we're in the 3rd screen, there is a negative term, AND the ordered terms is not the same as the total sum line: unwraps negative values, uses '-' between expressions where relevant.
• "total sum" line, always visible: shows the simplified sum of the totajl area.

If it was confusing in English, the (current) code shows the logic slightly better:

var needsExpansion = !horizontalTermList.equals( horizontalPolynomial ) || !verticalTermList.equals( verticalPolynomial );
var needsDistribution = horizontalTermList.terms.length !== 1 || verticalTermList.terms.length !== 1;
var needsMultiplied = needsDistribution && !multipliedTermList.equals( totalPolynomial );
var needsOrdered = needsMultiplied && !orderedTermList.equals( multipliedTermList ) &&
                   !( orderedTermList.equals( totalPolynomial ) && ( !this.allowPowers || !orderedTermList.hasNegativeTerm() ) );
var needsMinuses = needsMultiplied && this.allowPowers && orderedTermList.hasNegativeTerm() && !orderedTermList.equals( totalPolynomial );

Definitely let me know if anything here seems out-of-place (particularly if there seems to be a "missing" or "duplicate" line ever).

For investigation of resizing in #11.

Label on Problem panel should be changed to read Product instead.

In each partitioned area, with "partial products" set to "factors", I think it might be helpful to color the width and height (so it is obvious which one is the width and which is the height). Would that add to the sim, or take away from it?

So it doesn't look buttony.

Can the edit readouts (next to the edit buttons) also be clicked to open the keypad? This would be very helpful for touch devices (if the touch area can cover the area), but may also be useful for mouse use.

If the user enters that in the keypad, do we treat it as 0x or 0x^2 (very possible to do), or just treat it as 0?

Some things seem to be accidentally @private.

For example on the 100x100 screen (where partition lines snap to multiples of 10), if the total height is 7, I'd like for it to act the same way it would if the height was 1 (dock/partition line disappears, unless it is actively being dragged).

Does that sound ok?

To be displayed in the game's status bar. Noting here so I can remove it on my internal TODO list.

If the user gets one of the values correct and one wrong, should we detect that and only change the "wrong" value? Otherwise occasionally something like (9, 4) would switch to (-4, 9) where it transposes the 9 that they have.

Should help for easily type-checking things.

The readout/label doesn't fully fit inside the ideal area for it, so it looks a bit ugly:

@amyh-phet thoughts on how to resolve? I didn't want to make the partitions too equal in size on the 3rd screen, but that could resolve it. I could also reduce padding/sizes some.

@pixelzoom, any objections to me adding valueColor as an option to NumberPicker that controls the color of the displayed value?

Now that I've got some of the game mechanics testable, it would be valuable to see how it may differ from the exact design doc:

• There are some dynamic/autofill entries that seem to be fully specified (so will just be filled in 100% of the time). Exists on levels 3-6, 4-2, 4-5 and 4-6 (numbers).
• Some levels are transposes of others, so since this is done automatically I've only included them as one. Exists with (4-5 4-6) (5-1 5-2) (5-3 5-4) numbers, and (4-2 4-3) variables.
• The "dimension line labels are dynamic/autofill if all partition sizes on that side are editable, otherwise it's given" rule looks to be potentially broken by descriptions of 6-1 (numbers) and 6-1 (variables). Additionally, 3-1 and 5-1 (variables) seem to be identical to each other with this rule. Does that need to be updated?
• Other sims use "Show Answer" for game questions. Can we use that, or is "Show Solution" preferred?
• It appears that the game never uses dynamic/autofill partition sizes. Would that open up more space for questions?

I'll be available on Skype if it's easier to discuss there.

I'm wondering where to potentially place the factor labels on the 3rd screen (and show the largest constraints):

Widest calculation with the current font size:

Widest simplified sum of the left side:

Tallest calculation with the current font size:

Thoughts? Also, is it too disruptive to resize the calculation border to fit the formula? (Would change a lot while dragging on the 1st screen / decimal screen, but that doesn't apply to the generic screens).

Don't want to use centerX, instead we should use the center of the base line of text. May need to add something to RichText.

With current implementation, the panels can easily appear/disappear as user interacts with model.

Changes to current behavior:

• Panels always visible.

• If user has not entered any values for length/height on model, then a ? will be used to show any readouts in the Total area panel, any partial products displayed on the model (product or factor), and in the calculation panel below the model.

If a user has entered a value for height OR length, then:
Total area or Partial Product - Product selection (A button) = ?
Calculation panel (for both options) and Partial Product factors (a x b button) will display a color-coded box for any undefined dimension and the number entered for any defined dimension.

For doing things like Variables 6-1, we want to hide the dimension line label until ALL editable partition sizes on that side are filled in (it seems).

Does this generalize to the others, like numbers 4-1 where there are three editable partition sizes on one side? (What should the numbers 4-1 dimension line label show if 1 value is filled in and 2 are not?)

On the iPad, it's able to overlap with the partition line handles. Should set a maxWidth/maxHeight (both?) to prevent that.

Creating many Text nodes for RichText seems like an obvious culprit.

Currently if you switch between these two screens, it's possible to see that there's a slight "shift" because the "Product" and "total area" parts allow a bit more vertical room for exponents.

Is it fine if the 2nd screen also allows this much room, so there is no shift in panels when switching between the two screens?

Design docs show the panels fitted up to a collapsed box:

and shifted down when the box is opened:

Other simulations don't shift panels up/down based on whether the accordion boxes are collapsed or not, and I don't see a mockup for the "Problem" box being collapsed.

Should things stay in place when a box is collapsed? And if so, could we move the "Total area of model" box under the other two panels so that there is not an initial gap (e.g. atomic-interactions)?

I'm anticipating a slightly unappealing "stutter" while dragging if this drag handle is always a fixed distance from the rectangle. The mouse (in a drag) would not stay matched with the drag handle due to snapping.

I'd like to consider having the drag handle be able to slightly extend/retract from the rectangle while dragging (but only diagonally), so that it feels more natural.

May become obvious if this is needed once I start with the naive implementation with no extension/retraction.

On Screen 2, when Factors are displayed, they should be shown with an x for multiplication.

On Screen 3, the button to select Factors in the Partial Products panel should show parenthesis instead of an x to indicate multiplication.

I don't recall if this was decided in our meeting.

Should I implement some form of "Start level over" and "Go back to level selection" buttons instead of a single innocuous "next" button?

@amanda-phet and @kathy-phet
Can you give feedback on these mockups of the combo box ideas from our meeting today?

Default

Combo box open

Carousel

One issue we will need to remember is spacing for calculation panel and height label on screen 3

I didn't see an example for the "Area model calculation" with variables where partitions had duplicate exponents, e.g. width partitioned into "2x", "-x" and "5". Would the first line have these remain separated e.g. "(2x - x + 5)", or should it be simplified first e.g. "(x + 5)"?

Examples of appearance:

Alternatively I can have the readout take up a larger width.

Currently, the grids on the Raccoon and Decimals screens contain darker lines. For example, on the 20x20 scene on the Raccoon screen, the gridlines for 10 are darker.

After discussing the sim today, the gridlines should all be the same color to avoid users mistaking these lines as partition lines.

The area-calculation and partial-product selection buttons should be the same size, instead of:

Single line, half tick, increase both font sizes, move lines closer to area where appropriate.

@pixelzoom, any objections for me to add a function that controls how to convert the given value to a string?

We need to display a '1' for 1, but '0.5' for 0.5 (which won't work with toFixed).

Presumably if that option is given, we'll need to iterate over all possible picker values to determine the maximum dimensions of the value node (instead of checking min/max like is done now).

I presume if the user sets up a particular configuration on the 20x20 configuration and switches to 100x100, when they switch back to 20x20 their pre-made configuration will show up?

Should remove most width/height duplication internally.

A tighter assumption, like checking whether things are equal to (or in cases like 6-1, the transpose of) the generated problem values would definitely help with logic.

Otherwise, for cases like this (3-1):

say it's filled out like:

then the "find what is wrong" code notices that the product of total width and total height is not the total area. So it knows either the total area is wrong or one or more partition sizes are wrong. In this case, it can assume the total is correct (since it is not editable), so one or more partition sizes are wrong. The only editable ones are the top two (and since no partition sizes are dynamic ever, it can assume that it's not a partial product being "wrong"). It looks at the values, and all of the partial products look correct. The logic would need to determine which partial products are dynamic and which are static, and in this particular case say "even though the partial product is fine with 2x90, this is the only partition size that isn't fully determined by the problem, so this MUST be wrong".

That's a lot of moving parts, and I'd probably be able to get THAT correct, but then think of the case (6-1):

If there wasn't the issue with when to fill in dimension line totals (see #37, 3rd bullet point), then the transpose of a problem would be allowed (thus one answer needs to be 7, the other needs to be -1).

What happens when the user puts 7 in both locations? They can't BOTH be 7, since one needs to be -1. But marking both wrong probably isn't good (it needs to be kept in one location), but marking one location wrong feels even weirder, since it's preferring a direction. If one is marked wrong, you could edit the "right" entry to -1 and have the correct value, but may not be able to press "check" because you didn't edit the "wrong" entry? Yuk!

Deltas:

• Grid shows 0.1 units for a 3x3 square.

• Drag handles to create rectangle and place partition lines snap to 0.1 units.

• Spinners change number by 0.1.

• Scene selection button reads 3x3
  

When both the width and height are defined (with the new way it is planned to work), the entire area will either be positive or negative. Doesn't seem as helpful, but may still be helpful?