[FEATURE] Attributes Panel Updating

[BryonLewis]

Recreating the Track/Detection Attributes Panel for having the attributes be local to the dataset instead of a global version. This requires that user can create and modify the attributes that are used while working in the annotator instead of having to exit the annotator and go to settings.

Problems I noticed:

• Attributes panel was a brief stop in workflow where I would go to it and then typically go somewhere else to perform some action on the selected track.
• Attributes list could be long and require a bunch of scrolling to work properly.
• Types of attributes weren't known until you started editing them.
• Actual attributes are listed at the top of the screen for some reason above the editing area?
• We are going to need a way to add and edit attributes from within the annotator once the attributes are local to a dataset

Old Attributes

[BryonLewis]

Below is my initial prototype for an updated Attributes panel. It is not complete and there are several minor things that may change:

• The checkmark will obviously change to something else indicating the trackID and type color. I tried to use our standardized method of adding new items for track attributes and detections (they aren't hooked up yet).
• The settings icon per attribute I may hide and only be visible on hover. It's the way you can delete attributes from the dataset or modify the type.
• ConfidencePairs may have some editing to delete and add confidence pairs to the array (I don't know of a need for that right now so not worried about it). This would allow you to not only edit the top value in the array (the traditional way by changing the type) but specify what else is in the confidence array as well as removing/editing them. I assume that was the whole point about it being an array of values instead of a single tuple.
• I added the type as a hint to each item because it wasn't available before.
• My end goal is for there to be a Track view in the event/timeline area which gives a detailed view of the selected track. Annotation types at different frames as well as the ability to graph any set track/detection attributes. An aside to that is possibly adding the ability to visually represent track/detection attributes in the annotations using either geoJS 'markers' which are icons or text labels centered in the detection and colored base on user choice. That way attributes can be visualized outside of a single area.

[BryonLewis]

@subdavis - This is a much better format, good suggestion. See Issue description and first comment for the corresponding info.

[subdavis]

As a concept, I think this would be a huge improvement. I've been thinking about something exactly like this, so it's nice to have validation.

Here are some general questions:

• [UI/UX hat] I think the purpose of the tab is correct: the track, plus all the things you might want to edit about it. I think the layout will need a good amount of work, because that tab is a little hard to look at. Some more visual separation between the different parts would be good. I'm actually starting to think these thin gray lines just aren't good enough
• [UI/UX hat] When I first looked at this, i though "maybe a 3 column layout would be better, with the attributes on the right-hand side instead of in a "tab" behind the normal sidebar. Mostly just want to hear your thoughts, I don't have strong feelings.
• [Project management hat] This is cool, but this change isn't captured in your attributes overhaul design doc (I don't think). Is this necessary for that work, or just a quality of life improvement? Do you think this is important to do first?

I assume the attribute pane is now tightly coupled to a selectedTrackId -- this is a good change. Probably this pane should close if the track is unselected? Like, if I hit escape, you should go back to the regular sidebar?

My end goal is for there to be a Track view in the event/timeline area which gives a detailed view of the selected track. Annotation types at different frames as well as the ability to graph any set track/detection attributes. An aside to that is possibly adding the ability to visually represent track/detection attributes in the annotations using either geoJS 'markers' which are icons or text labels centered in the detection and colored base on user choice. That way attributes can be visualized outside of a single area.

I have a use case for this on MousePain, but it's pretty simple. Do you have one too?

If so, I'd encourage you to try implementing this as a consumer of the vue-media-annotator library in order to exercise the api surface and see how we're doing there. Maybe after we've done this a couple times, we can see what belongs in this project.

I'm hesitant to overgeneralize on this particular problem. I've done so in the past and regretted it. When doing visualizations like what you're describing, my customer has always wanted something really particular, so more power/burden on the library consumer I think is a good rule.

Tl;dr

This looks really great, I like the direction.

[BryonLewis]

Thanks again for looking this over.

[UI/UX hat] I think the purpose of the tab is correct: the track, plus all the things you might want to edit about it. I think the layout will need a good amount of work, because that tab is a little hard to look at. Some more visual separation between the different parts would be good. I'm actually starting to think these thin gray lines just aren't good enough

Agreed I just wanted a general feel so I could figure out where the corner cases could be or the limitations. I do feel like it is slightly cramped together and there are things that I've only toyed around with in my mind. Like confidencePairs should maybe be an expandable section if you really need to edit in the future but for phase one we don't have it there. I don't know if anyone has existing pipelines or data that contains multiple types.

[UI/UX hat] When I first looked at this, i though "maybe a 3 column layout would be better, with the attributes on the right-hand side instead of in a "tab" behind the normal sidebar. Mostly just want to hear your thoughts, I don't have strong feelings.

I've been wondering that but don't know when it gets too cramped? The third panel should be toggle-able with it hidden by default. I think we could use that third panel as a more general area if needed in the future for custom integrations or settings as well. These two issues may be something where we get the UX team involved and ask their opinion.

[Project management hat] This is cool, but this change isn't captured in your attributes overhaul design doc (I don't think). Is this necessary for that work, or just a quality of life improvement? Do you think this is important to do first?

I actually added a note section for brainstorming about this to that document first. I wanted to get feedback to make sure we were on the same page and then format that into a more formal plan about the procedure. I know we talked in length about the design before but it doesn't hurt to do check-ins to make sure we understand the plan.

Do you have one too?

No, but it seems like the natural evolution of a tool to visualize and create annotations. That's probably just remnants of being a tool creator for medical simulations. This would be a later phase after we get the sharing of track attributes and types complete because this would hook into the AnnotationLayers. I understand your points about overgeneralizing the data and I think we should consider the idea of enabling custom visualizations as a display option for attributes as well as some basic ones. Custom ones being developed in code and hooked in similar to your recipes (general idea, not the specifics). Giving a customer a basic starting concept can mentally place them in a state of thinking what works within the existing system and the minor modifications that can fit their needs instead of grandiose ideas. I've taken advantage of this before.

[BryonLewis]

I updated the Dev Document with a more detailed plan in which I lay out that I believe laying out the new UI while remaining connected to the /attribute endpoint will be beneficial before switching over to the metadata based version.

I also did some minor changes to the visualization because it just seemed too cluttered with the ability to set all those values when only needing to view them. There are still issues with spacing between the different sections, but I feel this updated ability to toggle into Edit mode (it's saved between selecting different tracks) makes it easier to have visualization as well as view all the attributes if you want to set data later.

The next step in this would be implementation of the editing/new dialog and figuring out solutions to deletion/updating existing items in the JSON file. That would then be followed by configuring it to use the metadata instead of the attribute endpoint.