Add "arrow" representation for object

[pixelzoom]

While we're thinking about final design considerations for the public version of this sim...

Over in #217 (comment), I said:

• It's difficult to add additional representations. For example, it will be difficult (impossible?) to support the classic "arrow" representation for the Object , like this example from Wikipedia:

In this representation, the arrow's tail is anchored to the optical axis. The arrow can be resized and translated along the optical axis. This representation has come up several time in design meetings.

So... Do you want to add the "arrow" representation for the object? (If there's a standard name for this representation, please chime in.) Since I'm planning to restructure things for #217, this would be the time to do it. But please think through the design implications. The arrow is very different than the other objects, because it can't be dragged freely, it's tail is anchored to the optical axis. The arrow can be resized (by dragging its tip up/down) or translated along the optical axis.

I don't know how difficult this will be. It will probably add ~20-40 hours to my original estimate. It will certainly be more expensive if we ignore it now and try to add it in the future.

[ariel-phet]

To me the sim feels incomplete without this representation. When we teach optics and the imaging equation, this is the representation we use. If I were a teacher using the sim, it is a request I would make to PhET. That is my personal opinion, but there are obviously various priorities on the project to balance. The sim is certainly still very valuable without this representation, but I do think it would be worth the effort.

[pixelzoom]

@ariel-phet said:

... When we teach optics and the imaging equation, this is the representation we use. ...

As someone who has recently come up to speed on this domain, I'll mention that this was indeed the representation that was used in the majority of web-based resources that I consulted.

[pixelzoom]

10/21/2021 design meeting: @arouinfar @kathy-phet @ariel-phet

• Yes, support arrow representation
• Arrows should be reflect-able about the optical axis, and have a minimum height.
• All things in the combo box will share a common position. If the position is too close to the optical axis when arrow is selected, the arrow will resize to its minimum height.
• When "Second Point" is checked, add a second arrow.
• Add the arrow to combo box for Lens and Mirror screens.

[pixelzoom]

Use dashed outline for virtual image arrow.

Vector addition arrows are a good first start for the "look".

[pixelzoom]

From 12/20/21 meeting notes in design doc:

What should we call the arrow/vector representation?

“Vector” is too complicated for the audience and overloaded. Textbooks usually just refer to it as the “Object” but naming it by its appearance “Arrow” is most natural.

[pixelzoom]

From #228 (comment):

All things in the combo box will share a common position. If the position is too close to the optical axis when arrow is selected, the arrow will resize to its minimum height.

I discussed this with @arouinfar, and we decided to modify this decision. The new structure of the sim will be divided into 3 scenes: framed object, arrows, light sources. The draggable thing (object or light source) in each scene will have a position, but position will not be shared across scenes.

This will prevent weird interactions like having to move a framed object because an arrow is too close to the optical axis.

[pixelzoom]

Vector addition arrows are a good first start for the "look".

ArrowNode options in vector-addition are:

const VECTOR_ARROW_OPTIONS = {
  headWidth: 12,
  headHeight: 14,
  tailWidth: 3.5,
  stroke: null,
  isHeadDynamic: true,
  fractionalHeadHeight: 0.5
};

[pixelzoom]

• Min arrow length is 20 cm. Dragging is not constrained to this min. When dragging ends, the arrow snaps to its min length. (Be sure to test with keyboard!)

I'm wondering if this is the right thing to do. It's possible to set the arrow length to < 20 cm via PhET-iO/Studio, and it will not snap to 20 cm. I also need to add better handling for the case where the arrow length is zero while dragging, because that's going to cause problems with scaling.

[arouinfar]

@pixelzoom I'm really loving the arrow scene. Your comments in #228 (comment) all sound reasonable to me, though I did notice one bug.

Drag-lock feature works for arrows. If you want to lock to a specific arrow length, press the drag-lock toggle button.

This is currently broken in master. I can still change the arrow height (with mouse and keyboard) when in the horizontal-only mode.

• Min arrow length is 20 cm. Dragging is not constrained to this min. When dragging ends, the arrow snaps to its min length. (Be sure to test with keyboard!)

I'm wondering if this is the right thing to do. It's possible to set the arrow length to < 20 cm via PhET-iO/Studio, and it will not snap to 20 cm. I also need to add better handling for the case where the arrow length is zero while dragging, because that's going to cause problems with scaling.

I don't think there's anything fundamentally wrong with an arrow height < 20 cm (so long as it is a non-zero value). This seems similar to the discussion we had in last week's PhET-iO meeting about not enforcing constrainValue for Studio data entry. If a client sets the height to 10 cm, I don't think it needs to snap back to 20 cm.

[pixelzoom]

This is currently broken in master. I can still change the arrow height (with mouse and keyboard) when in the horizontal-only mode.

Whoopsie. Fixed in master. I won't make you review it again. Closing.

[pixelzoom]

Reopening. @ariel-phet noted that the drag bounds are incorrect. The arrow can currently be dragged through (and to the right of) the optic.

[ariel-phet]

Discussed with @pixelzoom and @arouinfar and made some changes. We made modifications that make this representation more like the representation commonly seen in ray diagrams.

• The arrow now has a thin tail
• The magnitude of the arrow scales (but the tail does not get thinner or thicker)

Since the arrow is meant to be more of a 1d representation the current implementation now better reflects that idea.

[pixelzoom]

Changes discussed with @ariel-phet and @arouinfar were completed in ba4ca49. One remaining change is being tracked in #312 (separate opacity range for arrow).

This feature is schedule for review at 2/17 design meeting, so I'll leave it open until that's been done.

[pixelzoom]

2/17/22 design meeting:

Reorder the combo box as follows:

Pencil (default)
Penguin
Arrow
Light

Delete the Planet and Star objects (enumeration values, images, strings).

[pixelzoom]

Change requests from #228 (comment) have been completed. @arouinfar please review, feel free to close.

[arouinfar]

Thanks @pixelzoom. I reviewed in Studio to make sure the Planet & Star were also gone from the tree/enum. Everything looks good.