{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "event",
    "type" : "single",
    "title" : "USWDS Monthly Call - November 2024 |Digital.gov",
    "description": "USWDS Monthly Call - November 2024",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/11/21/uswds-monthly-call-november-2024/index.json","item" : [
    {"kicker" : "USWDS","title" :"USWDS Monthly Call - November 2024","deck" : "The next generation of the design system","summary" : "The U.S. Web Design System (USWDS) team will share their vision for the design system as a product, including USWDS Web Components and other new things the team expects to deliver in 2025.","date" : "2024-11-21T14:00:00-05:00","date_modified" : "2025-01-27T19:42:55-05:00","start_date" : "2024-11-21T14:00:00-05:00","end_date" : "2024-11-21T15:00:00-05:00",
      "event_organizer" : "Digital.gov","registration_url" : "https://gsa.zoomgov.com/meeting/register/vJItfumsrzwiGRcqviGv4fcTLhgHS8ClFEU","youtube_id" : "kFLPOKKEKRE","topics" : {
        
            "human-centered-design" : "Human-centered design",
            "open-government" : "Open government",
            "usability" : "Usability",
            "user-experience" : "User experience"
            },"primary_image" : { "uid" : "2024-uswds-monthly-call-nov-title-card", "alt" :
  "alt: Title card for U.S. Web Design System monthly call, November 21, 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-november-2024.pptx\"\u003eView the slides (Powerpoint presentation, 5 MB, 109 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 November 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 November 2024. Y\u0026rsquo;know it\u0026rsquo;s almost Thanksgiving, so let\u0026rsquo;s just do a classic Thanksgiving-themed USWDS logo in oranges, gold, and brown. Fall foliage. Nothing too clever!\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, glasses —today real-life me is wearing an orange, red, blue, and gold plaid shirt and some green socks, about green-cool-50.\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=\"http://designsystem.digital.gov/about/monthly-calls\"\u003e\u003cstrong\u003edesignsystem.digital.gov/about/monthly-calls\u003c/strong\u003e\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. And today we\u0026rsquo;re continuing something we\u0026rsquo;ve been doing the last couple calls regarding 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 sec 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.\u003c/p\u003e\n\u003cp\u003eSo, 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?\u003c/p\u003e\n\u003cp\u003eWell, first we\u0026rsquo;ll check out a couple of featured sites and then a handful of —* dare I say* — exciting product updates. And then we\u0026rsquo;ll get into it, building off of last month\u0026rsquo;s values presentation into more of what the heck we\u0026rsquo;re actually doing as we look ahead to the next generation of the design system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 4.\u003c/strong\u003e Let\u0026rsquo;s kick it off with a couple of featured sites!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 5.\u003c/strong\u003e First, \u003ca href=\"http://ohss.dhs.gov\"\u003e\u003cstrong\u003eohss.dhs.gov\u003c/strong\u003e\u003c/a\u003e, a site for the Office of Homeland Security Statistics. OHSS\u0026rsquo;s mission is to foster transparency and data-driven homeland security decision-making by analyzing and disseminating timely, objective Department of Homeland Security data and statistics. The OHSS homepage is simple and solid, with a set of three cards up in the hero section, showing:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eInformation related to immigration,\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eCoast Guard maritime response activities, and\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eEmergency and disaster deployments.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe palette is DHS blue and white, with that nice USWDS banner at the top of the page.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 6.\u003c/strong\u003e Related to the gov banner, our second featured site is \u003ca href=\"http://standards.digital.gov\"\u003e\u003cstrong\u003estandards.digital.gov\u003c/strong\u003e\u003c/a\u003e — a new site for the new Federal Website Standards. Federal website standards will help agencies provide high-quality, consistent digital experiences for everyone. The standards cover common visual and technical elements and reflect user experience best practices. We hope to talk more about Federal Website Standards with the Standards team next month, but for now, we can just enjoy the simple content-forward homepage, with a clean nav, a gov banner, a light blue hero section, and the words \u0026ldquo;Deliver consistent digital-first experience for the public.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 7.\u003c/strong\u003e Great work y\u0026rsquo;all. 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 some product updates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 9.\u003c/strong\u003e First, we\u0026rsquo;re on a new monthly release cadence for USWDS releases, and our November release is USWDS 3.10.0.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 10.\u003c/strong\u003e A few notable updates to USWDS 3.10.0:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eThe first is one I\u0026rsquo;m super happy to get out the door to folks. Based on some findings from usability testing, we updated the order of combo box search results. It\u0026rsquo;s a bit of a small thing, but it has a big impact. The component now displays options that start with the query string at the top of the results list, \u003cem\u003efollowed\u003c/em\u003e by options that \u003cem\u003econtain\u003c/em\u003e the query. In the old Combo box, users were confused when they searched for a string like \u0026ldquo;ma\u0026rdquo; in a group of state names and got \u0026ldquo;Alabama\u0026rdquo; as the first result — instead of Maine, Maryland, and Massachusetts. Now, you\u0026rsquo;ll still get \u0026ldquo;Alabama,\u0026rdquo; but it\u0026rsquo;ll come after all the entries that start with the string. Nice!\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eWe also improved the default hint text in the Time Picker.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eAnd, we fixed a bug that caused file input image previews to break when a Content Security Policy is enabled.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnd we\u0026rsquo;ve also included a few other small fixes you\u0026rsquo;ll want to check out.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 11.\u003c/strong\u003e We\u0026rsquo;re working on a December release now, as well as a 1.2.1 release to USWDS Compile that\u0026rsquo;ll help silence some of the distracting deprecation warnings we\u0026rsquo;ve been seeing in our Sass compiles. We\u0026rsquo;re also working to update our code to address those warnings, but it\u0026rsquo;s a little bit complicated! So look for an update to Compile coming soon.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 12.\u003c/strong\u003e We\u0026rsquo;ve also released three new Accessibility test pages: Memorable date, Time picker, and File input. We\u0026rsquo;re rolling right along with accessibility test pages, the next up are Collection, Summary box, Icon list, Button group, and Process list.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 13.\u003c/strong\u003e Next, one that\u0026rsquo;s been a long time coming, and a few months since we previewed it. One of our most requested items: a USWDS design kit for Figma.\u003c/p\u003e\n\u003cp\u003eOur initial Beta version of this new design kit is out now, and you can find it at \u003ca href=\"http://figma.com/community\"\u003efigma.com/community\u003c/a\u003e and by searching for USWDS, or by following [the link in the \u003ca href=\"https://www.figma.com/community/file/1440921849343185329/uswds-design-kit-beta\"\u003echat.\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 14.\u003c/strong\u003e We\u0026rsquo;re considering this a Beta, since it needs a bit more exposure to real-world usage, and probably a bit of adjustment before it\u0026rsquo;s fully ready for production use, but it\u0026rsquo;s ready for its public debut I hope. As we showed a few months back, this design kit brings the complete token library into the software as variables. We\u0026rsquo;ve also added a ton of documentation, even though I\u0026rsquo;m sure there\u0026rsquo;s plenty of room for improvement.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 15.\u003c/strong\u003e This includes 42 USWDS components built with USWDS design tokens, smart layout, custom properties, complete examples, and all the bells and whistles.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 16.\u003c/strong\u003e So, as I said, it\u0026rsquo;s in public Beta now and available for anyone to download now. I\u0026rsquo;m really happy to finally have it out in the world, and if there\u0026rsquo;s interest, perhaps we can do a deeper dive into using the design kit sometime in the new year.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 17.\u003c/strong\u003e In the world of USWDS Discussions, we\u0026rsquo;ve got a couple of things to highlight this month. We\u0026rsquo;ve got an active discussion about a Spinner component proposal, and an active pattern proposal about pre-filled information, as well as a discussion about using USWDS in a Next.js app with Server Side Rendering, and another about inclusive experiences beyond visual design.\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;d love to hear from folks on our accessibility discussion for November: An “autocompletely” useful WCAG technique!\u003c/p\u003e\n\u003cp\u003eAnd we\u0026rsquo;ve also posted the transcript to October\u0026rsquo;s monthly call, including answers to questions we didn\u0026rsquo;t get to in the call. Bonus content!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 18.\u003c/strong\u003e As we\u0026rsquo;ve been saying for the last few months, next month will be the last month for the V1 documentation site before its final sunsetting, so be sure to stop by and say your goodbyes before the end of the year.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 19.\u003c/strong\u003e And finally, one important change about our GitHub repos and contribution that we\u0026rsquo;ll get into our contributing docs soon, but wanted to tell you all about it first. We\u0026rsquo;re implementing some new controls in our repos, and one of the new requirements is \u003cem\u003esigned commits\u003c/em\u003e. If you\u0026rsquo;ve ever looked at a GitHub commit timeline and seen the commits with a \u0026ldquo;verified\u0026rdquo; label, that\u0026rsquo;s what a signed commit looks like. It\u0026rsquo;s just one way we can be more proactive in understanding the provenance of the code in our project — which is notably important to public, distributed, and open source projects like ours. We\u0026rsquo;re posting the instructions for adding \u003ca href=\"https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits\"\u003eGitHub code signing in the chat\u003c/a\u003e. Notably, I believe any commits initiated through the GitHub web interface will be signed by default, so that can be a good option for simpler contributions and you don\u0026rsquo;t want to learn how to set up SSH or GPG on your computer. If you don\u0026rsquo;t have signed commits, we can\u0026rsquo;t merge your code, so set it up if you haven\u0026rsquo;t already. It\u0026rsquo;s just a good practice.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 20.\u003c/strong\u003e So, today, we wanted to spend some time talking about the next generation of the design system. We\u0026rsquo;ve spent a bunch of time talking about our work with Web Components, but what does that mean for the rest of the codebase and what we\u0026rsquo;re planning to deliver next Spring?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 21.\u003c/strong\u003e Joining me today are my colleagues Matt and Anne. First, Anne Petersen, our Experience Design Lead. Anne, can you introduce yourself and give a self description for anyone audio-only?\u003c/p\u003e\n\u003cp\u003eAnne: Absolutely. I’m Anne, my pronouns are they/them, and visually I’m white, with short brown hair — the front’s a bit mussy and the sides \u003cem\u003every\u003c/em\u003e short — with small glasses and headphones, in a mustard yellow flannel. Back to you, Dan.\u003c/p\u003e\n\u003cp\u003eDan: Thanks Anne! Nice flannel!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 22.\u003c/strong\u003e Next, I\u0026rsquo;d like to introduce Matt Henry, our Engineering Lead. Matt, can you introduce yourself and give a self description for anyone audio-only?\u003c/p\u003e\n\u003cp\u003eMatt: Hello! Thanks Dan. I’m Matt, my pronouns are he/him and I’m a bald white man with a close-cropped white beard, glasses, and today I’m wearing a solid dark green shirt. Back to you, Dan.\u003c/p\u003e\n\u003cp\u003eDan: Thanks Matt! We\u0026rsquo;ll hear from Matt and Anne in a sec, but first I wanted to set the stage with a little bit about:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 23.\u003c/strong\u003e Tension and change.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 24.\u003c/strong\u003e We\u0026rsquo;ve talked a lot in the last year about the inevitability and the importance of change from the perspective of what a design system is meant to support.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 25.\u003c/strong\u003e We\u0026rsquo;re trying more and more to be practical but also to take a long view of the design system — trying to imagine both the design system and the teams that use it many years down the road. Does thinking about using USWDS in 10 years (or 20 years?) sound good? Does it still sound vital? Or does that sound like a terrible nightmare? A millstone? Why? What might that tell us about \u003cem\u003ewhat\u003c/em\u003e the design system should be, and \u003cem\u003ehow\u003c/em\u003e it should be?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 26.\u003c/strong\u003e In a positive view of the future we see our key to success as adaptation. That\u0026rsquo;s why it takes the lead in our product values: \u003cstrong\u003eDesign is adaptation\u003c/strong\u003e. We just have to continue to make it work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 27.\u003c/strong\u003e And how we make it work is by helping you adapt, helping you do design work, and trying to learn from that.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 28.\u003c/strong\u003e And that certainly sounds nice. But perhaps the reality of adaptation is \u003cem\u003etension\u003c/em\u003e — conflicting expectations, red in tooth and claw.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 29.\u003c/strong\u003e There\u0026rsquo;s a tension between difference and commonality, between individual identity and group identity. How much should our sites and services look and behave like one another? When does commonality positively affect user experience? When does it negatively affect experience?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 30.\u003c/strong\u003e Similarly there\u0026rsquo;s a tension between customization and configuration. What constraints are healthy constraints? Do we all have to play by the same rules?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 31.\u003c/strong\u003e And there\u0026rsquo;s a tension between present needs and future needs. In the present we want that faster horse. And we want the thing done. We don\u0026rsquo;t \u003cem\u003ecare\u003c/em\u003e about tech debt. Not yet at least. \u003cem\u003eThe future is unknowable, right?\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 32.\u003c/strong\u003e Tension can read as negative, as simply stress. But what if we just add the word \u0026ldquo;dynamic\u0026rdquo; — still stressful, but maybe  productive? This tension can sometimes be a tool.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 33.\u003c/strong\u003e When we\u0026rsquo;re thinking about the future of USWDS, we have to engage with these tensions because we know we have to change, and keep changing. We know that the USWDS codebase is showing its age. In fact, 2025 will be the design system\u0026rsquo;s 10th birthday.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 34.\u003c/strong\u003e When we think about the future of USWDS we think about what folks need to know to \u003cem\u003euse\u003c/em\u003e USWDS. Are these the skills folks still want to learn? What\u0026rsquo;s part of our core identity? Sass? BEM? HTML? CSS?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 35.\u003c/strong\u003e When we think about the future of USWDS we want to keep a good tangible goal in mind, like this variant of our polestar: Make it easier to adopt the design system and stay up to date.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 36.\u003c/strong\u003e And as we listen to folks, we understand that folks \u003cem\u003euse\u003c/em\u003e the design system in all kinds of ways.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 37.\u003c/strong\u003e Whose way.. is the right way? Who\u0026rsquo;s to say?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 38.\u003c/strong\u003e And is there a way to plot a path ahead that acknowledges all the tensions and impossibilities, but has an opinion and isn\u0026rsquo;t just gormless and wishy-washy. Anne, how can we do this?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 39.\u003c/strong\u003e Anne: When we think about shaping the future of our design system, it\u0026rsquo;s worth considering design systems as applied philosophy.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 40.\u003c/strong\u003e They’re our values made tangible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 41.\u003c/strong\u003e They’re our values made \u003cem\u003epractice\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 42.\u003c/strong\u003e They’re how we \u003cem\u003eperceive\u003c/em\u003e the world and make our corner of it better by centering the people we serve.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 43.\u003c/strong\u003e We learn more about both broad layers of people that use the design system — you, the teams who make use of what we make, and the public, or the people using what \u003cem\u003eyou\u003c/em\u003e make out of what \u003cem\u003ewe\u003c/em\u003e make. In the process of learning about \u003cem\u003eboth\u003c/em\u003e, we adapt and evolve. Each of those changes inform the \u003cem\u003enext\u003c/em\u003e changes. And all that we’ve learned informs our supporting core concepts like mission, vision and polestar.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 44.\u003c/strong\u003e Our mission: Shaping the future of government services.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 45.\u003c/strong\u003e Our vision: Empowered and supported digital service teams. Familiar and easy-to-use digital services.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 46.\u003c/strong\u003e Our polestar: We help government teams align, design, and keep their websites and services up to date.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 47.\u003c/strong\u003e And these lead to our values. On the product side: that design is adaptation, compliance is our baseline, we strengthen connections, get to easier earlier, and need to be a good steward.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 48.\u003c/strong\u003e On the engineering side: we embrace the platform. We support user experience with developer experience. We remember that we’re a layer. And we write plain-language code. These are core concepts we can rely on, and refer to when making decisions. The design system becomes our values made tangible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 49.\u003c/strong\u003e So, to go back to basics to think about all of this — this way to support \u003cem\u003eeveryone\u003c/em\u003e and build in a logical, scalable way— I went back to the original — the first — webpage of the World Wide Web.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 50.\u003c/strong\u003e Like the USWDS, the World Wide Web itself is in the public domain. Hey, us too. In accordance with the values that we just set out. In 1993, CERN allowed \u003cem\u003eeveryone\u003c/em\u003e to use the World Wide Web, created there.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 51.\u003c/strong\u003e Here’s the memo from CERN — though I wasn’t intending for you to read it here — it’s got pretty small memo text with some red seals. It notes here that “permission is granted for anyone to use, duplicate, modify and redistribute it.” And CERN of the modern day notes that that page reflected \u003ca href=\"https://home.cern/news/news/computing/30-years-free-and-open-web\"\u003eCERN’s core values of \u003cem\u003eopen collaboration for the benefit of society\u003c/em\u003e\u003c/a\u003e. Which sounds a lot like a mission statement too.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 52.\u003c/strong\u003e Here’s what that original webpage looked like. Plain text, links. Simple.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 53.\u003c/strong\u003e Well, actually \u003ca href=\"https://line-mode.cern.ch/www/hypertext/WWW/TheProject.html\"\u003emore like \u003cem\u003ethis\u003c/em\u003e at the time\u003c/a\u003e. Here, you can see the page building, line by green line on its black background, in the line-mode browser simulator that CERN created for the 30th anniversary of the World Wide Web’s creation. “What’s out there?” is the first kind of menu item here.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 54.\u003c/strong\u003e This original webpage was fairly meta. It referenced itself, self-documented itself, and provided entry and exit points. It contained information about itself, and how to do what \u003cem\u003eit\u003c/em\u003e does, so it could be built upon and evolved upon, into the future. And, to some extent, that’s the basis of design systems in general, and how they also work. It also shows how your values and mission make your system more anchored. Much like how we’re working.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 55.\u003c/strong\u003e So my point here is that what \u003cem\u003ewe’ve\u003c/em\u003e done, in comparison, also has a throughline to what we intend to do and beyond. It makes sense. It builds upon itself.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 56.\u003c/strong\u003e I’m not trying to say we’re \u003cem\u003ejust\u003c/em\u003e like that original World Wide Web itself — that sounds a little hubris-y — but we \u003cem\u003edo\u003c/em\u003e share a belief in our work being open and available and flexible and remixable, modifiable, replaceable, exchangeable — ultimately, \u003cem\u003emodular\u003c/em\u003e. The flexibility to pick and choose what you use and don’t, alongside what you build to be more specific to your use case. As opposed to the kind of closed garden, only-one-way-to-do-it kind of tendency that’s the case on the web in many places. The design system needs to be operable in as many places as possible, so staying closest to the web platform, for example, is our best call to be future-facing. \u003cem\u003eAnd\u003c/em\u003e we think that will help you, in using it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 57.\u003c/strong\u003e So you can \u003cem\u003eanticipate\u003c/em\u003e some of the decisions we might make if you know our values. If you know one of our values is staying as close as possible to the basic foundation of the web, you can probably guess where we’re going, and make your own decisions accordingly, even if we haven’t necessarily made that call yet. But also certainly you can just ask us. That’s what we’re here for every month.\u003c/p\u003e\n\u003cp\u003eNow, to break down the pieces of the decisions we’ve made recently, outlining the shape of this next generation of the system, and more importantly to bring it all back together, I’m going to pass it back over to Dan.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 58.\u003c/strong\u003e Dan: Since we\u0026rsquo;re bringing it all back together, I\u0026rsquo;d like to call the next section United.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 59.\u003c/strong\u003e To understand where we\u0026rsquo;re going, it\u0026rsquo;ll be helpful — for us and for you — to understand what we\u0026rsquo;re hearing in the many conversations we\u0026rsquo;ve had with teams and individuals about adopting USWDS and about Web Component technology.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 60.\u003c/strong\u003e As we\u0026rsquo;ve covered in extensive — perhaps tedious — detail over the last year, we\u0026rsquo;ve talked about how teams integrate the USWDS HTML/CSS spec into application templates, and how the complex and brittle structure of this core codebase can lead to a lot of downstream effort manually keeping up-to-date with changes from release to release. This is the story of USWDS Web Components: how we intend to both simplify a component\u0026rsquo;s API surface and deliver a component that requires less maintenance and fewer dependencies to integrate into a project.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 61.\u003c/strong\u003e And we\u0026rsquo;ve also talked about the tension and tradeoffs involved in using USWDS Web Components: the benefits we\u0026rsquo;ve mentioned — simplicity and maintainability — come at the expense of \u003cem\u003eflexibility\u003c/em\u003e. Because Web Components do more of the work themselves, they leave fewer choices available to designers and developers. They have opinions — they\u0026rsquo;re more prescriptive about what they can and can\u0026rsquo;t do, about what functionality they support — and they may not be \u003cem\u003eyour\u003c/em\u003e project\u0026rsquo;s opinions. In some cases, this can mean that the component cannot do what you need it to do, or what your USWDS-based project code currently does!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 62.\u003c/strong\u003e For all its complexity, traditional HTML/CSS has an incredible amount of power in its customizability. And this customizability has been at the core of our product\u0026rsquo;s value proposition since the beginning. \u0026ldquo;Adopt and adapt\u0026rdquo; is one of our long-time messages and one that\u0026rsquo;s central to our product value of \u0026ldquo;Design as adaptation.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 63.\u003c/strong\u003e Web Components make this value proposition more complicated.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 64.\u003c/strong\u003e When we talk to teams, this is generally what we hear: \u0026ldquo;A simpler way to use USWDS is great. A simpler way to do \u003cem\u003ewhat we need to do\u003c/em\u003e is great. But a simpler way \u003cem\u003eto do something different from what we\u0026rsquo;re doing\u003c/em\u003e is not great. In fact, it would be a big big problem.\u0026rdquo; Web Components are great until they aren\u0026rsquo;t great —* then* they\u0026rsquo;re the problem. They\u0026rsquo;re a potential blocker, and a bottleneck, and countless time-consuming discussions and arguments up and down the product and agency  and given the choice, teams may just not use them. And that’s understandable. The mission and the audience comes first.\u003c/p\u003e\n\u003cp\u003eAnd these are teams that currently use USWDS HTML/CSS. These are mature teams maintaining mature products. These are teams that value their ability to use human-centered design to meet the needs of their audience. Which I hope we all try to do.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 65.\u003c/strong\u003e When it comes to shaping the future of government digital services, we already see the potentially existential risk of building a design system that cannot change and adapt. We see it from both sides: in the cascading maintenance burden of making necessary breaking changes to our core codebase, and we see it in the opinionated constraints of a simplified solution stifling necessary adaptation.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 66.\u003c/strong\u003e Since some amount of effort is necessary on both paths — and both paths are useful — for us, the best resolution to this situation is to continue to improve \u003cem\u003eboth\u003c/em\u003e ways of using the design system, reducing the costs and risks of each over time. And on a case-by-case, component-by-component basis, teams can make the call about which set of costs and constraints is right for their team and their project.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 67.\u003c/strong\u003e So, teams have asked, as we\u0026rsquo;ve moved toward Web Components, what\u0026rsquo;s going to happen to the USWDS 3 codebase? Some of you have asked that question in our Q\u0026amp;As! Well, not only do we plan to continue to maintain it, but we expect \u003cstrong\u003ea long-term technical integration between USWDS Web Components and USWDS core HTML, CSS, and JavaScript\u003c/strong\u003e. Specifically, we see Web Components as something of a simplified API wrapper around USWDS core HTML. When you use a USWDS Web Component, it should \u003cem\u003erender\u003c/em\u003e USWDS core HTML/CSS to the browser. In this model, you can\u0026rsquo;t have the Web Component without \u003cem\u003ealso\u003c/em\u003e bringing along core for the ride.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 68.\u003c/strong\u003e So, we expect to see \u003cem\u003eboth\u003c/em\u003e products co-evolving together into the foreseeable future.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 69.\u003c/strong\u003e And as we take a look at how this would work, I\u0026rsquo;d like to try to simplify the discussion with some new terms. We\u0026rsquo;re now talking about \u003cem\u003etwo\u003c/em\u003e interrelated USWDS products: Web Components–based USWDS components \u003cem\u003eand\u003c/em\u003e our non-Web Component, traditional HTML/CSS/JS codebase of components for the web, the set of components we now call USWDS 3. That\u0026rsquo;s a lot of words, and most of them are \u0026ldquo;web\u0026rdquo; or \u0026ldquo;component.\u0026rdquo; And they\u0026rsquo;re both USWDS.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 70.\u003c/strong\u003e So, from now on, we’re going to call the Web Component product \u003cstrong\u003eUSWDS Elements\u003c/strong\u003e, or just Elements.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 71.\u003c/strong\u003e And we’re going to call the non-Web Component codebase \u003cstrong\u003eUSWDS Core\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 72.\u003c/strong\u003e The key benefit of USWDS Elements is simplification and encapsulation — they\u0026rsquo;re like a little seed, allowing folks to take USWDS Core code anywhere and add it to a site with nothing more than minimal markup and a JavaScript file, like a little USWDS Johnny Appleseed. No necessary compiling, less code on the page, and fewer user-facing markup changes over time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 73.\u003c/strong\u003e You could imagine adding new styling configurations to an Elements component that might \u003cem\u003enot\u003c/em\u003e affect Core, like a component-specific way to add a custom color or border-radius, which would be a trivial change using either custom CSS or a utility class in Core.\u003c/p\u003e\n\u003cp\u003eYou could imagine making a structural change to Core that would not affect Elements, like potentially changing the markup of a Core Accordion to a summary/details pattern.\u003c/p\u003e\n\u003cp\u003eAnd, you could imagine changes that could affect both, like adding a new content element into a link that might help indicate the type of link or information about the size of a file for download. In that instance, both Elements and Core would have to change.\u003c/p\u003e\n\u003cp\u003eBut, wherever they go, they will go together.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 74.\u003c/strong\u003e The creation of Core and Elements as two distinct but integrated products means — ironically — that we don\u0026rsquo;t have to bifurcate the product from a documentation perspective. There\u0026rsquo;s no old USWDS and new USWDS. While there are distinctions in the Elements’ API interface, they\u0026rsquo;re both doing the same kinds of things under the hood. We introduce Core and Elements, but maintain a united USWDS in the docs. This united USWDS will be important because we see many ways to use USWDS: only Elements, only Core, or what we consider most common, especially earlier in our release cycle: a mix of both.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 75.\u003c/strong\u003e This relationship will also affect how we use design tokens in the codebase. USWDS Core is built on Sass functions and mixins. USWDS Elements needs to incorporate CSS Custom Properties to work natively. And teams will want to use whichever flavor of token makes the most sense for them — possibly both in the same product. Not to mention integrating tokens into non-CSS environments like Figma variables and native apps.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 76.\u003c/strong\u003e This leads us to a third new USWDS product: \u003cstrong\u003eUSWDS Tokens\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 77.\u003c/strong\u003e USWDS Tokens is the logical endpoint for our work converting tokens into a canonical JSON data format. In the new model, Sass, CSS Variables, Figma, and other outputs would be considered \u003cem\u003etargets\u003c/em\u003e for token data, and we\u0026rsquo;d be developing plugin \u003cem\u003econverters\u003c/em\u003e for the JSON data to fit those targets. Elements and Core would both consume USWDS Tokens but consume different \u003cem\u003eoutput\u003c/em\u003e from that single source. You could even imagine some teams using USWDS Tokens, but \u003cem\u003enot\u003c/em\u003e using either Core or Elements — only for styling in a custom codebase — similar to how one might use a product like Open Props.\u003c/p\u003e\n\u003cp\u003eThe USWDS Token data itself wouldn\u0026rsquo;t change very frequently, but there\u0026rsquo;d be plenty of other opportunities for improvements, like new converters or perhaps performance-focused subsetters that output only the tokens necessary for a specific USWDS configuration.\u003c/p\u003e\n\u003cp\u003eUSWDS Tokens could also allow for long-requested features like JSON or YAML–based USWDS configuration files. Tokens need the opportunity to evolve separately from something CSS- or Sass-specific.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 78.\u003c/strong\u003e So, our new product model so far features \u003cstrong\u003eUSWDS Elements\u003c/strong\u003e, \u003cstrong\u003eUSWDS Core\u003c/strong\u003e, and \u003cstrong\u003eUSWDS Tokens\u003c/strong\u003e. There are all kinds of modular functionality you could imagine as \u003cem\u003eadditional\u003c/em\u003e standalone integrated products — for instance; we\u0026rsquo;re currently discussing how USWDS might integrate with internationalization via translation objects (called PO files) for common microcopy strings. But there\u0026rsquo;s a fourth product we see the opportunity to introduce alongside Elements, Core, and Tokens next year.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 79.\u003c/strong\u003e And that\u0026rsquo;s \u003cstrong\u003eUSWDS Utilities\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 80.\u003c/strong\u003e We introduced utilities — static, token-based single-purpose classes used for rapid prototyping and targeted stylistic interventions that don\u0026rsquo;t require modifying CSS — in USWDS 2.0. And they\u0026rsquo;re another part of the product that nobody wants to see go away as we \u003cem\u003ealso\u003c/em\u003e pursue Web Component-based USWDS Elements. But utility classes in USWDS are a little clunky. They were a nice addition that still makes a lot of sense but are significantly less sophisticated than purpose-built utility class libraries like Tailwind. They could be more flexible, more specific, more performant, and faster to compile. If you\u0026rsquo;ve seen the USWDS \u003ca href=\"https://uswds-tailwind.com/\"\u003eTailwind project\u003c/a\u003e developed by a community member, you see what a more modern version of USWDS Utilities could do. More and more, we\u0026rsquo;re starting to see utilities as conceptually similar to USWDS Tokens — something that\u0026rsquo;s primarily \u003cem\u003edata\u003c/em\u003e. And just with tokens, there\u0026rsquo;s a lot of power in treating that data as a \u003cem\u003esource\u003c/em\u003e, and specific outputs as \u003cem\u003etargets\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003eYou could imagine USWDS Utilities compiling from JSON to exactly the utility classes we now support, but separate from the USWDS compile process. You could also imagine combining USWDS Utilities and USWDS Tokens into a config that uses a third-party like Tailwind to do the utility class building — as in USWDS Tailwind.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 81.\u003c/strong\u003e Treating the USWDS monolith as separate interrelated products will allow each domain to evolve at its own pace. We don\u0026rsquo;t know yet which will move fastest or how, but we know that we want to be clear about how each is changing, reflecting our value of working in the open.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 82.\u003c/strong\u003e This is why, as we move to this model, we want to lean into semantic versioning. Communication is going to be critical for teams to know what\u0026rsquo;s changing and how it will affect them. When one of these products has a breaking change update, we should convey that information in the version number. You shouldn\u0026rsquo;t have to pore over each set of release notes to know whether you need to pay attention to an individual release — the version number should tell you.\u003c/p\u003e\n\u003cp\u003eWe expect Elements to have fewer breaking changes than Core as we move forward. We expect Tokens and Utilities to have relatively few breaking changes once they get established. This should \u003cem\u003ealso\u003c/em\u003e be reflected in their versioning. You’ll see our major version numbers go up faster in some USWDS products than others.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 83.\u003c/strong\u003e So, what is USWDS 4.0? The simple answer is that there will be no USWDS 4.0. At least, nothing called \u0026ldquo;USWDS 4.0.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 84.\u003c/strong\u003e Instead of USWDS 4.0, we\u0026rsquo;re introducing this new model of USWDS, four interrelated products:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUSWDS Core 4.0:\u003c/strong\u003e The next version after USWDS 3.x — the core HTML/CSS that powers our components.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUSWDS Elements 1.0:\u003c/strong\u003e A simplified API wrapped for USWDS Core, encapsulating USWDS components, starting with those directly connected to Federal Web Standards.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUSWDS Tokens 1.0:\u003c/strong\u003e The USWDS visual language, able to target multiple outputs across devices and platforms.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUSWDS Utilities 1.0:\u003c/strong\u003e A powerful styling and prototyping tool for use with or without USWDS Core.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAnd it\u0026rsquo;s all just USWDS\u003c/strong\u003e, a new generational model that, instead of USWDS 4.0, we\u0026rsquo;re internally calling United.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 85.\u003c/strong\u003e This United model of USWDS has incredible promise for supporting multiple ways of working, multiple models of team collaboration and modes of building, and multiple types of simultaneous change, but it will require real work not only in communication, but in structuring and scoping our work. And for more on that, I\u0026rsquo;ll pass it over to Matt!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 86.\u003c/strong\u003e Matt: Thanks Dan, this is Matt. Let\u0026rsquo;s talk about how we\u0026rsquo;re going to make this work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 87.\u003c/strong\u003e So we\u0026rsquo;re still working out details, but what Dan outlined is the big picture. On the engineering side, we\u0026rsquo;re thinking through how teams will be using a combination of these products, what infrastructure and refactoring we need to support interoperability between these upcoming USWDS products, and what we\u0026rsquo;ll prioritize as we think about getting it all done.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 88.\u003c/strong\u003e From the usage perspective, we imagine the most common scenario is mix and match — with teams selecting the product mix that’s best for their team skills and their product. We tend to think that teams will want to evaluate Elements first.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 89.\u003c/strong\u003e We\u0026rsquo;re designing Elements to be a starting point. If an Elements component meets your team’s needs, then you’re good to go. With Elements, we’re working on striking the right balance between power and ease of use so that these components should work for lots of teams a lot of the time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 90.\u003c/strong\u003e For teams comfortable with the functionality of an Elements component but have an existing infrastructure based on a different component API, we\u0026rsquo;re building Elements to be extensible and interoperable with any Web Components library. Teams can add a custom API wrapper on top of the Elements component to help it better fit into an existing codebase, and they\u0026rsquo;ll still be able to take advantage of the improved stability and maintainability of the USWDS Element under the hood.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 91.\u003c/strong\u003e But just in case your project needs \u003cem\u003emore\u003c/em\u003e configurability than an Elements component offers out-of-the-box, you can always “eject” to the Core component and customize it as much as you need, using the same ways you’re already used to. Many teams will be able to use USWDS Elements for entire projects, but because Elements and Core both use web standard technologies, you’ll be able to mix and match on a component-by-component basis.\u003c/p\u003e\n\u003cp\u003eSupporting this way of working will require a fair bit of refactoring under the hood of what we’re now calling USWDS Core.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 92.\u003c/strong\u003e Right now, even though USWDS is broken up into several packages, users still have to import pretty big chunks of the design system at a time in order for things to work as expected. We need to make the Core codebase significantly more modular so that you’ll be able to add only the components you need (whether those are Core components or Elements) and make sure the scripts and styles required to make those components work are as lightweight as we can make them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 93.\u003c/strong\u003e Part of this move towards greater modularity involves a slight conceptual reframe in how each product in the USWDS family relates to each other. As Dan alluded to earlier, I think of these relationships as being between tools and targets.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 94.\u003c/strong\u003e Right now, a lot of the logic for how styles, tokens, and utilities work is implemented in Sass. Our team authors styles in SCSS, and that makes the sass dependency a critical one for many teams that use USWDS, and it also imposes yet another dependency for some kind of tool to build that Sass when you need it. You might use USWDS Compile for this, or you might have another build tool that does this for you.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 95.\u003c/strong\u003e Eventually, we want to reorient that relationship a bit. At some point in the medium to long term, we’ll author styles directly in web standard CSS. This goes back to some of what we talked about in the October Monthly Call regarding leveraging the web platform.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 96.\u003c/strong\u003e But, I hasten to add, this doesn’t mean we’re going to stop supporting Sass. If you like your Sass, you can keep your Sass. However, one outcome of this reorientation will be that Sass/SCSS is one target among many of the USWDS Tokens package. So, Tokens will have the existing design tokens in a more technology-agnostic format and that will be able to be output into multiple other formats. So, Tokens is one tool that can have many possible targets, such as Sass variables, CSS custom properties, potentially even utility classes, or other formats such as colors for native mobile operating systems.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 97.\u003c/strong\u003e How is this change going to affect you? Importantly, we don\u0026rsquo;t want to introduce significant breaking changes as we move from USWDS 3 to Core 4.0. We believe a lot of the necessary refactoring will not have an impact on you. We won\u0026rsquo;t be changing class names or markup in this version bump — or, if we do, we\u0026rsquo;ll keep it very tightly scoped.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 98.\u003c/strong\u003e Since one of the goals of USWDS Elements is to reduce the development impact of breaking changes, we want to make sure we introduce an Elements version of a component before we consider making significant breaking changes to it on the Core side.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 99.\u003c/strong\u003e Continuity matters to us. The code you rely on will still be here. We’re just working to make things easier, more modular, and less opinionated for you and your teams. There will be changes and there will be bumps, but our new structure is meant to minimize them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 100.\u003c/strong\u003e So what can you expect going into 2025?\u003c/p\u003e\n\u003cp\u003eWe’ll work to release what we can as soon as we can. We’re biased toward shipping early, so you can test sooner rather than later.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 101.\u003c/strong\u003e We’ll work to keep things clear and as simple as possible. We intend that to be our method of operating going forward in the interest of our value of working in the open.\u003c/p\u003e\n\u003cp\u003eWe’ve started documenting big changes and the rationale behind them in Architectural Decision Records in the uswds-proposals repository. You can see the ADRs for the choice to build with Web Components as well as the choice of Lit as the library we’re using to help us author those components. Going forward, we’re going to keep adding ADRs for consequential choices we make, including the ones we’ve been talking about on the call today.\u003c/p\u003e\n\u003cp\u003eAnd that\u0026rsquo;s how we\u0026rsquo;re thinking about this new generation of USWDS from an engineering perspective. Back to you, Dan.\u003c/p\u003e\n\u003cp\u003eDan: Thank you, Matt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 102.\u003c/strong\u003e I\u0026rsquo;ll finish with a little about what to expect in 2025.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 103.\u003c/strong\u003e It\u0026rsquo;s interesting- this is both not so much of a big change and also a really big change for USWDS. Talking with teams about Web Components made a big impact on how we\u0026rsquo;re approaching this transition. Thanks for all you\u0026rsquo;ve shared so far and probably for all you\u0026rsquo;ll continue to share as we move forward. I don\u0026rsquo;t think our current outcome is one I would have predicted going into the process!\u003c/p\u003e\n\u003cp\u003eI think we\u0026rsquo;re really focused on the future these days, and trying to prepare for the reality of change, as well as how we can help prepare \u003cem\u003eyou\u003c/em\u003e for that reality also. This shifts our focus toward sustainable infrastructure changes and a model of the design system that we believe will be both more modern and more resilient.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 104.\u003c/strong\u003e But it \u003cem\u003eis\u003c/em\u003e a priority shift. We\u0026rsquo;re going to be putting more and more time into the product model and interoperability and less time into more new Web Components. But I think this is because we\u0026rsquo;re committed to making this work long-term and work well release-by-release.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 105.\u003c/strong\u003e So, as we look forward to our target date of Spring 2025, here\u0026rsquo;s what we hope to deliver:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUSWDS Elements 1.0:\u003c/strong\u003e A small selection of components, prioritizing those aligned with current pending Federal Website Standards and draft Standards, which, as of now, include Banner, Identifier, and Search. Beyond that, we\u0026rsquo;ll look to launch with a set that begins to be usable for forms. Since we\u0026rsquo;re focusing on simplification for USWDS Elements, we\u0026rsquo;re trying to launch with the most simple components, which teams typically don\u0026rsquo;t need to configure as much — like form fields instead of header and navigation elements.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUSWDS Core 4.0:\u003c/strong\u003e Focusing on interoperability with Elements and Tokens, without affecting existing styles, markup, or Sass-based tools.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUSWDS Tokens 1.0:\u003c/strong\u003e A Style Dictionary-based collection of USWDS design tokens that can power existing Sass in USWDS Core and any token-based needs for our launch of Elements.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUSWDS Utilities 1.0:\u003c/strong\u003e Likely launching with a straightforward port of the existing Sass-based system into a standalone repo.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eWebsite and documentation:\u003c/strong\u003e Incorporating new product information, with a strong focus on improving how we communicate what\u0026rsquo;s new, what\u0026rsquo;s changing, and what\u0026rsquo;s ahead. We want our website to be a practical way to get up to speed on what\u0026rsquo;s going on with USWDS, in addition to all our current guidance, docs, etc.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 106.\u003c/strong\u003e And that\u0026rsquo;s where we see the next generation of the design system, starting in Spring 2025: Not Old USWDS and New USWDS, rather a united USWDS moving forward. And with that, let\u0026rsquo;s get into some Q\u0026amp;A.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 107.\u003c/strong\u003e Audience Q\u0026amp;A\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 108.\u003c/strong\u003e Dan: Thanks for joining today’s USWDS monthly call. Next month, we\u0026rsquo;ll be talking about Federal Website Standards.\u003c/p\u003e\n\u003cp\u003ePlease look out for an event feedback survey from Digital.gov. You\u0026rsquo;ll get this in your email, and there\u0026rsquo;s also a link in the chat. Your feedback makes a difference to us, so we appreciate the extra time it takes you to provide it.\u003c/p\u003e\n\u003cp\u003eAnd if you have a question we couldn\u0026rsquo;t answer in the call, or thought of later, please head into our public Slack and ask it there. We\u0026rsquo;ll be there after the call to answer questions.\u003c/p\u003e\n\u003cp\u003eHave a great day. We\u0026rsquo;ll see you in December!\u003c/p\u003e\n\u003c/div\u003e\u003c/div\u003e\n\n\u003cp\u003eThis month, join the U.S. Web Design System (USWDS) team as they lay out their vision for the direction of the design system.\u003c/p\u003e\n\u003cp\u003eIn this session, you’ll learn about:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWhat the USWDS team is currently developing and why it\u0026rsquo;s important\u003c/li\u003e\n\u003cli\u003eWhat the team expects to deliver in 2025\u003c/li\u003e\n\u003cli\u003eThe design system’s shift toward modularity, and the future relationship between the existing codebase, design tokens, utilities, design kits, and Web Components\u003c/li\u003e\n\u003cli\u003eWhat these changes mean for you as a design system user\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, especially product managers and software engineers.\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\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-11-21-uswds-monthly-call-november-2024.md",
      
      "filepath" :"events/2024/11/2024-11-21-uswds-monthly-call-november-2024.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/events/2024/11/2024-11-21-uswds-monthly-call-november-2024.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/events/2024/11/2024-11-21-uswds-monthly-call-november-2024.md","slug" : "uswds-monthly-call-november-2024","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/11/21/uswds-monthly-call-november-2024/"
    }
  ]
}