A design system, component library for the web?

[gregwhitworth]

I'll paste in the summary here from a kickoff meeting we had with @bradfrost:

Hey everyone, as an FYI a few of us met with Brad Frost regarding a global design system based on his post here. To avoid having too many non-open meetings we decided to spin up a channel to try and iterate async on key questions.

1. Should this be a design system only and not include a component library?
2. If we started a component library what key components would we start with?
3. How do we get the right people involved to ensure that it makes progress but also has the necessary rigor to ensure people that adopt it are getting the key goals from this.

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.

[bkardell]

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.

[gregwhitworth]

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.

[css-meeting-bot]

The Open UI Community Group just discussed A design system, component library for the web?.

The full IRC log of that discussion

<hdv> gregwhitworth: I'll give a quick overview
<hdv> gregwhitworth: we spinned up a new channel for this
<hdv> gregwhitworth: Brad Frost wrote a proposal on his desire to make a global design system
<hdv> gregwhitworth: that was actually part of the original ideas behind Open UI, Brad rightly pointed out we pivoted somewhat
<hdv> gregwhitworth: because we're part of the W3C we have the potential to pull in experts re accessibility and internationalisation
<hdv> gregwhitworth: question for today is… would Open UI be a good venue to try and pull of a design system or component library
<hdv> gregwhitworth: Brad is a consultant in design systems
<hdv> gregwhitworth: he said a design system can be three things: a component library represented in code, components in design software (like Figma) and a documentation website
<hdv> gregwhitworth: these are kind of the buckets design system elements usually fall into in the industry
<bkardell_> q+
<hdv> gregwhitworth: so the question is if we want to go after those things… and can we make it work in a way where folks who haven't been contributing, how do we make it a welcoming space to contribute
<hdv> gregwhitworth: especially for frontend/UI/UX folks
<masonf> q+
<scotto_> q+
<gregwhitworth> ack bkardell_
<hdv> gregwhitworth: the question for today is: does this group want to tackle the work of doing any of the three groups (components in code, components in design software, documentation)
<brecht_dr> q+
<hdv> bkardell_: I think there's a value in doing something here
<hdv> q+
<hdv> bkardell_: early on we discussed there was value in doing things that don't become standards, eg defining 'parts' and documenting them is usseful in itsefl
<hdv> s/itsefl/itself
<hdv> bkardell_: it feels like the efforts proposed are a different type of work to what we're doing now, that probably needs different kinds of people involved
<gregwhitworth> ack masonf
<gregwhitworth> q+
<hdv> bkardell_: so maybe it would need to be a separate meeting
<luke> q+
<hdv> masonf: I like the idea, but scared of a lot of parts of it
<hdv> masonf: I'm reminded of the XKCD re inventing yet another standard
<hdv> masonf: I think Open UI is a great place to do it and has the right kind of people for it
<hdv> masonf: my main concern is: it needs to be clear … there are things we work on that are web standards track things, with destinations like CSSWG or WHATWG
<hdv> masonf: this is not that
<hdv> masonf: it's almost like an incubator for…
<hdv> s/it's/we're
<bkardell_> some of it could be, and I tried hard not to say the same thing, but it does feeel like it is like an incubator in an incubatorr
<hdv> [gregwhitworth in chat: it's an incubator on top of the incubator]
<gregwhitworth> q+ jack
<gregwhitworth> ack scotto_
<hdv> scotto_: I'm very concerned with some of these. There needs to be clear expectations set around them
<hdv> scotto_: things we've been talking about, like select and popover, clearly driven towards HTML adoption
<hdv> scotto_: if I had been working on them as part of a component library or design system for people to use now… I would be arguing even harder with you all on some of the decisions being made
<hdv> scotto_: there are accessibility issues that can't be solved today now without browsers doing specific mitigation
<hdv> scotto_: scotto_ I'm very nervous in providing actual component library output
<hdv> s/in/about
<masonf> q+
<hdv> scotto_: it probably needs lots of documentation around how to deal with lots of specifics
<bkardell_> can anyone speak to why there isn't a web components version of apg ? scotto_ ?
<hdv> scotto_: we probably shouldn't throw about components out there and say they are 100% accessible
<gregwhitworth> ack brecht_dr
<hdv> scotto_: because the accessibility depends on how it is actually being used
<hdv> brecht_dr: this is work that should not be underestimated, this work would be very hard to do
<hdv> brecht_dr: I wonder if Open UI itself can devote enough time for it
<hdv> brecht_dr: a concern voiced by Chris Coyier… at a certain point you have to make decisions, especially when it comes to accessibility
<hdv> brecht_dr: besides that the idea is fantastic. Maybe utopia.
<gregwhitworth> ack hdv
<gregwhitworth> hdv: I love this idea, I've wanted this for a long time
<gregwhitworth> hdv: I want people to get components that are a11y and friendly
<gregwhitworth> hdv: however, it will be very, very hard
<gregwhitworth> hdv: I work on the Dutch design system which is a part of the larger a11y efforts
<gregwhitworth> hdv: we deal with the same sort of things
<gregwhitworth> hdv: we make sure to say that it won't say it is 100% accessible
<gregwhitworth> hdv: none of these components can bring a11y. For example what text can you put onto a button, it's really, really hard to get a11y right
<gregwhitworth> hdv: if we can manage to build both the components + documentation then that would be gold
<bkardell_> multi multi multi year :)
<gregwhitworth> hdv: we should be getting user testing involved as well
<gregwhitworth> hdv: we need to make sure that they meet their needs
<gregwhitworth> hdv: the dutch design system is almost four years old and we're just now getting started with it
<gregwhitworth> hdv: I don't think Open UI should do this due to time
<gregwhitworth> hdv: APG is the closes to it but it has its own issues
<luke> q?
<bkardell_> It might be great if some govts donated their things to this to start... is that likely at all?
<brecht_dr> +1
<hdv> ours is under EUPL license and could def be reused
<hdv> (aka it's already donated)
<bkardell_> linky?
<hdv> gregwhitworth: I like to look at the CSS WG … because people assume from the outside it seems like it's just a syntactic thing
<bkardell_> * except when we do exactly that :)
<hdv> gregwhitworth: but it's a lot of very specific topics that only very few people know about
<luke> https://github.com/alphagov/govuk-design-system - this is MIT licensed so we can probably use some of it, just as an example
<bkardell_> q+
<hdv> gregwhitworth: for the documentation… Hidde said APG has its own issues
<hdv> gregwhitworth: how do we reconcile… should maybe our work be part of APG efforts, I'd want to avoid redundancies
<hdv> gregwhitworth: we'll probably need some artifact prior to writing code
<hdv> gregwhitworth: like a document
<hdv> gregwhitworth: similar to the explainers we wrote for select and others
<hdv> gregwhitworth: when we first pitched Open UI… we saw APG is probably the closest to the design system world
<hdv> gregwhitworth: I don't think Open UI has to start from scratch
<hdv> gregwhitworth: there is a lot out there already
<hdv> [ https://designsystem.digital.gov/components/ is also excellent ]
<hdv> gregwhitworth: we could probably get others to work together with it on us, that already have existing pattenrs
<hdv> s/pattenrs/patterns
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack luke
<bkardell_> There are a bunch of people who have tried to do generic versions of APG stuff... for example https://github.com/thepassle/generic-components
<hdv> luke: we've got enough documents, so we need something concrete at the end… what about the opposite… we have enough implementations (see the matrix of libraries on our site)
<hdv> luke: that''s a good start
<hdv> luke: I think some of this work isn't very far from the work that we're already doing, like making anatomies
<hdv> luke: luke: accessibility is obvious, but also internationalisation is important (browsers don't even have that fully covered)
<hdv> luke: the other thing is… which tech to use… we could build web components but what if someone needs to use it in React
<hdv> luke: then there's browser compat…some things aren't supported widely, which makes it tricky how much support to build into the components we would build
<gregwhitworth> q+
<hdv> luke: if we document issues with each patterns, that might be better than actually focusing on implementation
<hdv> luke: something the UK government does… not just components but also patterns, which show solid combinations of components, how they work together
<hdv> luke: starting from something like Shoelace is probably a good idea, but you would get all of the historical biases that Shoelace has
<gregwhitworth> ack jack
<hdv> jack: I've always stayed in the periphery of the W3C… tried to stay away from design by commitee
<hdv> jlukic: I'm working full time on a web component based design system that is generic
<hdv> jlukic: I'm interested in working with you on this
<hdv> jlukic: a novel is not usually written by multiple writers, it should be written by one writer or feel like it was
<hdv> jlukic: I spent years doing proprietary design systems and currently want to work on doing something open source
<hdv> jlukic: I'm excited about these ideas
<hdv> s/jack/jlukic
<gregwhitworth> ack masonf
<hdv> masonf: I wanted to respond to a few things… agree with gregwhitworth that we probably shouldn't split the group into multiple
<hdv> masonf: but the discussion is probably different between web standards track stuff and web components stuff, could be in one meeting
<keithamus> q+
<hdv> masonf: scott mentioned your opinions would be stronger if we were working on a component library than with standards features. One benefit of components in a library is that we can version them and fix mistakes more easily. And do more opiniated things
<hdv> masonf: it may be that some concerns are known and you can address them
<hdv> masonf: also +1 to this should not be underestimated and can take up a lot of resources
<hdv> masonf: if we're solving the problem it should be solved with an actual implementation
<hdv> scotto_: the thing is re browser features vs components… thing is I can safely _not_ anticipate that it won't ship in browsers until things are ironed out… whereas if we make web components it would become much more of a garbage fire
<hdv> scotto_: with browsers I am looser because there is time to figure things out, if it happens on that level.
<gregwhitworth> ack bkardell_
<hdv> scotto_: (not always the case, sometimes browsers featues do ship with issues that then can't be fixed because of potential web 'breakage')
<hdv> s/featues/features
<luke> q+
<hdv> bkardell_: I am also concerned about this being wildly underestimated and consuming all available resourcs
<hdv> s/recourcs/recources
<hdv> bkardell_: and design by committee can end up being those with the most willpower will continue to show up
<hdv> bkardell_: we talked about APG a few times, APG is not a standard, it's a document maintained by volunteers
<brecht_dr> q+
<hdv> bkardell_: that seems to me like the easiest target to look at as it has had the most thought put into it
<hdv> bkardell_: we probably should also work on making those things into an HTML element though
<gregwhitworth> Zakim, close the queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<scotto_> to be clear though. APG's purpose is to demonstrate how to use ARIA in accordance to the ARIA spec. The patterns that are demonstrated are not necessarily 100% worked out for usability, or even if they're the right pattern to solve any particular problem
<gregwhitworth> scotto_ that's good to know
<hdv> bkardell_: I don't know if the problem is so much that there are multiple tabsets out there… there are infinite tabsets and each one has a tonne of assumptions and it's hard to find them all
<hdv> q+
<hdv> bkardell_: I like the idea of maybe starting with design systems that were made by government organisations
<hdv> gregwhitworth: re the amount of work: I agree with Luke that we're already doing this
<hdv> gregwhitworth: how could we make this into something actionable?
<hdv> gregwhitworth: maybe a google doc with pros and cons of each approach we could take
<luke> q?
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack keithamus
<hdv> keithamus: I worry about that if we persued this and would need to stop web platform work as a result
<bkardell_> this is why I suggest it is a different thing, it can be a task force of openui or something... or we can literally spin up a new group
<hdv> keithamus: I also worry about what would it look like if we tried and then not finished it?
<gregwhitworth> q?
<hdv> keithamus: versioning and semantic versioning is a cool idea and a good contract
<hdv> keithamus: but in reality you can't break that much
<hdv> keithamus: you can say you've broken something, but you're likely going to end up with two major version to maintain
<gregwhitworth> ack luke
<scotto_> super +1 to that point keith made. one of the biggest issues i've run into with component library accessibility issues is not that the issues don't get resolved, but that people using the older versions are "stuck" on a full release, or even a point release
<chrishtr> q+
<hdv> luke: discussions that we've been here often take the shape of 'how should this behave'
<hdv> luke: even doing only single select, it takes a lot of time to get that right
<hdv> luke: we might have more value spending our time to make one component very good than trrying a design system that has a middle of the road version of everything
<gregwhitworth> luke I don't think they're mutually exclusive
<masonf> q+
<hdv> luke: if we make a global design system, this meeting is only in US/EU and outside work time for most outside of EU
<hdv> luke: it would also be good to get the site in a state that is easier to contribute to
<gregwhitworth> ack brecht_dr
<gregwhitworth> sorry luke
<hdv> brecht_dr: for this to work, more people and instances are needed, like governments
<hdv> brecht_dr: might be interesting that this gets a separate group that does the main research and facilitates the other instances
<hdv> brecht_dr: I think there's too much work to get this rolling from the start
<gregwhitworth> Zakim, end meeting

[gregwhitworth]

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.

1. Global design system
2. Component library endorsed or provided by Open UI that implements the GDS

Global Design System

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.

Component library

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.

Desired resolution from Open UI

Open UI will create a separate workstream focused on a Global Design System and determine a path for creation or endorsing of component library.

[bradfrost]

@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:

• Housing this effort under the OpenUI umbrella feels great! Reading the charter feels like a great hand-in-glove situation, and the hope is this work can build upon a lot of the great work already done within OpenUI.
• Running as an open source project makes a lot of sense. I've had a lot of great conversations with people who are excited about participating in this effort, so it would be great to structure it in a way to harness the enthusiasm and brain power of the worlds' development/design system community.
• Running it as a separate work stream makes sense to make the best use of peoples' time. But having the ability to share insights and info (synergy!!!) between the tracks can be mutually beneficial. The standards track can weigh in and guide the Global Design System work, and the Global Design System work can help inform the important standards work.
• Starting with some trial components that are distinct from existing in-flight work makes sense so as not to muddy the waters. There's been some good discussion around the distinction between the Global Design System and the existing work stream, and what components to start with should help clarify the distinction between the two tracks.

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.

[jensimmons]

What is the outcome desired here?

What real problem of the web is this solving?

[css-meeting-bot]

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)

The full IRC log of that discussion

<jarhar> gregwhitworth: in the global design system channel, a great picture was posted that showed the spectrum of what design systems can cover
<brad_frost> bkardell_ yep
<jarhar> gregwhitworth: aren't we already doing this? i think we are doing this, html does this to an extent, and there are other things we've resolved on like card and skeleton, if someone was to build these then this is what the accessibility roles should be. we didn't find a home within openui for this, but its within our charter
<jarhar> gregwhitworth: im proposing that we cover things from atoms to molecules. the skeleton is for other sites to define
<jarhar> gregwhitworth: atom is an input or a label, molecule is both of them combined
<jarhar> gregwhitworth: the working model was - theres a lot of people that are interested in this project who dont want to attend 1 hour meetings every week and want to lean in to it as an open source project
<jarhar> gregwhitworth: i want to lean in to that, but if we want to build a global design system which says this is going to be accessible and have good privacy etc.
<jarhar> gregwhitworth: i dont want to start off with a 1 hour weekly meeting that is about the design system layer
<jarhar> gregwhitworth: 80% of what people have been working on with select and combobox could easily fall into design system
<jarhar> gregwhitworth: i recommend that we not do those ones in that workstream. we should find 4 other things and tackle them
<jarhar> gregwhitworth: also set a clear boundary, html could be an implementation target for this or it could be a bunch of component libraries
<jarhar> gregwhitworth: so i want to clarify the 2 workstreams
<jarhar> gregwhitworth: i think we've all seen the xkcd where we're creating another document
<jarhar> gregwhitworth: i dont think the docs ultimately matter. people are referencing docs to build their components
<jarhar> gregwhitworth: they will get mass adoption if they get into the browser
<jarhar> gregwhitworth: ensuring they're extensible and stylable
<jarhar> gregwhitworth: there does need to be a component library, there are a lot of ideas about how to do that
<jarhar> gregwhitworth: i dont want to spend time in this call about how we are going to do that
<jarhar> gregwhitworth: ive been talking to people about different ways we can do this
<jarhar> gregwhitworth: my desired resolution for this is that openui will create a separate workstream for the global design system
<gregwhitworth> q?
<bkardell_> q+
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: im confused as to what that looks like
<jarhar> bkardell_: i do think it should be a separate workstream, but i dont know what it means to not have weekly meetings but embrace it more as open source
<gregwhitworth> q+
<jarhar> bkardell_: someone still needs to govern open source and make descisions and have discussion
<gregwhitworth> q?
<jarhar> bkardell_: one thing i floated in discord was - theres a problem with trying to approach this is that starting from zero - you have to have a critical mass for it to matter to anybody, and its not an achievable thing to start from scratch. it could maybe be best achieved by adopting some existing thing, and the problem is there that picking winners
<jarhar> is not super great
<jarhar> bkardell_: i think it would be better to have a group that could work on - start with government ones that would be independently funded and motivated to be accessible etc.
<jarhar> bkardell_: but it kind of doesn't matter to me which one
<jarhar> bkardell_: the devils are in the details of this. i like the separate workstream, figure out something that works for everybody
<jarhar> bkardell_: but im curious the rest of it
<jarhar> gregwhitworth: i am not pretending that we have everything figured out, i want to try to move towards action so that people who are interested can start landing things
<jarhar> gregwhitworth: one of the key things for consensus within the openui area, what does that look like? the second that accessibility is brought up we would annoy scott, and then we would of course apply the horizontal label that has the w3c label and we can get aria involved
<jarhar> gregwhitworth: to your point of what that looks like, do we need 3 lgtms and keep it async, i dont know, we can update the working model if people have good ideas
<jarhar> gregwhitworth: whatwg has been working in this way, things we can learn from others, lean into async
<jarhar> gregwhitworth: openui has been very much working as an open source solution being in github, but we do lean back a ton on consensus, which i dont think is a bad thing but only required for those sticky topics
<jarhar> gregwhitworth: with the component library one, lets punt that to a separate topic because its a massive can of worms
<jarhar> gregwhitworth: we don't want to just write docs because its not going to matter
<jarhar> bkardell_: so is the resolution to begin to define a separate workstream?
<jarhar> gregwhitworth: yes
<jarhar> gregwhitworth: if people see things they dont like occurring, then we can change
<jarhar> gregwhitworth: we have potential critical mass so we should start landing these things
<jarhar> gregwhitworth: next discussion is component library. do we bring one in?
<jarhar> gregwhitworth: bring in is vague because i dont know what that would look like
<bkardell_> +1
<jarhar> gregwhitworth: resolution is openui is ok with a separate workstream, separate component library is yet to be defined
<jarhar> zcorpan: what outcome is desired here? what problem of the web is this solving?
<zcorpan> Questions from Jen: What is the outcome desired here? What real problem of the web is this solving?
<zcorpan> https://github.com//issues/1017#issuecomment-2115855870
<jarhar> gregwhitworth: the charter of openui is to define the behaviors, accessibility requirements, etc. so that people could go to one location and build their components on them
<jarhar> gregwhitworth: with many of those ultimately landing in the browsers
<jarhar> gregwhitworth: the desired outcome is that we are meaningfully drawing that line in the sand
<jarhar> gregwhitworth: the majority of us in openui have been focused on landing them in browsers
<jarhar> gregwhitworth: there are things in the select explainer that are specific to landing them in whatwg, but not about this is a foo component that anybody could implement
<jarhar> gregwhitworth: the separate workstream would be focused on that
<brad_frost> q+
<jarhar> gregwhitworth: what of those do we want to pull down and land in html or css
<jarhar> gregwhitworth: one of the key areas is that someone wants to see primitives land, im building this stuff
<jarhar> gregwhitworth: hopefully that answers jens question
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack brad_frost
<jarhar> brad_frost: to frame it a bit as well, your existing experience with card and skeleton are good examples
<jarhar> brad_frost: what we see in the industry having these ui needs are on the hook to create them from scratch
<jarhar> brad_frost: some of those things might not be candidates for html
<jarhar> brad_frost: they could be, but they might not be
<jarhar> brad_frost: theres an opportunity to have an intermediary later where this is in html or youre on your own
<jarhar> brad_frost: home for common ui patterns that are sanctioned by really smart people that understand accessibility etc. to give it the authority that the present libraries dont have. teams kind of going shopping or do their own research, what we would love is heres this badge heres this and you get the good stuff for free
<jarhar> brad_frost: but the semantics and functionality are in place
<scotto8> q+
<jarhar> brad_frost: some of these things - other opportunity is heres something that people can use now while the conversations about standardization is happening
<jarhar> brad_frost: this layer in between can help influence the standards track as well as go outwards and give people a real leg up on their work in the meantime
<gregwhitworth> ack scotto8
<gregwhitworth> ack scotto
<jarhar> scotto8: question on that, there is - one of the ideas, using card as an example, since its not a real term
<jarhar> scotto8: would the goal of the design system be that this is what a card is, or is it to acknowledge that a card is just a box that you can put on any html element and heres some situations where you might use particular html elements
<jarhar> scotto8: the latter is a lot of words that people might not read
<brad_frost> q+
<jarhar> scotto8: the former is ???
<gregwhitworth> ack brad_frost
<jarhar> brad_frost: its a great question, and thats the sort of - the thing that we've seen accross the industry, a card is a thing as a ui concept that has a definition and a shape to it, even if the underlying html structure is going to change, especially for a card which is composable
<jarhar> brad_frost: what we see is that many popular design system defines important things about the style: heres border, radius, etc
<jarhar> brad_frost: or theres a variant of that which is a bare box which is invisible
<jarhar> brad_frost: from a semantic standpoint, it could be a div, but conceptually, its a concept which has properties attached to it. badge is another one which is just a div or span but its a concept with guidance and conventions and properties
<jarhar> brad_frost: as we do a cross section across design systems these are well establieshed
<jarhar> brad_frost: we want to triangulate these and put them in one place
<jarhar> brad_frost: and do the due diligence and rigor to make sure that the solutions are sturdy for everyone to benefit from
<jarhar> brad_frost: what youre touching on scott is the distinction between the html layer and this layer, because these things are weird, theyre clearly concepts and materials that people are using, but do they actually need their own html tag? perhaps, but maybe also not. this layer provides an avenue for us to be able to create and explore these things,
<jarhar> could have those conversations about should we pull this into the html layer now or later or never
<bkardell_> q+
<jarhar> jamesn: im curious with things like popover landing in the browser, should this new global design system come with a mandate of emphasizing elements that might be added to the browser? should we stay away from those? which path would be more productive for this working group?
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: this is the first conversation i had with greg about openui. this is a key question
<jarhar> bkardell_: i want tabs
<jarhar> bkardell_: part of me, is like it would be better to help bless 4 different sets of tabs and say any of those are good, we got them to share these common qualities so you can style them in similar ways
<jarhar> bkardell_: it might be easier to make that happen
<jarhar> bkardell_: maybe we should do that. at the same time, tabs in html seems achievable
<jarhar> bkardell_: it always feels like we're close, theres people spending time on it
<jarhar> bkardell_: rob has the last bits of this that im hoping we will see some new hey we can do this
<gregwhitworth> q+
<jarhar> bkardell_: thats a really good question, i want the answer too. should we pick those up or avoid those?
<brad_frost> q+
<jarhar> gregwhitworth: the current workstream definitely should james. we should be going based on the prorioty list of people rebuilding the ones built in, and we learned a lot with popover and select
<jarhar> gregwhitworth: after we land select hopefully we will have a blueprint
<jarhar> gregwhitworth: everyone that comes to openui and asks how to get involved, i dont want to say only if you have a vision in the browser
<jarhar> gregwhitworth: if people want to spend the time to do the research, skeletons not going to land but i would still love to get that research out in the public, we shouldn't be turning them away
<jarhar> gregwhitworth: if scott is strong enough to get agreement, we can say this exists and dont use it. heres what people use it for, but if the people in that workstream conclude that this is actually bad, to brians point then we're not starting from zero
<jarhar> gregwhitworth: can then go in and make modifications in that world, in that blessed state, whatever that looks like. tabs is a good one, we have spent time on it
<jarhar> gregwhitworth: i think adoption of those things starts informing where the other workstream should spend its time, we should invest time shipping that in the browser
<keithamus> q+
<jarhar> gregwhitworth: we could be more performant than that one, we could see other people using this
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack brad_frost
<jarhar> brad_frost: difference between standards track and this track, could be a bit more opinionated - with standards the tab work is the edges of the bell curve, it really requires a lot of intelectual work to account for every use case
<jarhar> brad_frost: what has to happens for standards track which is important
<jarhar> brad_frost: most of the time when you're reaching for tabs heres some ingredients
<jarhar> brad_frost: by design its not comprehensive, which is a different mentality than something that needs to land in html
<jarhar> brad_frost: i see this as a pressure release to deliver value for developers
<jarhar> brad_frost: maybe its not the tabs to end all tabs but most people could pick this up and use it
<jarhar> brad_frost: put that as a distinction between these layers, you still need to do the work but at the same time you're not needing to be as comprehensive as a standards track element would be
<bkardell_> our proposal made the same distinction - it tried to punt on stuff outside the most common cases
<gregwhitworth> ack keithamus
<Luke> q+
<jarhar> keithamus: i have a couple of questions. one is like, where do we see the end result? in 10 years? do we intend to get this into the standard or what? this could provide a way to funnel work into openui or prioritize work
<jarhar> keithamus: i wonder if we need that which is to say, we probably have a load of work ahead of us with select and a bunch of form controls after that, and state of html which gives us developers needs
<bkardell_> q+
<jarhar> keithamus: im not arguing against an open design system, but does that give us things to funnel down?
<gregwhitworth> ack Luke
<jarhar> Luke: one thing that might have already been mentioned, is that one thing that is useful from a design system perspective is that it could allow us to prioritize the building blocks to be able to build these things easier yourself
<jarhar> Luke: stylable select has... we've gotten popover at least
<jarhar> Luke: focusgroup is kind of along those lines, its a primitive you could use to build your own select
<jarhar> Luke: and lots of that isn't from the implementation perspective, its from the im going to close select when i press this button what does it do
<jarhar> Luke: thats the kind of things we could get at the design system level, if youre painting to a canvas it doesn't matter that its not html
<jarhar> Luke: oh this primtivie is useful in the platform, we should focus on - aria actions for example, theyve got close buttons and we cant do that in html easily
<jarhar> Luke: its not necessarily doing more work than we're already doing, its moving it to a different level, because these discussion we've had previously
<jarhar> Luke: the other bit of it is will we build a prototype and get people to try it out
<jarhar> Luke: people might say thats terrible, if we build it in html its a lot of work to change it. if we build it as a web component its easier to change
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: i have been really keen on using some real world data to inform work
<jarhar> bkardell_: using custom elements to try out, figure out what works
<jarhar> bkardell_: with tabs, we figured out that theres 20 markup patterns
<jarhar> bkardell_: how do you pick which one?
<jarhar> bkardell_: to answer keiths question, that we could get out of it, is some insight because a library or a set of libraries that have some joint effort and blessing and they're not a standard but they have stamp of approval
<jarhar> bkardell_: they would get a boost and we would see them in httparchive data
<jarhar> bkardell_: i think thats worth something, we can find out if people actually adopt them
<jarhar> bkardell_: are they as useful as we think they are
<Luke> +1
<gregwhitworth> Proposed Resolution: Create a Global Design System workstream in Open UI and do not start from zero with a component library(s) (TBD)
<bkardell_> +1
<Luke> +1
<jarhar> keithamus: whats the dont start from zero?
<brad_frost> +1
<jarhar> gregwhitworth: in all the discussions ive had, the most important thing, noone has time
<jarhar> gregwhitworth: i dont want to spend time have people author docs that ultimately do not get leveraged
<jarhar> gregwhitworth: not that its wasted time, but i think theres enough interest that people are going to invest their time, and i want to be respectful of that time, and have a funnel in place where we know there will be successful adoption
<jarhar> gregwhitworth: ive been investigating workstreams, where we spin up an issue in that workstream, lets pick a heatmap and move foward, but not spend 3 months talking about it
<jarhar> gregwhitworth: thats the gist of it
<keithamus> +1
<jarhar> gregwhitworth: if you would like that reframed, thats fine
<gregwhitworth> RESOLVED: Create a Global Design System workstream in Open UI and do not start from zero with a component library(s) (TBD)

[mfreed7]

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.

[bkardell]

@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