Implement initial visual design

[brettfiedler]

This issue will be for creating this initial pass of the visual design

This pass includes: Dynamic lengths, angle guides, background color changes, checkbox controls for corner labels and angle guides.

To be covered still:

• Visual changes when achieving a parallelogram
• Visual changes during special parallelogram cases (all side lengths equal, all angles 90)
• Start up interaction hints

[brettfiedler]

I shared this design with JG and TS during the last virtual model meeting.

Mockups

Colors used (RGB)

Focus Pink shape: 250 51 141 Desaturated blue background: 167 167 255 Angle guide grey: 100 100 100

These colors are just riffs on the existing color scheme and are not set in stone.

Notable modifications

• [x] 1. Play area boundary slightly rounded at edges.
  • This can just be aesthetic since the vertices are also rounded with a larger corner radius.
• [x] 2. Background color changed from dark blue to a desaturated tone of the same blue.

Additions

Shape (Vertices and sides)

• [x] Add a shape with dynamic side segments and round vertices ("corners")

• Round vertex radius aligns with the pointer area.

Segments grow to a set length, then a new one begin to draw until it reaches the set length, and so on.

• Initial side segment width should be slightly smaller than the vertex radius (the current pointer area width for the side may need to increase to match). New segments step down slightly in width (like a telescoping antenna).
  • For reference, In the mockup I began with 0.9'' and stepped down in increments of 0.05'', so approx 5% width decrease.
  • We can also consider not stepping down and make all segments the same width. This will likely achieve the same effect with less emphasis.
• For the purposes of visualization, I think the first segment may need to be a bit longer so that it "looks" the same length as the other if it's starting at the center of the vertex. Open to other ideas!

Segment length will eventually depend on the number of "bins" needed to describe the side lengths relative to their opposite side. For now:

• Set the segment max length so that our initial square is two segments per side.

Angle guides

• [x] Add toggleable Angle Guides with checkbox in Control area

• Angle guides for rough visual comparison of angles

• A partial circle divided into 30 degree alternating colored pie slices is revealed in the interior of the shape at each angle.

• To make this work, the "zero degree" slice needs to lock to the largest segment of it's side as the shape is transformed. The guides will appear mirrored and flipped across the shape in this configuration, but the number of segments may be more important here. Perhaps we can try a completely color-free version ("outline") as well which will step around this issue.

• The guides can't actually be centered on the vertex otherwise not enough of the angle shows. It has to be centered where the interior of two sides intersect (which depends on their width). If we step down the length, the intersection is with the imaginary intersection of the first segment widths.

Corner labels

• [x] Draw labels on vertices with "Corner Labels" checkbox in control area

Labels center on the vertices. Currently labeled 1,2,3,4 from top left, clockwise which I believe matches the currently Voicing. This should change if the Voicing changes.

Control area

• [x] Checkboxes vertically centered with the play area

[brettfiedler]

Assigning @jessegreenberg to begin implementation! 🥳

I occasionally present a few other options for each feature that differ from the mockups - feel free to implement those instead if it is significantly easier and we can assess it at that point first.

Ping me here or in Slack for any questions that crop up ahead of design meeting.

[jessegreenberg]

Excellent! Collecting questions in this comment:

• [x] The vertices are going to be displayed circular but are square in the model (for hit detection with other sides and vertices). Is this OK?
• [x] Similar question for the sides and their tapered width. Sides have a defined width in the model for hit detection, is it OK that the taper is purely graphical?
• [x] If the side segments are based on the size of the vertex, they aren't really based on the model value for the side width (more of a code consideration). What if we made the side width larger so that the initial side segment matches the model value for the side width.
• [x] >For the purposes of visualization, I think the first segment may need to be a bit longer...While playing with it it didn't seem necessary, but we can certainly do something like this.
• [x] At 5% taper per segment the sides can get very slim when the sides are stretched all the way across the play area.

[brettfiedler]

Responses as of 2/14:

Excellent! Collecting questions in this comment:

• [x] The vertices are going to be displayed circular but are square in the model (for hit detection with other sides and vertices). Is this OK?
• [x] Similar question for the sides and their tapered width. Sides have a defined width in the model for hit detection, is it OK that the taper is purely graphical?

Yeah, I expected both of these!

• [x] If the side segments are based on the size of the vertex, they aren't really based on the model value for the side width (more of a code consideration). What if we made the side width larger so that the initial side segment matches the model value for the side width.

This is probably fine. As long as the vertex grab takes precedence (is in "front"). I just don't think we'll want the grabbable area of the side to exceed the vertex width.

