Rectangel Tools in front-end-monorepo

[ErikOstlund]

The purpose of this discussion is to get input from the team on how to create a RotatingRectangle tool and a TemporalRotatingRectangle tool in the front-end-monorepo.

Currently, the front-end-monorepo has a standard Rectangle tool. I will propose two methods to achieve this goal using the existing Rectangle tool. This certainly doesn't mean there are only two options. I am open to other ideas!

Option 1

Extend the Rectangle tool to a new RotatingRectangle tool. Then extend the RotatingRectangle tool to a new TemporalRotatingRectangle tool.
This would be done by following the pattern in this PR (extending the Point tool to a new TemporalPoint tool):
PR2099

This option will create two new Rectangle tools for a total of three Rectangle tools in the front-end-monorepo.

• Rectangle
• RotatingRectangle
• TemporalRotatingRectangle

This seems to be the cleanest and most intuitive approach because this option focuses on separation of concerns: each tool focuses on one thing and will create an 'easy to find' and 'easy to test' component/file structure.

This option would prevent sending unnecessary data to the api. Each tool would only send the parameters needed.

Rectangle Tool will send:

• details
• frame
• height
• toolIndex
• toolType
• width
• x_center
• y_center

RotatingRectangle Tool will send:
Same asRectangle but with this additional parameter

• angle

TemporalRotatingRectangle Tool will send:
Same asRotatingRectangle but with this additional parameter

• displayTime

Option 2

Note: This is an option I am looking for more input on. If people have strong opinions and feel this is the way to go, I'd like to know.

Add configurable flags to the Rectangle tool.
Could add a canRotate and displayTime flags.

I'm not sure how this will affect api calls. Will each tool always send all properties? If a Rectangle tool is used, will it have angle and displayTime properties?

I can see this approach being fine if we were just adding the RotatingRectangle tool, but we have to keep in mind that a TemporalRotatingRectangle is also being added. I'm worried code will get out of hand very quickly.

Separation of concerns is my biggest issue with this one.

Option 3

???

Thanks for reading and for your input!

[CKrawczyk]

For down-stream aggregation Option 1 is cleaner as rotating shapes are handled differently than non-rotating ones (the difference stems from how the "distance" between two angles is different than the "distance" between two points because angles wrap back around at 360 deg).

Also, the auto-configuration step for aggregation only works with the workflow data, and that is the step that needs to pick between the non-rotating extractor and the rotating extractor (as it is currently written), so having them be different tool types would require less reworking of how aggregation works with the data.

[srallen]

Good to know! I was curious about what your preference would be.

[srallen]

One option is that in the eventual new design for project builder workflow drawing task editor, we could represent it as just a configurable option in UI, but underlying set it up as a separate tool from the original rectangle tool in the workflow task object? Do we anticipate any other divergence between rectangle and rotating rectangle where having a fully separate editor would be of benefit or necessary?

Just thinking ahead: for the temporal versions, in the editor, those would be the only available drawing tools if the video player is selected I think? Do we eventually want to build and support temporal version of all the drawing tools or only a sub-set? @CKrawczyk do you have any thoughts on aggregation for the temporal drawing tools? @ErikOstlund can provide more details on its function, but currently there will be a string datetime time included with the drawing annotation that I think would need aggregation since there would be variation on when the volunteer hits pause and draws.

[CKrawczyk]

I also agree that the front-end can make this a single UI as long as it is stored with a different tool name on the workflow task object.

As for the temproal data, a timestamp along with the other data would be all aggregation needed, but just like with the rotating case, this would need to have is own extractor/reducer that propperly handles the aggregation (I don't know what this would look like, but I know it will be very different than the current reducers). As long as this is labeled as a different tool type on the workflow object aggregation will be able to send it along to the correct functions (when those functions exist).

[srallen]

Ok Option 1 sounds like it's the best pick for now, particularly because of downstream needs with the aggregation service. @ErikOstlund would you be up for writing an ADR about how we're keeping rotating rectangle separate and what the temporal drawing tools are?

[ErikOstlund]

Will do. 👍

[srallen]

Thanks!