phetsims / area-builder Goto Github PK

This was requested during most recent design meeting.

Testing 1.0.0-dev.15

Steps to reproduce:

1. Start on the first screen
2. Drag a tile to the upper-left-most position
3. Quickly drag multiple tiles to the lower-right until just before the first one slides finally into place
   The dragged out tiles should now be overlapping.

It seems to count towards area, but not perimeter, so it could cause some serious misunderstandings:

On the first screen, if you create a shape on one board, then switch to the other view (e.g. from the single large board view to the two smaller boards) and then switch back, and then clear the board, the shape disappears immediately instead of fading out.

Steps:

1. Drag some tiles out into the building area. Notice that after they have been placed they can still be picked up and moved elsewhere.
2. Switch the board to the two smaller boards.
3. Switch back to the first board.
4. The tiles that were originally placed can no longer be moved.

Tested on Win8.1 (FF32, Chrome 37, IE11)

Name: Area Builder
URL: http://www.colorado.edu/physics/phet/dev/html/area-builder/1.0.0-dev.17/area-builder_en.html
Version: 1.0.0-dev.17
Features missing: touch
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Language: en-US
Window: 1366x633
Pixel Ratio: 1/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 10 uniform: 254
Texture: size: 16384 imageUnits: 16 (vertex: 4, combined: 20)
Max viewport: 16384x16384
OES_texture_float: true

Test device: Macbook pro
Operating System: 10.9.4
Browser: Firefox

Problem description: When I dragged up green pieces randomly to the game board (to see where they snapped in place) in a challenge some pieces were allowed to overlap. In the end there were three regions that had overlap. They were all with the vertical stack of 2 squares. After the board was filled I tried each piece and none overlapped anymore. In the second screenshot you should see three regions that are slightly darker green with vertical stacks.

Steps to reproduce: drag up multi-square pieces and drop randomly on the board (toward the bottom or center). Keep going as it fills up.
Severity: minor, for now

Screenshots:

Troubleshooting information (do not edit):

Name: Area Builder
URL: http://www.colorado.edu/physics/phet/dev/html/area-builder/1.0.0-dev.10/area-builder_en.html
Version: 1.0.0-dev.10
Features missing: touch
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0
Language: en-US
Window: 1106x603
Pixel Ratio: 1/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 16 uniform: 1024
Texture: size: 4096 imageUnits: 16 (vertex: 16, combined: 16)
Max viewport: 16384x16384
OES_texture_float: true

This issues is to track performance optimizations that are made for this sim.

While not exactly incorrect, fractions really should be written vertically instead of horizontally (as if they are just typed out on a keyboard).
So, looking for something like this:

Instead of what we currently have:

The fractions can be smaller in size so that they still fit on one line

PhET's sim-completion checklist indicates that each sim should have a doc/model.txt file that describes the model used in the simulation. I don't know if this sim needs one or not, just noting that it doesn't currently have one.

Test device: macbook pro
Operating System: 10.9.4
Browser: Firefox 31.0
Problem description: When I clicked "A Solution" the banner displayed the info strangely. This was also a funny challenge because the area was the smallest I've ever seen (4). Also, the panel did not display the perimeter I built.
Steps to reproduce: not sure
Severity: high
Screenshots:

Troubleshooting information (do not edit):
Name: Area Builder
URL: http://www.colorado.edu/physics/phet/dev/html/area-builder/1.0.0-rc.1/area-builder_en.html
Version: 1.0.0-rc.1
Features missing: touch
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0
Language: en-US
Window: 1321x885
Pixel Ratio: 1/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 16 uniform: 1024
Texture: size: 4096 imageUnits: 16 (vertex: 16, combined: 16)
Max viewport: 16384x16384
OES_texture_float: true

While working on Level 2, I am noticing quite a few incorrect perimeters. This seems to happen when I am changing my solution after checking twice (while watching the right-hand panel update dynamically). Often, when I move one square to a location that would keep the perimeter the same, it shows it as different, and in this case, updated to show that I had the correct perimeter:

Here, the final step should have added two to my perimeter but it stayed at 16:

Here is one that was just incorrect from the start,

and now the solution banner shows issue #48,

If you drag more than one block on the playground before it traverses to its destination the traveling blocks will all over lap. ie, after a the 1st square has been placed (base square), 2 or more squares traversing to add to the base square will occupy the same location as the total area increases and perimeter increases.