• [x] >For the purposes of visualization, I think the first segment may need to be a bit longer...While playing with it it didn't seem necessary, but we can certainly do something like this.

Yeah, I suppose that feels true here after playing with it.

• [x] At 5% taper per segment the sides can get very slim when the sides are stretched all the way across the play area.

It does. I'm not sure if that's a problem yet. Let's go ahead and retain the hit detection and pointer area for drag even with the small width and see how that feels for now.

[brettfiedler]

For archival purposes, the appearance I played with in answering the above:

[jessegreenberg]

Discussed some points wiht @BLFiedler

• [x] To get around issues of side occlusion and angle difference from side taper, we are going to center the arcs of the angle guide on each vertex. The guide will be a "donut" around each vertex so that the vertex itself and the corner labels are not occluded.
• [x] It IS important that the angle guides rotate with the shape. To accomplish this the starting angle of the guide will be locked to the one of the side segments(largest one).
• [x] The model width for sides should be constant across the length, ignoring taper. Mouse/touch areas should match model width and ignore taper.

[jessegreenberg]

OK, I think what is described in this issue has been implemented, including the angle guides and notes in https://github.com/phetsims/quadrilateral/issues/60#issuecomment-1039308535. Mouse/touch areas for sides can be verified again with ?showPointerAreas.

This is ready for your review @BLFiedler .

[brettfiedler]

Changes to current visual design

• [x] Cut angle guide radius in half to see if it diminishes the visual overlap when making a small shape
• [x] Change corner labels 1,2,3,4 to A,B,C,D (this supports at least internally naming sides by lowercase and less confusing to define angle names ( angle412 vs angle DAB)
• [x] Change shape color to gold (RGB 255 217 102 in mockup below) to move away from Focus Highlight pink.

Additions to current visual design

• [x] Change shape color to something else when the shape is a parallelogram. Let's go for a bright green (RGB 21 255 127?

• [x] Draw a transparent square at the corners to indicate whenever 90 degrees for all angles has been achieved (rectangle or square). If angle guides are checked, replace them with this square. (NOTE: we may want to find a way to keep the angle guides in so the three 30 degree marks are still apparent for anyone unfamiliar with 90 = square) ^^^^^ Rectangle case on left, square on right ^^^^^

• [x] Increase the outline width (maybe double?) of the segments when all side lengths are equal (rhombus or square). Let's try only doing this to the segments and not the vertices at first.

Once all of these are in along with their sounds, it's time to decide what needs to be smoothed, tweaked, or altogether eliminated...

[brettfiedler]

• [x] Eliminate the taper on the side lengths but maintain the segments and telescoping effect.

This is to address the fact that the shape stops looking like a shape and introduces asymmetry. Also, it will bring the visuals in line with the pointer areas.

[jessegreenberg]

OK I think I am caught up to spec here. Ready for review. Just noting some things that may or may not be important.

1) Without the taper there isn't a need for custom mouse/touch areas. The sides are the touch areas and you won't see a unique highlight with ?showPointerAreas. 2) If the angle guides are invisible when at right angle, the "Angle Guides" checkbox does nothing if pressed on sim startup. 3) There are oddities going on because all of the angle checks here use the same angleToleranceInterval as the one used to determine if it is a parallelogram. So there are cases currently where right angle indicators are displayed when the model thinks we are not a parallelogram.

[jessegreenberg]

For #3 above, @BLFiedler suggested on slack

We can either gate it within being a parallelogram or tighten the 90 tolerance. I'm leaning toward the latter though.

Ill add another tolerance variable just for the 90 degree indicators and see how it goes.

[jessegreenberg]

I added a new tolerance that controls when right angle indicators are displayed. Can be controlled with ?rightAngleIndicatorToleranceInterval. Default value is 0.025. This value does not change with input like the angleToleranceInterval.

OK assigning to @BLFiedler to review the last three comments and the current behavior of the simulation.

[brettfiedler]

One note on the implementation of the right angle markers - The right angles should only appear when ALL angles are right angles. The intention is to highlight the property of a square/rectangle is important, not that a particular angle is 90 degrees.

Had a long discussion with Taliesin on these and other scaffolding topics, but I'll keep thinking about the meshing of tolerance for parallelogram and the markers.

[jessegreenberg]

I see, sorry I misread that. Fixed in the above commit. With this behavior I think there may not be a tolerance issue anymore. Now the right angle indicators can only be visible if the shape is a square or rectangle. And we can only have square or rectangle if the model is in a parallelogram state. rightAngleIndicatorToleranceInterval is no longer used. Back to @BLFiedler for review.

[brettfiedler]

Visual tweaks are ongoing in other issues.