Design draft: Alternative annotation list interface

[fcollman]

This is an alternative design to #1044 about how to handle the display of the annotation properties across the list based on trying to reuse the visual metaphors from the segment properties.

here's another screenshot showing a filter, and sorting applied and expanding the hidden filter menus

Here the annotation list gets a query box to filter the annotations, and there is the tag like interface for categorical variables, and the numerical filters for numerical features. Both are collapsable so that you can have more vertical room for viewing annotations once you get your query setup.

Some differences, is that I wanted to be able to put the categorical variables into the list as columns so you could sort them easily, but wanted to minimize the vertical space. Here the property names are clickable in the tag search interface to allow them to be added/removed as columns. The columns can be sorted.

also, once you enter a query, and it filters the list, only the annotations that meet the query are rendered in the cross section views, so you can see the visual impact and correlations of the query more easily. The shader of course would let you do this as well, but less dynamically and with more coding.

[chrisj]

I think query affecting visibility should be shared with segment list if we want it. Ideally as much common behavior as possible. Probably a viability toggle. The delete takes the place of starring.

Being able to toggle display of position could be valuable for saving space, especially with rich annotation properties

[fcollman]

I think query affecting visibility should be shared with segment list if we want it. Ideally as much common behavior as possible. Probably a viability toggle. The delete takes the place of starring.

Being able to toggle display of position could be valuable for saving space, especially with rich annotation properties

what is a "viability" toggle. Do you want to extend the "starred" annotation model where we have two annotation lists? one for querying and one for selection? I think that will be very challenging in the vertical space we have.

or do you think we just shouldn't have it affect visibility? Or you just mean that we should just make it an option whether or not being in the filter query causes you to be visible/invisible?

we could make the visibility a property available to the shader to make it possible to write shaders that would have this property.. but i think in practice nobody would do that so it wouldn't be a very used feature.

[fcollman]

since the initial PR i added coordinates as numerical properties and annotation types as categorical properties. I can make the checking/unchecking of the coordinates add/remove them from the annotation table view, but have them all checked by default.

[chrisj]

Maybe we should keep the behavior separate as there are different needs between annotations/segments. A design discussion would be great. My primary thought is that if the UI looks similar, it should behave similar

[syamace-metacell]

@fcollman @chrisj from a design perspective, this alternative version is typically what users would expect with a rich data table (+ sort/filter capabilities) but considering the limited space and Neuroglancer's existing patterns, I'm not 100% convinced of this version. This would introduce a new design pattern, which isn't necessarily a bad thing and one that I think will scale well with the skeleton tab (though there's some alignment work to be done there if we do proceed with this).

My initial thought was #1044 covers the use cases while keeping additions to existing patterns small, but the difference between the two that I see that's making me reconsider this version is that this allows for numerical filters and right now, I don't see a neat way of doing it with #1044 (besides just text in the query box).

In terms of alignment with segmentation tab, I think it's okay that the annotation tab is different. The way I look at it right now is that annotation has more properties to filter by and it would seem like an overkill if we add the same to seg. tab.

Overall, the version in #1044 keeps it minimal (also added a comment there), while #1048 allows for more flexibility and room for scale around filtering properties (which again, will scale well with the skeleton tab). Personally, I'd prefer this for scalability but it depends on much we want to add to exisiting patterns/introduce new ones.