phetsims / atomic-interactions Goto Github PK

ActualConcepts has delivered a version of this for testing, we need to compare its behavior to the specification. This will be assigned to the lead designer. Here is a link to the version that should be tested: http://www.colorado.edu/physics/phet/dev/html/atomic-interactions/1.0.0-dev.1/atomic-interactions_en.html.

According to the design document, the radio buttons in the top menu should be aligned horizontally with the radio buttons in the Forces menu:

Design:

Currently, they are too far to the left. Please shift the top radio buttons to the right to fix this alignment issue.

Please increase the vertical spacing between text labels to more closely match the original specification:

Notice, for example, that the Atom Diameter label is currently vertically too close to the Custom Attraction radio button, and should have more buffer space between them:

ALSO, this will be easier if the total height of the top menu is increased, again to match the specifications. Notice that when both menus are fully open (as shown above), the bottom menu extends nearly to the bottom of the screen in the design mockup. In the current sim, the top menu is smaller than the spec.

Current sim behaviour does not match the Java sim.

When the sim is paused, and the atom is moved the Force arrows should still change in proportion to the relative positions of the atoms.

For example, if I display the total force arrow, and then pause the sim, I see this:

With the sim still paused, if I move the atoms to a different position, the force arrows should change in response, but instead, I see this, which incorrectly represents the forces on the atoms as unchanged:

Only if I press Play or Step-Forward do the correct force arrows appear, like so (very small, and pointing towards each other):

Credits need to be added for this sim.

Currently, the Custom attraction settings (i.e. diameter and strength) reset to their initial settings when switching to another pair of atoms and then back to Custom. Note: This was unfortunately the behavior of the Java sim as well.

It makes more sense if settings and the position of the sliders would remain unchanged unless the student changes them deliberately or hits reset-all, so that a student or instructor can draw comparisons more readily.

Behaviour should be more similar to the weaker-stronger slider in Acid-Base Solutions, which retains its position even when the toggle switch turns off/removes the slider.

To conserve vertical space when we did the layout, we placed the Hide Forces option on the 'title' area of the Forces accordion box.

Unfortunately, the default behaviour of the accordion box is that touching anywhere in the 'title' bar opens/closes the accordion box. This seems to take priority, so it is basically impossible on a touch device to select 'Hide Forces'.

We either need to change the layout to add in title space (essentially using the layout in the Interactions screen of states of matter), or limit the open/close behaviour of the accordion box to only the touch area around the minimize "button".

@jbphet Can you comment on whether latter option is feasible, considering that the accordion box is a common component? If this is not currently an option, we might want to discuss if there are likely other sims that will need this functionality in future?

Current force arrows on the atoms are 100% opaque, which makes it difficult to see all of the information being displayed when they overlap:

The updated colors look good, but please increase the transparency to mimic the Java sim implementation:

The design document shows the following, where the heading fonts are significantly smaller than the radio button label font:

Please...
(1) Adjust the size and position of the pin graphic to match the design
(2) Reduce the font size for the 'Pinned' and 'Moving' labels to match the design
(3) Adjust the alignment of these labels (so that they are left aligned with the column below, as shown in the design document).
(4) If possible, more closely match the spacing between columns shown in the design.

Currently, the Return Atom button becomes visible as soon as the center of the atom leave the dev area:

Is it possible for the button to only appear after the center of the atom exits the browser window?

If the sim is loaded and then the Custom Attraction option is selected, the pushpin graphic changes position - which should not happen.

This does not happen if another atom combination is selected first (e.g. select Neon-Argon before selecting Custom Attraction), and the pushpin goes back to the correct position if another atom pair is selected and then we return to Custom.

This is how it should look:

Is it possible to ensure that the rounding of the corners in the top (atoms) and bottom (forces) menus are the same, and match the design specifications more closely:

Specifications from design doc:

Current sim corners:

The reset-all button should reset everything to the sim-startup settings, meaning it should also reset the graph to the fully zoomed-in state, identical to when the sim is initially loaded.

Design spec shows the following:

Please...
(1) Increase the font size of the 'Return Atom' label to match spec (should be the same size as the axis labels of the graph), and increase the button size to fit.
(2) Align the left-edge of the button with the left edge of the pinned atom, as shown.

Increase spacing between Slow Motion/Normal radio buttons and the "Play" button to better match the design document:

This should also fix the overlapping touch areas between these controls.

Also, adjust spacing between Play and "step forward" buttons to minimize or eliminate overlap between the touch areas.

From the design doc:

On the vertical line labelled with an epsilon symbol, there should be an arrow only at the top end when the curve itself is hidden below the distance axis. The bottom arrowhead only appears when the bottom of the curve is visible.

In dev 2, the force arrows on the atoms look like this:

It should instead match the color of the Total force arrow shown in the Forces menu:

The design spec and Java sim show atoms fading more quickly to black (or transparent), like so:

The current version of the sim does not look like it matches the either the gradient or color (this is most noticeable for Argon, but the colors are also slightly different for Neon etc.):

Just like the "Move the atom" text/arrow in the Java sim, the hand graphic in the new sim should only disappear after an atom is moved (either by the user directly moving it, or by the user moving the dot on the graph):

If the user switches which atoms are in use before moving an atom (i.e. clicks on the radio buttons in the atoms list at the right), this should have no effect on whether the hand is visible.

The design document shows the the Custom attraction sliders like so:

The sliders in the current version look like this instead:

Please...
(1) Increase the slider width to match the design doc, and align the heading of each slider (e.g. Atom Diameter) to the left-edge of the radio button (and adjust the slider left-edge and labels appropriately).

(2) Remove the labels "small" and "large" from the Atom diameter slider, as shown in the design doc, and decrease vertical spacing in response to this.

For the arrows in ForcesControlPanel, the options are duplicated 3 times:

    var totalForceArrow = new ArrowNode( 25, 0, 0, 0, {
      fill: '#49B649',
      headHeight: 12,
      headWidth: 20,
      tailWidth: 8
    } );
    var attractiveArrow = new ArrowNode( 25, 0, 0, 0, {
      fill: '#FC9732',
      headHeight: 12,
      headWidth: 20,
      tailWidth: 8
    } );

    var repulsiveArrow = new ArrowNode( 0, 0, 25, 0, {
      fill: '#FD17FF',
      headHeight: 12,
      headWidth: 20,
      tailWidth: 8
    } );

Everything except the fill should be factored out into common options. Then use _.extend to provide the fill.

The Pin graphic should be positioned higher and to the left in the starting atom, as shown in the design doc:

Compare: In dev2, the pin is positioned lower and further to the right:

(1) The text "Hide Forces" and "Total Force" should be left-aligned with the straight edge of the bracket for the last radio button.

(2) Slightly decrease the font size for the Attractive and Repulsive labels, in order to increase the spacing between the first two radio buttons.

See this snapshot from the design doc:

When you mouseover the moveable atom, the mouse cursor changes to "hand" icon. For consistency, this should also happen when you mouseover the hand graphic that appears on the moveable atom at the start of the game.

At the strongest setting, the epsilon arrow extends beyond the boundaries of the interaction potential graph and obscures the axis label. In the Java sim, the maximum well depth does not allow for this to happen. When the interaction strength is at its strongest, there should be no overlap between the epsilon arrow and the horizontal axis.

dev.4:

Desired maximum depth:

Broken by #15.

The image below shows the current sim (at 1024 x 670 aspect ratio) on top, aligned with a copy of the design spec at the same size overlaid on it (at the bottom), for comparison:

Please adjust the graph to better match the design as follows:

• Decrease the width of the graph (keeping it aligned roughly with the current right-edge)
• Decrease the height of the graph (without moving the bottom edge)
• Increase the transparency of the gridlines
• Increase the font size for the sigma and epsilon symbols
• Slightly decrease the size of both zoom buttons
• Remove thicker grey horizontal line which is overlaid on the 'zero' of the graph (i.e. the middle gridline should be the same appearance as all the other gridlines)
• Re-align the pinned atom to the new left edge of the graph

The panels on the right-side of the screen (where you select the atoms or forces) both currently have a white stroke border around them which was not present in the mockup.

Can this be removed?

Because of issues like #6 and #17, I don't think this sim has been tested for i18n compliance.

The text "Distance between atoms" should be aligned in the center of the horizontal axis and there should be slightly more vertical space between the axis and the text.

See for example this image from page 4 of the design document:

Vs. the current dev version of the simulation:

Because the zoom buttons for the graph have a white background:
(1) they can't possibly highlight when the mouse is over them (there is no color brighter than white)
(2) they can't look 3D

Consider using a different background color.

Compare with the same scenery-phet.ZoomButton used in ph-scale:

In 1.0.0-dev.2, while clicking and dragging the oxygen atoms into each other with slow motion enabled, they end up going crazy:

Seen on Win 8.1 browsers and iPad 2 (iOS 7)