To Reproduce:
-Open sim
-Drag one square to the play ground (the corner makes the bug easier to see)
-Now drag a sequence of squares before the any can make contact with the base square.

Troubleshooting information (do not edit):
Name: Area Builder
URL: http://www.colorado.edu/physics/phet/dev/html/area-builder/1.0.0-dev.17/area-builder_en.html
Version: 1.0.0-dev.17
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Language: en-US
Window: 1366x657
Pixel Ratio: 1/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 10 uniform: 254
Texture: size: 8192 imageUnits: 16 (vertex: 4, combined: 20)
Max viewport: 8192x8192
OES_texture_float: true

Screenshot below. I've made the "Build it!" and "Area = {0}" strings a bit longer, as may happen when the sim is localized. The strings overlap, so apparently the layout code isn't handling this properly. The "Find the area" challenges have the same problem.

images/license.txt currently contains 1 entry for an image that doesn't exist (eraser.png) and no entries for the images that do exist.

Searching for 'image!AREA_BUILDER' in the code, it looks like only 2 of the 8 images files are actually used. Recommended to delete the others.

This is true for the play and game screens.

Do we have any vertical space to move things away from the board?

To reproduce.
-Open sim
-Collapse boxes showing Area and Perimeter
-Hit Reset (Boxes remain open)

Troubleshooting information (do not edit):
Name: Area Builder
URL: http://www.colorado.edu/physics/phet/dev/html/area-builder/1.0.0-dev.17/area-builder_en.html
Version: 1.0.0-dev.17
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Language: en-US
Window: 1366x657
Pixel Ratio: 1/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 10 uniform: 254
Texture: size: 8192 imageUnits: 16 (vertex: 4, combined: 20)
Max viewport: 8192x8192
OES_texture_float: true

vegas is listed as a dependency in area-build-config.js, but is not included in phetLibs in package.json.

This was discussed at the most recent design meeting. The screenshot below is from version 1.0.0-dev.17, and the control/indicator panel is highlighted. We decided in the meeting that this panel should only contain the controls, and that the indicators should be on their own, not in a box.

Below are 2 screens shots, showing 2 "Find the area" challenges. One of them I got correct, the other I got incorrect. In the case of the correct answer, the "You entered" panel has a white background; in the incorrect case, the background is yellow. I'm guessing that this is a bug, and it should be yellow in both cases.

