Hollywooding the Gravity Vector Arrow

[AgustinVallejo]

Creating this issue to discuss how are we going to display the gravity force, as the actual values can be overwhelmingly small or big... Any precedent either visually or in the codebase?

[jonathanolson]

I'm not aware of a precedent personally (there might be one). Perhaps we could use something proportional to the scale of the arrow (if we don't just lengthen the arrow, but widen it too?) That might look bad too.

I think we've just... kept the arrows accurate, and sometimes they can be very long or short? I'm aware of cases where if an arrow is very short, we just omit it visually.

[AgustinVallejo]

I dont mind really long arrows, what's problematic according to the interviews is that in some presets the arrows are literally invisible because of how small they are, so they can give the false impression of an absence of gravity, and we certainly don't want that.

[jonathanolson]

Perhaps we could have a visual indicator for "small, off-scale, but still there"? Like the arrow goes semi-transparent, with a dashed outline?

[AgustinVallejo]

I'm thinking that the arrow could shift in size between normal values 1 to 10 arbitrary units, and bigger or smaller it could have a x10^3 or x10^-5 indicator... we could either use Newtons as units or just arbitrary units in which I guess 5 could be the default state, to better see increases and decreases.

What do you think? @DianaTavares @arouinfar

[samreid]

During today's meeting, it seemed the +/- buttons could change the arrow scale and it worked ok to solve that problem. @AgustinVallejo said there is also supposed to be a message at the bottom of the screen. We also found it awkward that you cannot see what the scale is by looking, but @AgustinVallejo said the design team didn't want to add another number. But maybe we can visualize the zoom level in another way? But it is not a linear scale, and we don't want to accidentally convey that it is.

[DianaTavares]

I hope that with the “Scale” name in the control, they understand that the vectors are just scaling and not that the force is increasing or decreasing.
An alternative is to add something like in waves, an arrow in the right upper corner of the play area when a force vector is active, showing the scale of the vector with a scientific notation, to include Newtons as the units:

[AgustinVallejo]

I really like that suggestion!

[AgustinVallejo]

In today's design meeting it was decided that a slider should be used.

[zepumph]

From today's design meeting:

For the scale slider:

• Make tick mark for each "10 to the X"
• Have the min and max be tick mark labels (just those 2
• Support i18n for scale and labels
• Use number control
• For slider keyboard steps: shift step +/-half of a 10 power, normal +/-10 power, pageup/down +/- 2 10 powers

For the text: horizontally centered, in the bottom of the play area, like this:

[AgustinVallejo]

This seems to be complete, assigning @DianaTavares for reviewing! Specially the position of the labels

[AgustinVallejo]

I have to add: The slider is currently free for any number but sticks back to 10^0 when you get close to it.

[arouinfar]

Here's what things currently look like in master normally and with stringTest=long

Here are the notes from discussion with @samreid @AgustinVallejo:

• The general slider strategy is good, and the layout has improved by moving the min/max labels to the tick marks.
• SR suggested we may need more cueing around the default value, especially since the thumb will snap there. We tried a variety of things.
  • Adding tick marks every order of magnitude with the same style as min/max ticks. This makes the values far more interpretable, and we liked this approach.
  • Adding tick marks every other order of magnitude. If the slider track gets shorter (and it likely will) this is a good alternative.
  • Making the 10^0 tick mark taller than the others. To make the tick style noticeably different, the minor tick marks end up very short.
  • Adding a 1 label to the 10^0 tick mark. It's a bit too close to the min label, and the slider track will likely get a bit shorter too.
  • Conclusion: At minimum, let's add tick marks every (or every other) order of magnitude, depending on how much horizontal space we end up with. Interviews will let us know if additional cueing is needed for the default value.
• The "Scale:" label looks very small. It is likely encountering its maxWidth and automatically shrinking. We would like to make more room for this label, and experimented with making the slider track shorter but did not have time to complete the pixel-polishing synchronously.

Since our meeting, I've reviewed things a bit more:

• We should consider increasing the width of the panels to alleviate the crowding issues with the "Scale:" label. We already allow them to get wider with stringTest=long, so we have room. Can we try splitting the difference between the current default width and the panel maxWidth?
• I think we can slightly reduce the slider track size without compromising usability. This may not be necessary if widening the panel a bit allows prevents "Scale:" from reaching its maxWidth.
• Let's definitely add tick marks to the slider. If we don't have to reduce the track length, let's add ticks for each order of magnitude. If we do have to reduce the track width, every other order of magnitude will be fine.
• The placement of the "Some force vectors are off-scale." warning looks off. It also fails stringTest=long and is occluded by the panel. Let's center it horizontally in the play area as shown in the mockup in Hollywooding the Gravity Vector Arrow #104 (comment). I think the string looks good at the top of the screen, so we can keep it there, just would like to see it properly centered.

[DianaTavares]

I had an interview today and I find this behavior strange:

• the text of "some forces vectors might be off scale" appears very soon for big vectors:

I think it needs to appear when the vectors get behind the panel or out of the view of the play area. In the example that I present, the vector goes out of the play area when it is moving (probably that is the reason of the text from the beginning). In that case, I recommend showing the text only when the vector is out, no matter that the text appears and disappears, but it is better that the user thinks that something is wrong with the vectors when he/she can see it, and the text appears.

• Conversely, the text does not appear when the vector is tiny. As soon as the vector is no longer visible, the text should appear.
  

[DianaTavares]

I also noticed in today's interview that the vectors, when they are huge, have a strange behavior. I took this screen shoot during the interview, where the vectors look fuzzy:

I tried to reproduce that on my computer, but I couldn't, in place I get what is displayed in this video (hope you can appreciate them. I reduce the velocity of the video):

some vectors just appear and disappear, and also looks like broken close to the mass panel:

I know that vectors this size are not useful for the learning. If that is difficult to fix, I think that just by adding to the text that information, that is enough. “Some force vectors might be off-scale and with the velocity of reproduction they can look fuzzy”.

[AgustinVallejo]

We had a brief design meeting today!

• Threshold of the offscale warning message was adjusted
• The message itself was changed
• It was decided to center the [returnBodies,message] container between the control panel and the zoomButtons.
• Change the default force scale for some of the presets

[AgustinVallejo]

This looks done! Please review and close if ready, @arouinfar

[arouinfar]

Thanks @AgustinVallejo, the layout looks great in master!