Troubleshooting information:
Name: Atomic Interactions
URL: http://www.colorado.edu/physics/phet/dev/html/atomic-interactions/1.0.0-dev.2/atomic-interactions_en.html
Version: 1.0.0-dev.2
Features missing: touch
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.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: 9 uniform: 254
Texture: size: 16384 imageUnits: 16 (vertex: 4, combined: 20)
Max viewport: 16384x16384
OES_texture_float: true

atomic-interactions is importing 24 strings, images and .js files from states-of-matter.

Problems with this:

(1) The dependency is missing from package.json

(2) It creates a circular dependency, see phetsims/states-of-matter#48

This is an existing issue in the Java sim, and has been carried through to the HTML5.

In the Custom Attraction mode, if the interaction strength is adjusted to be very small, the horizontal adjustment arrow is now floating and not attached to the curve:

This isn't ideal behaviour (it's best if the control stayed attached to the thing it controls), but is relatively low priority to fix.

Note that we're also likely moving the horizontal arrow control higher on the curve (see #24), so that may affect the position too.

Reducing the atom diameter due to the decreased vertical spacing in the sim, and to avoid overlap with the graph has resulted in changed horizontal scaling of the graph (since the graph is intended to align with the atoms, sigma scales according to atom diameter (except oxygen), and sigma determines the left edge placement of the curve on the plot).

The consequence is that we now have a graph that
(i) doesn't display the shape of the curve as well as the Java version [which is important for student learning], and
(ii) leaves a much longer "tail" of the curve at the right (where the force on the atom is very small, leading to the misperception that the atom is not moving at all nor attracted to the other atom).

We'll need to iterate a bit to find optimal size parameters, possibly allow for the atoms to overlap (or change the range of sigma values available), or otherwise tweak the sim to correct these issues.