% grunt lint-sim
Running "jshint:simFiles" (jshint) task
Linting js/game/view/ColorProportionsPrompt.js ...ERROR
[L83:C15] W078: Setter is defined without getter.
set color1( color ) {
Linting js/game/view/ColorProportionsPrompt.js ...ERROR
[L87:C15] W078: Setter is defined without getter.
set color2( color ) {
Linting js/game/view/ColorProportionsPrompt.js ...ERROR
[L91:C25] W078: Setter is defined without getter.
set color1Proportion( color1Proportion ) {
Linting js/game/view/ColorProportionsPrompt.js ...ERROR
[L53:C21] W098: 'patchRadiusX' is defined but never used.
var patchRadiusX = this.color1FractionNode.bounds.height * 0.5;
Linting js/game/view/ColorProportionsPrompt.js ...ERROR
[L54:C21] W098: 'patchRadiusY' is defined but never used.
var patchRadiusY = this.color1FractionNode.bounds.height * 0.35;
Linting js/game/view/ColorProportionsPrompt.js ...ERROR
[L93:C27] W098: 'color2Proportion' is defined but never used.
var color2Proportion = new Fraction( color1Proportion.denominator - color1Proportion.numerator, color1Proportion.denominator );
Linting js/game/view/FractionNode.js ...ERROR
[L71:C17] W078: Setter is defined without getter.
set fraction( fraction ) {

When discussing the changes made for #11 at the most recent design meeting, the design team decided that it would actually be best to add another level to the game so that the user can confront franctions+area first in one level with progressing difficulty of fractions, then add perimeter into the mix in a separate level. Here are the notes from the meeting (extracted from the meeting notes recorded in the design doc):

One last change to game: Add a level 6!

• level 5: fractions and area. First three = “easy” fractions.
• level 6: fractions, area, and perimeter. First three = “easy” fractions.

What is this stuff at the top of area-builder_en.html? I don't see anything similar in the html of recently-deployed sims (color-vision, wave-on-a-string).

<!--[if lt IE 7]>
<html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>
<html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>
<html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!-->
<html class="no-js"> <!--<![endif]-->

KeyPad looks like a prime candidate for migration to common code.

Test device: Win desktop

Operating System: Win 7

Browser: FF

Problem description: navbar icons render poorly

Steps to reproduce:

Severity: probably need simpler icons on navbar (but not on homescreen)

Screenshots:

Troubleshooting information (do not edit):
Name: Area Builder
URL: http://www.colorado.edu/physics/phet/dev/html/area-builder/1.0.0-rc.1/area-builder_en.html
Version: 1.0.0-rc.1
Features missing: touch
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Language: en-US
Window: 1920x943
Pixel Ratio: 1/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 10 uniform: 254
Texture: size: 16384 imageUnits: 16 (vertex: 4, combined: 20)
Max viewport: 16384x16384
OES_texture_float: true

Below is a screenshot from the "Explore" screen of Area Builder. Solid lines are used for the placement grid, dashed lines are used in the interior of the shape that the user is building. At the lower left is a check box whose icon shows a set of dashed lines. Which lines do you think should disappear when this box is unchecked? I would guess the dashed lines, but the solid lines actually disappear. So perhaps the icon next to the check box should use solid lines?

In version 1.0.0-dev.17, it is possible to get some significant variation in the fractions that are presented to the users in the challenges on level 5. Since the fractions are chosen randomly from halves, 3rds, 4ths, etc. up to 9ths, there can be cases where all of the challenges are very easy, all very hard, or hard ones followed by easy ones. We may want to put some constraints in place to make it go from easier to harder fractions as the level progresses.

see phetsims/graphing-lines#13

Was 'area' an old name for this repo? Recommend changing name in README.md to area-builder.

In the 9/11/2014 design meeting, it was requested that the dimensions indicator be turned on (if not already on) when showing feedback for "find the area" style challenges. The argument for this is that the users can use the numbers to gain insight into the correct answer. When the user moves on to the next challenge, the state of the indicator prior to the 'display correct answer' state should be restored.

As of 1.0.0-dev.18, this sim is using the default layout bounds, which have been found to be not quite what we are after, see phetsims/joist#126. There is a value for UPDATED_LAYOUT_BOUNDS available in the ScreenView.js class, but it is only being used in some simulations, so I'll need to dig into this a bit to figure out exactly what should be used here.

Here's the (very nice-looking) control for switching between single and dual board modes in the "Explore" screen:

I was looking for the implementation of this, and it's spread out a bit more than it should be.

In AreaBuilderExplorationView, the control is explicitly pieced together over ~35 lines:

var dualBoardIcon = new HBox( ....
var singleBoardIcon = new ExploreIcon(...
var switchPanel = new Panel(

And the icons are created in ExploreIcon, which is used only for this control.

Recommended to move the related code from AreaBuilderExplorationView and ExploreIcon into BoardDisplayModePanel, with constructor:

function BoardDisplayModePanel( boardDisplayModeProperty ) {...}

Both screens have a control panel that looks like this:

The only thing that appears to differ is the panel margin, which is larger in the 'Game' screen. But there is no shared implementation of this panel. AreaBuilderExplorationView creates it brute force:

var controlPanel = new Panel(...

AreaBuilderGameView takes a better approach:

this.controlPanel = new AreaBuilderGameControlPanel(...

Recommended to generalize AreaBuilderGameControlPanel, move it to the sim's common/view/ directory, and use in both screens.

See screenshot below. Should "Area = 18" be vertically aligned with "A Solution"? Nothing appears in the space below it when the challenge is completed.

Screenshot below, red outline shows the screen's layout bounds.

This is a subjective aesthetic issue. But the level-selection buttons seems placed a bit high to me. There is a lot of negative space below them. It would look better if the buttons were vertically centered in the screen's layout bounds, and the title (Choose You Level!) were vertically centered in the negative space above the buttons.

For an example that is similar to the layout I'm describing, see reactants-products-and-leftovers.SettingsNode

When the 'dimensions' check box is turned on, the top dimension can sometimes feel cramped. See screenshot below, where the '3' along the top of the users shape is sandwiched between the grid and the accordion box. It looks like there's plenty of vertical space elsewhere, so this could be given some room with a little layout tweaking.

There have been several instances during testing where the same challenge is presented twice in a row with nothing changed except for the colors. This is probably a result of the algorithm that determines uniqueness of challenges - it should basically ignore color as something that establishes that a challenge is unique.

A single line for credits.thanks makes the About dialog look a little wide to my eye. Have a look at some of the other MLL sims (ABS, BCE,...) to see how the line is broken. Totally subjective...

This sim is nearing publication, time for the code review. @pixelzoom has agreed to take this on.

These strings in area-builder-strings_en.json don't appear to be used:

"aSolutionColon": "A solution:",
"solutionColon": "Solution:",

Test device:
Macbook

Operating System:
OS 10.9.4

Browser:
Safari 7.0.5 (9537.77.4)
Chrome 36.0.1985.143
Firefox 31.0

Problem description:
The text and graphics on the Explore screen seem different than on the Game screen. Everything seems a little fuzzy. The game screen looks really crisp and clean in comparison.

Steps to reproduce:

Severity:
Not sure...this doesn't affect functionality. If it's an easy fix, would be nice to have it taken care of for the first version of Area Builder, but if it's complicated, I'd be okay waiting for this for version 2.0.

Screenshots:
I've taken a closeup of the dimensions tool on each screen for comparison purposes.
Explore screen:

Game screen:

Troubleshooting information (do not edit):
Name: Area Builder
URL: http://www.colorado.edu/physics/phet/dev/html/area-builder/1.0.0-dev.13/area-builder_en.html
Version: 1.0.0-dev.13
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.77.4 (KHTML, like Gecko) Version/7.0.5 Safari/537.77.4
Language: en-us
Window: 1264x719
Pixel Ratio: 2/1
WebGL: disabled

When the initial challenge is presented in the play area, should "Area" and "Perimeter" be left-aligned? They are in the banner, but in the initial challenge description, everything is centered. @patricialoeblein was concerned about not noticing that there were multiple criteria for this kind of challenge.

During the 9/11/2014 design meeting, we saw some cases where the carousel was in a lower position after playing the game for a while.

HCarousel looks like a prime candidate for migration to common code.

package.json says:

"simTitleStringKey": "AREA/area-builder.name"

But there is no such string in area-builder-strings_en.json. There is this string, whose key probably needs to be changed:

"area.name": "Area Builder",

@amanda-phet @ariel-phet
I'm wondering if we should add one other piece to the feedback on Find the Area challenges... should dew have the dimensions tool turn on? So, in the screenshot below, we'd also see dimensions in addition to the grid.

Why is the paper airplane on the bucket? I looked into the code and GitHub issues, but there isn't any discussion or explanation about it.

common/model/ code refers to 'resident shape' and 'composite shape', and it's not obvious what these mean. Recommended to define somewhere in the code and in implementation-notes.txt.

Should probably draw these in code. They look fine on Chrome, but in other browsers look pretty lame.

Test device: MacBook Pro
Operating System: OSX 10.9.4
Browser: Chrome 37.0.2062.120
(Also happened on Kathy's PC running Chrome)

Problem description:
When in game mode, level 5 cannot be entered if level 1 or 2 has been entered first. Level 5 can be entered right away or after levels 3 and/or 4, but not after 1 and/or 2.

Steps to reproduce:
Start the sim and choose Game.
Enter level 1 or level 2, and click Start Over
Click on Level 5, and nothing happens.
Clicking the refresh button does not allow level 5 to be entered.

Severity:
This needs to be fixed before publishing.

Troubleshooting information (do not edit):
Name: Area Builder
URL: http://www.colorado.edu/physics/phet/dev/html/area-builder/1.0.0-dev.18/area-builder_en.html
Version: 1.0.0-dev.18
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
Language: en-US
Window: 1312x683
Pixel Ratio: 2/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 31 uniform: 1024
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 16)
Max viewport: 16384x16384
OES_texture_float: true

I think the use of the comma seems incorrect. Perhaps a colon or semi-colon ? I think a colon is more widely used, therefore I like it, but I don't know if there is a math use with which might add to the confusion.

Also, I am not a fan of the oval for color identification. Is there a less "shape" thing we could use like the bucket pouring color that is used in paint?

Right now there are several places in the code that are assuming that a shape is removed from the model when it returns to its origin and is not being controlled by the user. This is a bit implicit, and should be replaced by an explicit trigger that is fired by the parent model when the element is removed.