{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "event",
    "type" : "single",
    "title" : "USWDS Monthly Call - April 2024 |Digital.gov",
    "description": "USWDS Monthly Call - April 2024",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/04/18/uswds-monthly-call-april-2024/index.json","item" : [
    {"kicker" : "USWDS","title" :"USWDS Monthly Call - April 2024","deck" : "An introduction to Web Components","summary" : "The U.S. Web Design System (USWDS) team will go over some basics of Web Components and how they apply to the design system.","date" : "2024-04-18T14:00:00-05:00","date_modified" : "2025-01-27T19:42:55-05:00","start_date" : "2024-04-18T14:00:00-05:00","end_date" : "2024-04-18T15:00:00-05:00",
      "event_organizer" : "Digital.gov","host" : "U.S. Web Design System","registration_url" : "https://gsa.zoomgov.com/meeting/register/vJIscu2trTIvG5qnaDHtM3sylW5ysfzYq_Y","youtube_id" : "GHomUbYTgwQ","topics" : {
        
            "design" : "Design",
            "human-centered-design" : "Human-centered design",
            "software-engineering" : "Software engineering"
            },"primary_image" : { "uid" : "2024-uswds-monthly-call-april-title-card", "alt" :
  "Title card image of USWDS logo, a multi-colored pentagon shape consisting of five triangles, centered on a black background. In blue text, the first line says, U.S. Web Design System (USWDS). Below in white text, the second line has the event name, USWDS monthly call April 2024. Below in blue text is date followed by the date of the event in white, April 18, 2024. The next line in blue text is Time followed by the time of the event in white, 2:00 pm ET.", "width" :
  "1200", "height" :
  "628", "credit" :
  "", "caption" :
  "", "format" :
  "png" },"content" :"\n\u003ca\n    href=\"https://s3.amazonaws.com/digitalgov/static/uswds-monthly-call-april-2024.pptx\"\u003eView the slides (Powerpoint presentation, 5.9 MB, 96 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 April 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 April 2024. This month we\u0026rsquo;re celebrating the budding leaves and spectacular flowers of spring (with shades of pink and green and blue).\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. Today my physical self is wearing a simple green checked shirt. It\u0026rsquo;s also a bright-green socks day!\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 posted a link to our monthly call 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 I encourage you to ask questions in the chat at any time. If any member of our team can answer your question in the chat, we\u0026rsquo;ll do so, otherwise there\u0026rsquo;ll be some time for questions and answers at the end of the hour. Also, be sure to introduce yourself in the chat as well — 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\u0026rsquo;re welcome to close or hide the chat window during the main presentation. You can reopen it 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\u003eWe\u0026rsquo;ve got a nice site launch, some product updates, and then we\u0026rsquo;ll spend the rest of the time with an introduction to something we think is super important to the future of the design system: something called Web Components.\u003c/p\u003e\n\u003cp\u003eAnd then hopefully we\u0026rsquo;ll have plenty of time for Q\u0026amp;A.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 4:\u003c/strong\u003e So let\u0026rsquo;s get into it with new site launches\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 5:\u003c/strong\u003e Today we\u0026rsquo;re looking at \u003ca href=\"https://beta.notify.gov/\"\u003ebeta.notify.gov\u003c/a\u003e: This is the beta site for a new service from TTS here at GSA, Notify.gov. Notify.gov is a text message service that helps federal, state, local, tribal and territorial governments more effectively communicate with the people they serve. It\u0026rsquo;s currently in a select pilot program. On the Notify.gov homepage, we see a simple and direct bell icon with a bright red notification dot. The hero area is bold and blue, with an illustration of a mobile device receiving a text message, and the words \u0026ldquo;Reach people where they are with government-powered text messages.\u0026rdquo;\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 First a number of research updates. We\u0026rsquo;ve put a bunch of effort into operationalizing usability research over the last year, and it\u0026rsquo;s really starting to come together. Last month we performed some usability research focused on five components: Banner, Site Alert, Memorable Date, Time Picker, and Radio Buttons.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 9:\u003c/strong\u003e We\u0026rsquo;ve been continuing our focus on research with people with disabilities and users of assistive technology. In this last round, we had five users with visual impairments (three blind and two low-vision); one user with a motor impairment; and two users with mental health conditions (ADHD, anxiety, and depression).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 10:\u003c/strong\u003e We were also able to test on a broad range of devices and user agents: four screen readers, one instance of screen magnification, and tests on both mobile and desktop.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 11:\u003c/strong\u003e We\u0026rsquo;ll have more to come on findings from this last round of research, but we learn a lot with every round, and we\u0026rsquo;re gearing up for the next ones now.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 12:\u003c/strong\u003e Next a quick update on component discussions. We\u0026rsquo;re adding \u003ca href=\"https://github.com/uswds/uswds/discussions/categories/component-proposals\"\u003ea link to our new component proposal discussion board in the chat\u003c/a\u003e where we\u0026rsquo;re working to solicit discussion on components teams hope to see in the design system. We\u0026rsquo;ve got ten active discussions right now:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eCommon feedback\u003c/li\u003e\n\u003cli\u003eCUI banner\u003c/li\u003e\n\u003cli\u003eGlossary\u003c/li\u003e\n\u003cli\u003eSpinner\u003c/li\u003e\n\u003cli\u003eTabs\u003c/li\u003e\n\u003cli\u003eToast\u003c/li\u003e\n\u003cli\u003eToggle\u003c/li\u003e\n\u003cli\u003eQuote with attribution\u003c/li\u003e\n\u003cli\u003eSkipto\u003c/li\u003e\n\u003cli\u003eSidebar primary navigation\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWe\u0026rsquo;re also getting ready to get the tabs discussion into the formal proposal phase, converting the information we\u0026rsquo;ve gathered in the discussion into a formal proposal. When we\u0026rsquo;ve finished, we\u0026rsquo;ll post an update into the tabs discussion, and ask any follow-up questions we have in there as well.\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;ll be talking more about component proposals and evaluation in the coming months.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 13:\u003c/strong\u003e And finally, I\u0026rsquo;d like to point to a couple other discussions on the borders right now. We\u0026rsquo;ve had some interesting conversation around the idea of \u0026ldquo;dull colors\u0026rdquo; or what we might think of as the \u0026ldquo;calm\u0026rdquo; equivalent of the \u0026ldquo;vivid\u0026rdquo; color variants we currently support.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s a good proposal, and is a thoughtful look at how we might provide an even fuller gamut of color token options.\u003c/p\u003e\n\u003cp\u003eThere are also a couple other accessibility-related discussions that might be of interest. This month is recognized as National Stress Awareness Month, and we\u0026rsquo;re wondering how teams think about designing with stress in mind, and also how we might think about usability research that gives insight into usability under conditions of stress.\u003c/p\u003e\n\u003cp\u003eThere are also a couple other accessibility-related discussions on WCAG 2.2, and the overlap between content and WCAG. So jump in if you have something to contribute!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 14:\u003c/strong\u003e This month we\u0026rsquo;re going to give an introduction to a technology that we think is going to be really meaningful for the design system, and has the potential to have a big impact on how we build with the design system, design with the design system, and stay up to date with the design system. And that\u0026rsquo;s something called Web Components. Today we\u0026rsquo;ll try to talk about what this technology is, and why we care so much — without getting too too technical.\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;ll be talking about this a bunch more over the foreseeable future, and this is just the start.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 15:\u003c/strong\u003e Have you ever \u0026ldquo;viewed source\u0026rdquo; on a website? You can do that for anything you can open in a web browser. There isn\u0026rsquo;t much reason to do this — there are other ways to interact with the underlying code of a webpage, if you\u0026rsquo;re a developer. But if you\u0026rsquo;re a certain age, and that age is close to mine (somewhere in the vicinity of 50), there was something of a perverse charm in knowing that you can look under the hood of any page you visit on the web and see some of what makes it tick.\u003c/p\u003e\n\u003cp\u003eBack when the web was young, this was one of the best ways to learn how the web worked. And it\u0026rsquo;s still sort of gratifying to know that you can peel the lid off even the most sophisticated of sites and look right down into its guts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 16:\u003c/strong\u003e And when you do, you\u0026rsquo;ll see something kinda like what\u0026rsquo;s on this slide. Here we\u0026rsquo;ve peeled the lid off the USWDS homepage, and underneath is a bunch of code like we see on the right side of the screen, in gold: monospaced, code-y stuff, things that look like a computer was writing an outline. Maybe you see things in there like \u003ccode\u003e\u0026lt;body\u0026gt;\u003c/code\u003e, \u003ccode\u003e\u0026lt;section\u0026gt;\u003c/code\u003e, \u003ccode\u003eclass\u003c/code\u003e, or \u003ccode\u003e\u0026lt;div\u0026gt;\u003c/code\u003e. Lots of angle brackets!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 17:\u003c/strong\u003e This is what — technically — we refer to as \u0026ldquo;brackety stuff.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 18:\u003c/strong\u003e Or perhaps \u003cem\u003emore\u003c/em\u003e technically, as \u003cem\u003emarkup\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 19:\u003c/strong\u003e This markup language has changed a bit since the early days of the web, but if you looked at the markup from a website from 1996, it would be remarkably similar to what you see today. Probably a lot simpler — our markup style has gotten a bit… verbose these days — but it wouldn\u0026rsquo;t be like reading a completely different language. It wouldn\u0026rsquo;t even be as archaic as something like Old English.\u003c/p\u003e\n\u003cp\u003eSince the earliest days, this common markup has been the stable foundation of the web.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 20:\u003c/strong\u003e In fact, it was in 1994 — still in the very early days of the web — that the web standards body known as the \u003ca href=\"https://www.w3.org/\"\u003eW3C (World Wide Web Consortium)\u003c/a\u003e was formed. By 1996, they\u0026rsquo;d assumed standardization responsibilities for this markup language.\u003c/p\u003e\n\u003cp\u003eThis standardization was important because of what the web was trying to do — connect information across the world, between pages and documents that might not share any commonalities but a common language. If they were going to connect successfully, it was because they shared this common language.\u003c/p\u003e\n\u003cp\u003eThe stability, consistency, and dependability of standardization helped the internet grow.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 21:\u003c/strong\u003e And this common language, this markup language, has a very \u0026rsquo;90s name. It\u0026rsquo;s the HyperText Markup Language. HyperText (a term actually coined in the \u0026rsquo;60s) essentially just means text connected by links. And this HyperText Markup Language is our common language of the web, HTML. And these days, most folks have heard of that.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 22:\u003c/strong\u003e HTML is everywhere… except where you might expect it! With all the HTML lying just beneath every single website and service we visit, it may come as a surprise to learn that — for the most part — most modern websites aren\u0026rsquo;t typically written in HTML at all.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 23:\u003c/strong\u003e And to understand why, it\u0026rsquo;s worth thinking about something we talk about pretty often here at USWDS: and that\u0026rsquo;s components.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 24:\u003c/strong\u003e Components are a way to think about how websites are constructed from modular, remixable building blocks: these are things like headers and footers, buttons, cards, icons, date pickers, navigations, step indicators, breadcrumbs, and search, etc. We see something of a simplified example of these on screen, with components as little squares with dotted-line borders.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 25:\u003c/strong\u003e These components are meant to be repeated and reused all across our applications, across all kinds of different forms, pages, and workflows. Most of the stuff we see on any website or service is a component of some type. A wireframe for a web page or interaction flow — something like what we see on screen — can sometimes just be a way to see how components are remixed and reassembled to create a coherent layout.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 26:\u003c/strong\u003e For modern websites, anything that appears again and again, like a component, is a great candidate for a \u003cem\u003etemplate\u003c/em\u003e — like a stamp or a little printing press — that outputs that component wherever it\u0026rsquo;s needed, with the proper content and data for \u003cem\u003ejust\u003c/em\u003e that instance: \u003cem\u003ejust that\u003c/em\u003e button, \u003cem\u003ejust that\u003c/em\u003e form field, \u003cem\u003ejust that\u003c/em\u003e breadcrumb trail, \u003cem\u003ejust that\u003c/em\u003e side navigation. Design this little component printing press once, and include it every time you need to output a component.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 27:\u003c/strong\u003e So what does a template do? A template receives unique data and content as an input and outputs the HTML that the browser interprets.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 28:\u003c/strong\u003e So just as you can think of a page as made of components…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 29:\u003c/strong\u003e It is perhaps more accurately made of component templates. Modern websites are built out of templates small and large. Component templates, section templates, page templates, interaction templates, workflow templates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 30:\u003c/strong\u003e Essentially, template languages allow applications to output HTML dynamically, based on data and logic. You\u0026rsquo;re not writing a bunch of HTML, you\u0026rsquo;re writing logic and passing data, and letting the machine take care of the repetitive hassle of writing all that HTML.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 31:\u003c/strong\u003e If HTML is highly standardized, the world of templates and template languages is… not so much. There are all kinds of template languages, changing all the time. Developers might know a bunch of them, or they might only know one really well. While HTML evolves slowly, the product of a centralized international standards body, template languages follow the logic of the marketplace, finding new evolutionary niches based on new developer needs, individual passion, and a desire to build something new and better, or even just different. There will always be more of them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 32:\u003c/strong\u003e So, the web wouldn\u0026rsquo;t exist without the standardized interoperability of a common HTML…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 33:\u003c/strong\u003e …but modern dynamic applications couldn\u0026rsquo;t exist without template languages.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 34:\u003c/strong\u003e Yet even while the hare of templating languages scurries this way and that, constantly whizzing back and forth, the tortoise of the standardized world of web technologies continues to plod ever forward.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 35:\u003c/strong\u003e About ten years ago, in 2013, the web standards body responsible for HTML published the beginning of a way to integrate the power of component templates into the fundamental technology of markup, by adding the ability to build custom \u003cem\u003eadditions\u003c/em\u003e to HTML.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 36:\u003c/strong\u003e To understand what this means, let\u0026rsquo;s take a look at some HTML elements…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 37:\u003c/strong\u003e The fundamental unit of HTML is the element, and today, in the current living standard, there are just a bit more than 100 of them. Almost exactly as many as there are in the periodic table of the elements, for the physical elements of chemistry! (There are about 111 HTML elements — depending on how you count them — and there are about 118 physical elements…)\u003c/p\u003e\n\u003cp\u003eAn element is simply a way to describe a part of a document. Like a heading, or an article, or a paragraph, a section, or a general division. Elements give structure to documents. They describe a model of the content of a document.\u003c/p\u003e\n\u003cp\u003eIf you look around at the grid of HTML elements on screen now (this isn\u0026rsquo;t all of them, by the way!) you may see a bunch of things that look familiar: heading levels like \u003ccode\u003eh1\u003c/code\u003e-\u003ccode\u003eh6\u003c/code\u003e; \u003ccode\u003etable\u003c/code\u003e, \u003ccode\u003eform\u003c/code\u003e, \u003ccode\u003einput\u003c/code\u003e, and \u003ccode\u003ebutton\u003c/code\u003e; the paragraph \u003ccode\u003ep\u003c/code\u003e, and perhaps the hydrogen of the HTML elements…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 38:\u003c/strong\u003e …the anchor link: \u003ccode\u003ea\u003c/code\u003e. Which we now see highlighted in the grid. \u003ccode\u003eA\u003c/code\u003e is a great element, and is the element that made the web what it is. Let\u0026rsquo;s use the \u003ccode\u003ea\u003c/code\u003e element to look at the parts of an element.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 39:\u003c/strong\u003e So here\u0026rsquo;s an element in the wild. Since most — but not all — elements are designed to structure content, they\u0026rsquo;re designed with a two-part system, an opening tag and a closing tag that enclose some kind of content.\u003c/p\u003e\n\u003cp\u003eOpening and closing tags are surrounded by angle brackets. The closing tag uses a forward slash to indicate that it\u0026rsquo;s a closing tag, and the opening tag can also include \u003cstrong\u003eattributes\u003c/strong\u003e, or information about this specific instance of the element.\u003c/p\u003e\n\u003cp\u003eIn this case, the attribute for the \u003ccode\u003ea\u003c/code\u003e element is one that\u0026rsquo;s pretty critical for any anchor link, the hyperlink reference to the destination address, otherwise known as an \u003ccode\u003ehref\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eSo for an anchor link, you really just need two things:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThe text that serves as the link\u003c/li\u003e\n\u003cli\u003eAnd the destination address for the link\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThat\u0026rsquo;s what this element encodes. That\u0026rsquo;s the \u003cem\u003emodel\u003c/em\u003e for a hyperlink.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 40:\u003c/strong\u003e On-screen, this is what we see.\u003c/p\u003e\n\u003cp\u003eWe see USWDS, blue and underlined by default. If we select this link, our browser will take us to the address we specified in the element\u0026rsquo;s \u003ccode\u003ehref\u003c/code\u003e. If we hover over this link with a mouse, the cursor will change into a pointing finger to indicate that this element can be selected.\u003c/p\u003e\n\u003cp\u003eWe \u003cem\u003edon\u0026rsquo;t\u003c/em\u003e see the element\u0026rsquo;s tags, or any of the attributes, exactly. What we see is the browser\u0026rsquo;s \u003cem\u003einterpretation\u003c/em\u003e of the element model, with the content and data we specified.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 41:\u003c/strong\u003e HTML elements are the starting point for modeling components. But what about when a component doesn\u0026rsquo;t have an analogous element?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 42:\u003c/strong\u003e Or when an element doesn\u0026rsquo;t support all the functionality required by a component?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 43:\u003c/strong\u003e This is when we have to build our own models.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 44:\u003c/strong\u003e To give an example of what this might mean, let\u0026rsquo;s look at \u003cstrong\u003eBreadcrumb\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 45:\u003c/strong\u003e Maybe you could imagine breadcrumb being a standard HTML element. It wouldn\u0026rsquo;t be a stretch, but it doesn\u0026rsquo;t exist.\u003c/p\u003e\n\u003cp\u003eLet\u0026rsquo;s look at a few instances of a breadcrumb to try to identify its key aspects.\u003c/p\u003e\n\u003cp\u003eOn screen we see four breadcrumbs of differing lengths. Each has a house icon at the beginning. Each has little chevron-shaped separators between underlined text.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 46:\u003c/strong\u003e As we see highlighted in the screen, the first thing we might notice is that those bits of underlined text are links. A breadcrumb is a collection of links.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 47:\u003c/strong\u003e At the start of each collection is a home, now highlighted on the screen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 48:\u003c/strong\u003e And at the end of each collection is the current page, now highlighted on the screen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 49:\u003c/strong\u003e So this might be our content model:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA collection of links\u003c/li\u003e\n\u003cli\u003eThe first is always a link to a common home\u003c/li\u003e\n\u003cli\u003eThen there can be any number of optional links\u003c/li\u003e\n\u003cli\u003eAnd finally a link to the current page\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIf you had just this content, you\u0026rsquo;d have everything you need to build a breadcrumb.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 50:\u003c/strong\u003e And if we want to express this in the language of standard elements, we have to manually interpret the model into standard elements. This can be complicated, and there are all kinds of questions you need to answer in this interpretation process, but this slide shows a bit of where we might land over in the gold markup area:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWe\u0026rsquo;ve defined the breadcrumb as a \u003ccode\u003enav\u003c/code\u003e navigation element.\u003c/li\u003e\n\u003cli\u003eWe\u0026rsquo;ve defined the collection of links as an ordered list.\u003c/li\u003e\n\u003cli\u003eAnd we\u0026rsquo;ve defined a \u003ccode\u003eclass\u003c/code\u003e attribute for each element, so we can write styles that target each of these unique classes.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eOur model can be very simple. Complex interpretation doesn\u0026rsquo;t \u003cem\u003erequire\u003c/em\u003e a complex model. Our model doesn\u0026rsquo;t have to answer the questions we address in the interpretation; it only has to sufficiently describe the content.\u003c/p\u003e\n\u003cp\u003eFrom this relatively simple model, we\u0026rsquo;ve developed a fairly complex bit of markup!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 51:\u003c/strong\u003e But USWDS doesn\u0026rsquo;t deliver models or interpreters, it delivers only the final stage in this process: the markup. What we might call a markup \u003cem\u003especification\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 52:\u003c/strong\u003e So what does a project team do with what USWDS delivers; with this specification?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 53:\u003c/strong\u003e Well teams have to reverse engineer our markup specification back into a model they can use as a project component template…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 54:\u003c/strong\u003e Then they can pass their own project data into their template, and use that template as an interpreter to output their own project-specific markup that matches the USWDS spec.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 55:\u003c/strong\u003e And what happens when USWDS updates the HTML spec? Teams have to go in and update their component templates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 56:\u003c/strong\u003e They have to identify what\u0026rsquo;s changed in the new USWDS spec.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 57:\u003c/strong\u003e And then they update their component template to make sure it\u0026rsquo;s outputting markup that matches the new spec. And they have to do this every time USWDS makes a markup change.\u003c/p\u003e\n\u003cp\u003eAccessibility changes often have related markup changes.\u003c/p\u003e\n\u003cp\u003eKey functionality changes often have related markup changes.\u003c/p\u003e\n\u003cp\u003eStatic content changes are often markup changes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 58:\u003c/strong\u003e This is work! Time, energy, resources! Multiplied by every team that\u0026rsquo;s using the design system. You can see why not every team can keep up with our updates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 59:\u003c/strong\u003e And it means that it makes it hard for USWDS to change. We have to be very conservative about the types of changes we can make and when we can make them.\u003c/p\u003e\n\u003cp\u003eThe diversity of template languages has meant that we\u0026rsquo;ve never been able to support any of them directly, and we\u0026rsquo;ve been stuck delivering an HTML spec — even while we know that this isn\u0026rsquo;t how teams build.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 60:\u003c/strong\u003e But what if — instead of the HTML spec — we could deliver the model directly, as some kind of custom element?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 61:\u003c/strong\u003e Along with an element interpreter to translate the custom element into standard HTML?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 62:\u003c/strong\u003e Well wouldn\u0026rsquo;t that be pretty much exactly a component template?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 63:\u003c/strong\u003e Yes. Yes it would.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 64:\u003c/strong\u003e And that ability to define custom elements and element interpreters is what the HTML standard released in 2013. And after some time, that standard is mature enough, and the browser support is good enough, that we can begin to use it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 65:\u003c/strong\u003e And this standard is the global web standard we call Web Components.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 66:\u003c/strong\u003e And as we started to see before, the power of Web Components is how we build our models, and the flexibility this allows our element interpreters to change and evolve the type of markup they assemble.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 67:\u003c/strong\u003e Let\u0026rsquo;s return to our Breadcrumb model, and to the set of different Breadcrumb instances we used to develop that model. Here again, we see those four breadcrumb instances, of different lengths.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 68:\u003c/strong\u003e Our content model can stay as it was. But now we want to investigate what it might mean to \u003cstrong\u003econfigure\u003c/strong\u003e our Breadcrumb. That is, if we think back to the HTML element model, are there any attributes we could imagine that would be little knobs or switches for our element, that might affect the way the breadcrumb looks or behaves?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 69:\u003c/strong\u003e For example, maybe you should be able to change the font? Like we see here changing the font to a serif.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 70:\u003c/strong\u003e Or maybe you might want to change the icons, either for the home or for the separators?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 71:\u003c/strong\u003e Or maybe there should be an option to omit the house icon altogether?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 72:\u003c/strong\u003e This is only the beginning of this type of discussion, but it begins to develop not only a content model for the element, but an \u003cem\u003eattributes\u003c/em\u003e model as well. Attributes might include\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003efont\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehouseIcon\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eseparatorIcon\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehasHouse\u003c/code\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBut there could be other kinds of configuration options as well.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 73:\u003c/strong\u003e And a really powerful thing about defining models is that they can support all kinds of potential output and markup. This concise model defines not only a current state for the Breadcrumb, as we see here with those Breadcrumbs we\u0026rsquo;ve seen before…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 74:\u003c/strong\u003e …but potentially different presentations of Breadcrumb as well. Now I\u0026rsquo;m not saying what we see here on screen is a good idea: For longer breadcrumbs, replacing the inner items with a dropdown menu. Probably a bad idea! But it\u0026rsquo;s possible that there\u0026rsquo;s something that\u0026rsquo;s either better than the current state, or becomes a user expectation. Our model describes \u003cem\u003ethis potential\u003c/em\u003e version of a breadcrumb \u003cem\u003ejust as well as\u003c/em\u003e the current version. And as long as breadcrumb stays, \u003cem\u003econceptually\u003c/em\u003e, as a collection of links that starts with Home and ends with the current page, our model doesn\u0026rsquo;t have to change, and the way we interface with our custom element doesn\u0026rsquo;t need to change either.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 75:\u003c/strong\u003e The power of the Web Component is the ability to have a simple, elegant model, as expressed as a custom element, that can be a consistent interface for a developer, even as the element interpreter changes under the hood.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 76:\u003c/strong\u003e Because unlike a markup spec, developers can update element interpreters automatically.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 77:\u003c/strong\u003e Developers only have to care about the interface, only those elements of the model that need project-specific configuration.\u003c/p\u003e\n\u003cp\u003eWhen we\u0026rsquo;re thinking about developing custom element interfaces, we have four goals: make them clear, concise, consistent, and configurable. Let\u0026rsquo;s take a look at a couple examples to get a sense of what I mean!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 78:\u003c/strong\u003e On this slide, we get a look at what the custom element interface might look like for a Breadcrumb Web Component.\u003c/p\u003e\n\u003cp\u003eWe want it to be \u003cem\u003eclear\u003c/em\u003e and \u003cem\u003econcise\u003c/em\u003e: This five-link breadcrumb instance is only six lines long, focusing on the collection of anchor links unique to this instance. We see from the first line of code in the opening tag, that this element is called \u003ccode\u003eusa-breadcrumb\u003c/code\u003e. And it contains four unique anchor links.\u003c/p\u003e\n\u003cp\u003eWhy not the Home link? Well, since the home link has the same text from instance to instance, we can leave out that link from the collection, and only capture its url in the element properties. Why ask someone to write out the word \u0026ldquo;Home\u0026rdquo; if they don\u0026rsquo;t have to?\u003c/p\u003e\n\u003cp\u003e(Though I will say, as an aside, that it\u0026rsquo;s a longer topic, but we do want to consider multilingual needs in here as well, and we\u0026rsquo;d build in the ability to do that…)\u003c/p\u003e\n\u003cp\u003eAnd we also want to make the breadcrumb \u003cstrong\u003econfigurable\u003c/strong\u003e. This example shows how you\nmight add a configuration option to add special RDFa metadata to the breadcrumb to improve search results and findability just by adding an RDFa attribute.\u003c/p\u003e\n\u003cp\u003eAnd finally, \u003cstrong\u003econsistency\u003c/strong\u003e: Since this custom element interface includes all the information the element interpreter needs to build all kinds of breadcrumbs, the custom elements interface doesn\u0026rsquo;t need to change over time. Crucially, the interface can remain the same, while the interpreter does all the heavy lifting, and that interpreter can be easily updated from version to version of the design system.\u003c/p\u003e\n\u003cp\u003eIn the end, you can see the difference between our new Web Component — and its six lines that developers need to learn — versus the 54-plus lines that developers need to track in our current markup spec.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 79:\u003c/strong\u003e We\u0026rsquo;ll just take a quick scroll through those 54 lines on the right side of the page… it\u0026rsquo;s much longer…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 80:\u003c/strong\u003e Really, a lot longer!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 81:\u003c/strong\u003e All these extra lines are just more things for developers to track. Additional points of potential failure when building a website. And these are details that developers shouldn\u0026rsquo;t be required to track and understand. When it comes to Web Components, for developers it\u0026rsquo;s the interface that\u0026rsquo;s important, not the final markup.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 82:\u003c/strong\u003e Our government Banner is another good example. Perhaps an even more dramatic example than Breadcrumb. It can be hard to stay up to date with the banner, since any time we can make an improvement to the copy, it requires a manual update for a developer. What if the banner wasn\u0026rsquo;t 93 lines of markup to track and implement?\u003c/p\u003e\n\u003cp\u003eWhat if it was closer to the clear, concise, configurable, and consistent six lines we see on this slide?\u003c/p\u003e\n\u003cp\u003eThis custom element, \u003ccode\u003eusa-banner\u003c/code\u003e, contains all the critical information a developer needs to set up and configure the banner:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWe can set the domain as \u0026ldquo;gov\u0026rdquo; so the rendered banner shows shows copy that refers to .gov domains\u003c/li\u003e\n\u003cli\u003eWe can set the background to dark, so it has a custom color.\u003c/li\u003e\n\u003cli\u003eAnd we can use USWDS design tokens to set the width of the component to \u0026ldquo;widescreen\u0026rdquo; so the text extends the same width as the rest of the elements on the site.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnd that\u0026rsquo;s it. The element interpreter does the rest, and developers don\u0026rsquo;t have to worry about 93 lines of custom markup, and copy that are subject to change and evolution over time!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 83:\u003c/strong\u003e So for example, what if we wanted to display the Spanish version of the banner. Instead of copying all the Spanish language copy and metadata into a custom template, we can just add a new attribute: \u003ccode\u003elang=\u0026quot;es\u0026quot;\u003c/code\u003e, and the banner updates to Spanish with just a single line of code.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 84:\u003c/strong\u003e Clear, concise, configurable, and consistent custom elements. The element interface stays consistent…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 85:\u003c/strong\u003e …while the element interpreter handles changes under the hood.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 86:\u003c/strong\u003e This makes the move to Web Components a big change in terms of upgradeability and maintainability. When you\u0026rsquo;re updating a Web Component, you\u0026rsquo;re updating interpreters, not markup. And upgrading the interpreter can be as simple as running a simple update script — essentially pushing a button.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 87:\u003c/strong\u003e Anything handled by the interpreter updates automatically…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 88:\u003c/strong\u003e This can be things like markup, logic, accessibility support, metadata, static content, styling, and behaviors.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 89:\u003c/strong\u003e And this means a move to thinking about theming as \u003cem\u003econfiguration\u003c/em\u003e — something that can happen closer to the custom element layer. Theming is more like input data to a component, rather than a layer of styling that\u0026rsquo;s applied from an external stylesheet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 90:\u003c/strong\u003e Altogether, the custom elements and element interpreters model of Web Components combines the power, continuity, and broad support of standards with the flexibility of templates and templating languages. It\u0026rsquo;s a well supported, cross-browser, platform-agnostic standard that takes the design system out of the static world of a markup spec into the dynamic world of templating…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 91:\u003c/strong\u003e Making the design system easier to implement, and easier to stay up to date.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 92:\u003c/strong\u003e Because maintenance and maintainability \u003cem\u003eis just the baseline\u003c/em\u003e. Not just for the design system, but for everyone who uses it. What would you do if you weren\u0026rsquo;t focused on maintenance? What higher order questions could you begin to solve? What \u003cem\u003emission-\u003c/em\u003e and \u003cem\u003euser-\u003c/em\u003e centered questions would you try to solve?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 93:\u003c/strong\u003e What could we do if we had the opportunity to focus on our shared mission: Shaping the future of government digital services? This technology is critical, necessary infrastructure, but the important question is what we\u0026rsquo;re able to do with it. And that\u0026rsquo;s a great question to start to ask.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 94:\u003c/strong\u003e So before we get into Q\u0026amp;A, I\u0026rsquo;d like to introduce James Mejia, a front-end engineer, and a contractor on the USWDS core team, and the person who knows more of the details than I do! James, can you introduce yourself, and we\u0026rsquo;ll move on to Q\u0026amp;A!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 95:\u003c/strong\u003e Q\u0026amp;A\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 96:\u003c/strong\u003e Thanks for joining today\u0026rsquo;s USWDS monthly call. We\u0026rsquo;ll be back next month to help celebrate Global Accessibility Awareness Day with a special guest and discussion on building accessible civic spaces. This is going to be a good one! Please 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\u0026rsquo;d 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 in the call, or thought of later, please head into our public Slack and ask it there. We\u0026rsquo;ll be around after the call to answer questions.\u003c/p\u003e\n\u003cp\u003eHave a great day, and a great April, and we\u0026rsquo;ll see you in May!\u003c/p\u003e\n\u003c/div\u003e\u003c/div\u003e\n\n\u003cp\u003eWeb Components have been mentioned in a lot of recent discussions about the future of the U.S. Web Design System (USWDS) . What is this technology, exactly, and what can it mean for the design system?\u003c/p\u003e\n\u003cp\u003eIn this session, the USWDS team will:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eExplain Web Components technology in plain language\u003c/li\u003e\n\u003cli\u003eDiscuss the value of bringing modern web technologies to the design system\u003c/li\u003e\n\u003cli\u003eExplore how using a new technology can affect any user of the design system, not just developers\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eThis event is best suited for:\u003c/strong\u003e All design system users (all levels). This will be a technical discussion, but anyone can attend as it requires no specialized knowledge.\u003c/p\u003e\n\u003cp\u003eSpeakers\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDan Williams\u003c/strong\u003e \u003cstrong\u003e-\u003c/strong\u003e Product Lead, USWDS\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJames Mejia\u003c/strong\u003e \u003cstrong\u003e-\u003c/strong\u003e Developer, USWDS contractor\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"join-our-communities-of-practice\"\u003eJoin our Communities of Practice\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://designsystem.digital.gov/about/community/\"\u003eUSWDS\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.section508.gov/manage/join-the-508-community/\"\u003eSection 508 IT Accessibility\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cem\u003eThis event is part of a monthly series that takes place on the third Thursday of each month. Don’t forget to set a placeholder on your personal calendar for our future events this year.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"about-the-uswds\"\u003eAbout the USWDS\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://designsystem.digital.gov/\"\u003eThe U.S. Web Design System\u003c/a\u003e is a toolkit of principles, guidance, and code to help government teams design and build accessible, mobile-friendly websites backed by user research and modern best practices.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://designsystem.digital.gov/\"\u003eThe U.S. Web Design System\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/uswds/uswds/issues\"\u003eContribute on GitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"mailto:uswds@gsa.gov\"\u003eEmail Us\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://digital.gov/communities/uswds/\"\u003eJoin our community\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/uswds\"\u003eFollow @uswds on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n",
      "branch" : "bc-archive-content-3",
      "filename" :"2024-04-18-uswds-monthly-call-april-2024.md",
      
      "filepath" :"events/2024/04/2024-04-18-uswds-monthly-call-april-2024.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/events/2024/04/2024-04-18-uswds-monthly-call-april-2024.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/events/2024/04/2024-04-18-uswds-monthly-call-april-2024.md","slug" : "uswds-monthly-call-april-2024","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2024/04/18/uswds-monthly-call-april-2024/"
    }
  ]
}