{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "event",
    "type" : "single",
    "title" : "USWDS Monthly Call - September 2024 |Digital.gov",
    "description": "USWDS Monthly Call - September 2024",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/09/19/uswds-monthly-call-september-2024/index.json","item" : [
    {"kicker" : "USWDS","title" :"USWDS Monthly Call - September 2024","deck" : "The landscape of Web Components","summary" : "The U.S. Web Design System team will share their exploration of Web Component-based design systems and best practices.","date" : "2024-09-19T14:00:00-05:00","date_modified" : "2025-01-27T19:42:55-05:00","start_date" : "2024-09-19T14:00:00-05:00","end_date" : "2024-09-19T15:00:00-05:00",
      "event_organizer" : "Digital.gov","registration_url" : "https://gsa.zoomgov.com/meeting/register/vJIsdemgrT8tHZvOdHYHRTKhveBs1rHPdBc","youtube_id" : "E826mR1B6_Y","topics" : {
        
            "design" : "Design",
            "human-centered-design" : "Human-centered design",
            "open-source" : "Open source",
            "software-engineering" : "Software engineering"
            },"primary_image" : { "uid" : "2024-uswds-monthly-call-sep-title-card", "alt" :
  "Title card for U.S. Web Design System monthly call, September 19, 2024 at 2 pm, Eastern.", "width" :
  "1200", "height" :
  "628", "credit" :
  "", "caption" :
  "", "format" :
  "png" },"content" :"\n\u003ca\n    href=\"https://s3.amazonaws.com/digitalgov/static/uswds-monthly-call-september-2024.pptx\"\u003eView the slides (Powerpoint presentation, 6.7 MB, 75 slides)\u003c/a\u003e\n\n\n\u003cdiv class=\"usa-accordion accordion\"\u003e\u003ch3 class=\"usa-accordion__heading\"\u003e\n    \u003cbutton\n      class=\"usa-accordion__button\"\n      title=\"View \"\n      aria-expanded=\"false\"\n      aria-controls=\"accordion-1\"\n    \u003e\n      \u003cspan class=\"icon\"\u003e\n          \u003csvg\n            class=\"usa-icon dg-icon dg-icon--standard margin-bottom-05\"\n            aria-hidden=\"true\"\n            focusable=\"false\"\n          \u003e\n            \n            \u003cuse xlink:href=\"/preview/gsa/digitalgov.gov/bc-archive-content-3/uswds/img/sprite.svg#content_copy\"\u003e\u003c/use\u003e\n          \u003c/svg\u003e\n        \u003c/span\u003e\u003cspan class=\"src\"\u003e\n        \u003cstrong class=\"kicker\"\u003eSlide by Slide\u003c/strong\u003eUSWDS Monthly Call - Presentation Script for September 2024\n        \u003c/span\n      \u003e\n    \u003c/button\u003e\n  \u003c/h3\u003e\u003cdiv\n      id=\"accordion-1\"\n      class=\"accordion-body usa-accordion__content usa-prose\"\n    \u003e\u003cp\u003e\u003cstrong\u003eSlide 1:\u003c/strong\u003e Thanks Jeannie, and welcome, everyone, to the U.S. Web Design System monthly call for September 2024. It\u0026rsquo;s getting a bit cooler out here in the pacific northwest. This month we\u0026rsquo;re celebrating the fall equinox this weekend with a USWDS logo in green, white, and blue like the Earth. And at least around here, I\u0026rsquo;m seeing more and more pumpkins around town, both on stoops and in stores, so here\u0026rsquo;s a pumpkin-colored USWDS logo!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 2:\u003c/strong\u003e My name is Dan Williams, he/him, and I\u0026rsquo;m the USWDS project lead. Here, on-screen, is my avatar: dark hair, blue sweater, collared shirt. As of this month, the avatar now has glasses — matching real life me, who\u0026rsquo;s wearing a blue shirt today, green socks, and red slacks, approximately red-60.\u003c/p\u003e\n\u003cp\u003eAs Jeannie mentioned, we are recording this call, and I\u0026rsquo;m happy to say we\u0026rsquo;ve started to be able to share the recordings of these monthly calls publicly. You can find pretty much everything from the last year\u0026rsquo;s worth of monthly calls — back to January 2023 — on our website, at \u003ca href=\"https://designsystem.digital.gov/about/monthly-calls/\"\u003edesignsystem.digital.gov/about/monthly-calls\u003c/a\u003e. We typically post videos shortly after the monthly call, and we also link out to the slides and the script, hosted at Digital.gov. We\u0026rsquo;ve also started collecting each month\u0026rsquo;s Q\u0026amp;A as a GitHub discussion linked from the monthly calls page. We\u0026rsquo;ve posted a link to our monthly calls page in the chat.\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;ll be posting other links and references into the chat as we go along. Today we\u0026rsquo;re trying something new when it comes to chats and questions. Today, in your Zoom window you\u0026rsquo;ll find a Q\u0026amp;A button in addition to a chat button, possibly under a \u0026ldquo;More\u0026rdquo; button. We\u0026rsquo;d like to encourage folks to ask questions in the Q\u0026amp;A section instead of the chat. Take a second now to find the Q\u0026amp;A section and open it up. If any member of our team can answer your question in the Q\u0026amp;A section, we\u0026rsquo;ll do so. Otherwise, there\u0026rsquo;ll be some time for questions and answers at the end of the hour. But the chat\u0026rsquo;s \u003cem\u003estill\u003c/em\u003e nice too! Let\u0026rsquo;s use the chat for introducing ourselves or for any other comments or discussion. Be sure to introduce yourself in the chat — it\u0026rsquo;s nice to know who\u0026rsquo;s here. It\u0026rsquo;s good to have you here today.\u003c/p\u003e\n\u003cp\u003eFor those of you who find the chat distracting, you’re welcome to close or hide those discussions during the main presentation. You can reopen them later during the Q\u0026amp;A session at the end of this call. So thanks! And, with that, let\u0026rsquo;s get started!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 3:\u003c/strong\u003e So what\u0026rsquo;s our agenda for today? Well, we\u0026rsquo;ve got a number of things to show off, largely influenced by community suggestions. We’ve got a couple new sites to feature, a few quick product updates,and then we\u0026rsquo;ll talk about what we\u0026rsquo;re seeing, learning, and thinking about the Web Components landscape. Then we should have time for a bit of Q\u0026amp;A.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 4:\u003c/strong\u003e So let\u0026rsquo;s get into it with today’s featured sites. There are a couple exceptional examples today.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 5:\u003c/strong\u003e First, \u003ca href=\"https://www.pbgc.gov\"\u003epbgc.gov\u003c/a\u003e, a USWDS-powered website for the Pension Benefit Guaranty Corporation. Since 1974, PBGC has protected retirement security and the retirement incomes of over 31 million American workers, retirees, and their families in private sector defined-benefit pension plans. The PBGC homepage features an immediately recognizable USWDS-themed header and navigation in red, white, and blue. The hero image is a complex texture of charts and graphs, with the words FY 2023 Projections Report.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 6:\u003c/strong\u003e And also, a bit closer to home, \u003ca href=\"https://tts.gsa.gov\"\u003etts.gsa.gov\u003c/a\u003e, a new website for the Technology Transformation Services, here at GSA. TTS applies modern methodologies and technologies to improve the lives of the public and public servants. They help agencies make their services more accessible, efficient, and effective with modern applications, platforms, processes, personnel, and software solutions. The TTS homepage shows a gray-blue hero section with an illustration of a diverse range of people using devices. The text reads, \u0026ldquo;Every interaction with the public is an opportunity to improve trust in government.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 7:\u003c/strong\u003e Congratulations and great work! Be sure to let our team know when a new site launches, either with an email or a note on the USWDS public Slack channel!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 8:\u003c/strong\u003e Now for a few product updates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 9:\u003c/strong\u003e We were hoping to get USWDS 3.9.0 out last month, but it just didn\u0026rsquo;t happen. It\u0026rsquo;s much further along now, and I feel pretty confident that it\u0026rsquo;s on track for the end of \u003cem\u003ethis\u003c/em\u003e month.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 10:\u003c/strong\u003e As a reminder, here\u0026rsquo;s some of \u003ca href=\"https://github.com/uswds/uswds/milestone/154\"\u003ewhat\u0026rsquo;s coming in USWDS 3.9.0\u003c/a\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFixes a tab order bug in the mobile header\u003c/li\u003e\n\u003cli\u003eFixes a keyboard/mouse interaction issue in date picker\u003c/li\u003e\n\u003cli\u003eImproves performance of input mask\u003c/li\u003e\n\u003cli\u003eImproves legibility of pagination links\u003c/li\u003e\n\u003cli\u003eAdds ability to add custom breakpoints to utilities\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 11:\u003c/strong\u003e We\u0026rsquo;re also continuing progress with publishing accessibility test pages. We\u0026rsquo;ve got three new ones up on the site now: Checkbox, Radio button, and Combo box. We\u0026rsquo;re posting links to these new pages in the chat, \u003cem\u003eand\u003c/em\u003e we\u0026rsquo;re working on three new component test pages for next month: TK. So stay tuned for those!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 12:\u003c/strong\u003e Next, it\u0026rsquo;s been a bit over five years since we released USWDS 2.0, and it\u0026rsquo;s finally time to sunset the version 1.0 documentation site. We\u0026rsquo;d been keeping it around as an archive for the last couple years, but it\u0026rsquo;s not really possible for us to keep it up in perpetuity, preserved in amber, especially while all across government teams are pushed to be extra intentional about the number of active websites they maintain. So, we\u0026rsquo;ve targeted the end of the year as a decommissioning date. Please say your goodbyes, and reach out at our email address, \u003ca href=\"mailto:uswds@gsa.gov\"\u003euswds@gsa.gov\u003c/a\u003e, if your team uses any aspect of the 1.0 site in your day-to-day work, and we can try to determine if there\u0026rsquo;s anything we should keep before the site is only available via a resource like archive.org.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 13:\u003c/strong\u003e And finally, checking in on our public discussions. There’s a \u003ca href=\"https://github.com/uswds/uswds/discussions/6047\"\u003enew one since last month’s call, which is a proposal for Info or Follow\u003c/a\u003e as a sidebar or portion of a footer, along with a new pattern proposal. We should note we’re still working out the process for patterns to figure out how that should be different from component proposals. This pattern proposal is for \u003ca href=\"https://github.com/uswds/uswds/discussions/6053\"\u003epre-filled information in a form\u003c/a\u003e. We have an accessibility discussion about \u003ca href=\"https://github.com/uswds/uswds/discussions/6063\"\u003ehow you’re all using the range slider\u003c/a\u003e, and lastly, the summary of the \u003ca href=\"https://github.com/uswds/uswds/discussions/6060\"\u003equestions and answers from the August monthly call\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 14:\u003c/strong\u003e Now, let\u0026rsquo;s get into our main topic: the Web Components landscape. I know you have questions about our approach to Web Components and we do, too—lots of questions. As we start to make the big leap out of our legacy codebase and into the next generation of the design system, we want to take the time to understand the landscape of Web Components: how they\u0026rsquo;re documented and used, primarily in design systems, but not exclusively.\u003c/p\u003e\n\u003cp\u003eFrom this landscape analysis, we can begin to identify not only trends and patterns but also aspects of implementations that we identify as particularly effective or notable. From that data, we begin to create a mental map of the problem space — one that will help us chart our own way through.\u003c/p\u003e\n\u003cp\u003eOne note that we will be mentioning product names here and there. These are for reference only and are in no way an endorsement of the site or service.\u003c/p\u003e\n\u003cp\u003eSo, to help talk about what we\u0026rsquo;ve found and what we find notable, I\u0026rsquo;d like to introduce a couple members of our team.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 15:\u003c/strong\u003e First, Matt Henry, the engineering lead on the USWDS team. Matt, can you introduce yourself and give a quick self description for anyone audio-only?\u003c/p\u003e\n\u003cp\u003eMatt: Sure thing. Hey, ya’ll, Matt Henry, based in Raliegh North Carolina, where the sun is finally coming out after a gloomy rainy morning. I use He/Him pronouns and as Dan, said I’m the engineering lead for the design system. I’m a white man with glasses, a close crop beard and bald, wearing I think the same red and gray shirt I wore for last month’s call.\u003c/p\u003e\n\u003cp\u003eDan: Thanks Matt!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 16:\u003c/strong\u003e I\u0026rsquo;d also like to introduce Jacline Contrino, our UX researcher, and a contractor on the USWDS team. Jacline, can you introduce yourself and give a quick self description?\u003c/p\u003e\n\u003cp\u003eJacline: Sure. Hi everyone, I’m Jacline. I use she/her pronouns and today I’m wearing a pink and white striped button-up shirt and big gold hoop earrings. I have shoulder length brown curly hair.\u003c/p\u003e\n\u003cp\u003eDan: Thanks Jacline! Why don\u0026rsquo;t you take it from here and talk about what we\u0026rsquo;ve been doing?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 17:\u003c/strong\u003e Jacline: Thanks Dan. Wouldn\u0026rsquo;t you know that Web Components are a big topic? And we have a lot of questions and things we want to learn!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 18:\u003c/strong\u003e For instance - how do we keep government teams’ needs in mind with what we’re building? What kind of \u003cstrong\u003eteam structures\u003c/strong\u003e, tech stacks, and resources are you all working with?\u003c/p\u003e\n\u003cp\u003eWhat does good \u003cstrong\u003edocumentation\u003c/strong\u003e look like? What are the key things we need to get right?\u003c/p\u003e\n\u003cp\u003eWhat are some of the key ways Web Components are \u003cstrong\u003estructured\u003c/strong\u003e? How does data and content get into a Web Component? What models do they follow? How flexible can they be? And how are they distributed and installed?\u003c/p\u003e\n\u003cp\u003eAnd \u003cstrong\u003eperformance\u003c/strong\u003e: How fast do they load? How much code do they require? How are teams developing Web Components that are resilient and stand up to stress?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 19:\u003c/strong\u003e Those are just a few of our questions — and since it’s nearly impossible to answer all of them with a single research approach, we’re using several methods, such as:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA \u003cstrong\u003elandscape analysis\u003c/strong\u003e of design systems that offer Web Components. What are other design systems doing and what might we want to adopt?\u003c/li\u003e\n\u003cli\u003eA \u003cstrong\u003esurvey\u003c/strong\u003e to gauge government team size, staffing, tech stacks used, familiarity with certain programming languages, and more.\n\u003cstrong\u003e*Discussions\u003c/strong\u003e with teams that are already building with Web Components.\u003c/li\u003e\n\u003cli\u003eDoing one-on-one \u003cstrong\u003einterviews\u003c/strong\u003e for more in-depth and technical conversations with experts to learn about their experiences and lessons learned.\u003c/li\u003e\n\u003cli\u003eAnd finally, the \u003cstrong\u003ebeta program\u003c/strong\u003e itself, and the feedback and issues you provide.\u003c/li\u003e\n\u003cli\u003eWe’re nearly done with the landscape analysis and have completed the survey. We’ve started interviewing folks individually and will continue to do that for the next few weeks.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 20:\u003c/strong\u003e So, let’s talk about what we found with our “Government teams and tools survey.” We sent out a survey last month to gauge team structures, resources, and technology of government digital or product teams.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 21:\u003c/strong\u003e First of all, thanks to all of you who may have filled that out — we got a great response! It’s important to us that we understand your teams and how you work, so we were delighted that so many of you filled it out. We had a total of 115 responses. Over 50 different agencies were represented in the survey which was fantastic.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 22:\u003c/strong\u003e Let’s talk about what we found with digital product team structures first.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 23:\u003c/strong\u003e The size of teams tends to be on the small side. About half of respondents said their team had between 3-10 people. But surprisingly, nearly a quarter reported having large teams of over 20 people. Most teams report having 5 or fewer developers. And the same goes for designers. Surprisingly, about one-in-five respondents say they don\u0026rsquo;t have a developer on their team.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 24:\u003c/strong\u003e Even so, when we looked at all the roles people reported having on their digital or product teams, Developers were the most represented, followed by Designers, UX Researchers, Content Strategists, and Product Leads, respectively.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 25:\u003c/strong\u003e Generally, the feeling among respondents is that their team is not fully staffed and that people are fulfilling multiple roles on their teams.\u003c/p\u003e\n\u003cp\u003eAbout 57% do not think that their team is fully staffed, and about 25% do. A vast majority of respondents (87%) said that people have to fulfill multiple roles on their teams. So, some teams might both feel fully staffed and require folks to accomplish the tasks of multiple roles.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 26:\u003c/strong\u003e Another question we asked was “Does your product or agency have its own design system?” We’re excited to see that, of those who answered this question (which was 82 people), a majority of respondents (or 70%) said that they use a design system in some way.\u003c/p\u003e\n\u003cp\u003eMany of them have already developed or are currently developing their own design system, often extended from USWDS. Others reported that they only use USWDS and don’t have their own design system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 27:\u003c/strong\u003e So what did we learn when it comes to tech stacks and skills of teams?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 28:\u003c/strong\u003e We asked about teams’ familiarity with certain coding languages, GitHub, and Web Components.\u003c/p\u003e\n\u003cp\u003eWe learned that teams are most familiar with HTML. That holds true for CSS and JavaScript as well, although familiarity for those technologies was a little less than with HTML — particularly JavaScript.\u003c/p\u003e\n\u003cp\u003eMost reported being familiar with GitHub, and a large proportion are “somewhat familiar” rather than “very familiar” with Web Components, so comparatively less than the other technologies.\u003c/p\u003e\n\u003cp\u003eAs for most used technologies, folks reported that React and Angular are their most-used frameworks. Again, HTML, CSS, and Javascript were the most used programming languages. And npm, Yarn, and CDNs are the most common package managers and distribution systems teams use.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 29:\u003c/strong\u003e Given these findings, we have some takeaways as we develop Web Components.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 30:\u003c/strong\u003e We know we need to make USWDS easy to adopt for small teams that are understaffed and have few or no developers. For instance, installation and setup should be as simple as possible, and our documentation should be clear, explicit, and not make too many assumptions about technical familiarity. This would also benefit those who said they’re not very familiar with Web Components.\u003c/p\u003e\n\u003cp\u003eSince many of you reported that you often fulfill multiple roles on your team, we should, again, be careful not to make assumptions. We should focus on what people are trying to do rather than \u003cem\u003ewho does it\u003c/em\u003e since many might be doing the job of a developer \u003cem\u003eand\u003c/em\u003e a designer.\u003c/p\u003e\n\u003cp\u003eAnd finally, now that we know a bit more about the tech stacks used on many government teams, we can better keep those in mind as we develop Web Components to ensure easier, seamless integrations.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 31:\u003c/strong\u003e Jacline: Now let\u0026rsquo;s take a look at the Web Component landscape analysis we’re starting to wrap up.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 32:\u003c/strong\u003e Let’s start by sharing our research questions.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 33:\u003c/strong\u003e We were interested in a few specific categories:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDocumentation\u003c/strong\u003e: What are other design systems prioritizing in terms of Web Component documentation? What types of content do we see?\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCode structure\u003c/strong\u003e: How are other design systems building Web Components? What\u0026rsquo;s their component model? How does content and data get into them? In general, from a developer\u0026rsquo;s perspective: what does a component look like?\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCode size and performance\u003c/strong\u003e: How big are these things? How much data does a browser have to load before the component loads? Is there any commonality around a component\u0026rsquo;s footprint, when comparing similar components?\u003c/li\u003e\n\u003cli\u003eand \u003cstrong\u003eDistribution\u003c/strong\u003e: How are these components getting from the design system to the project using it? How are they loaded onto the page? How straightforward is it to add a component to a project?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 34:\u003c/strong\u003e We’re approaching this landscape analysis in a collaborative way, since there\u0026rsquo;s a lot of subject matter expertise required to collect and understand this information! Our three senior developers have been working with me, and we’re also working closely with our Product Lead (Dan) and Engineering Lead (Matt) on the fed side.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 35:\u003c/strong\u003e We drew from about a dozen different design systems for our analysis, from inside and outside the government space, both in the United States and elsewhere. This includes government design systems from VA, CMS, and the state of California, as well as common non-government Web Component–based systems like Carbon, Nord, Patternfly, and Shoelace.\u003c/p\u003e\n\u003cp\u003eSo far we’ve collected data on a few specific components common to most design systems: \u003cstrong\u003elink\u003c/strong\u003e, \u003cstrong\u003ecard\u003c/strong\u003e, \u003cstrong\u003eaccordion\u003c/strong\u003e, and \u003cstrong\u003ealert\u003c/strong\u003e. Individual core team developers are collecting data across design systems to update our landscape spreadsheet.\u003c/p\u003e\n\u003cp\u003eWe’ve had several whiteboard sessions to identify trends and findings. This helps us build a common understanding and familiarity with the types of decisions design systems are making, refine our own questions, and often uncover new ones.\u003c/p\u003e\n\u003cp\u003eThis effort is still ongoing but here’s what we\u0026rsquo;ve learned so far, starting with documentation.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 36:\u003c/strong\u003e Documentation is at the center of the experience, and it\u0026rsquo;s often the first opportunity to interface with the product. And we\u0026rsquo;ve seen that design systems have their own priorities and approaches.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 37:\u003c/strong\u003e Essentially, documentation helps you do what you need to do. What were we trying to do? Well, we looked at a few tasks:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e*Getting familiar with a component\u003c/strong\u003e: Kicking the tires, as it were - understanding how to work with a component as directly as possible.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eInstalling a component into a project\u003c/strong\u003e: How do you get it and use it?\u003c/li\u003e\n\u003cli\u003eand \u003cstrong\u003eConfiguring and customizing a component\u003c/strong\u003e: How can you make a component do what you need it to do? Either changing what it does or changing how it looks.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 38:\u003c/strong\u003e Let’s talk about the ways documentation can help users get familiar with a component.\u003c/p\u003e\n\u003cp\u003eThe most common way that systems try to build familiarity is with interactive demos — giving developers the opportunity to manipulate a component and see how it behaves, often when still in the context of documentation. This was ubiquitous in nongovernment design systems, and common — if not consistently so — in government design systems.\u003c/p\u003e\n\u003cp\u003eA couple of design systems build most interactivity directly into their docs pages, but most design systems direct users to external platforms such as Storybook, CodePen, or Code Sandbox to allow this kind of interactivity and basic prototyping, like what we see on this slide — an example of Storybook documentation that allows a developer to manipulate properties and text content.\u003c/p\u003e\n\u003cp\u003eBut, it wasn\u0026rsquo;t always clear when there was interactive functionality available. This link was sometimes buried in the docs.\u003c/p\u003e\n\u003cp\u003eWithout some kind of interactive functionality, developers have to rely only on API documentation to understand what a component can do, and increasingly, the ubiquity of interactive documentation outside of government indicates that developers will increasingly expect the ability to interact with the component \u003cem\u003ebefore\u003c/em\u003e they install it into a project.\u003c/p\u003e\n\u003cp\u003eWe see interactivity as critical to the developer experience.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 39:\u003c/strong\u003e How do you install a component into your project? Finding documentation that answers this question was a bit of a challenge for us. It was rarely clear from a component\u0026rsquo;s page how you would install the component into your project. Only a handful of design systems had an \u003cstrong\u003einstallation\u003c/strong\u003e section in the component documentation. On this slide, we see an example from the California Design System, which shows how to install the component, through either npm or via a CDN.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s possible that for many design systems, installation is baked into some other aspect of the product, but it was surprising to find that so few of them provided installation instructions from the component page. USWDS is, perhaps, distinct in our expectation that teams will use our Web Components a la carte — that is, individually and selectively — so this may have influenced our expectations.\u003c/p\u003e\n\u003cp\u003eWe see value in making this information clear and prominent.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 40:\u003c/strong\u003e Once someone installs a Web Component package, they’ll need to connect the component to their application\u0026rsquo;s data, content, and logic — and configure the component to both do what it needs to do and display how it needs to display. This is the core responsibility of any component in an application. Establishing and maintaining this connection and configuration is perhaps a developer\u0026rsquo;s most important task.\u003c/p\u003e\n\u003cp\u003eSo we took note of how other design systems are documenting their Web Component connection and configuration options, otherwise known as the Application Programming Interface, or API.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 41:\u003c/strong\u003e When it comes to documenting an API, there are a number of common ways of interacting with components reflected in documentation.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eProperties\u003c/strong\u003e: Settings passed to component markup. For example, an alert component may have a \u003ccode\u003evariant\u003c/code\u003e property that can be set to something like \u003ccode\u003ewarning\u003c/code\u003e, \u003ccode\u003einfo\u003c/code\u003e, or \u003ccode\u003eerror\u003c/code\u003e depending on the type of alert. This property usually changes the color of the alert and its icon.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEvents\u003c/strong\u003e: Data a component sends based on a component interaction. For example, an input component may have a \u003ccode\u003eblur\u003c/code\u003e event that the component emits (or \u0026ldquo;fires\u0026rdquo;) when a user navigates away from the input and it loses focus. (It loses focus, thus, \u0026ldquo;blur\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSlots\u003c/strong\u003e: Named content regions inside a component. For example, a Card component might have a slot named \u003ccode\u003efooter\u003c/code\u003e where you\u0026rsquo;d add the content that belongs at the bottom of the card.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eParts\u003c/strong\u003e: Subsections of a component, styleable with CSS. For example, an Accordion component might have a part for an individual item\u0026rsquo;s open/close indicator.\u003c/li\u003e\n\u003cli\u003eand \u003cstrong\u003eTokens\u003c/strong\u003e: CSS variables that influence component styling. For example, an \u003ccode\u003ecard-border-radius\u003c/code\u003e CSS variable might set the border radius for all application cards.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePretty much every component has properties of some sort, and we see property documentation in any Web Components–based design system. The rest of the elements of an API can vary from system to system and component to component. Less common elements of an API, but still potentially useful include:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eMethods\u003c/strong\u003e, which are JavaScript-specific controls for component interactivity.\u003c/li\u003e\n\u003cli\u003eand \u003cstrong\u003eContent model\u003c/strong\u003e, which is a way to group properties that accept content together.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 42:\u003c/strong\u003e We found that overall, Web Component API shared some structural commonalities.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAPIs are consistently organized using the categories we looked at in the previous slide.\u003c/li\u003e\n\u003cli\u003eThe API almost always appears on the same page as other component information, though it can occasionally appear in a page-level tab.\u003c/li\u003e\n\u003cli\u003eAPI documentation is consistently organized using tables showing the names of the API items, the type of data they accept, and their default value.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnd all of this tends to be more understandable when it\u0026rsquo;s tied either to some kind of example, or to an interactive component where you can try out the setting in the component.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 43:\u003c/strong\u003e As we mentioned earlier, we can\u0026rsquo;t expect that everyone shares the same level of expertise, especially around Web Components. We identified some real usefulness in providing links to contextual information about API categories, like this example of a link to learn more about using slots, next to a component\u0026rsquo;s slots documentation.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 44:\u003c/strong\u003e But, looking through the components and the documentation together, we sometimes would see places where there seemed to be undocumented functionality, particularly related to undocumented CSS parts.\u003c/p\u003e\n\u003cp\u003eDesign tokens didn\u0026rsquo;t yet feel well integrated. Either they were omitted, or there were so many of them documented that they were hard to browse and understand — a real wall of text and code.\u003c/p\u003e\n\u003cp\u003eDesign token documentation, in general, while potentially of use to designers, was one of the most designer-unfriendly parts of the documentation. Which leads us to wonder: \u003cem\u003eIs this type of documentation only for developers\u003c/em\u003e? And perhaps that\u0026rsquo;s OK. Maybe the appropriate place for designer-friendly documentation is in the tools designers are already using: in design kits and designer-focused software.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 45:\u003c/strong\u003e Another thing we looked at was how other design systems are documenting \u003cstrong\u003emultiple frameworks, or component flavors\u003c/strong\u003e. In other words, how do they document components available in multiple formats: like a component available as plain HTML, Web Components, and also as React. We will be in this situation as we move to Web Components, supporting both the new generation of the design system, and the existing legacy version we use today.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 46:\u003c/strong\u003e Design systems tend to approach \u003cstrong\u003edistinguishing formats, and documenting formats\u003c/strong\u003e, differently. Some use tabs to display documentation for different versions on the same page, some split formats onto different pages, some handle different formats on different platforms (like Storybook) or completely different websites.\u003c/p\u003e\n\u003cp\u003eAt times, it was unclear if Web Components even existed in some design systems, and took some digging to figure it out!\u003c/p\u003e\n\u003cp\u003eDistinguishing and documenting both legacy USWDS and Web Components USWDS will be a challenge. We know that supporting interactivity is pushing us in the direction of Storybook documentation for the near term, but we\u0026rsquo;ll have to work extra hard to make it clear to users what documentation lives where.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 47:\u003c/strong\u003e And lastly, we looked at how design systems communicate component \u003cem\u003estatus\u003c/em\u003e. For example, how do design systems help users answer questions like: “Should I use this component? How mature is it? Is it passing the required checks?”\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 48:\u003c/strong\u003e We looked at how design systems are documenting \u003cstrong\u003eaccessibility status\u003c/strong\u003e of components.\u003c/p\u003e\n\u003cp\u003eWe found that while most do not provide this information at all, a handful did, mostly with tags. We really liked one design system that used testing tags for different component states and test types, such as keyboard navigation test status.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 49:\u003c/strong\u003e \u003cstrong\u003eWhen it comes to indicating component maturity\u003c/strong\u003e, such as if the component is in an experimental phase, a stable phase, deprecated, etc., again, many design systems use clear and simple tags to communicate that, although we did find one that used a type of step indicator to show the component’s progress through a multi-step process (as we’re showing in the top screenshot on this slide). Tags are usually at the top of the page but they also occasionally show up in the side navigation, and sometimes icons are used as well. Some tag labels we saw were things like: in research, alpha, beta, production, planned, draft, new, ready, stable, experimental, etc. Some indicate version number with tags too.\u003c/p\u003e\n\u003cp\u003eAcross design systems, status tags serve as a kind of mini set of dashboard lights for a component. Users are likely growing accustomed to finding indicators at the top of a component\u0026rsquo;s page that give an at-a-glance confirmation that a component is OK to use and conforms to requirements.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 50:\u003c/strong\u003e Dan: This is Dan. Documentation is a huge subject, and while there are lots of ways to approach guidance across design systems, we\u0026rsquo;ve identified a few key common user stories related to technical guidance for components. We need to support:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAt-a-glance confirmation that a component is OK to use.\u003c/li\u003e\n\u003cli\u003eAn obvious location for Web Components documentation, connected to our existing documentation.\u003c/li\u003e\n\u003cli\u003eThe ability to interact with the component before installing it into a project.\u003c/li\u003e\n\u003cli\u003eSuccinct component-level installation instructions.\u003c/li\u003e\n\u003cli\u003eClear and logical API guidance alongside an interactive component.\u003c/li\u003e\n\u003cli\u003eA documentation-driven approach that keeps documentation current with functionality.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBack to you Jacline!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 51:\u003c/strong\u003e Jacline: Thanks Dan —Beyond documentation, we wanted to learn how design systems are distributing Web Components.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 52:\u003c/strong\u003e The quick answer is that most design systems offer distribution through an npm package or directly through a CDN link. One design system offered a direct download of a zip file. But, as we mentioned earlier, it wasn’t always easy to find the installation instructions, and it wasn\u0026rsquo;t always clear if teams were able to install only specific components. Matt, what are our preliminary thoughts on distribution?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 53:\u003c/strong\u003e Matt: Thanks Jacline. We’ll most likely offer a couple of ways that users can add USWDS web components to their sites and applications. First, we’ll definitely have an NPM package. Since there’s a package for the current version of USWDS, many teams will already be familiar with this way of getting our code into their projects.\u003c/p\u003e\n\u003cp\u003eThe USWDS Web Components NPM package will have pre-built, but unoptimized versions of the components to allow you to not just to add them, but also to extend and modify them. When I say the components are pre-built, I mean that we’ll run the component source code through our build tool—a tool called vite—to bundle all the dependencies together, and compile any styles that need preprocessing. Pre-building in this way is how we’re moving past the need for a separate package like uswds-compile for building USWDS web components. If you install the components from NPM, this is what you’ll get.\u003c/p\u003e\n\u003cp\u003eAlternatively, we also see value in distributing the components via a Content Delivery Network, or CDN. CDNs are third-party platforms that are optimized for fast distribution of assets, like code, directly to the end-user’s browser. Adding the CDN version of the Web Components to a project should be as simple as adding a script tag to the page pointing to the CDN’s URL. You’ll be able to immediately start working with the components on any page that includes that script tag pointing to the CDN link.\u003c/p\u003e\n\u003cp\u003eWe expect that different installation methods will work better for different teams, depending on their needs. CDNs can be very helpful for teams that don’t want or need to do their own optimization of components, and just want to easily add them to their sites or applications without the complexity of a build process. Alternatively, packages are great for teams that want to interact more directly with the code inside of components, or who have their own build pipelines where they’ll integrate USWDS Web Components.\u003c/p\u003e\n\u003cp\u003eNow over to Dan to talk component structure!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 54:\u003c/strong\u003e Dan: Thanks Matt — Ok, one the gnarliest items we\u0026rsquo;re starting to get into in our landscape analysis is component structure: how do components express what we might think of as their component model? Perhaps the best way to explain this is to look at an example.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 55:\u003c/strong\u003e Way back a million years ago in April, we gave an introduction to Web Components, which included this slide that outlined a potential model for a Breadcrumb Web Component. The general idea with component modeling is that with Web Components, we\u0026rsquo;re able to simplify our component in a way that\u0026rsquo;s often impossible with conventional markup that uses only classed elements for structure and presentation. We can reduce it to only \u003cem\u003ethe model\u003c/em\u003e of a Breadcrumb.\u003c/p\u003e\n\u003cp\u003eThe Breadcrumb in this slide reduces the 54+ lines of conventional markup to 6 lines of Web Component markup, by simplifying a Breadcrumb to a collection of links.\u003c/p\u003e\n\u003cp\u003eUnder the hood, the Web Component uses JavaScript to manipulate that simplified markup into the markup required to render the complete Breadcrumb in the browser.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 56:\u003c/strong\u003e We could call this particular modeling technique \u003cstrong\u003eSimplified HTML Web Component\u003c/strong\u003e: Structured content with simplified form, since it uses simplified native HTML as the core of the model and wraps it in a Web Component wrapper.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 57:\u003c/strong\u003e Another modeling technique might take a similar approach but provides a more semantically complete HTML core. We could call this a \u003cstrong\u003eStandard HTML Web Component\u003c/strong\u003e: Structured content with complete semantic form. You might think of these HTML-based models as a \u003cem\u003eprogressive enhancement\u003c/em\u003e approach to Web Components, using the building blocks of native HTML, but using the Web Component custom element to style, enhance, and provide an interface layer to JavaScript frameworks.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 58:\u003c/strong\u003e But you could go further and abstract away native HTML altogether. Perhaps systems can build a more straightforward model by leaving native HTML behind. Instead of anchor links (\u003ccode\u003ea\u003c/code\u003e links), this model uses a custom subcomponent instead. We could call this a \u003cstrong\u003eModularized Web Component\u003c/strong\u003e: Structured content abstracted with custom elements. This can be useful if the component has a structure that doesn\u0026rsquo;t translate obviously and directly into native HTML. Subcomponents can help modularize a component and sometimes give teams options for rearranging component internals.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 59:\u003c/strong\u003e And at the farthest end of the abstraction spectrum is a Web Component with no content at all — no markup outside of the properties in the custom element itself. We could call this a \u003cstrong\u003eSelf-Contained Web Component\u003c/strong\u003e: with content fully abstracted as properties. Here we see an example of a self-contained breadcrumb, where the links are expressed as a JSON object, converted into a string and passed into a \u003ccode\u003elinks\u003c/code\u003e attribute.\u003c/p\u003e\n\u003cp\u003eAnd this is the lens we\u0026rsquo;ve started to use to understand the landscape of design system approaches to component structure.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 60:\u003c/strong\u003e What can we learn about how systems represent the parts of a component?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 61:\u003c/strong\u003e Across the landscape, is content content? Or data?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 62:\u003c/strong\u003e And do design systems use mostly native elements or mostly custom elements in their internal structure?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 63:\u003c/strong\u003e We\u0026rsquo;ve started by looking at the Accordion component and the Alert component. And the results are… inconclusive! But, with only the exception of one design system\u0026rsquo;s Accordion component, we don\u0026rsquo;t see many examples of passing elements other than paragraph elements (\u003ccode\u003ep\u003c/code\u003e tags) into Web Component content. The biggest consistency we can identify seems to be that design systems will be inclined to build self-contained components unless those components need to parse rich text, or text that\u0026rsquo;s less structured.\u003c/p\u003e\n\u003cp\u003eAccordions are more likely to have their primary content as content and heading content as data. Alerts are something of a mix between content as data and as content.\u003c/p\u003e\n\u003cp\u003eAlerts tend to be too simple to warrant modularization and subcomponents, but Accordions will usually use subcomponents if the component accepts the heading as content and not as data.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 64:\u003c/strong\u003e But we\u0026rsquo;ve also expanded our scope when it comes to Web Component structure, since it\u0026rsquo;s an active topic of conversation, with a lot of interest and opinions from developers inside and outside of design systems. Matt, can you talk about why that\u0026rsquo;s so?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 65:\u003c/strong\u003e Matt: Thanks Dan. The active discussions around Web Components these days are centered around performance and, as you alluded earlier, progressive enhancement. One thing that almost all of the design systems we looked at have in common is that the components more or less require JavaScript to render content. As we saw, you can use those components a lot like you might use a self-contained React component where the tag itself is empty or has minimal content inside.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 66:\u003c/strong\u003e In the landscape analysis, we didn’t see many custom-element–based design systems using the HTML Web Components model. The California Design System\u0026rsquo;s Accordion component which contains a set of native HTML \u003ccode\u003edetails\u003c/code\u003e and \u003ccode\u003esummary\u003c/code\u003e elements is probably the best example. However, this approach is gaining a lot of momentum with developers who focus on performance and accessibility.\u003c/p\u003e\n\u003cp\u003eBecause HTML is what all browsers understand by default, when a component is written this way, the content inside renders, whether or not JavaScript runs or whether or not it runs promptly. If and when JavaScript executes, it will apply the component’s custom look and feel; the styles and enhancements. But if it doesn’t, the user can still see the content, and interact with the browser-native controls.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 67:\u003c/strong\u003e HTML remains the future-proof foundation of the web. When you can’t always predict the context in which code is going to run, and when we think about potential edge cases at scale—especially with the availability needs of government products and services—it makes sense to consider the resilience of HTML, the importance of critical content, and the continued relevance of a progressive enhancement approach.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 68:\u003c/strong\u003e Dan: Thanks Matt. So the last thing I\u0026rsquo;d like to quickly touch on is performance. It\u0026rsquo;s one of the last things we\u0026rsquo;ve been able to get to in our landscape analysis, but it\u0026rsquo;s something that\u0026rsquo;s growing in importance.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 69:\u003c/strong\u003e Like so many other things, performance is complicated. Caching, compression, application structure, hydration, and code quality all play a role. But there\u0026rsquo;s still some value in tracking good old fashioned code size.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 70:\u003c/strong\u003e Here we see a selection of sizes of Alert Web Component JavaScript. Some of these were easy to measure, since they were self-contained. Others are estimates since we weren\u0026rsquo;t able to directly install them in projects and they included imports that we haven\u0026rsquo;t fully mapped and measured. But I still think this gives a good sense of the differences in the landscape, with the smallest coming in at 3 KB, and the rest hanging out in the general vicinity of 10-12 KB.\u003c/p\u003e\n\u003cp\u003eAnd then there\u0026rsquo;s the outlier at 367 KB. Maybe it was having a bad day, and to be fair, it gzips down to about 35 KB, but still, that can take up a bit of a project\u0026rsquo;s performance budget!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 71:\u003c/strong\u003e Accordion didn\u0026rsquo;t have this extreme outlier, but is a heavier package in general, with an average of around 30 KB.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s still pretty early in our performance analysis, but we want to be really considerate as we move forward, understanding the balance between functionality and weight, and trying to pick a path forward that delivers the necessary amount of configuration in the smallest possible size.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 72:\u003c/strong\u003e Almost every item we\u0026rsquo;ve discussed in our landscape analysis is a question of balance and priority. There are rarely clear right answers and wrong answers, rather decisions that favor one outcome over another. This landscape analysis is an important tool for us in understanding different approaches to product balance. This landscape analysis is just another data source, alongside the surveys, interviews, discussions, Beta feedback, and other perspectives we hear in forums like the monthly call.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 73:\u003c/strong\u003e We\u0026rsquo;re doing our best to understand what a good balance looks like for our design system and for the diverse and wide-ranging audience of folks that use our design system and use the products we build with it. As we move forward our legacy implementation of USWDS into a Web Components generation we\u0026rsquo;ll be using a number of principles and goals as our guide.\u003c/p\u003e\n\u003cp\u003eFirst, our design principles:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eStart with real user needs\u003c/li\u003e\n\u003cli\u003eEarn trust\u003c/li\u003e\n\u003cli\u003eEmbrace accessibility\u003c/li\u003e\n\u003cli\u003ePromote continuity\u003c/li\u003e\n\u003cli\u003eListen\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnd next our mission, vision, and polestar: Helping government teams align, design, and keep their websites and services up to date. In the service of empowered and supported digital service teams and familiar and easy-to-use digital services. So, together we can shape the future of government digital services.\u003c/p\u003e\n\u003cp\u003eAs we shape the future of the design system, we believe there\u0026rsquo;s at least one more layer of principles to explore: Product and Engineering principles. These answer the question, \u003cem\u003ehow\u003c/em\u003e are we designing the design system in the service of our design principles and mission, and what does this mean for our product.\u003c/p\u003e\n\u003cp\u003eThese aren\u0026rsquo;t abstract things, they influence what we do and our approach to judging the success of what we do. Next month, we\u0026rsquo;ll try and tie it all together with a principles-driven approach to USWDS.\u003c/p\u003e\n\u003c/div\u003e\u003c/div\u003e\n\n\u003cp\u003eThis month, join the U.S. Web Design System (USWDS) team in exploring the landscape of Web Components. The team will share their recent landscape analysis of Web Components-based design systems and discuss how these findings set a course for future USWDS development.\u003c/p\u003e\n\u003cp\u003eIn this online session with the USWDS team, you will:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eLearn what’s new in USWDS 3.9\u003c/li\u003e\n\u003cli\u003eExplore how other design systems are approaching Web Components\u003c/li\u003e\n\u003cli\u003eGain insight to the team’s thoughts about where USWDS might fit in the broader landscape of modern design systems\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eThis event is best suited for:\u003c/strong\u003e Design system users of all levels. This will be a technical discussion geared toward developers, but anyone can attend; it requires no specialized knowledge.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSpeakers\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDan Williams\u003c/strong\u003e - Product Lead, USWDS\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMatt Henry\u003c/strong\u003e - Engineering Lead, USWDS\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnne Petersen\u003c/strong\u003e - Experience Design Lead, USWDS\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJacline Contrino\u003c/strong\u003e - UX Researcher, USWDS contractor\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"join-our-communities-of-practice\"\u003eJoin our Communities of Practice\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://designsystem.digital.gov/about/community/\"\u003eUSWDS\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.section508.gov/manage/join-the-508-community/\"\u003eSection 508 IT Accessibility\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cem\u003eThis event is part of a monthly series that takes place on the third Thursday of each month. Don’t forget to set a placeholder on your personal calendar for our future events this year.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"about-the-uswds\"\u003eAbout the USWDS\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://designsystem.digital.gov/\"\u003eThe U.S. Web Design System\u003c/a\u003e is a toolkit of principles, guidance, and code to help government teams design and build accessible, mobile-friendly websites backed by user research and modern best practices.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://designsystem.digital.gov/\"\u003eThe U.S. Web Design System\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/uswds/uswds/issues\"\u003eContribute on GitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"mailto:uswds@gsa.gov\"\u003eEmail Us\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://digital.gov/communities/uswds/\"\u003eJoin our community\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/uswds\"\u003eFollow @uswds on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cem\u003eDisclaimer\u003c/em\u003e: All references to specific brands, products, and/or companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.\u003c/p\u003e\n",
      "branch" : "bc-archive-content-3",
      "filename" :"2024-09-19-uswds-monthly-call-september-2024.md",
      
      "filepath" :"events/2024/09/2024-09-19-uswds-monthly-call-september-2024.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/events/2024/09/2024-09-19-uswds-monthly-call-september-2024.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/events/2024/09/2024-09-19-uswds-monthly-call-september-2024.md","slug" : "uswds-monthly-call-september-2024","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/09/19/uswds-monthly-call-september-2024/"
    }
  ]
}