Repository navigation
MVP list of components #2
Description
Activity
I think the truth is, this effort is not one where value comes from completion, rather there is a quite modest threshold of components where the benefits of using this as a foundation dwarfs the benefits of not using it, or using a more closed-ecosystem approach.
I would use this today -- and contribute to it -- if it was stable and came with ten solid components. I know I would have to build the next ten myself, but I would take comfort in knowing that this will be the last time I do.
@bradfrost can you please provide the MVP
@JensRoland 100% completely agree and I appreciate the insigths. Any change you have a short-list that you would pull this in and use it?
I'm hoping that based on Brad's experience will provide us with a short list that when he's doing his contracting he would recommend using this.
@cellar-door that said, do you have a MVP of components that will need to exist for your scenario to adopt it?
Asking co-pilot I get the following categories that seem to overlap.
Buttons: Essential for user interactions, buttons come in various styles and functionalities.
Forms: Including input fields, checkboxes, radio buttons, and dropdowns for collecting user data.
Modals/Dialogs: Used for displaying content in a layer above the main page.
Navigation: Components like menus, tabs, and breadcrumbs to help users navigate the application.
Cards: Used to display content in a concise and organized manner.
Tables: For displaying data in a tabular format.
Alerts/Notifications: To inform users about important information or actions.
Icons: Visual symbols to enhance the user interface.
Grids/Layouts: For arranging content in a structured manner.
Tooltips: Small pop-ups that provide additional information when hovering over an element.I would like to avoid any type of layout components early on. Additionally, I'd personally prefer to avoid any form or table components in the Alpha variant. So this would narrow the MVP list down to:
- Buttons: Essential for user interactions, buttons come in various styles and functionalities.
- Modals/Dialogs: Used for displaying content in a layer above the main page.
- Navigation: Components like menus, tabs, and breadcrumbs to help users navigate the application.
- Cards: Used to display content in a concise and organized manner.
- Alerts/Notifications: To inform users about important information or actions.
- Icons: Visual symbols to enhance the user interface.
- Tooltips: Small pop-ups that provide additional information when hovering over an element.
I know that "buttons" can fall into the "forms" category but they will be necessary for modals/dialogs, tooltips and possibly navigation depending on the scenario.
I think it's important to re-iterate that where possible we will utilize the platform. So while there is a
buttonanddialogelements this isn't saying that those may not be re-used in proposals. That said, if they aren't used this may highlight gaps in the platform so we don't necessarily want to discourage it unless there is reasoning.What about form controls like
- Password input (with a button to reveal the password in plain text)
- Checkbox (with customisable checkmark/indeterminate line)
- Radio button (with customisable dot)
- Switch (with customisable track/handle content)
- Spin button (with plus/minus button controls)
I do acknowledge that form controls are trickier to implement that other components, but they might provide nice precursors to standardised styleable form controls.
I may be alone in this preference, but why not start by styling what's already in HTML? table, button, input, select, fieldset, label, dialog, list, figure (responsive?), horisontal rule, blockquote, maybe nav?... Pure vanilla HTML, no web components, no shadow DOM, no interactivity beyond what's provided by HTML itself.
I get that it's not as sexy as creating rich web components with lots of added behavior, but there's a reason why HTML has a
<dialog>element but no<carousel>or<tabs>.Classless or class-based doesn't matter to me, but going native HTML ('light dom') means deferring a lot of hard questions about how to handle dynamic updates while being able to debate and get feedback on key aspects of themeability, design tokens, accessibililty, and naming.
I am also a big advocate for having the option to use no-JS ('styling-only') components for non-dynamic elements, since I don't always want to use an SPA, and if I have a SSR plus HATEOAS-powered web site then I really don't want to wait for a web component to register itself before those breadcrumb links show up.
@JensRoland that is my point here to an extent:
I think it's important to re-iterate that where possible we will utilize the platform. So while there is a button and dialog elements this isn't saying that those may not be re-used in proposals. That said, if they aren't used this may highlight gaps in the platform so we don't necessarily want to discourage it unless there is reasoning.
I don't personally want to start with
tableand honestly there are a lot of issues that many folks in this group are helping tackle with<dialog>as well as with<select>. Those may be as simple as just a name-space wrapper for DX consistencies but as I noted above, time will tell as we may discover gaps.And finally, this is an OSS solution and all I'm trying to do is understand what people feel the MVP list they would need for an alpha release that they would bring in.
I am also a big advocate for having the option to use no-JS ('styling-only') components for non-dynamic elements
100%, agree where feasible. I tried to capture aspects of this in a generic "Checklist" that we would require before it would ultimately be adopted in the library. Feel free to review and add to it. The RFC process that @cellar-door is doing for
badgeis meant to start helping us create a fly-wheel that the group can rally around.To this end, if someone feels there are values in other components that have been listed above I don't think this group would "block" it, it's more that many of them have a lot of complexities (like
comboboxor a completely platformtabssolution) and we may be able to get others out the door that are more narrow in scope. I like your thinking overall and will welcome the contributions especially if we can start getting alignment on the intake process :)Reacted by Jens RolandMy personal and subjective MVP list would be: button, select, input, table (not a dynamic datatable, just a styled table in my case), toggle switch, spinner/throbber, range selector/slider, and icon.
Sprinkle in some design tokens for theming of colors, spacing, typography, and some utility classes for responsive layouts and grids, and I'm a happy guy.
As for the Checklist, I went over it in December and added a few comments -- my only objection was to the
"Is a web component | The Open UI component library will only ship web components"bullet, which I took to mean no shipping of no-JS styles-only 'components', but perhaps I just misunderstood the wording.It seems like there's a ton of prior art in this area. Has there been any specific research into it with the aim of creating an MVP list?
Possibly relevant examples:
Personally I wouldn't mind some kind of merging of OpenProps and OpenUI since the two projects seem compatible technically and philosophically, but I am not deep enough into the details to understand why that might not be feasible/desirable.
As for research into prior art, the maintainers did put together a great matrix of components currently supported by existing component libraries - see it here: https://open-ui.org/research/component-matrix/
Personally I wouldn't mind some kind of merging of OpenProps and OpenUI since the two projects seem compatible technically and philosophically, but I am not deep enough into the details to understand why that might not be feasible/desirable.
As for research into prior art, the maintainers did put together a great matrix of components currently supported by existing component libraries - see it here: https://open-ui.org/research/component-matrix/
I would have to go back and check but I expect that this matrix is way out of date at this point, and it's surprising how much changes in this regard in 5 years. Like, even material - thoughts and opinions on things that were done in material shifted significantly. I mean, I am not saying it doesn't have value but it really should be re-looked at. It's at least debatable what you can take away from libraries that didn't take off or survive too.
I'm also having a little trouble thinking directly about an MVP list because the goals for the design system are a little nebulous to me. I think it might help to be a bit more concrete with some targets.
For example: with the design system, you should be able to build things like:
Hey all!
My sincere apologies for my delay here; I've been scrambling!I can share with you the common components we've built again and again for many design systems for many industries and for organizations of all shapes and sizes. I'll link up to examples of these components taken from our generic "Vanilla" design system that we've used as a boilerplate to kick-start many of our client projects. (We'll set aside conversation around how helpful that might be from an implementation standpoint for now).
Anywho! Here are the components that are common across nearly all of our design system efforts. Feel free to click on each of the links that will take you to our Storybook, which does a decent job of articulating the anatomy and purpose of each one.
- Buttons
- Form controls
- Messaging
- Blocks
- Interactive (lousy category title, but ¯\_(ツ)_/¯)
- Table
- Toolbar
- Layout & Containers
- Typography
- Navigation
If I had more time I'd detail these a bit more, but I'll record a video talking through each in a bit more detail.
ANYWAYS, these are the common components that we've created (and recreated and recreated and recreated and recreated) again and again. Something like this might be a decent 1.0 for a mature global design system.
But as for an MVP, here are the components that I think would be the most important and valuable to prioritize.
- Buttons
- Button
- Button group
- Form controls
- Text field
- Textarea field
- Select field
- Radio field
- Checkbox field
- Messaging
- Alert
- Badge
- Skeleton
- Loading Indicator
- Tooltip
- Blocks
- Card
- Interactive (lousy category title, but ¯_(ツ)_/¯)
- Tabs
- Accordion
- Modal
- Drawer
- Show/hide
- Layout & Containers
- Grid
- Navigation
- Breadcrumbs
- Pagination
The components I've omitted here tend to be ergonomic wrappers for HTML elements (e.g. heading, table), are a little less common (e.g. file upload and counter), or are less universal (e.g. layout-container).
I of course would be happy to have conversations around all of this! For next steps, I'll try to put together a quick video running through each of these in more detail.
And weighing in on other peoples' comments.
I would use this today -- and contribute to it -- if it was stable and came with ten solid components. I know I would have to build the next ten myself, but I would take comfort in knowing that this will be the last time I do.
@JensRoland Agree!
Asking co-pilot I get the following categories that seem to overlap.
@gregwhitworth Decent job, ChatGPT! hahaha
I would like to avoid any type of layout components early on.
I agree with this, even if a grid component with very common layout patterns (e.g. a "2up" pattern where items are stacked on small screens, then sit at 50% width when space becomes available) is extraordinarily valuable. But it's definitely a third rail! Poorly understood, many ways of doing it, etc.
Additionally, I'd personally prefer to avoid any form or table components in the Alpha variant.
I agree with the table component, and think I agree on forms if you're simply talking about the sequence of building things. I agree with you that we shouldn't start with form controls; it would make good sense to get a few inert/uncontroversial components under our belts before picking up more complex components.
That said, I think form controls are THE MOST valuable components that a global design system could provide. If there were literally no other components except these form fields ("field" meaning label traveling with input + optional helper text + validation feedback):
- Text field
- Textarea field
- Select field
- Radio field
- Checkbox field
It would be a huge win for the web. But again, I agree that starting there would likely be too complex. Get some quick wins first, get into a rhythm, and then pick these things up.
I know that "buttons" can fall into the "forms" category but they will be necessary for modals/dialogs, tooltips and possibly navigation depending on the scenario.
In our experience, it's good to treat buttons as distinct from form controls. Buttons are their own weird and complex world!
I think it's important to re-iterate that where possible we will utilize the platform. So while there is a button and dialog elements this isn't saying that those may not be re-used in proposals. That said, if they aren't used this may highlight gaps in the platform so we don't necessarily want to discourage it unless there is reasoning.
It's really important for these components to make use of the appropriate native HTML elements.
<dialog>is fantastic, but there is still a fair amount of work to do by developers to turn it into a ready-to-use modal component. Same for<button>; the tag is incredibly important, and a button design system component provides the necessary props to achieve common button use cases: different styles (e.g. primary/secondary), different sizes (e.g. small/large), icons (icon before/after/icon only), and so on. The button component is a welcome abstraction that allows developers to focus on making the button function rather than futzing with the styles.Password input (with a button to reveal the password in plain text) Checkbox (with customisable checkmark/indeterminate line) Radio button (with customisable dot) Switch (with customisable track/handle content) Spin button (with plus/minus button controls)
@gfellerph These are good ones! Checkbox and radio fields are absolutely essential in my view. Password, switch (aka toggle), and spin button (aka counter) are helpful too, but in our experience less universal than meat-and-potatoes form controls (text field, textarea field, select field, radio field, checkbox field). So good post-MVP considerations!
I may be alone in this preference, but why not start by styling what's already in HTML? table, button, input, select, fieldset, label, dialog, list, figure (responsive?), horisontal rule, blockquote, maybe nav?... Pure vanilla HTML, no web components, no shadow DOM, no interactivity beyond what's provided by HTML itself.
@JensRoland I agree with @gregwhitworth's response here. In my initial article, I talk about the importance of providing more pre-fab components rather than lower-level things that require a bunch of assembly. That said...
Personally I wouldn't mind some kind of merging of OpenProps and OpenUI since the two projects seem compatible technically and philosophically, but I am not deep enough into the details to understand why that might not be feasible/desirable.
This is great! And it brings up the importance between a component system and a styling (aka design token) system. We're digging into the weeds about this in our course right now, and I will write an article articulating all of this, but these are two separate-yet-related systems that work together to achieve a UI result.
This effort involves creating a component system that focuses exclusively on structure and functionality. Other efforts (OpenProps, Tailwind, Material, Bootstrap, etc) can provide a styling (design token) system that describes the visual language to flow through the component system. It would be absolutely possible — and amazing! — for there to be global design system themes. It would be the CSS Zen Garden for the global design system!
For example: with the design system, you should be able to build things like: a marketing site, an online store, a dashboard.
@sorvell 100% agree. These are great examples that show the diversity of applications of these components. It's not exclusive to one type of digital experience; the system would need to be applicable to any experience that is utilizing forms, buttons, typography, messaging, cards, etc.
Based on the comments above, is a modified mvp initial list
- Button
- Button group
- Alert
- Badge
- Skeleton
- Loading Indicator
- Card
- Tabs
- Accordion
- Modal
- Drawer
- Show/hide
- Breadcrumbs
- Pagination
And if so, I might suggest leaving off even tabs, accordion, modal and drawer initially - or just pick 1 to start?
There's an inherent trade off between standardization and reducing boilerplate on the one hand and higher level functionality, extensibility, and flexible styling on the other. I think this is one of the key reasons approaches like shadcn have become popular.
Even if we were just to start with Button....
- should this be more than a stylesheet? If so, why?
- if it's a custom element, does it use slots or attributes or both for content?
- does it support hyperlinks? form participation? non-form use?
- if it has positions for different content like leading and trailing icons, does it support other options or a vertical mode?
- does it try to support patterns like rippling as material does? what if this would require other DOM?
Button exists and mostly does what we want so including it in a design system is almost all about standardizing and reducing boilerplate.
Some of the other options discussed are more novel, providing high level behavior or filling/fixing missing gaps. That may be easier to target first?
- better grouping
- alert/prompt (pseudo-exist)
- skeleton / loading indicator
- drawer
- breadcrumbs / pagination
should this be more than a stylesheet? If so, why?
Yes, for the reasons outlined here and here.
if it's a custom element, does it use slots or attributes or both for content?
In our experience, attributes, slots, and both are all viable and good options! Really depends on the component and the use case. For something like button, it makes really good sense to be able to slot in icons, though for certain org-specific design systems we've controlled icon through attributes only.
does it support hyperlinks? form participation? non-form use?
We've built many button components that swap out HTML tags under the hood (e.g.
<ds-button href="#" variant="primary">I'm a hyperlink</ds-button>. However, for this specific design system I don't think that would be a good idea. Best to leave it to<button>, but yes it would need to work for forms and non-form use.if it has positions for different content like leading and trailing icons, does it support other options or a vertical mode?
Yep, the whole component system should build in logical properties and use flexible API language. We've used
iconPosition="before|after"before, but I feel like leaning into existing standards language for alignment and positioning would make a ton of sense.does it try to support patterns like rippling as material does? what if this would require other DOM?
Ha, no! shudders That's actually one of the big drivers behind this effort: the structure/behavior should be decoupled from its aesthetic language (which includes the funky ripple click effect in Material). People can bring whatever aesthetic they'd like to the party, and the hope would be for the components to be extensible for people to add hooks and build on top of the library's sturdy foundations.
Button exists and mostly does what we want so including it in a design system is almost all about standardizing and reducing boilerplate.
Buttons are included in nearly all design systems and tend to address these common renderings:
- Aesthetics (
primary|secondary|tertiary|flat|raised|etc) - Sizes (
small|large|etc) - Icons (icon before text, after text, icon only)
- Disabled state
- Block-level (full-width)
Some of the other options discussed are more novel, providing high level behavior or filling/fixing missing gaps. That may be easier to target first?
Yeah I think that's a great call to identify a criteria for the MVP priority. Here a start to some criteria:
- Value/usefulness for user developers - save people time/agony/money (this in my opinion the most important criteria)
- Complexity - which might translate to "ease of implementation"
- Commonality - How often is this reinvented?
- Accessibility wins - components that help address common accessibility issues
You get the idea. What other criteria could help guide the prioritization?
- Aesthetics (
Here's where we landed as far as things to focus on first while we establish the coding conventions (Issue #13):
- Button
- Text field (aka input field)
- Alert (aka banner, etc)
- Badge (aka pill, etc)
- Modal (aka dialog, popup, etc)
Once we have the code conventions established, we can work on implementing those first before broadening it to the other components.
