Text overlap when applied force changes direction (Friction)

ghost commented 7 years ago

Test device:

MacBook Air (13-inch, Early 2015)

Operating System:

macOS Sierra 10.12.4

Browser:

Safari 10.1

Problem description:

In the Simulation wrapper, a text overlap will occur if the Forces box and the Values box in the Friction screen are checked, the masses are moving fairly quickly, and suddenly force is applied in the direction opposite the movement of the masses. Discovered while testing phetsims/QA/issues/42. I checked the published version; the overlapping occurs in it as well.

Steps to reproduce:

Add two crates.
Increase applied force to maximum.
Once the crates are traveling at 40 m/s, apply force in the direction opposite the movement.
Notice how the text "Applied Force" overlaps with the value for the Friction Force just as the direction of the applied force changes.

Screenshots: screen shot 2017-08-24 at 4 26 23 pm

Troubleshooting information (do not edit): Name: ‪Forces and Motion: Basics‬ URL: https://phet.colorado.edu/sims/html/forces-and-motion-basics/latest/forces-and-motion-basics_en.html Version: 2.1.4 2017-08-15 08:05:23 UTC Features missing: touch User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30 Language: en-US Window: 1440x736 Pixel Ratio: 1/1 WebGL: WebGL 1.0 (2.1 INTEL-10.24.45) GLSL: WebGL GLSL ES 1.0 (1.20) Vendor: WebKit (WebKit WebGL) Vertex: attribs: 16 varying: 15 uniform: 1024 Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 16) Max viewport: 16384x16384 OES_texture_float: true Dependencies JSON: {"assert":{"sha":"7d27130a","branch":"HEAD"},"axon":{"sha":"e0192608","branch":"HEAD"},"babel":{"sha":"1e0ba48a","branch":"master"},"brand":{"sha":"853b3b17","branch":"HEAD"},"chipper":{"sha":"07058555","branch":"HEAD"},"dot":{"sha":"39436598","branch":"HEAD"},"forces-and-motion-basics":{"sha":"679f2e0b","branch":"HEAD"},"joist":{"sha":"65cda5ee","branch":"HEAD"},"kite":{"sha":"73302899","branch":"HEAD"},"phet-core":{"sha":"c48bf320","branch":"HEAD"},"phetcommon":{"sha":"7bad0484","branch":"HEAD"},"query-string-machine":{"sha":"05231e54","branch":"HEAD"},"scenery":{"sha":"182dae83","branch":"HEAD"},"scenery-phet":{"sha":"f0fc9ae8","branch":"HEAD"},"sherpa":{"sha":"bcc28cd6","branch":"HEAD"},"sun":{"sha":"f2bd9d60","branch":"HEAD"},"tandem":{"sha":"200263ae","branch":"HEAD"},"vibe":{"sha":"0b1c33f9","branch":"HEAD"}}

jessegreenberg commented 7 years ago

Thanks @lmulhall-phet. It looks like this issue is not specific to this version. @arouinfar @ariel-phet can you please advise on whether or not this should be fixed and what the fix to the layout should be?

arouinfar commented 7 years ago

Looks like the label location depends on the the arrow size and proximity to other labels.

(1) When there's enough room, the magnitude is inside of the arrow.

(2) The magnitude moves below "Applied Force" when the arrow becomes too small.

(3) When the vectors in are in the same direction, the "Friction Force" is bumped below the arrow, and there's generally occlusion issues with at least one of the values. screen shot 2017-08-24 at 10 52 21 pm screen shot 2017-08-24 at 10 30 36 pm

Perhaps when the forces are in the same direction, it'd be best to always display the magnitude of the force below the force name, as with the "Applied Force" in the scenario (2). That way the strings/values would never collide.

jessegreenberg commented 7 years ago

Thanks @arouinfar, that is a good idea, here is what that looks like capture2

We could also alilgn horizontally to give the mass a little space: capture

arouinfar commented 7 years ago

@jessegreenberg I really like the 2nd screenshot in https://github.com/phetsims/forces-and-motion-basics/issues/245#issuecomment-324989181 with the magnitude of the Friction Force next to the string.

arouinfar commented 7 years ago

I took a look at master, and it looks like you went with the 2nd option. Overall, looks good, but we'll need to also handle cases like this:

jessegreenberg commented 7 years ago

It looks like this was handled before by switching the layering order of the friction and applied force arrows so the readout of the friction force could be seen while the value of applied force could be inferred by relative size. If the applied force arrow is always on top, will that fix the problem? That would be the easiest solution.

jessegreenberg commented 7 years ago

All text is visible but it looks a little weird. capture