List of Features

[aboydnw]

Context

Just noting down a running list of components that we are planning to build as a part of the refactor.

1. Does this list already exist somewhere? (besides this miro board)
2. Should this live within a wiki somewhere?

List of Components/Features

Core VEDA Features:

1. Data catalog (catalog w/list view for more metadata)
2. E&A (time-series generation tool) (includes layer selection, time-series chart panel, and map)
3. Story catalog (catalog w/visual layout)
4. Stories mdx components?
5. (Future) 3D visualization tool
6. (Future) Widget component

Building Blocks:

1. Basic map block
2. Information cards (on home page, story catalog, etc)
3. Generic chart component (time-series, bar, pie, etc?)
4. Date picker
5. Announcements banner
6. Cookie consent form (future)

Layout Components:

1. Page header
2. Navigation
3. Footer

Custom Instance Features:

1. Featured Content Carousel (GHG)
2. Video Carousel (EIC)
3. Point selection map w/metadata (urban data map on GHG)
4. Event explorer (methane plume data explorer on GHG)
5. Globe video visualization (EIC)

[faustoperez]

I think this is exactly the next step design-wise.

I propose to create an agnostic vanilla template instance using USWDS in which we include the different components that VEDA supports. I see two benefits:

• DS team builds the library towards a common goal
• Impact team can use a shared language to make proposals and modify instances

[aboydnw]

I agree @faustoperez (after R3 ongoing right now)
Is that work covered by this ticket? #998

Also, what do you think of the list I compiled? Feel free to edit it directly. Do you think it is about the right level of detail to define a component? Anything missing?

[faustoperez]

It is covered by #998. I will resume this work and complete your component list after R3 👍

[aboydnw]

@sandrahoang686 @hanbyul-here @dzole0311 here is the components ticket that we discussed during sprint planning today, feel free to drop in your thoughts as we align our thinking on what is a core feature/component and what is something more flexible on the instance side

[sandrahoang686]

Core feature components as I've discussed very early on in the planning of the refactor and as the ADR talks a little about here are key product features within the VEDA dashboard. Instead of thinking of strictly pre-defined pages -> we move to thinking of the VEDA dashboard as core features we deliver (E&A page, Data Catalog, Data Stories, etc..). These are core features that are developed and maintained on the veda-ui/core library side and any updates to these features would affect all instances. Product and Design should define what these "Core" features are... but have for the most part been identified in the miro board linked in this issue. These are currently using the devseed DS library and i'm guessing we would slowly be phasing them out at some point? Or until these core features are re-envisioned? (Core feature components are also made up of smaller presentational components talked about below.. for example E&A feature has the datepicker component)

• Other components (presentational) in veda-ui that are not "Core Features" for example the banner component or the datepicker exist in veda-ui and can be used across instances. These are just reuseable components we already have and can support if we want them to be available across instances. Instances can of course bring their own presentational components if they'd like though.. (caution, if they'd like to bring their own datepicker per say though, it would clash with the date pickers in our core features, a risk they'd assume on their end, many presentational components are part of USWDS already as well..)

Layout components are anything related to a site's layout across various pages/views. For example, Header, Footer, Navigation, Sidebar, etc.. These are things we can expose from veda-ui side since we already have them built but could also be overridden on the instance side if they wanted to bring their own layout (we already do this in some of the instances with the override configurability, see ghg custom page footer here).. bringing their own layout component will require them to figure out how it lays out in the larger layout with core feature components but thats a problem to be deferred to later. Layout should be dictated instance side but the template instance would have layout already built in and out of the box, possibly** exposed from veda-ui side like how we currently do it with devseed ui theme library here.

Custom Instance Components are components that are specific to an instance and can be compared to an instance's override components like EIC's video carousel. These are components that are not a core feature of the veda dashboard product but instead are just custom wants and features stakeholders want as part of their specific dashboard. The Carousel for GHG as part of R3 is an example as well. These should be built instance side.

This doesn't hard list out all the components but I was hoping to explain the differences between types of components to help when thinking about designing the template instance. When designing the template instance, I would caution against redesigning our core featues like E&A entirely with USWDS unless we would like to update a presentational component within a core feature... like how we did with the datepicker... @aboydnw @faustoperez

[aboydnw]

Thank you for the detailed thoughts @sandrahoang686 🙌

I adjusted the original comment to hopefully better reflect this thinking. I broke things out into 4 groups:

1. Composite Features (what we've been referring to as "core")
2. Building Blocks (what you referred to as "other components")
3. Layout Components
4. Custom Instance Features

I like the idea that when somebody uses a composite feature, it comes largely as-is (with whatever flexibility we have built into the feature itself)

But then they could use these "building blocks" to create their own custom features, like GHG is doing right now with the urban data map. Then, at least we are providing a way for instances to create their own features without having to start from scratch and work too hard to match look and feel.

Then the layout components are the layout components as you described

And custom instance features are ones that we monitor to potentially become composite features within VEDA. For example, if everybody wants a point-data explorer like GHG is making for urban data, we should then look to bring it back in as a composite feature within VEDA

If you all agree with this grouping, then did I get down all the right features/components? It would be good to keep a running list active, both for ourselves and the instance owners.

[aboydnw]

Summarizing our discussion during standup today:

1. Our initial focus for the refactor work will be on the composite features, as these are the core of what makes the VEDA Dashboard, and the things we know we want to expose to instances for them to use. Then, we might expose layout components.
2. Only after that will we move to exposing building blocks, and that might be a little bit based on the needs of instances, like if GHG needs the announcements banner exposed so they can do some customizations.
3. The custom instance features is more a list for us to monitor to see if there are common use cases across instances, and that might drive core feature development in the future. But, not something we are actively targeting for the refactor work.
4. The long term idea for this list is to become the "menu" of available features and components that instances managers and developers can use to build their dashboards.

I will use this list to create backlog items for the team, and our next step will be the E&A feature. As we go along, we should continuously update this list, and consider moving it to a more permanent, visible location for others to see.

[aboydnw]

Posting a comment here since I don't have a better place to put this at the moment. Here are my thoughts on an MVP for the template instance.

MVP Template Instance

1. Everything will either be core features or necessary layout components
2. Wherever possible, we will use USWDS components and styling (with expected exceptions being in core features/tools already built)

Content Units

• Data:
  • Some subset of gridded raster data currently available in Earthdata instance (probably known entities like NO2?)
• Tools:
  • E&A / time series generator
• Widgets:
  • Only existing widgets available on pages rendered through MDX
• Pages:
  • Homepage, with info/links to how to use the template instance
  • Data Catalog
  • Stories Catalog
  • Dataset overviews for selected data
  • Stories for selected data

Additional Layout Components:

• Nav
• Header
• Footer

Not Included:

• Custom features from instances such as carousel, plume explorer, point data explorer
• Widget catalog or advancing the capabilities of existing widgets

@sandrahoang686 @faustoperez does that help at all? Is that already what you all had in mind for the template instance?

[sandrahoang686]

I think this makes alot of sense for MVP sounds like we are going to do what we can mostly with what we have which is great and then using USWDS for layout and theming without touch more of the core features 👍🏼