Note also that the much deeper well for oxygen also creates some labelling issues, where the vertical arrow indicating epsilon is very close to the left-side of the curve (such that it is difficult to see) - hopefully the horizontal scaling changes will also ameliorate this problem (if not, we'll create a new issue for that, and possibly fudge the epsilon value to be much larger but not "realistically" large).

Compare the mock-up:

To the current HTML5 version:

Note in particular that the horizontal green line should be thinner, the vertical arrow control should be vertically-centered on that line, and the green color of all of these adjustment controls should be more green (i.e. less yellow).

If possible, the arrow heads on both controls should also be a bit wider, but this not critical.

(tagging @arouinfar just to keep her in the loop, since this will also affect States of Matter)

I just ran the test-server, and Atomic Interactions is failing the fuzz test. Looks like there are two separate errors:

Uncaught Error: Assertion failed: Segment start is infinite
Error: Assertion failed: Segment start is infinite
    at window.assertions.assertFunction (http://localhost/git-dev/assert/js/assert.js:22:13)
    at Subpath.inherit.addSegmentDirectly (http://localhost/git-dev/kite/js/util/Subpath.js?bust=1440178647924:103:39)
    at http://localhost/git-dev/kite/js/util/Subpath.js?bust=1440178647924:120:17
    at Function.St (http://localhost/git-dev/sherpa/lib/lodash-2.4.1.min.js?bust=1440178647924:23:149)
    at Subpath.inherit.addSegment (http://localhost/git-dev/kite/js/util/Subpath.js?bust=1440178647924:119:9)
    at ArrowShape.inherit.addSegmentAndBounds (http://localhost/git-dev/kite/js/Shape.js?bust=1440178647924:784:29)
    at ArrowShape.inherit.lineToPoint (http://localhost/git-dev/kite/js/Shape.js?bust=1440178647924:146:14)
    at ArrowShape.inherit.lineTo (http://localhost/git-dev/kite/js/Shape.js?bust=1440178647924:136:44)
    at http://localhost/git-dev/scenery-phet/js/ArrowShape.js?bust=1440178647924:82:19
    at Function.St (http://localhost/git-dev/sherpa/lib/lodash-2.4.1.min.js?bust=1440178647924:23:149)

and:

Uncaught TypeError: Cannot read property 'getPositionReference' of undefined
TypeError: Cannot read property 'getPositionReference' of undefined
    at DualAtomModel.inherit.updateForces (http://localhost/git-dev/states-of-matter/js/atomic-interactions/model/DualAtomModel.js?bust=1440178647924:533:46)
    at DualAtomModel.inherit.positionChanged (http://localhost/git-dev/states-of-matter/js/atomic-interactions/model/DualAtomModel.js?bust=1440178647924:501:16)
    at Array. (http://localhost/git-dev/states-of-matter/js/atomic-interactions/view/GrabbableParticleNode.js?bust=1440178647924:88:23)
    at Property.inherit._notifyObservers (http://localhost/git-dev/axon/js/Property.js?bust=1440178647924:112:29)
    at NeonAtom.inherit.setPosition (http://localhost/git-dev/states-of-matter/js/common/model/particle/StatesOfMatterAtom.js?bust=1440178647924:44:29)
    at Object.GrabbableParticleNode.addInputListener.SimpleDragHandler.drag (http://localhost/git-dev/states-of-matter/js/atomic-interactions/view/GrabbableParticleNode.js?bust=1440178647924:74:40)
    at Object.SimpleDragHandler.dragListener.move (http://localhost/git-dev/scenery/js/input/SimpleDragHandler.js?bust=1440178647924:123:27)
    at Input.inherit.dispatchToPointer (http://localhost/git-dev/scenery/js/input/Input.js?bust=1440178647924:798:29)
    at Input.inherit.dispatchEvent (http://localhost/git-dev/scenery/js/input/Input.js?bust=1440178647924:766:14)
    at Input.inherit.branchChangeEvents (http://localhost/git-dev/scenery/js/input/Input.js?bust=1440178647924:692:16)

The top menu is narrower than the Forces menu in the current version:

Please adjust the width of the top menu to match the spec by expanding the purple area (note alignment of both left and right edges), but do not move the radio buttons:

Projector mode looks exactly as we specified in the design doc, but some polishing could be done to significantly improve the look.

(1) Have the gradient of the moveable atoms fade out to transparent instead of to black (this might actually be best generalized to the original atoms on black background, so that fewer changes need to be made or redrawn when we switch between modes).

(2) Add black stroke border to the control menus at the right side.

(3) possibly change the color of the zoom controls [but this might eventually be fixed in https://github.com//issues/18]

I doubled the labels on the graph axes, to simulate translation to a different locale. Screenshot below of what it looks like. The placement of the labels is very obviously hardcoded for the English strings.

The pushpin looks more like it's floating on top of the atoms than pinning them, because the whole pin is visible (which looks great in the menu, but not great in context).

@arouinfar and I should probably discuss.

At small interaction strength, the touch areas on the graph for custom attraction settings become incredibly overlapped (both of the custom arrows, plus the bottom line (duplicates adjustment of interaction strength - we might consider amalgamating this with the vertical arrow control, rather than having duplicate controls that overlap), plus the graph marker indicating atom position).

We'll likely need to make a couple of changes to ameliorate this - the easiest first step will be to move the horizontal (atom diameter) adjustment arrow vertically upwards on the curve to avoid overlap.

Not sure what to do about the overlap between the graph 'dot' and the vertical adjustment arrows.

When the oxygen atom is moved in the Oxygen-Oxygen case, the behavior doesn't match the Java sim.

(1) When the moving atom is moved a very small distance, a "bond" vibration does correctly occur. BUT, the pinned (left) atom should only vibrate momentarily, and then it should stop. Only the moving (right) atom continues to vibrate back and forth.

(2) When the moving atom is moved even halfway up right side of the vertical part of the curve from a stationary position, often the atom escapes off-screen. Sometimes the return atom button appears AND THEN the atom returns in an instant and is "bonded" resulting in the expected vibrations. The distance moved to cause an escaped atom does not seem consistent, either.

(3) When bonded (and the moving atom is vibrating), the point on the graph fluctuates and jumps around much more than it did in the Java sim.

Steps to reproduce:

1. Drag the particle on the graph
2. Move it far to the left (the particle will be stuck at some point)
3. Move it to the right again. The particle will be far to the left of the mouse

Broken by #15.

atomic-interactions has no strings file and it's title is defined in states-of-matter. This causes the build tasks that generate README.md to fail. (And unclear how Rosetta will behave for a sim with no strings file.)

When you switch to the Oxygen-Oxygen pair, the marker showing the position of the moveable atom is not visible on the graph even when fully zoomed out, and it should be, just as it is for any other pair of atoms.

If needed, adjust the scaling of the vertical axis to make sure that the "dot" is visible on the graph when fully zoomed out.

Source-code directory structure for a 1-screen sim should look like this:

js/
 atomic-interactions/
    model/
    view/

There is an issue causing the atom to move slower than it should in the HTML5 sim (dev 3), even during "Normal" speed motion.

Details:
I originally thought this was due to the changed graph dimensions, but I compared the two sims by moving the Neon atom so that the two Neon atoms are just touching, and timed how long it took to return to this position once released.

The HTML5 sim takes roughly twice as much time to return to the same position.

@jbphet suggested I run the sim w/ the profiler parameter, and that seems to show 58-60 fps throughout the motion of the atom, so I don't think it's a performance issue.