[FEATURE] Ability to create activity groups.

[subdavis]

trafficstars

Roadmap

Activity groups will be introduced in DIVE version 1.9

• [x] Design schema. Done in #1045
• [x] Implement schema and playback. Done in #1205
• [ ] Implement full web kpf support. In progress in #1235
• [ ] Implement full desktop kfp support. Parser is done, needs to be hooked up to the UI.
• [x] Implement activity group creation and editing. Done in #1237
• [ ] Finish activity group creation, editing, deletion. #1238

Releases

• https://github.com/Kitware/dive/releases/tag/1.9.0-beta.1
• https://github.com/Kitware/dive/releases/tag/1.9.0-beta.2

[waxlamp]

Probably needs a design doc.

[subdavis]

Design documentation

We can't work on implementation until MultiCam is settled. Possibly we should backburner this.

Enumeration of features

This feature is for general-purpose temporal groupings. These can be interpreted as "activities" or any other semantic group.

• Groups are created by choosing 1 or more track members. A group may not exist without members.
• Like tracks, groups have confidencePairs and attributes. As a first pass, only the type will be editable. Later, we will make the attribute editor work for groups.
• At the time of group creation, the user may choose to define bounds on the group. By default, groups will have undefined bounds, and their start and end time will be the extremes of their composite track start and end times.
• No bounds rules will be enforced. For example, non-time-overlapping tracks may be added to a group. A group may be restricted to a time interval where none of its composite members actually exist. We can "warn" about these types of discrepancies in the group editor modal, but I don't think it's feasible to logically restrict behavior, there are too many edge cases. For example, if a group is defined for 10-20 and then a member track is edited to no longer exist in that time region, what should happen.
• Tracks can be involved in activities for sub-regions of those activities. These bounds might be enforced to at least exist within the defined bounds of the group (if set), I'm not sure yet. A likely outcome is that the bounds are enforced based on the known track/group bounds at the time of creation, but after editing a track, the bounds can become broken, which won't be clear to the user until they open the group editor modal again.

Group List UI

• Groups will be initially created using the merge UI. This will become a more general-purpose multi-select UI.
• Tracks can be added to existing groups somehow, I'm not sure yet, but I think it will be an option on the group and not the track.

Group list UI Location:

• Option 1: Contextual view. Use the contextual right sidebar (like the advanced confidence thresholds) to house the group UI.
• Option 2: Tabbed view. Put tabs into the left sidebar for toggling between tracks and groups. This is sorta not ideal because it won't let you see your groups and the multi-select UI at the same time.

[waxlamp]

@waxlamp, @marySalvi, @BryonLewis: please provide questions/thoughts about Brandon's design.

[waxlamp]

This seems like a reasonable design. I don't understand enough about how this is supposed to work to comment on the UI design, but I think the unconstrained temporality is a good model for capturing the essence of a group. And I agree that "activity group" will fit into this generic model quite easily.