{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "event",
    "type" : "single",
    "title" : "USWDS Monthly Call - February 2022 |Digital.gov",
    "description": "USWDS Monthly Call - February 2022",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2022/02/17/uswds-monthly-call-february-2022/index.json","item" : [
    {"kicker" : "Moving Toward a USWDS API","title" :"USWDS Monthly Call - February 2022","summary" : "In this event, we will explore possibilities for a component API for the U.S. Web Design System.","date" : "2022-02-17T14:00:00-05:00","date_modified" : "2025-01-27T19:42:55-05:00","start_date" : "2022-02-17T14:00:00-05:00","end_date" : "2022-02-17T15:00:00-05:00",
      "event_organizer" : "Digital.gov","host" : "U.S. Web Design System","registration_url" : "https://www.eventbrite.com/e/uswds-monthly-call-moving-toward-a-uswds-api-feb-2022-tickets-267702765177","authors" : {"dan-williams" : "Dan Williams"},"topics" : {
        
            "application-programming-interface" : "Application programming interface",
            "design" : "Design"
            },"content" :"\u003cp\u003e\u003ca href=\"https://designsystem.digital.gov/files/monthly-calls/uswds-monthly-call-february-2022-distro.pptx.zip\"\u003eView the slides (PowerPoint presentation, 13.4 MB, 75 pages)\u003c/a\u003e\u003c/p\u003e\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 Script for February 2022\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 Hi there and welcome to the U.S. Web Design System monthly call for February 2022. And, for February we\u0026rsquo;re celebrating Black history month (with a red, gold, green, and brown logo), Valentine\u0026rsquo;s Day (with a logo in shades of pink), and Washington\u0026rsquo;s Birthday (otherwise known as Presidents Day — with a red, white, blue, and gray logo).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 2:\u003c/strong\u003e My name is Dan Williams, and I\u0026rsquo;m the USWDS product lead and this is my avatar, which maybe looks a bit like my best self — bright-eyed and positive perhaps! Thanks for being here!\u003c/p\u003e\n\u003cp\u003eFirst, I\u0026rsquo;d like to mention that we\u0026rsquo;re recording this monthly call, so please refrain from turning on your camera. We will manually turn off any cameras to ensure the recording doesn\u0026rsquo;t show us on camera.\u003c/p\u003e\n\u003cp\u003eI’d also like to remind you that all attendees must abide by the TTS Code of Conduct, which is available at handbook.tts.gsa.gov/code-of-conduct. We’ve posted the link to the code of conduct 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’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? First we\u0026rsquo;ll show off three excellent new site launches. Then I\u0026rsquo;ve got a handful of design system product updates. And then we\u0026rsquo;ll take a look at what is means to work toward a USWDS API — some of the opportunities we see, the problems were trying to solve, and how we\u0026rsquo;re thinking about this challenge.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 4:\u003c/strong\u003e So let\u0026rsquo;s get into it with site launches.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 5:\u003c/strong\u003e First up, \u003ca href=\"https://www.childtaxcredit.gov/\"\u003ehttps://www.childtaxcredit.gov/\u003c/a\u003e, a new site to help folks with children claim their new child tax credit. The homepage shows a big bright picture of a father and his kids, along with buttons to Get your Child Tax Credit and Check your eligibility. Also of note is a language switcher in the top-right corner, that points Spanish speaking users to the Spanish-language version of the site.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 6:\u003c/strong\u003e Next, \u003ca href=\"https://www.doioig.gov/\"\u003ehttps://www.doioig.gov/\u003c/a\u003e, the website of the Office of the Inspector General for the Department of the Interior. If you use the USWDS Identifier, it includes links required on all government web sites. One of those links is to your agency\u0026rsquo;s Office of the Inspector General. For the Department of the Interior, their OIG homepage shows a large image of the coronavirus, the words \u0026ldquo;pandemic response oversight,\u0026rdquo; and a big red button in the top right corner that reads \u0026ldquo;report fraud, waste, and abuse.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 7:\u003c/strong\u003e And finally, \u003ca href=\"https://www.dhs.gov/\"\u003ehttps://www.dhs.gov/\u003c/a\u003e, the website of the Department of Homeland Security. We were pleased to work with the DHS team early in their redesign process, and we\u0026rsquo;re proud to see what they built. The DHS team worked hard to build a site that uses the design system as close to its default settings as possible, and the result is a site and a homepage that\u0026rsquo;s immediately identifiable. Their homepage is a clear white and DHS blue, gov banner at the top of the page, search in the top-right, and hero section featuring DHS personnel, and a message that reads \u0026ldquo;a strong year of progress at DHS\u0026rdquo;.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 8:\u003c/strong\u003e Congratulations, and great work, everyone! Each month there\u0026rsquo;s a lot of hard work reflected in these humble screenshots. 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 9:\u003c/strong\u003e So, about sending us an email. After a couple good years of service, our \u003ca href=\"mailto:uswds@support.digitalgov.gov\"\u003euswds@support.digitalgov.gov\u003c/a\u003e email address is retiring. Starting this month, we\u0026rsquo;re changing the USWDS support email address. I know everyone has come to know and love \u003ca href=\"mailto:uswds@support.digitalgov.gov\"\u003euswds@support.digitalgov.gov\u003c/a\u003e and particularly how it runs tripplingly off the tongue and typing fingers, but over the coming month we\u0026rsquo;ll be phasing it out in favor of a new address. So, today let\u0026rsquo;s raise a glass for \u003ca href=\"mailto:uswds@support.digitalgov.gov\"\u003euswds@support.digitalgov.gov\u003c/a\u003e and say hello to:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 10:\u003c/strong\u003e \u003ca href=\"mailto:uswds@gsa.gov\"\u003euswds@gsa.gov\u003c/a\u003e. Moving forward, if you\u0026rsquo;d like to get in touch with us, send us a note at the simple and straightforward \u003ca href=\"mailto:uswds@gsa.gov\"\u003euswds@gsa.gov\u003c/a\u003e. In fact, you can use that email address today — and you should! So update your address books, and tell your friends.\u003c/p\u003e\n\u003cp\u003eBehind the scenes, we\u0026rsquo;re moving to a new email ticketing system, and while in the best case this should be a \u0026ldquo;who cares why are you telling me this\u0026rdquo; thing, there may be a few hiccups as we make the transition. If you see an email coming from \u0026ldquo;IT Service Desk\u0026rdquo; after emailing us, it\u0026rsquo;s probably us. We hope that within a week or so all our emails will be obvious and clearly from USWDS, but if you\u0026rsquo;ve emailed us and haven\u0026rsquo;t heard anything back, check in again — we\u0026rsquo;re still there, and we\u0026rsquo;re still ironing out the quirks.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 11:\u003c/strong\u003e So now, a few product updates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 12:\u003c/strong\u003e So, moving on to design system releases. USWDS 2.13.2\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 13:\u003c/strong\u003e Improved submenu item targets in the Header: We\u0026rsquo;re making the touch and click target bigger in header dropdown menus.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 14:\u003c/strong\u003e Improved ARIA markup in the Combo box: We improved the accessibility of Combo box by including the proper aria-control property on the select.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 15:\u003c/strong\u003e Removed inline styles from GitHub icon: We improved the markup of the Github icon to prevent a possible conflict with common  Content Security Policies which can flag use of inline styles.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 16:\u003c/strong\u003e Improved accessibility of disclosure buttons in mobile Footer: We improved the accessibility of the large footer by assuring that each collapsible section is triggered by a proper button.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 17:\u003c/strong\u003e And that\u0026rsquo;s USWDS 2.13.2 — available next week.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 18:\u003c/strong\u003e We\u0026rsquo;re also gearing up for a new release of the USWDS 3.0: Beta 3 — which gets us to Sass Module support! We\u0026rsquo;re still working through the finishing touches on this, but we\u0026rsquo;ll have a version of USWDS with Sass module support next week. Next on our list is making it as easy as possible for teams to use this new module-based Sass in their existing codebase.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 19:\u003c/strong\u003e And that\u0026rsquo;s USWDS 3.0 Beta 3 — as I said, also available next week.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 20:\u003c/strong\u003e Toward a USWDS API\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 21:\u003c/strong\u003e Why do we even use design systems? Why are they powerful?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 22:\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eSpeak the same design language\u003c/li\u003e\n\u003cli\u003eStart building faster\u003c/li\u003e\n\u003cli\u003eShare solutions\u003c/li\u003e\n\u003cli\u003eCoordinate design across a large organization\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBy that measure USWDS is pretty successful.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 23:\u003c/strong\u003e But what about staying in sync over time? Coordination isn\u0026rsquo;t just starting from the same styles, it\u0026rsquo;s staying in sync as the design system improves and matures — and this is where USWDS begins to break down a bit. An effective design system doesn\u0026rsquo;t just scale design expertise at a single moment in time, it connects projects so projects can grow and improve together over time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 24:\u003c/strong\u003e Here\u0026rsquo;s what we\u0026rsquo;d hope this kind of design system — with connected improvement over time — would work: We\u0026rsquo;d have a network of projects connected together with the design system as the central node — either directly, or via a parent design system that is, itself, connected to USWDS.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 25:\u003c/strong\u003e As teams implement the design system and adapt it to their needs, they learn how the design system can improve — where there are bugs, accessibility issues, or any place what the design system provides isn\u0026rsquo;t as effective as it should be.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 26:\u003c/strong\u003e These teams can make a change, or a fix, or let USWDS know that there\u0026rsquo;s a problem.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 27:\u003c/strong\u003e Then USWDS picks up the improvement. We fix it at the design system level, and we make an update to our code.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 28:\u003c/strong\u003e We push the improvement out in an update. Then downstream projects install the update, and the improvements scale across the network of design system users.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 29:\u003c/strong\u003e That\u0026rsquo;s the ideal case. And that\u0026rsquo;s where we can really see the power of a design system — not just as a one-and-done thing, but as a way to evolve together and at scale across the whole project network, over time. The whole network benefits.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 30:\u003c/strong\u003e Today, it\u0026rsquo;s not quite so simple or so effective. And this is because it can be hard to stay in sync with the design system, and it takes effort to update to new versions — the more we change in an update, the more effort it can take.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 31:\u003c/strong\u003e Back in the halcyon early days of a design system all is well. Everyone\u0026rsquo;s in the same place, everything\u0026rsquo;s new and everyone\u0026rsquo;s in sync!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 32:\u003c/strong\u003e But if it takes energy to update and stay in sync, not every team will be able to do it — or be able to do it at the same speed. The harder it is to update, the bigger the difference between teams that can do it and teams that cannot.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 33:\u003c/strong\u003e Fragmentation grows with each new version.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 34:\u003c/strong\u003e But the design system can\u0026rsquo;t just stop evolving. It can\u0026rsquo;t freeze or stop maturing. In the world of software development, to stop is to begin to die.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 35:\u003c/strong\u003e And with each change, not only does the fragmentation widen, but the effort needed to migrate to the current version grows and grows. This tech debt only gets bigger and bigger over time. Teams that don\u0026rsquo;t have the resources to stay up-to-date will only find it more and more difficult to migrate when it\u0026rsquo;s really needed.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 36:\u003c/strong\u003e And now just scale this issue up in time and footprint. The more the design system grows, when updating is hard, the problem gets bigger and bigger. So it\u0026rsquo;s important to address these updating and migrating issues as soon as possible. Like planting a tree — the best time was probably a couple years ago. But the next best time is now.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 37:\u003c/strong\u003e How can we reduce breaking changes while allowing product evolution? As we saw in our September monthly call from last year, breaking changes are at the heart of this difficulty, where a breaking change is defined as a change in our source code that can require downstream change to for our users — a change to how people and machines use the design system code — a change to what\u0026rsquo;s called the Application Programming Interface, or API.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 38:\u003c/strong\u003e But what is an API? APIs are the explicit connections between applications. They\u0026rsquo;re the user interface for code.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 39:\u003c/strong\u003e They\u0026rsquo;re like little predefined inputs and outputs: the way our application says \u0026ldquo;do this and get that.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 40:\u003c/strong\u003e Hook them up properly and get predictable results.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 41:\u003c/strong\u003e But if the user interface changes, the connection breaks. If you \u0026ldquo;do this\u0026rdquo; and no longer \u0026ldquo;get that,\u0026rdquo; the interface is broken.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 42:\u003c/strong\u003e So how does this work in practice? And what does this mean in the context of USWDS? How does the USWDS API (or the lack of one?) keep the design system from reaching its potential, and what might we do to address this problem?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 43:\u003c/strong\u003e To work through this issue, I\u0026rsquo;d like to introduce you to a different kind of analogous product: a magical machine I\u0026rsquo;ve invented. It\u0026rsquo;s called the VirtuWheel.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 44:\u003c/strong\u003e Say hello to VirtuWheel: It\u0026rsquo;s a pretty cool piece of magical technology. It can actually create a real wheel out of pure information. Just set it up, connect it to your car, it\u0026rsquo;ll build a new set of wheels for your car every time you use your car. Set it up, connect to the internet, and get a real wheel. It’s the future of wheels.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 45:\u003c/strong\u003e But VirtuWheel is a little complicated. What we ship to you are our best-in-class blueprints and you do have to assemble it yourself. Oh but it\u0026rsquo;s incredible… once you put it together. It connects to the internet. You assemble a matrix of sensors, assign each sensor a unique name, which corresponds to an instruction set that tells the machine how to build a part of the final wheel. The instruction set is called VirtuWheelOS, and it connects each of the sensors, by name, to its individual definition.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 46:\u003c/strong\u003e And there are all kinds of sensors. There are bolt sensors and rim sensors. Tread sensors and air pressure sensors. Nuts and washers have sensors too! We made a sensor for every single part, even the ones you\u0026rsquo;ve never heard of! Just put them all together in the right arrangement and you\u0026rsquo;re good to go!\u003c/p\u003e\n\u003cp\u003eAnd if you need VirtuWheel for a bicycle or a tractor, we have a special set of blueprints for those too. It does have all different sensors, though.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 47:\u003c/strong\u003e But when all those sensors and connectors are setup and in the right place…\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 48:\u003c/strong\u003e …it works!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 49:\u003c/strong\u003e You just generated a just-in-time real-deal wheel you can drive on.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 50:\u003c/strong\u003e Hey, you installed your VirtuWheel, great! Now, good news and bad news. First, we learned that VirtuWheel is not as effective on icy roads as we were hoping. And it\u0026rsquo;s susceptible to corrosion in extreme winter conditions as well. Glad we caught these issues early.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 51:\u003c/strong\u003e And we have a fix. Just download VirtuWheel OS 1.1… and follow the instructions for changing the order and naming of all the sensors in your version. Make sure not to install VirtuWheel OS 1.1 without reordering and renaming your sensors — your wheel may behave… unpredictably.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 52:\u003c/strong\u003e And now VirtuWheelOS 1.2 is out now, too. It builds on the improvements in VirtuWheelOS 1.1 to deliver an even smoother ride. Just follow the instructions from VirtuWheelOS 1.1, then make the additional changes outlined in the VirtuWheelOS 1.2 release notes. We include all new blueprints with each update!\u003c/p\u003e\n\u003cp\u003eIt is a bit technical. Hopefully you still have the person around who installed the original VirtuWheel.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 53:\u003c/strong\u003e Before you know it, it becomes too much work to keep up with the changes to VirtuWheelOS. And when VirtuWheelOS 2.0 comes out, all it sounds like is work.\u003c/p\u003e\n\u003cp\u003eNot only that, but some folks with newer cars are frustrated with VirtuWheel for another reason. VirtuWheel only initializes its wheel when you turn on the car. Some newer car makers want the ability to press a button on the dashboard to change the wheel mode from, say, normal to ice mode or off-road mode. Some imagine changing the wheel mode automatically, based on sensors in the wheel itself. But VirtuWheel doesn\u0026rsquo;t support this — you have to turn the car on and off to trigger a new VirtuWheel.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 54:\u003c/strong\u003e VirtuWheel is amazing: it can make a real wheel out of pure information and magic! But it\u0026rsquo;s complicated because not only do you have to build it yourself, but VirtuWheelOS depends on how you build it, and the specific names of all the sensors you installed, and their arrangement. It\u0026rsquo;s frustrating that it\u0026rsquo;s as complicated as building an actual wheel to know how to build a VirtuWheel!\u003c/p\u003e\n\u003cp\u003eOne of the many issues with our VirtuWheel is that it really doesn\u0026rsquo;t have an interface. The interface is, essentially, how you build it. The interface is the name of each individual sensor and how those sensors have been installed. That\u0026rsquo;s why updates to VirtuWheelOS can be so complicated: To change it, you have to rebuild it every time. The wheel may be virtual, but the sensors are not — it\u0026rsquo;s your responsibility to make sure they\u0026rsquo;re up to date with the OS.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 55:\u003c/strong\u003e That\u0026rsquo;s when someone invented the Virtual Sensor. That\u0026rsquo;s right. If we can make a virtual wheel, why use virtual sensors to build it? Why require users to assemble it themselves?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 56:\u003c/strong\u003e This was the proposal that made jaws drop at the VirtuWheel research and development department annual meeting. The team showed off a new VirtuWheel device that used virtual sensors defined by VirtuWheelOS to build the wheel. They work just like real sensors! They output a real wheel just like the other sensors.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 57:\u003c/strong\u003e But now you don\u0026rsquo;t need to assemble it. All users had to do was attach one simple device to their vehicle and it made a wheel. It automatically connects to VirtuWheel OS. No setup required.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 58:\u003c/strong\u003e And what\u0026rsquo;s more, the new device has a control panel.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 59:\u003c/strong\u003e Now you control your VirtuWheel with a control panel, instead of by building a new wheel for each purpose.\u003c/p\u003e\n\u003cp\u003eThe control panel has three dials: vehicle, radius, and condition. Instead of building new devices each time, you just set some settings.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 60:\u003c/strong\u003e Choose Car and the device makes a car wheel. You can set the vehicle type to car, bike, or tractor.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 61:\u003c/strong\u003e Choose Bike and the device makes a bicycle wheel. You can set the radius to small, medium, or large.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 62:\u003c/strong\u003e Choose Tractor and the device makes a tractor wheel. And you can set the condition to standard, ice, or off-road.\u003c/p\u003e\n\u003cp\u003eInside, the new VirtuWheel does its magic, and reconfigures its virtual sensors and instruction sets.\u003c/p\u003e\n\u003cp\u003eThe new virtual sensors and control panel made a huge difference to how folks could use VirtuWheel. It was much easier to set up and install — no messing around with blueprints and sensors. It was much easier to understand — there were just a few documented settings. And it was much easier to maintain as well.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 63:\u003c/strong\u003e Then the developers showed off something amazing that was never before possible with VirtuWheel: Automatic puncture fix and zero-friction bearings. This could make a huge difference for safety and performance, but it required a massive overhaul to the wheel sensors. With earlier versions, folks might expect to spend hours or days rebuilding their VirtuWheel to get these improvements, but with the new architecture, all they needed to do was update the OS, the virtual sensors arranged themselves automatically, and users just got the new, better wheel.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 64:\u003c/strong\u003e As long as VirtuWheel didn\u0026rsquo;t change the settings on the control panel, users would get the wheel they expect, with any improvements, without all the effort. Now it really did seem like magic.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 65:\u003c/strong\u003e No blueprints.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 66:\u003c/strong\u003e No sensor building.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 67:\u003c/strong\u003e Now the settings, not the internal structure, are the interface. But someone raised an objection: What about the hobbyists? They love tinkering with VirtuWheel and getting their hands dirty understanding the sensors!\u003c/p\u003e\n\u003cp\u003eNot to worry said the engineers — anyone can still open up the machine and tinker. They\u0026rsquo;ll just be tinkering at a different level. Those who like to tinker can tinker and those who don\u0026rsquo;t care at all about what\u0026rsquo;s going on inside the machine never have to think about it.\u003c/p\u003e\n\u003cp\u003eWhat about the settings on the control panel itself, asked a stakeholder? How do we know if it fits all the use cases our users need? How do we build the best, most useful control panel, asked another? And how can we make sure that our new VirtuWheel is compatible with all the different ways folks are building modern vehicles, asked a third?\u003c/p\u003e\n\u003cp\u003eWell, the engineers replied, we\u0026rsquo;ll have to do the best we can at first, ask what folks need, and learn how our audience is using VirtuWheel. We\u0026rsquo;ll look at what architecture is most interoperable. We\u0026rsquo;ll do our best, and iterate on the control panel as we move forward with the product — but now, at least, we\u0026rsquo;re asking the right questions.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 68:\u003c/strong\u003e When we think about what we\u0026rsquo;re building with USWDS, our components are essentially similar to the VirtuWheel, instead of making wheels for cars, we\u0026rsquo;re delivering buttons, form fields, custom lists, modals, cards, etc. for websites and services. But our components share the original VirtuWheel\u0026rsquo;s implementation and maintenance issues. VirtuWheel\u0026rsquo;s blueprints, sensors, names, and definitions are our markup, class names, and styling.\u003c/p\u003e\n\u003cp\u003eAnd when we think about a component API — an application programming interface — just as with VirtuWheel, we\u0026rsquo;re talking about abstracting all of that internal stuff away, and focusing on the control panel: what settings does the component need? what content does it accept? and how does it connect to the rest of the service and other components?\u003c/p\u003e\n\u003cp\u003eFor each component, we need to ask: What does its control panel do? what inputs and outputs does it have? and what\u0026rsquo;s the shape of its power cable, essentially — does it have three prongs or two?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 69:\u003c/strong\u003e We\u0026rsquo;ll need to think not only about what a component is, but what a component needs to do. I believe this has significant overlap with some of the thinking around semantic markup and the priorities that lead to the development of HTML5. This, for instance, is what led us from the \u003ccode\u003e\u0026lt;b\u0026gt;\u003c/code\u003e tag to the \u003ccode\u003e\u0026lt;strong\u0026gt;\u003c/code\u003e tag. Both tags are rudimentary APIs, but the modern \u003ccode\u003e\u0026lt;strong\u0026gt;\u003c/code\u003e tag helps us focus on the purpose, not output. It is, arguably, a more effective API because the naming convention, the abstraction, the thing that is meant to stay most consistent over time is the purpose of the element. Semantics and purpose is something we\u0026rsquo;ll keep in mind as we think about a USWDS component API.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 70 \u0026amp; 71:\u003c/strong\u003e And this gets to the purpose and the power of an API: The API — the controls — are what stay the same so that everything else can change. The true importance of a button isn\u0026rsquo;t in the specifics of how it\u0026rsquo;s built — what\u0026rsquo;s going internally to make a button appear — it\u0026rsquo;s in what it does, it\u0026rsquo;s purpose. APIs let teams focus on what the component is doing, and abstracts away everything else. It makes the \u0026ldquo;everything else\u0026rdquo; our responsibility, the responsibility of the design system. You can focus on things that are closer to your product and your mission: what the button says, how important it should be, and what action the button triggers. We focus on making sure it acts like a button for everyone that uses it: Improving its accessibility, perfecting its typography, and making sure it\u0026rsquo;s doing everything you want it to do, as well as it can do it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 72:\u003c/strong\u003e We see this as the next major paradigm shift in the story of the design system. USWDS 1.0 introduced a practical, reusable styleguide. USWDS 2.0 introduced a consistent language of design tokens. USWDS 3.0 will unbundle the design system and improve modularity. And as we move on from 3.0, our focus will be on resilience, maintainability, and interoperability — toward building a design system that can evolve at scale, together, for years to come.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 73:\u003c/strong\u003e In many ways, realizing the full power of the design system still lies ahead of us. So let\u0026rsquo;s get out there and reinvent our wheels.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 74:\u003c/strong\u003e [Q\u0026amp;A]\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlide 75:\u003c/strong\u003e Thanks for joining today’s USWDS monthly call. Next month, the monthly call will be on March 17, 2022, the third Thursday of the month, and St. Patrick\u0026rsquo;s Day. We\u0026rsquo;ll have a USWDS 3.0 Preview!\u003c/p\u003e\n\u003cp\u003eAs always, I encourage you to join our community in the #uswds-public Slack channel so you can follow our progress, get answers, and contribute to the discussion.\u003c/p\u003e\n\u003cp\u003eFollow us on Github at github.com/uswds, check out our website, and visit designsystem.digital.gov/about/community to join us and your colleagues across government who are using USWDS.\u003c/p\u003e\n\u003cp\u003eThank you, and see you next month!\u003c/p\u003e\n\u003c/div\u003e\u003c/div\u003e\n\n\u003chr\u003e\n\u003cp\u003eWhat would it look like to implement and customize our design system via a component API? \u003c/p\u003e\n\u003cp\u003eJoin us for a discussion of what might be next for USWDS after the release of USWDS 3.0 this spring.\u003c/p\u003e\n\u003cp\u003eThe USWDS team will discuss how an API might help us work all together more effectively, and how an API might make it easier to maintain and update a USWDS project. \u003c/p\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@support.digitalgov.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" :"2022-02-11-uswds-monthly-call-february-2022.md",
      
      "filepath" :"events/2022/02/2022-02-11-uswds-monthly-call-february-2022.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/events/2022/02/2022-02-11-uswds-monthly-call-february-2022.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/events/2022/02/2022-02-11-uswds-monthly-call-february-2022.md","slug" : "uswds-monthly-call-february-2022","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/event/2022/02/17/uswds-monthly-call-february-2022/"
    }
  ]
}