Open aboydnw opened 1 month ago
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:
I agree @faustoperez (after R3 ongoing right now) Is that work covered by this ticket? https://github.com/NASA-IMPACT/veda-ui/issues/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?
It is covered by #998. I will resume this work and complete your component list after R3 👍
@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
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)
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
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:
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.
Summarizing our discussion during standup today:
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.
Context
Just noting down a running list of components that we are planning to build as a part of the refactor.
List of Components/Features
VEDA Features:
Building Blocks:
Layout Components:
Custom Instance Features: