{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "event",
    "type" : "single",
    "title" : "USWDS Monthly Call - October 2024 |Digital.gov",
    "description": "USWDS Monthly Call - October 2024",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/10/17/uswds-monthly-call-october-2024/index.json","item" : [
    {"kicker" : "USWDS","title" :"USWDS Monthly Call - October 2024","deck" : "Product and engineering principles","summary" : "The U.S. Web Design System team will share the product and engineering principles they're using to guide the development of the design system. event_organizer: Digital.gov","date" : "2024-10-17T14:00:00-05:00","date_modified" : "2025-01-27T19:42:55-05:00","start_date" : "2024-10-17T14:00:00-05:00","end_date" : "2024-10-17T15:00:00-05:00",
      "registration_url" : "https://gsa.zoomgov.com/meeting/register/vJIsfuqsrzwuE5Vksm7GGAK9tfUz8dy-9Sc","youtube_id" : "H8XUPJxiUEc","topics" : {
        
            "human-centered-design" : "Human-centered design",
            "open-government" : "Open government",
            "usability" : "Usability",
            "user-experience" : "User experience"
            },"primary_image" : { "uid" : "2024-uswds-monthly-call-october-title-card", "alt" :
  "Title card for U.S. Web Design System monthly call, October 17, 2024 at 2 pm, Eastern.", "width" :
  "1200", "height" :
  "630", "credit" :
  "", "caption" :
  "", "format" :
  "png" },"content" :"\n\u003ca\n    href=\"https://s3.amazonaws.com/digitalgov/static/uswds-monthly-call-october-2024.pptx\"\u003eView the slides (Powerpoint presentation, 2.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 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 October 2024. We\u0026rsquo;re clearly in the middle of spooky season. With Halloween only a couple weeks away, the USWDS logo is trying to get its costume ready. It\u0026rsquo;s doing its best to be a vampire, but — as we can see here with the two triangles in red and the rest in black — it\u0026rsquo;s still having trouble getting the fangs to look right.\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 — and here on-screen is my avatar: dark hair, blue sweater, collared shirt, glasses —today real-life me is wearing a gray shirt, warm red pants, and some pinkish socks, approximately violet-warm-10.\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 \u003cstrong\u003estill\u003c/strong\u003e nice too! Let\u0026rsquo;s use the chat to introduce 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? Well, we\u0026rsquo;ve got a bit of a back-to-basics call today. First, we’ve got a new product to feature and a few quick USWDS product updates. Then we\u0026rsquo;ll talk about values — how we\u0026rsquo;re thinking about our product and engineering values as we look ahead, behind, all around, and toward future generations of the design system. And then we\u0026rsquo;ll have time for Q\u0026amp;A at the end—hopefully, a bit more time than we\u0026rsquo;ve left in recent calls.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 4.\u003c/strong\u003e So let\u0026rsquo;s get into it with today’s featured sites. We\u0026rsquo;ve got a nice new product to highlight today — one we\u0026rsquo;ve been using.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 5.\u003c/strong\u003e Recently, Cloud.gov Pages, which you can find at \u003ca href=\"https://pages.cloud.gov\"\u003epages.cloud.gov\u003c/a\u003e, released two automated site reports, the Pages Accessibility Report and the Pages Vulnerability Report. Now, Pages is a publishing platform for modern 21st-Century IDEA-conformant websites, and we use it for hosting the USWDS website. These once-a-month automated site reports check your websites for potential security vulnerabilities and accessibility issues, estimate the severity of the found issues, and suggest fixes for common problems.\u003c/p\u003e\n\u003cp\u003eThe \u003cstrong\u003ePages Accessibility Report\u003c/strong\u003e uses the open-source \u003ccode\u003eaxe-core\u003c/code\u003e project to identify common website accessibility issues. This report identifies up to 55% of your website’s accessibility issues, including the WCAG 2.2 ruleset.\u003c/p\u003e\n\u003cp\u003eThe \u003cstrong\u003ePages Vulnerability Report\u003c/strong\u003e is powered by the Zed Attack Proxy (or \u0026ldquo;ZAP\u0026rdquo;) to detect risks like data exposure and security flaws. ZAP is a respected open-source tool used by many federal technology products.\u003c/p\u003e\n\u003cp\u003eOn the slide, we see a screenshot of an accessibility report for one of our GitHub branches, the one where we were building our breadcrumb accessibility checklist. It shows two accessibility errors, one serious and one minor. The page is a solid combination of USWDS default styles and some custom functionality built just for this display.\u003c/p\u003e\n\u003cp\u003eAnd yes, we do have a couple of accessibility issues we’re working to assess and fix!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 6.\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 7.\u003c/strong\u003e Now for a few product updates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 8.\u003c/strong\u003e As promised — sweat smile emoji — we released USWDS 3.9.0 at the beginning of this month. I won\u0026rsquo;t spend a third monthly call outlining what you can find in this release, but if you\u0026rsquo;d like to check it out, we\u0026rsquo;re posting a link to the release notes in the chat.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 9.\u003c/strong\u003e Based on our experience with some of our recent large releases, we\u0026rsquo;re moving to a new methodology for releases: Scheduling a consistent monthly cadence for releases, and releasing what\u0026rsquo;s ready by the monthly deadline, not building out release content ahead of time and releasing when all those items are ready.\u003c/p\u003e\n\u003cp\u003eThis new approach will improve the velocity of releases and prevent slower work from blocking a release.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 10.\u003c/strong\u003e November\u0026rsquo;s release is most likely a point release, USWDS 3.9.1 — a couple of the items we have on track are:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA fix for an inconsistency in the internal JavaScript for Modal. This is an internal change pointed out by the Touchpoints team. Now the code will better align to our code standards and best practices. Thank you Touchpoints!\u003c/li\u003e\n\u003cli\u003eWe also expect an update to the styling of row headers in the Table component to match those for column headers\u003c/li\u003e\n\u003cli\u003eSimplified screen reader instructions in Combo box and Time picker\u003c/li\u003e\n\u003cli\u003eAnd probably more!\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eLook for our November release in early November.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 11.\u003c/strong\u003e We\u0026rsquo;re also continuing to publish accessibility test pages. Four new ones, focused on navigation (breadcrumb, pagination, in-page navigation, and side navigation), are up on the site now. We\u0026rsquo;re posting links to these new pages in the chat. Next up are Time picker, File input, and Memorable date, so stay tuned for those in November.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 12.\u003c/strong\u003e Next, checking in on our public discussions.\u003c/p\u003e\n\u003cp\u003eWe have a few new component proposals—CUI banner, Heatmap, and Toast—as well as a new pattern proposal: pre-filled form. There\u0026rsquo;s also a new discussion about supporting USWDS solutions in native mobile applications.\u003c/p\u003e\n\u003cp\u003eThis month\u0026rsquo;s accessibility discussion is about going beyond visual design, and we\u0026rsquo;ve also posted the Q\u0026amp;A from the September monthly call in the Discussion Q\u0026amp;A section!\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s a lot happening in Discussions, so check it out!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 13.\u003c/strong\u003e In Web Components world, the \u003ccode\u003eweb-components 0.0.1-alpha\u003c/code\u003e package is out now on npm for installation. This package includes Banner Beta 1 and Link Beta 1.\u003c/p\u003e\n\u003cp\u003eIn development, we\u0026rsquo;ve got Identifier Beta 1, as well as Beta 2 for both Banner and Link. We\u0026rsquo;ve also started work on Text input and Card, which are both in Pre-Alpha.\u003c/p\u003e\n\u003cp\u003eAnd finally, we\u0026rsquo;re digging into compatibility between Lit and StencilJS by starting up a StencilJS testing sandbox. So, continued progress there.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 14.\u003c/strong\u003e Lastly, as I mentioned last month, 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;ve targeted the end of the year as a decommissioning date. So 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 we decommission the site.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 15.\u003c/strong\u003e This month we\u0026rsquo;re talking about Product and Engineering Values for the design system: Why do we have them? What are they used for? And how might they help us navigate the many difficult questions we need to answer as we put together a vision for the future of the design system. It\u0026rsquo;s a big topic, so let\u0026rsquo;s get into it with a couple of my colleagues and teammates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 16.\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 who is audio-only?\u003c/p\u003e\n\u003cp\u003eMatt: Sure can. Thanks, Dan. As Dan said, I’m the engineering lead for the USWDS. I’m based in Raliegh, North Carolina. I’m a white man with a close-cropped white beard, looking autumnal in a light denim jacket, plain shirt, and orange beanie.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 17.\u003c/strong\u003e Dan: Thanks, Matt! I\u0026rsquo;d also like to introduce Anne Petersen, our Experience Design Lead. Anne, can you introduce yourself and give a quick self-description?\u003c/p\u003e\n\u003cp\u003eAnne: I’m Anne, my pronouns are they/them, and visually, I’m white, with short brown hair — the front’s a bit fluffy today — small glasses and large headphones, in a blue collared shirt. Back to you, Dan.\u003c/p\u003e\n\u003cp\u003eDan: Thanks, Anne. I\u0026rsquo;d like to pass it right back to you to help us set the stage for talking about values.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 18.\u003c/strong\u003e Anne: Thanks! This is Anne again. So, why are we talking values?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 19.\u003c/strong\u003e Well, USWDS just turned nine years old. Nine years!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 20.\u003c/strong\u003e We launched on September 28th, 2015.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 21.\u003c/strong\u003e Our first design principles were published on our wiki in 2016. The table of contents for this set is Web standards, Progressive enhancement, and Performance, and the wiki notes that these are drafts. But let’s take a second to pay attention to them—they’re a good indicator of our future.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 22.\u003c/strong\u003e Here’s the next version of our design principles, from December 2016, as a screenshot, with the icons from that site.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 23.\u003c/strong\u003e They were: Make the best thing the easiest thing. Be accessible out of the box. Design for flexibility, and reuse, reuse, reuse.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 24.\u003c/strong\u003e This led to our current design principles: Start with real user needs. Earn trust. Embrace accessibility. Promote continuity. Listen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 25.\u003c/strong\u003e These design principles apply to \u003cem\u003eeverything\u003c/em\u003e that uses USWDS. They definitely apply to us. They’re probably appropriate for your work, too.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 26.\u003c/strong\u003e And yes, they still apply. This is the “hmm, yes” emoji from our Slack, nodding and pointing along. Yes, logical, sound. What government work needs.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 27.\u003c/strong\u003e But what about USWDS itself? What might we need that’s more specific?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 28.\u003c/strong\u003e How do we make decisions that are particular to USWDS?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 29.\u003c/strong\u003e To do what we do best: to serve the public and support \u003cem\u003eyou\u003c/em\u003e. Let’s back up to our reason for being, what we’re doing, and why.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 30.\u003c/strong\u003e In September 2023, we \u003ca href=\"https://designsystem.digital.gov/about/\"\u003erefreshed our mission and vision and created our polestar\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 31.\u003c/strong\u003e To remind you how we’re defining these: our mission is our statement of purpose, our why. Our vision is what problems we want to solve and for who. And our polestar shows how we want to work to get there.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 32.\u003c/strong\u003e Our mission: shaping the future of government digital services.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 33.\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 34.\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 35.\u003c/strong\u003e These show us our general direction. But we have to make more specific decisions.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 36.\u003c/strong\u003e \u003cem\u003eHow?\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 37.\u003c/strong\u003e Well, certainly, we make decisions by building on research with the public.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 38.\u003c/strong\u003e By building on research with you,\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 39.\u003c/strong\u003e By building on current technological developments,\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 40.\u003c/strong\u003e And by building on expectations.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 41.\u003c/strong\u003e But even then, we’re often faced with multiple absolutely reasonable options.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 42.\u003c/strong\u003e So, like you, I would expect that we make decisions based on the information we have available to us. And we keep learning.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 43.\u003c/strong\u003e But we can also make decisions based on the \u003cem\u003evalues\u003c/em\u003e that guide us.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 44.\u003c/strong\u003e Now, if we don’t have the exact same values as other teams, those other teams may make different decisions.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 45.\u003c/strong\u003e And that is \u003cem\u003etotally reasonable\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 46.\u003c/strong\u003e We all have to remember that our context is different. We will have different priorities — if only because the people we serve most directly have differing priorities.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 47.\u003c/strong\u003e The thing we have to keep front and center is that USWDS is \u003cem\u003efoundational\u003c/em\u003e. It’s beneath all else. From one dictionary definition, a foundation is “the lowest load-bearing part of a building, typically below ground level.”\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 48.\u003c/strong\u003e Which makes these decisions \u003cem\u003ehard\u003c/em\u003e, because everything above us depends on us.\u003c/p\u003e\n\u003cp\u003eSo we need a \u003cem\u003estructure\u003c/em\u003e, a framework, which will guide our decisions. To keep us tacking toward the right star. That is, toward our polestar, vision, and mission. And \u003cem\u003etelling\u003c/em\u003e you about this structure — these product and engineering values — can help \u003cem\u003eyou\u003c/em\u003e understand why we’re making the decisions we do. And maybe even anticipate them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 49.\u003c/strong\u003e I’ll turn it over to Dan to go into detail on our product values.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 50.\u003c/strong\u003e Dan: Thanks Anne, this is Dan. Earlier we mentioned the USWDS 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\u003eThese principles are a bit like service principles for projects that build with USWDS - they\u0026rsquo;re meant for everyone. We follow them. You all follow them. These service principles provide a general decision-making framework for projects across the government. But — of course — we\u0026rsquo;re all building different things. There are all kinds of justifiable decisions that can flow from these principles.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 51.\u003c/strong\u003e but how do \u003cstrong\u003ewe\u003c/strong\u003e work in the service of these principles? What values help guide \u003cstrong\u003eUSWDS\u003c/strong\u003e as a unique product in the U.S. Government?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 52.\u003c/strong\u003e Long-time followers of the design system will rightfully point out that USWDS already has product values, and you can find them at \u003ca href=\"http://designsystem.digital.gov/about/product-values\"\u003edesignsystem.digital.gov/about/product-values\u003c/a\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePut user needs first.\u003c/li\u003e\n\u003cli\u003eMake it easy to do the right thing.\u003c/li\u003e\n\u003cli\u003eAccessibility is fundamental.\u003c/li\u003e\n\u003cli\u003eStart from existing solutions.\u003c/li\u003e\n\u003cli\u003eBe consistent, not static.\u003c/li\u003e\n\u003cli\u003eShare what we do.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNot bad. Still relevant. But looking through these values, you\u0026rsquo;ll see a number of items that could be redundant with the \u003cstrong\u003eservice\u003c/strong\u003e principles we\u0026rsquo;ve captured in the USWDS \u003ca href=\"https://designsystem.digital.gov/design-principles/\"\u003eDesign Principles\u003c/a\u003e. And that\u0026rsquo;s because these product values pre-date the design principles, and helped inform those design principles.\u003c/p\u003e\n\u003cp\u003eAs we move forward with the design system, it\u0026rsquo;s the right time to take another look at our product values, in the context of the overall Design Principles \u003cstrong\u003eand\u003c/strong\u003e in the context of what we\u0026rsquo;ve learned about the design system in the six years since we first drafted our current values. What\u0026rsquo;s changed?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 53.\u003c/strong\u003e The biggest thing that\u0026rsquo;s changed is that we\u0026rsquo;ve learned more about what makes this design system unique and effective. And my biggest insight over that time is that we\u0026rsquo;re more than a codebase, more than a style guide, more than guidance and principles, more than a website. Those things are all super important, but I\u0026rsquo;ve found some of the biggest value in \u003cstrong\u003econnections\u003c/strong\u003e between teams across government, and in helping to provide a shared problem space and shared solution space for working through the many questions and discoveries, hard-earned success and setbacks, small joys and irritations that we share, working on the web.\u003c/p\u003e\n\u003cp\u003eAt its best, the \u003cem\u003edesign\u003c/em\u003e system can act as a kind of \u003cem\u003enervous\u003c/em\u003e system, connecting and coordinating the good work happening across teams, agencies, and silos. It\u0026rsquo;s definitely not just a broadcast mechanism but a network of \u003cem\u003etwo-way\u003c/em\u003e communication. A system that\u0026rsquo;s more than its component parts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 54.\u003c/strong\u003e What\u0026rsquo;s important to this system? As we chart a path ahead, here\u0026rsquo;s what we\u0026rsquo;ve identified. We\u0026rsquo;ll look at them all together before digging into each one.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDesign is adaptation.\u003c/li\u003e\n\u003cli\u003eCompliance is the baseline.\u003c/li\u003e\n\u003cli\u003eStrengthen connections.\u003c/li\u003e\n\u003cli\u003eEasier earlier.\u003c/li\u003e\n\u003cli\u003eBe a good steward.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 55.\u003c/strong\u003e First: \u003cstrong\u003eDesign is adaptation.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 56.\u003c/strong\u003e If we\u0026rsquo;re here to facilitate design, what is design? Design is a process of adaptation, of \u003cem\u003efitness\u003c/em\u003e, of fitting a decision to its context. Design is a process that happens again and again as the context changes, as we try and learn, and as the feedback cycles roll ceaselessly forward. We\u0026rsquo;re here to support design work by engineers, UX designers, visual and product designers, researchers, writers, accessibility specialists, product managers, and contributors of all kinds. Everyone designs, so how can we help encourage, coordinate, and develop alongside this process?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWe build for building.\u003c/strong\u003e We develop tools not just for painting by numbers but for building new things and improving existing things. We\u0026rsquo;re less of a model airplane kit and more of a toolbox.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWe work from existing solutions.\u003c/strong\u003e If design is adaptation, we first find something to adapt. We try to avoid the blank page.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWe\u0026rsquo;re consistent, not static.\u003c/strong\u003e We embrace the inevitability and necessity of change. We experiment. We try to identify those aspects in which we feel most confident and try to find stability, but we resist fixity.\u003c/p\u003e\n\u003cp\u003eIn short, we \u003cem\u003esupport design\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 57.\u003c/strong\u003e If design is adaptation, we favor choices that help discover new solutions.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 58.\u003c/strong\u003e Next: \u003cstrong\u003eCompliance is the baseline.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 59.\u003c/strong\u003e We’re a government team that understands what government teams need, including compliance with Section 508 and 21st Century IDEA — and we\u0026rsquo;re here to make that easier. \u003cem\u003eBut we can\u0026rsquo;t stop there.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eWe have a \u003cstrong\u003egovernment focus, and government responsibilities\u003c/strong\u003e. While we support the fundamentals of interface design, we\u0026rsquo;re also here to identify and develop patterns and components that support government-specific needs. \u003cem\u003eAnd\u003c/em\u003e we need to bear in mind not only government technical requirements but what our sites and services require \u003cem\u003eof our audiences\u003c/em\u003e. We know how important government services can be at certain times and in certain situations. Sometimes folks \u003cstrong\u003edon\u0026rsquo;t\u003c/strong\u003e have a choice. What we provide has to work and has to work well.\u003c/p\u003e\n\u003cp\u003eWe \u003cstrong\u003estart with compliance, but go further\u003c/strong\u003e. We need to provide compliance from the start, but we also want to \u003cstrong\u003esupport and shape best practices\u003c/strong\u003e that frequently aren\u0026rsquo;t always requirements.\u003c/p\u003e\n\u003cp\u003eAnd, we \u003cstrong\u003esupport mission focus\u003c/strong\u003e. We want to help a broad, diverse range of teams work in the service of their unique mission, and simplify the digital design minutiae that sometimes get in the way.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 60.\u003c/strong\u003e Because compliance is the baseline, we favor choices that help teams meet and exceed requirements.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 61.\u003c/strong\u003e \u003cstrong\u003eWe strengthen connections.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 62.\u003c/strong\u003e We can\u0026rsquo;t \u003cem\u003eand shouldn\u0026rsquo;t\u003c/em\u003e do this alone. As I\u0026rsquo;d mentioned earlier, the design system isn\u0026rsquo;t a broadcast mechanism; it\u0026rsquo;s a way we can work together across teams, agencies, and silos, to identify, share, and scale solutions.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eDevelop a working language.\u003c/strong\u003e We want teams from across agencies to share solutions just as much as we want designers to communicate with developers. A working language serves a kind of continuity between different varieties of solutions.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eLower the barriers to contribution.\u003c/strong\u003e The design system is better the more people use it and contribute to it.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eWork in the open.\u003c/strong\u003e The process is part of the product. Working in the open doesn\u0026rsquo;t just provide access and insight. It doesn\u0026rsquo;t only help prevent surprises. It doesn\u0026rsquo;t just share and scale. It does all those important things, but working in the open means acknowledging ups and downs. Communicating the ups and downs helps us assume less, and be more proactive, honest, straightforward, and humble. When we\u0026rsquo;re learning in the open as well, it introduces a vulnerability that can be an opening for connection and participation.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMeet teams where they are.\u003c/strong\u003e We gotta be practical. All the words and values and ideals are worth a lot less if teams can\u0026rsquo;t use them to help design and build government websites and services. We need to work to be realistic and understand real constraints.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSupport reusability.\u003c/strong\u003e We can\u0026rsquo;t share and scale if teams can\u0026rsquo;t use and reuse what we deliver. We need to develop solutions that are portable.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 63.\u003c/strong\u003e If we want to strengthen connections, we favor choices that improve communication.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 64.\u003c/strong\u003e Our next Product value is \u003cstrong\u003eEasier earlier\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 65.\u003c/strong\u003e Everyone starts somewhere. Let\u0026rsquo;s make that place as good as it can be, especially when that place is a place of unfamiliarity. Our design system needs to do a lot, and it needs to support significant customization and configuration, but we need to simplify the first interaction. We need to structure our product so the first door is the easiest door to open and walk through. So the first choice is the simplest.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eFlatten the learning curve.\u003c/strong\u003e We want to provide an easier path through the product. This isn\u0026rsquo;t only about usability, but understanding the right user needs at the right time.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eProvide good defaults.\u003c/strong\u003e Start somewhere good. We want to be thoughtful about the starting point. We can\u0026rsquo;t require customization to make the product work properly. What can we do to provide good functionality out of the box?\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAdd complexity later.\u003c/strong\u003e We need to identify the \u003cstrong\u003esimple\u003c/strong\u003e interaction and work from there. Don\u0026rsquo;t lead with everything all at once. We don\u0026rsquo;t need to avoid complexity, but our first priority is the simpler interaction.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSupport the next step.\u003c/strong\u003e We don\u0026rsquo;t want to make the distance between steps too great. People get stuck when the next step isn\u0026rsquo;t obvious or isn\u0026rsquo;t a natural progression from the previous step. We have to support \u003cem\u003eprogression\u003c/em\u003e.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 66.\u003c/strong\u003e If we want to get to easier earlier, we favor choices that enable the beginner.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 67.\u003c/strong\u003e Finally, \u003cstrong\u003ebe a good steward\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 68.\u003c/strong\u003e We\u0026rsquo;re here with the support of public resources. To that end, we work not only to build better tools, but also to help improve performance, efficiency, governance, and institutional memory- to use our resources well.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eWe’re here for the long haul.\u003c/strong\u003e We\u0026rsquo;re a long-term solution that will be supporting teams long after the first design or redesign. We need to work together and change together.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMaintainability\u003c/strong\u003e becomes a higher priority when we\u0026rsquo;re in it for the long haul. Staying up-to-date isn\u0026rsquo;t about conformance, it\u0026rsquo;s about supporting long-term success.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMake the case.\u003c/strong\u003e Teams are independent. They have their own missions, opinions, audiences, and constraints. We not only respect our colleagues when we make the case for what we do, we understand that working together has costs as well as benefits. Not only does technical implementation have a cost, but justification has a cost as well. We\u0026rsquo;re not giving orders, we\u0026rsquo;re trying to build a case. We want to collect research broadly from all kinds of teams and make decisions with that evidence. This helps not only understand how we need to change but lowers the costs of that change.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eCollect and scale expertise.\u003c/strong\u003e Not every design and engineering decision can scale, but we should work hard to identify those that can. Design and engineering are expensive but valuable. Sharing solutions not only helps every team do more, but it shapes the best practices that may become expectations. Collecting and scaling expertise helps prepare every team for the best practices of the future.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eAnd \u003cstrong\u003eSupport the process.\u003c/strong\u003e The process is the core mechanic. In the long term, we think that how we work is at least as important as the tools we deliver. We think that the only way to consistently look ahead and adapt to the unknown of the future is to have a process that keeps us connected to teams, communicating with teams, and open to new possibilities.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 69.\u003c/strong\u003e If we want to be a good steward, we favor choices that take a practical, long-term perspective.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 70.\u003c/strong\u003e Now I\u0026rsquo;d like to pass it to Matt to talk about engineering values.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 71.\u003c/strong\u003e Matt: Thanks Dan. The author and designer Frank Chimero gave a talk in 2015 called “The Web’s Grain” about the power of designing websites in a way that embraces the possibilities and limitations inherent to the web platform and the devices that we use to interact with it. He meant grain in the sense that wood has a grain. Designing with the web’s grain, then, is like cutting wood in the direction of its grain. Today, we’re talking more about building technology than designing interactions, but I bring it up because the idea of the web having a grain is an important one that applies to just about every aspect of how we all make things for the platform.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 72.\u003c/strong\u003e So what does it mean to build technology with the grain of the web?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 73.\u003c/strong\u003e One thing it could mean is to use each part of the web platform for its intended purpose. That is, use HTML to structure a document\u0026rsquo;s content, use CSS to modify the page\u0026rsquo;s appearance, and use JavaScript to add behaviors and complex interactivity.\u003c/p\u003e\n\u003cp\u003eAnother way of saying this might be to understand what the primitive elements of the web are and to use them for their intended purposes. This applies to the languages that we use to build things on the web. Still, it also applies to the technologies and architectures that make up the web itself, things like HTTP, which is the basic transfer protocol for sending data to your browser, URLs for creating unique addresses for all of the content on the web, and HyperText for linking pages together, among others.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 74.\u003c/strong\u003e Another thing it could mean is to embrace the quirks of the platform. As designers, developers, and content authors, we build websites and send them out into the world, but we have little to no control over the environment in which our pages will actually be viewed. We can \u003cstrong\u003ealso\u003c/strong\u003e embrace this lack of control. We can use data to make educated guesses about the browsers and devices users will have or the speed at which they\u0026rsquo;ll be able to download everything we\u0026rsquo;ve sent them, but at the end of the day, we can\u0026rsquo;t know for sure. If it\u0026rsquo;s important for our audience to be able to see our content, or complete tasks in our applications, we have to build things that work in as many environments and conditions as possible. And we have to recognize that, even with the best analytics, we can\u0026rsquo;t always be sure what those runtime environments will be.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 75.\u003c/strong\u003e The web isn\u0026rsquo;t just technology. It\u0026rsquo;s also a set of conventions, norms, and expectations that have built up over time—conventions like ways to dismiss modal pop-ups, best practices around information architecture and content design, etc. Building with the grain of the web means following these conventions.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 76.\u003c/strong\u003e These are some things it might mean to build with the grain of the web, but so far, we haven’t talked about why it might be a good idea to do that.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 77.\u003c/strong\u003e One reason is that the web platform is resilient by design, so embracing the platform is a way to leverage that resilience.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 78.\u003c/strong\u003e The web is a medium for sharing content, so browsers work very hard to get that content to users if at all possible. When a browser encounters an unfamiliar HTML tag, it simply renders the tag\u0026rsquo;s contents. This is just as true of custom element tags like the ones the design system is beginning to work with as it is of malformed HTML. An undefined or mistyped HTML element will render as if it’s a \u003ccode\u003ediv\u003c/code\u003e since the platform is designed to try to get content in front of the end user no matter what.\u003c/p\u003e\n\u003cp\u003eSimilarly, for CSS, a browser will simply ignore any style rules it doesn\u0026rsquo;t support. In the early days of \u0026ldquo;CSS3,\u0026rdquo; a developer could add \u003ccode\u003eborder-radius \u003c/code\u003e rules to their stylesheet that would create rounded corners in browsers that supported the then-new property, and older browsers would simply ignore the unfamiliar rule and render a pointy-cornered box.\u003c/p\u003e\n\u003cp\u003eHTML and CSS are designed to fail gracefully.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 79.\u003c/strong\u003e JavaScript is arguably the most powerful part of the web platform stack in that it empowers developers to build entire applications that run in the browser. However, it is also the least resilient component of the platform. The more a developer uses JavaScript to get content, markup, or styles on a page, the harder it is to take advantage of the web platform\u0026rsquo;s native resilience.\u003c/p\u003e\n\u003cp\u003eJavaScript can trade resilience for power.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 80.\u003c/strong\u003e Another reason to build with the web’s grain is performance. The web platform was built to be fast.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 81.\u003c/strong\u003e This is true of every layer of the platform, from the basic network protocols up to the rendering engines in browsers themselves. In describing his goals in designing HTTP, Tim Berners-Lee said “the target was fetch of about one-tenth of a second. It had to be ‘Get this document’ and ‘Here it is!’”\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 82.\u003c/strong\u003e Similarly, browser vendors make every effort to make the web as fast as possible for users. The processes by which they do this are complicated but ultimately amount to having smart priorities about the order in which the images that make up a web page are downloaded, parsed, rendered, and executed. This sequence, referred to as \u003ca href=\"https://web.dev/learn/performance/understanding-the-critical-path\"\u003ethe critical path\u003c/a\u003e, is optimized to build the DOM first, then apply styles, and then run JavaScript that might affect the DOM.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 83.\u003c/strong\u003e One way of working with the grain of the web platform is to lean into this prioritization to take advantage of the work that browser vendors put into making everything fast. The more foundational page structure, style, and content that a developer puts into JavaScript, the slower the overall experience will be for the end user. If a page’s entire DOM is created in JavaScript, then that page will miss out on the inherent speed built into the first phase of the rendering process. The same applies to using JavaScript to apply styles. Optimal performance comes from building the page with semantic HTML first, then tweaking with JavaScript. Another way of saying this is that the fastest pages let the browser do the performance-intensive work in the order they were designed to do so. The more that a developer chooses to re-implement that rendering process themselves, the more responsibility they then have for the page’s performance.\u003c/p\u003e\n\u003cp\u003eJavaScript can trade performance for power.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 84.\u003c/strong\u003e The inherent speed of the platform is, in many ways, a best case scenario. There are all kinds of things that can make the web slow. Some of these things, like poor connectivity, or slow devices, are out of developers’ control. The best we can do is build with these potential limitations in mind, work around them where possible, and do our best to not introduce more slowness ourselves.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 85.\u003c/strong\u003e Accessibility is another area where embracing the web platform has the potential to yield better results than going all-in on scratch-built components.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 86.\u003c/strong\u003e In just the same way that browser vendors work to make the web fast, they also put tremendous effort into making the web accessible to all, including assistive technology users. The simplest way to take advantage of this work is to use built-in semantically rich HTML elements wherever possible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 87.\u003c/strong\u003e The danger of choosing to build components from scratch or from HTML that doesn’t have its own semantics is that it becomes incumbent on the developer to manually and painstakingly add in support for accessibility APIs using tools like ARIA. While it is possible to build accessible applications that provide great experiences for assistive technology users this way, it is much more difficult to do so. In addition to requiring much more development effort, it also necessitates a great deal more usability testing to ensure they are creating accessible, inclusive experiences (this isn’t to suggest that teams using semantic HTML don’t need to do usability testing—only that those who build fully custom components will need to do considerably more testing).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 88.\u003c/strong\u003e As the W3C’s Web Accessibility Initiative points out, \u003ca href=\"https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/\"\u003e“No ARIA is better than bad ARIA.”\u003c/a\u003e ARIA is not a quick-fix for creating accessible sites and apps. Taking on the responsibility of adding landmarks for assistive tech runs the not-insignificant risk of implementing those landmarks in a way that is more confusing than it is helpful. Again, the point of this is not to say that teams should never build their own components from scratch but rather to suggest that they consider leveraging more robust and robustly accessible built-in solutions to the fullest extent possible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 89.\u003c/strong\u003e The upshot of this is that, as with performance and resilience, the more that teams elect to build components out of JavaScript, the more responsibility they take for ensuring that what they build works for all of their users.\u003c/p\u003e\n\u003cp\u003eJavaScript can trade accessibility for power.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 90.\u003c/strong\u003e What, in practical terms, does this mean? Hopefully, by this point, you’re at least open to the idea that there are real, tangible benefits to building with the grain of the web. But this is a presentation about the US Web Design System, so I want to talk now about some of the engineering values we think this idea implies or that are at least compatible with this line of thinking.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 91.\u003c/strong\u003e And here they are:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eEmbrace the platform.\u003c/li\u003e\n\u003cli\u003eSupport UX with developer experience.\u003c/li\u003e\n\u003cli\u003eWe’re a layer.\u003c/li\u003e\n\u003cli\u003eWrite plain-language code.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 92.\u003c/strong\u003e The first principle shouldn’t be a huge surprise given the discussion so far. It’s to embrace the platform, or work with the grain of the web. We’ve already talked a fair bit about what this means, but it’s worth being specific about how it applies to the USWDS.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 93.\u003c/strong\u003e One important aspect of embracing the platform is to \u003cstrong\u003ehelp the platform do its job\u003c/strong\u003e — or to use each part of the platform for its intended purpose. HTML should be semantic and tags should describe the content they contain to the largest practicable extent.\u003c/p\u003e\n\u003cp\u003eFor USWDS Web Components, it means embracing the HTML Web Components architecture we talked about in September’s monthly call. As a refresher, HTML Web Components are custom elements that have some HTML in between the opening and closing tags of the custom element. Building at least some of our components this way should allow page authors to write simple (think \u0026ldquo;web 1.0\u0026rdquo;) markup, while the presentational markup, such as any extra divs or classes necessary for styling, stays mostly in the shadow DOM.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eClosely related to this is that USWDS needs to \u003cstrong\u003euse progressive enhancement.\u003c/strong\u003e HTML web components containing relatively simple markup will enable teams to deliver critical content no matter what. Building components that way will ensure that content is available before JavaScript runs or even if it never does. But it also allows those components to apply all of the design and behavior customizations that CSS and JavaScript allow if and when they become available.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAvoid lock-in.\u003c/strong\u003e Building with the web platform, and using its native idioms is a way to keep USWDS from being tied to any particular framework.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnother way of saying this would be that we should prefer native and web standard tools to third-party tools and libraries. However, we’re a small team with a lot of work to do, so we can’t always write everything from scratch ourselves. So when we do adopt a library, we should choose something lightweight—both light in terms of the amount of data sent over the wire as well as in how it changes web-native behaviors.\u003c/p\u003e\n\u003cp\u003eMigrating away from Sass (and the tooling required to support it) and toward CSS variables/custom properties is an example of how we\u0026rsquo;re doing this today. Another way of saying the principle at work here is to favor solutions closer to the grain.\u003c/p\u003e\n\u003cp\u003eA related point to avoiding lock-in is reducing switching costs. By keeping our reliance on dependencies as low as possible, we’ll be well-positioned to move on from them if they stop working the way we need them to or if a better alternative comes along.\u003c/p\u003e\n\u003cp\u003eAnother aspect of this is that we should pick tools that are not the most popular but most portable. Just because a library has widespread adoption doesn’t necessarily mean it will be a good fit for this project or its users.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIn general, we want to work to \u003cstrong\u003esupport the open standards of the web\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 94.\u003c/strong\u003e When we embrace the platform, we favor choices that work with the grain of the web.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 95.\u003c/strong\u003e The next value is to \u003cstrong\u003eSupport UX with developer experience\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 96.\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUser experience shapes the tools:\u003c/strong\u003e We\u0026rsquo;re not working in a vacuum, and we\u0026rsquo;re obviously not building for ourselves. We\u0026rsquo;re building sites and services that others use. We need to make sure that we\u0026rsquo;re building tools that make it easier for developers to build the kinds of sites and services that work for the person using the site or service, wherever they\u0026rsquo;re coming from.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePerformance matters:\u003c/strong\u003e It can be easy to lose track of the performance costs when we\u0026rsquo;re using devices powerful enough to make it easy to build sites and services. But performance can have a real usability impact, a cost impact, and an energy impact. We have to work to keep that impact visible. We have to work to keep performance costs low.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMake accessibility easier, not invisible:\u003c/strong\u003e We have to be careful not to lose the user in the abstraction. It can be amazing and powerful to build accessible decisions into the tools we ship and the components we use, but we have to work to make sure that delivering and using accessible tools doesn\u0026rsquo;t result in accessibility disappearing from view.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSupport repairability:\u003c/strong\u003e Finally, tools and products don\u0026rsquo;t always work as well as they should. If a developer can work to fix something in one of our components, they shouldn\u0026rsquo;t always have to wait for us. We should deliver components that teams can get into and open the box. We want teams to have the ability to repair and improve our work — first for their project, but hopefully also later for an improvement we can incorporate.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 97.\u003c/strong\u003e When we support UX with developer experience, we favor choices that prioritize the end-user experience.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 98.\u003c/strong\u003e Recognize that \u003cstrong\u003ewe’re a layer\u003c/strong\u003e. USWDS is only going to be \u003cem\u003epart\u003c/em\u003e of the stack you use to build sites and applications.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 99.\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eBe a dependency not a fork.\u003c/strong\u003e We want to make it easier for teams to add USWDS to their projects in such a way as to maintain the connection between our work and theirs over time.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eOur opinions cascade.\u003c/strong\u003e We need to be thoughtful about the impact that USWDS has on downstream teams. Recognize that choices made at the Design System level establish the floor for performance and accessibility. If our components leverage too much JavaScript too early, that’s a performance tax we pass onto every single user. Developers should be able to make their own choices about how much JavaScript to use and at what point they hand control of the page over to scripts.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis doesn’t mean that USWDS doesn’t or can’t be opinionated, but it does mean that the design system team needs to be thoughtful about how those opinions impact downstream teams and ultimately the public users of products built with USWDS.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eUse semantic versioning.\u003c/strong\u003e Be clear when things change. Semantic versioning is a kind of contract between developers and users. This contract gives users confidence that the code they’re consuming isn’t going to break anything in their code if they install it—unless the upstream team tells them ahead of time that the update contains a breaking change. USWDS will adopt semantic versioning for the web components package first, and then down the line revisit versioning for other parts of the design system.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eAnd being a layer means we have to \u003cstrong\u003esupport different tech stacks\u003c/strong\u003e. If USWDS goes all-in on a set of technologies, it may sound great to teams already using those tools, but it imposes significant costs on everyone else. But since we’re all building for the web, the closer we stick to web standard technologies, the easier it will be for every team that wants to use USWDS to do so.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 100.\u003c/strong\u003e If we\u0026rsquo;re a layer, we favor choices that are thoughtful about our impact.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 101.\u003c/strong\u003e The last value I want to talk through with you today is that we should write plain-language code. In government, we strive to use plain language in our content in order to make that content accessible to the broadest possible audience. This is something we should aim for in our code as well.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 102.\u003c/strong\u003e Not everyone who uses USWDS is a front-end development expert. Indeed — not everyone using USWDS is a developer at all. In light of that, we must write code that as many people as possible can understand, implement, and extend.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eWrite for reading:\u003c/strong\u003e Recognize that all code we write has to be read by others, as well as by our future selves!\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eEmbrace the idiom:\u003c/strong\u003e Write with the convention of the language. Be cautious about how you introduce new abstractions, idiosyncrasies, or concepts.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eDocumentation first:\u003c/strong\u003e Integrate documentation tightly into the development process, and make sure our docs are oriented toward helping developers get things done in their sites and apps.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSupport other developers:\u003c/strong\u003e And finally, we use plain language so that others can follow along and contribute.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 103.\u003c/strong\u003e If we write plain language code, we favor choices that open our code to more contributors.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnd now I\u0026rsquo;ll pass it back to Dan to wrap us up!\u003c/p\u003e\n\u003cp\u003eDan: Thanks Matt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 104.\u003c/strong\u003e Today we introduced new product values:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDesign is adaptation.\u003c/li\u003e\n\u003cli\u003eCompliance is the baseline.\u003c/li\u003e\n\u003cli\u003eStrengthen connections.\u003c/li\u003e\n\u003cli\u003eEasier earlier.\u003c/li\u003e\n\u003cli\u003eand Be a good steward.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnd new engineering values that support those product values:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eEmbrace the platform.\u003c/li\u003e\n\u003cli\u003eSupport UX with developer experience.\u003c/li\u003e\n\u003cli\u003eWe’re a layer.\u003c/li\u003e\n\u003cli\u003eand Write plain-language code.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWhere do we go from here? Well as I mentioned, we\u0026rsquo;ve gotta be practical. Now we\u0026rsquo;re working through how we move from values to product.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 105.\u003c/strong\u003e Working with values alongside product helps guide an agile and iterative process. Both for our team, and for yours, knowing where we\u0026rsquo;re coming from can tell you where we\u0026rsquo;re going.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 106.\u003c/strong\u003e I know that the future looks interesting. Our core codebase, design tokens, and utilities, plus a simplified, modular web components solution points to some promising directions for a powerful unified product that\u0026rsquo;s able to grow and adapt. I look forward to presenting more of the vision for that future for everyone next month! Thanks, and 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 build off these values to give a clearer look at the next generation of USWDS.\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 weren\u0026rsquo;t able to answer on 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 and a great conclusion to your summer. We\u0026rsquo;ll see you in November!\u003c/p\u003e\n\u003c/div\u003e\u003c/div\u003e\n\n\u003cp\u003eJoin the U.S. Web Design System (USWDS) team for a talk about the product and engineering principles and values that guide the team’s decision-making as they look towards the future.\u003c/p\u003e\n\u003cp\u003eIn this session, you’ll:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eLearn about USWDS principles and values and how they help the team make decisions.\u003c/li\u003e\n\u003cli\u003eUnderstand how these principles inform direction with web components.\u003c/li\u003e\n\u003cli\u003eDiscover the USWDS team’s vision for the future of the design system.\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\u003cstrong\u003eDisclaimer\u003c/strong\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-10-17-uswds-monthly-call-october-2024.md",
      
      "filepath" :"events/2024/10/2024-10-17-uswds-monthly-call-october-2024.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/events/2024/10/2024-10-17-uswds-monthly-call-october-2024.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/events/2024/10/2024-10-17-uswds-monthly-call-october-2024.md","slug" : "uswds-monthly-call-october-2024","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/10/17/uswds-monthly-call-october-2024/"
    }
  ]
}