Existing visualizations allow for displaying only a subset of the information potentially returned from APIs. There's also no pattern for extending interactive elements to individual data points, such as recasting LD coloring for data on the positions panel based on a selected point.
We should try to do this in the most general way possible but will need to preprogram our default instance to meet the needs of a specific use case (the Broad portal) to start. Overlaid info boxes should be built in HTML, not SVG, purely for the ease of working with text, links, and tabular data within them (example here).
Estimate
This feature will probably take about two weeks of development to build and test.
Dependencies
This depends on the completion of #30 which establishes a new serializable layout syntax. That syntax will allow for much more intuitive optional inclusion and customization of arbitrary "HTML modules" such as this feature.
Existing visualizations allow for displaying only a subset of the information potentially returned from APIs. There's also no pattern for extending interactive elements to individual data points, such as recasting LD coloring for data on the positions panel based on a selected point.
We should try to do this in the most general way possible but will need to preprogram our default instance to meet the needs of a specific use case (the Broad portal) to start. Overlaid info boxes should be built in HTML, not SVG, purely for the ease of working with text, links, and tabular data within them (example here).
Estimate
This feature will probably take about two weeks of development to build and test.
Dependencies
This depends on the completion of #30 which establishes a new serializable layout syntax. That syntax will allow for much more intuitive optional inclusion and customization of arbitrary "HTML modules" such as this feature.