Use-case specific interfaces ADR

[nerik]

From https://github.com/NASA-IMPACT/veda-architecture/issues/290

We have received feedback from EIS and MAAP scientists that generic data browsing is often not enough, and some simple custom features (interactive context, combining data) bring a lot of value in terms of making the data actionable for users for specific use cases such as fire incident analysis or biomass reporting.

The goal of this objective is to explore how scientists can create and publish optimised interactive interfaces for specific use cases.

We currently have two specific use cases for this:

• Custom vector visualization for EIS Fire Data, with two exploratory ad-hoc solutions:
  - Explore WASM for supporting users in creating interactive interfaces (and integration as a Story embed)
  - Proposal for a custom frontend implementation
• Plume dataset exploration

This is a ticket to lay down the different design and technical frontend decisions we'll have to make for this to be sustainable long term.

Where in the dashboard for the users?

1. As a custom version of the current Explore page?
2. As content of the dataset overview page?
   1. Could also live in a distinct tab
3. As a distinct Data Story
4. As its own distinct "Labs" section
5. Outside of the dashboard

We've pretty much already eliminated hypothesis NASA-IMPACT/veda-config#1 as there is already an ongoing refactor of this area of the website. Options 2, 3 and 4 would make use of the infrastructure already in place, especially rendering MDX blocks. Option 4 has been suggested to improve discoverability.

Where should use-case specific code live?

1. Within veda-ui
2. Within veda-config or other config instance
3. In another repo

The advantage of option 1 would be to facilitate the reuse of use-case-specific logic across several instances. There's no clear use case of sharing datasets across instances, however, one could easily assume that common behaviors could be shared (thinking of the marker + popup example).
Option 2 however would likely encourage faster iteration cycles as we don't have to worry about reusability or over-abstracting things. Having runnable code living inside a repo named *-config irks me a little bit but I guess it's already the case with MDX anyways.
We could always consider option 3 if very complex/very specific use cases arise.

API

How do we provide hooks into the VEDA ecosystem to develop fully custom experiences? One assumes here that potentially we (the team at DS) would not necessarily be the ones building the new features/experiences.

TBD

See:
https://github.com/NASA-IMPACT/veda-ui/blob/main/docs/content/PAGE_OVERRIDES.md
https://github.com/NASA-IMPACT/veda-ui/blob/main/docs/content/CUSTOM_PAGES.md

cc @danielfdsilva

[danielfdsilva]

After meeting with the team, this is our proposed approach to this problem:

Short term

The immediate short term approach relies on using embed blocks. Users will be able to create tools off of VEDA and then include them in stories.

Long term

The long term solution caters to more advanced use cases and it is geared towards developers.
These will be custom developed on a use-case basis using existing components or crafting new ones as needed (which can then be added to the veda-ui pool of components), and custom code.
The code for these interactive pieces will live in each instance of VEDA and will be able to be used in MDX documents (as blocks) or on custom pages.
The custom pages that can be created (option to the user) to host these custom visualizations will be collated under a common hub called tools (name pending). The tools hub will be accessible from the main navigation and will be instance specific. Each dataset overview page will link to the tools that are relevant to that dataset.