Open gregwhitworth opened 8 months ago
Early on in openui we discussed what we wanted openui to be and came to this idea that there were sort of levels here. Like, there was usefulness in doing and publishing some research on a component together to spell out and label its 'parts' and differences in interactions, etc as a community. A step further maybe we could make the same basic CSS work on any of them, or maybe they can have the same fundamental events/event names and so on. Maybe a step further they can begin to eliminate seemingly unnecessary subtle, but important (especially for a11y) differences. We talked about having a kind of shared conformance/test thing...Maybe another level still we might develop a reference implementation. That is where we were headed with https://tabvengers.github.io/spicy-sections/ . Then, finally, some would become proposals to change HTML (or CSS or whatever) itself.
In practice it seems (to me) that we've mostly focused on a little research and then HTML prototypes/HTML. What work we've done on parts hasn't been in participation with a large group of existing systems, and actually turned out to be at odds where the rubber hit the road in HTML in certain cases. I think that was a very fine idea but the practical realities seemed to make that difficult.
I am not opposed to also something short of implementations but I do think we actually need implementations for this to be viable. I'm not sure that implementations means the only answer is strictly speaking a component library either though. That is, in the thing above you could imagine several 'conforming implementations' where conforming would transfer the faith in the 'spec'. However, there is another take on this which I have brought up since 2014 that alternatively we could set up some kind of review process/group where people could send existing components for some kind of "you can have faith in this" stamps sort of equivalent to horizontal review in w3c. It doesn't give everyone "the one" answer, but a small set and a central place to find high quality ones that then easily seed a way toward 'the one' if ncessary... The trouble here again is mainly how do you fund the necessary participation to make that work.
Now that someone else has chimed in; I'm not opposed to us producing design system documents and then implementations that take those forms, possibly a web component; maybe an HTML solution to @bkardell point. I think the reason I like the component library approach is to @bradfrost position it introduces a "weight" by having them be in a recognized and respected namespace (eg: <w3c-foo>
).
One key thing that I will want to ensure however is that if we go with design system "specs" we discuss how this aligns/conflicts with the ARIA Authoring Practices.
However, there is another take on this which I have brought up since 2014 that alternatively we could set up some kind of review process/group where people could send existing components for some kind of "you can have faith in this" stamps sort of equivalent to horizontal review in w3c.
This kind of takes me down memory lane when people would put badges on their site that they're XHTML verified
My only qualm with this is that we would need to re-verify on a defined cadence to award this "badge". That said, some of this could be automated away with selenium testing but ultimately for true "validation" we'd need to selectively do manual audits which brings us back to time and who would do this work? I think at that point I would personally build/collaborate/adopt a single web component library and rev on those.
The Open UI Community Group just discussed A design system, component library for the web?
.
Hey folks, one key item I want to make sure is that the group makes this actionable as there has been a lot of discussion around it.
In speaking with a few folks, including @bradfrost I wanted to recommend that we break this apart into two different segments.
Open UI does much of this work already; although I've noticed that we often start mixing aspects of a component/controls functional and non-functional requirements with implementation within a user-agent and the HTML specification. These do not, and I agree with some, that they shouldn't be intertwined.
Should this be a part of Open UI
I do believe that it should and is already covered by our charter. This is actually something that we've resolved on for prior components that were raised to Open UI for both card
and skeleton
.
What level should GDS Cover? In our GDS Discord channel Red_Code posted a great image by Rohan Kamath that shows the potential spectrum of components -> Pages.
With this, I recommend that Open UI focus on Sub-atomic, Atoms and Molecules where necessary. Additionally, to avoid conflict with current efforts I do not think that we should work on any components/controls that are actively being worked on as Open UI Explainer. I think we should pick a 1 - 2 atoms or molecules (TBD) to prove out the working model and value proposition.
Working Model I truly think that this group should function as a separate workstream. However; everyone is very busy with meetings and so I would like to take advice from many that have voiced support for this initiative and primarily run it as an Open Source project. When there is a need for driving consensus on functional behaviors due to not being able to align on consensus within a Github issue/PR then they will be added to the current Open UI telecon.
I do think that Open UI should ensure that the designs result in an implementation for ease of adoption and keeping from us introducing yet another document that devs and designers may look at to produce their own design system.
To this end, we should evaluate the various approaches (in a different issue) as there have been some great ideas put forward and I've had some interesting discussions with interested parties. I will note that the largest concerns members of Open UI have raised is the number one commodity we have little of, time. This is why I think it's so important to drive this workstream a bit different to increase velocity and contributions while ensuring the rigor that enables us to ensure what we endorse meets Open UI's principles of ensuring they are performant, accessible, extensible, styleable and support internationalization by default.
One of the key reasons my mind has changed on this was speaking with a component library author where they raised their reason to contribute to this project was to ease the transition of primitives that make building component libraries complex.
Open UI will create a separate workstream focused on a Global Design System and determine a path for creation or endorsing of component library.
@gregwhitworth Thanks so much for all of your leadership and framing for all of this. It's really exciting to see this idea progress!
I don't have much to add to what Greg outlined, but rather give some +1s to a few things:
Looking forward to keeping the conversation going and helping turn this idea into a reality. Many thanks to @gregwhitworth and everyone else for all the great conversation and enthusiasm.
What is the outcome desired here?
What real problem of the web is this solving?
The Open UI Community Group just discussed A design system, component library for the web?
, and agreed to the following:
RESOLVED: Create a Global Design System workstream in Open UI and do not start from zero with a component library(s) (TBD)
I wasn't present, but from the minutes, it seems like this should not be back on the agenda, so I'll remove the label.
@jensimmons if you search the minutes for "zcorpan: what outcome is desired here? what problem of the web is this solving?" @zcorpan did ask your question and there is some answer there
Hey. I just released Nue 1.0 (beta). It's a web framework for UX developers based on a global design system. Think modern-day CSS zen garden: https://nuejs.org/blog/nue-1-beta/
Would love to hear your thoughts!
I'll paste in the summary here from a kickoff meeting we had with @bradfrost:
This issue to focus on the first topic as the other two follow after that. I'll ping in the discord channel about this to try and centralize the discussion here as well.