diff --git a/content/communities/communicators.md b/content/communities/communicators.md index 1559d88eea..a1c981e176 100644 --- a/content/communities/communicators.md +++ b/content/communities/communicators.md @@ -1,29 +1,38 @@ --- -# See all topics at https://digital.gov/topics -topics: - - content-strategy - - plain-language - - social-media - - communication -dg_acronym: FCN -dg_logo: communities-communicators.svg -date: 2021-02-24 18:49:00 -0500 title: Join the Communicators summary: "Improve written and verbal communication to make government more effective." - deck: Share and learn with communications and public affairs practitioners. +dg_shortname: Communicators +dg_acronym: FCN +dg_logo: communities-communicators.svg +dg_highlight: true +date: 2021-02-24 18:49:00 -0500 + # See all authors at https://digital.gov/authors authors: - deanna-mccray-james - josie-anderson -dg_shortname: Communicators -slug: communicators -kicker: Communities of practice +# See all topics at https://digital.gov/topics +topics: + - content-strategy + - plain-language + - social-media + - communication + +event_cop: communicators + +community_list: + - platform: listserv + type: government + subscribe_email: "fcn-request@listserv.gsa.gov" + subscribe_email_subject: "Join the Communicators Community" + terms: "Government employees and contractors with an official .gov or .mil email are eligible to join." + members: 2,554 + join_cop_button: "Communicators community members" -primary_image: # Controls how this page appears across the site # 0 -- hidden # 1 -- visible @@ -43,9 +52,7 @@ community_list: are eligible to join. members: 2,501 join_cop_button: Communicators community members -dg_highlight: true -event_cop: - - communicators + --- Government professionals from all levels come together in this community to improve written and verbal communication to make government communication more effective. diff --git a/content/communities/contact-center.md b/content/communities/contact-center.md index dc9b487fdd..f3767a3f74 100644 --- a/content/communities/contact-center.md +++ b/content/communities/contact-center.md @@ -15,8 +15,7 @@ topics: - contact-centers - customer-experience -event_cop: - - contact-center +event_cop: contact-center community_list: - platform: listserv diff --git a/content/communities/multilingual.md b/content/communities/multilingual.md index bb8a1bd532..78a60cc845 100644 --- a/content/communities/multilingual.md +++ b/content/communities/multilingual.md @@ -18,8 +18,7 @@ authors: - lgodfrey - fedora-braverman -event_cop: - - multilingual +event_cop: multilingual # see all topics at https://digital.gov/topics topics: diff --git a/content/communities/plain-language-community-of-practice.md b/content/communities/plain-language-community-of-practice.md index 8c0574ada2..ab24987bb9 100644 --- a/content/communities/plain-language-community-of-practice.md +++ b/content/communities/plain-language-community-of-practice.md @@ -27,8 +27,7 @@ topics: - plain-language - communication -event_cop: - - plain-language +event_cop: plain-language # Weight: controls how this page appears across the site # 0 -- hidden diff --git a/content/communities/social-media.md b/content/communities/social-media.md index ed0be597c5..875f430d52 100644 --- a/content/communities/social-media.md +++ b/content/communities/social-media.md @@ -18,8 +18,7 @@ authors: topics: - social-media -event_cop: - - social-media +event_cop: social-media # Page weight: controls how this page appears across the site # 0 -- hidden diff --git a/content/communities/user-experience.md b/content/communities/user-experience.md index 0da041e6eb..9d43c1df8a 100644 --- a/content/communities/user-experience.md +++ b/content/communities/user-experience.md @@ -17,8 +17,7 @@ aliases: topics: - user-experience -event_cop: - - user-experience +event_cop: user-experience # Weight: controls how this page appears across the site # 0 -- hidden diff --git a/content/communities/web-analytics-and-optimization.md b/content/communities/web-analytics-and-optimization.md index 630434128f..f337eb99a2 100644 --- a/content/communities/web-analytics-and-optimization.md +++ b/content/communities/web-analytics-and-optimization.md @@ -24,8 +24,7 @@ aliases: authors: - tlowden -event_cop: - - web-analytics +event_cop: web-analytics # Controls how this page appears across the site # 0 -- hidden diff --git a/content/communities/web-managers-forum.md b/content/communities/web-managers-forum.md index c6b67cf1bd..3982f0b196 100644 --- a/content/communities/web-managers-forum.md +++ b/content/communities/web-managers-forum.md @@ -46,8 +46,7 @@ authors: - beth-martin - ruxi-giura -event_cop: - - web-managers +event_cop: web-managers # Page weight: controls how this page appears across the site # 0 -- hidden diff --git a/content/events/2022/10/2022-10-13-october-2022-uswds-monthly-call.md b/content/events/2022/10/2022-10-13-october-2022-uswds-monthly-call.md index 07524f853f..68cb9cafba 100644 --- a/content/events/2022/10/2022-10-13-october-2022-uswds-monthly-call.md +++ b/content/events/2022/10/2022-10-13-october-2022-uswds-monthly-call.md @@ -6,7 +6,6 @@ summary: We’ll discuss our approach to developing User Profile design patterns look at some specific guidance, and talk about why it’s so important. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: null registration_url: https://www.eventbrite.com/e/uswds-monthly-call-user-profile-patterns-oct-2022-tickets-441135597447 captions: https://www.streamtext.net/player?event=BIS-GSA-JY date: 2022-10-20 14:00:00 -0500 @@ -24,7 +23,6 @@ slug: october-2022-uswds-monthly-call # zoom, youtube_live, adobe_connect, google event_platform: zoom primary_image: uswds-monthly-call-october-title-card - --- {{< asset-static file="uswds-monthly-call-october-2022.pptx" label="View the slides (PowerPoint presentation, 7.2 MB, 67 pages)" >}} @@ -59,7 +57,7 @@ And if all goes well, we'll have some time left at the end of Q&A. So let's get **Slide 4:** With a nice new site launch -**Slide 5:** This month, it's exciting to share beta.usa.gov (and beta.usa.gov en español) with you. For USAGov, launching these sites is the next step toward continuing USAGov’s role as the federal front door. Explore the new content structure focused on one user intent per page and interactive features that will allow users to find their answers quicker. On the beta.usa.gov homepage a crisp red, white, and blue design. We see an alert notifying folks that this is a beta site, a link to USAGov en Espanol in the top-right, and a blue hero box with the text: Welcome to the USA.gov beta site, the first step to a new USA.gov. +**Slide 5:** This month, it's exciting to share beta.usa.gov (and beta.usa.gov en español) with you. For USAGov, launching these sites is the next step toward continuing USAGov’s role as the federal front door. Explore the new content structure focused on one user intent per page and interactive features that will allow users to find their answers quicker. On the beta.usa.gov homepage a crisp red, white, and blue design. We see an alert notifying folks that this is a beta site, a link to USAGov en Espanol in the top-right, and a blue hero box with the text: Welcome to the USA.gov beta site, the first step to a new USA.gov. **Slide 6:** 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! @@ -130,9 +128,9 @@ We all know that a website is more than just components on a page — the whole What does this mean when it comes to name, address, and contact information? What barriers might this information introduce? I'd like to pass it to Meaghan to talk about why these are critical patterns, and what we've learned from our research. -**Slide 25:** Meghan: As we discussed in the last monthly meeting, we did a lot of research to learn from our colleagues around the federal space, and hear from them what types of interactions they are wrestling with and what they would like USWDS to work on. We primarily spoke with people on web teams at high impact service providers — also known as HISPs — the agencies and programs that have the most direct contact with the American people. From these digital teams we heard how challenging asking about personal information can be. Teams discussed trying to design effective information collection tools, while also balancing validation requirements and reporting obligations. At the same time, teams wanted to respect the true diversity of their audience and the individuals that use their sites. We see a colorful illustration of people on the next slides. +**Slide 25:** Meghan: As we discussed in the last monthly meeting, we did a lot of research to learn from our colleagues around the federal space, and hear from them what types of interactions they are wrestling with and what they would like USWDS to work on. We primarily spoke with people on web teams at high impact service providers — also known as HISPs — the agencies and programs that have the most direct contact with the American people. From these digital teams we heard how challenging asking about personal information can be. Teams discussed trying to design effective information collection tools, while also balancing validation requirements and reporting obligations. At the same time, teams wanted to respect the true diversity of their audience and the individuals that use their sites. We see a colorful illustration of people on the next slides. -**Slide 26:** This respect — which often means supporting users from varying cultures, backgrounds, and perspectives — and in all sorts of different situations — was something digital teams felt was critical to good and effective experience design. But it is also something that supports various executive orders, including [Executive Order 14058](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/12/13/executive-order-on-transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government/) Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government and [Executive Order 13985](https://www.performance.gov/equity/) Advancing Racial Equity and Support for Underserved Communities through the Federal Government. +**Slide 26:** This respect — which often means supporting users from varying cultures, backgrounds, and perspectives — and in all sorts of different situations — was something digital teams felt was critical to good and effective experience design. But it is also something that supports various executive orders, including [Executive Order 14058](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/12/13/executive-order-on-transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government/) Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government and [Executive Order 13985](https://www.performance.gov/equity/) Advancing Racial Equity and Support for Underserved Communities through the Federal Government. **Slide 27:** We’ve developed ten patterns to help users: @@ -147,7 +145,7 @@ What does this mean when it comes to name, address, and contact information? Wha 9. Provide their biological sex or gender, and 10. Share their pronouns -Some of these patterns are pretty straightforward and some of these are really complicated — and some of these are only just emerging in a rapidly changing environment. +Some of these patterns are pretty straightforward and some of these are really complicated — and some of these are only just emerging in a rapidly changing environment. **Slide 28:** Today we are going to focus on the first four: helping users to provide their name, enter their address, provide their email, and enter their phone number. In future Monthly Calls we’ll dive into the others. @@ -155,7 +153,7 @@ Some of these patterns are pretty straightforward and some of these are really c **Slide 30:** Each pattern has a description, how it can apply to your website or service, and how to approach a solution. -**Slide 31:** Each pattern has Guidance. Recommendations on what to do — and what not to do. +**Slide 31:** Each pattern has Guidance. Recommendations on what to do — and what not to do. **Slide 32:** Each pattern has Considerations: Practical implementation details, often related to usability and accessibility. @@ -163,7 +161,7 @@ Some of these patterns are pretty straightforward and some of these are really c **Slide 34:** And patterns have supporting information: Other examples, related components, and sources we used in addition to our direct research. So let’s get started. -**Slide 35:** Let's start with name patterns. It might seem that asking for someone’s name is pretty straightforward — after all, everyone has one! But personal names are surprisingly complicated. For example, +**Slide 35:** Let's start with name patterns. It might seem that asking for someone’s name is pretty straightforward — after all, everyone has one! But personal names are surprisingly complicated. For example, **Slide 36:** In some cultures people have only one name. So if you require a first and last name, not only will the user not have one of each, but they wouldn’t know in which field to place the one name they have. @@ -175,7 +173,7 @@ Some of these patterns are pretty straightforward and some of these are really c **Slide 40:** And names can have multiple upper- and lowercase letters, as well as multiple spaces or hyphens. -**Slide 41:** And in some cultures it is common to have two — or more — last names. +**Slide 41:** And in some cultures it is common to have two — or more — last names. **Slide 42:** You may have heard that Anna May Wong, an American actress of Chinese heritage, will be the first Asian American on U.S. currency. A true trailblazer, she will be on a new quarter. Born Wong Liu Tsong, she was known professionally as Anna May Wong. In many cultures, including Chinese, the family name comes first and the given name comes second, making “first name” inappropriate and potentially confusing. @@ -191,15 +189,15 @@ The pattern guidance recommends providing multiple text entry fields, with direc Our pattern guidance also suggests -- Supporting long text fields — and short names +- Supporting long text fields — and short names - Supporting a rich array of special characters - Allowing users to enter more than one name in each field - Allowing both upper and lowercase letters in each field, along with hyphens, apostrophes and blank spaces -- And we address asking for a maiden name — we recommend against this practice. But if you do need a previous name, ask for it. +- And we address asking for a maiden name — we recommend against this practice. But if you do need a previous name, ask for it. **Slide 44:** At this time we are recommending that you consider incorporating “given” and “family” name into your name field labels. This slide highlights the **First or given name** and **Last or Family name** labels in the name pattern. This seems to be an emerging best practice and also addresses some of the challenges with non-Western European names. -**Slide 45:** As I mentioned, if you don’t need to parse apart the pieces of a name — if you don’t need to validate the name, for instance — just ask for the full name in one field. +**Slide 45:** As I mentioned, if you don’t need to parse apart the pieces of a name — if you don’t need to validate the name, for instance — just ask for the full name in one field. **Slide 46:** And if you will be reaching out to verbally speak with someone, or expect formal correspondence, consider asking how they’d like to be addressed. For example, Dan, or Mr. Gonzalez, or Dr. Gonzalez. @@ -249,13 +247,13 @@ A street address is required for a mailing address, but it may not be required f **Slide 54:** While we were working on the address pattern, we did make an unwelcome discovery. Users of assistive technology, especially screen readers, had a consistently difficult time navigating the Combobox used for the State dropdown. -When the address pattern is published, you'll notice a change in how we're approaching the treatment of some elements because of these challenges. We’ve replaced the Combobox with the Select component. This change will be making its way through related component guidance and templates within the design system, so stay tuned for more information. +When the address pattern is published, you'll notice a change in how we're approaching the treatment of some elements because of these challenges. We’ve replaced the Combobox with the Select component. This change will be making its way through related component guidance and templates within the design system, so stay tuned for more information. **Slide 55:** The email address pattern is pretty straightforward, but there are considerations and opportunities. **Slide 56:** We recommend you clearly state why you need someone’s email address and under what circumstances you would use it to contact them. -**Slide 57:** Email addresses can be very long. Make sure to accommodate up to 256 characters — which would be a really long (but valid!) email address. +**Slide 57:** Email addresses can be very long. Make sure to accommodate up to 256 characters — which would be a really long (but valid!) email address. **Slide 58:** Email addresses can get complicated. Simple validation is best. We do recommend you validate formatting by checking for an at symbol that is preceded and followed by one or more characters. We also recommend both client-side and server-side validation, if possible. @@ -264,7 +262,7 @@ When the address pattern is published, you'll notice a change in how we're appro - Make sure to accommodate up to 256 characters - Allow people to paste their email address and consider enabling autocomplete to enter the address if they’ve entered it before. - Also, consider the safety implications associated with people who share email addresses. You may need to ask for permission to leave potentially sensitive information. -- It is great if you can check for common misspellings of popular email providers — but don’t autocorrect them! Warn people if you detect a likely misspelling, but allow them to continue, since it might be a genuine email address. +- It is great if you can check for common misspellings of popular email providers — but don’t autocorrect them! Warn people if you detect a likely misspelling, but allow them to continue, since it might be a genuine email address. - Don’t restrict top-level domains, unless you have a very specific audience, such as only people with .gov or .mil addresses. This slide shows an email address field with a section below asking if sensitive information should be sent via email. @@ -273,7 +271,7 @@ This slide shows an email address field with a section below asking if sensitive **Slide 61:** Some of the key guidance associated with helping users to enter phone numbers addresses this: -- Use “text” input type instead of “numeric”, since numeric inputs carry some usability and accessibility problems. But you can help folks out by using the inputmode="numeric" attribute in that text field to both restrict the field to numbers and to automatically enable the numeric keyboard on mobile devices. On this slide we see an image of a mobile device with a phone number field on it. The device shows the numeric keyboard activated… +- Use “text” input type instead of “numeric”, since numeric inputs carry some usability and accessibility problems. But you can help folks out by using the inputmode="numeric" attribute in that text field to both restrict the field to numbers and to automatically enable the numeric keyboard on mobile devices. On this slide we see an image of a mobile device with a phone number field on it. The device shows the numeric keyboard activated… - If you will be contacting the individual by phone, ask whether you can leave sensitive information in a voicemail or text message. Remember people may be sharing phones with others, and may not want to share personal information with them, too. - Another recommendation we made is that you consider using an input mask to shape the correct format, allowing the user to type in the numbers and see it represented in a familiar format. And to demo the input mask component, I’m going to turn it over to Jon. @@ -310,14 +308,14 @@ Many of the digital solutions we create rely on collecting personal information When what we ask for doesn’t allow users to confidently and accurately communicate their answers — or allow them to update this information as their circumstances change — we may have created a poor user experience and eroded trust from the start. We’ll discuss our approach to developing User Profile design patterns, look at some specific guidance, and talk about why it’s so important. -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2022/11/2022-11-08-uswds-monthly-call-november-2022.md b/content/events/2022/11/2022-11-08-uswds-monthly-call-november-2022.md index 0b11238862..bd2c9803f0 100644 --- a/content/events/2022/11/2022-11-08-uswds-monthly-call-november-2022.md +++ b/content/events/2022/11/2022-11-08-uswds-monthly-call-november-2022.md @@ -4,7 +4,6 @@ kicker: USWDS summary: Continuing our look at user profile patterns host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://www.eventbrite.com/e/uswds-monthly-call-user-profile-patterns-part-2-nov-2022-tickets-463996765817 captions: https://www.streamtext.net/player?event=BIS-GSA-JY date: 2022-11-17 14:00:00 -0500 @@ -44,7 +43,7 @@ For those of you who find the chat distracting, you’re welcome to close or hid So thanks! And, with that, let's get started! -**Slide 3:** So what's our agenda for today? +**Slide 3:** So what's our agenda for today? First we'll highlight a whole lotta product updates. And then we’ll spend the rest of our time here today talking about user profile patterns, specifically patterns addressing race and ethnicity, gender identity and sex, and pronouns! And if all goes well, we'll have some time left at the end of Q&A. So let's get right into it. @@ -55,10 +54,10 @@ And if all goes well, we'll have some time left at the end of Q&A. So let's get **Slide 6:** The first new component is [in-page navigation](https://designsystem.digital.gov/components/in-page-navigation/). In-page navigation allows users to specific sections on a long content page. On this slide we see the in-page navigation component page, and we've put the link to this component in the chat. -**Slide 7:** We also released a [language selector component](https://designsystem.digital.gov/components/language-selector/) in USWDS 3.3.0. As we heard a couple months back, the consistent placement, interface, and behavior of the language selection component allows users to easily find and access content in the language the user is most comfortable in. This component supports three new patterns: +**Slide 7:** We also released a [language selector component](https://designsystem.digital.gov/components/language-selector/) in USWDS 3.3.0. As we heard a couple months back, the consistent placement, interface, and behavior of the language selection component allows users to easily find and access content in the language the user is most comfortable in. This component supports three new patterns: -Select between two languages, -Select from three or more languages, and +Select between two languages, +Select from three or more languages, and Find selected content in other languages On this slide we see the in-page navigation component page, and we've put the link to this component in the chat. @@ -79,23 +78,23 @@ The report is available at [designsystem.digital.gov/together](https://designsys **Slide 14:** And here's another example, [the Address pattern](https://designsystem.digital.gov/patterns/create-a-user-profile/address/). The address pattern is meant to help a user enter their physical or mailing addresses for successful communications. And these are just two of the 17 new patterns that are available now. -**Slide 15:** I'm going to take a quick live look at all this new work on our website in a second, but I wanted to call out a couple new website features that I think have really made a big difference. The first is our new in-page navigation component. I found it really, really easy to add this component to our site, and to tune its properties and settings so I was getting just the output and interaction I was expecting. Our component uses JavaScript to generate the contents of the navigation, so you're not constantly having to keep the nav in sync with your content. It's about as simple as adding an aside with a special class to your template, and the component does the rest. +**Slide 15:** I'm going to take a quick live look at all this new work on our website in a second, but I wanted to call out a couple new website features that I think have really made a big difference. The first is our new in-page navigation component. I found it really, really easy to add this component to our site, and to tune its properties and settings so I was getting just the output and interaction I was expecting. Our component uses JavaScript to generate the contents of the navigation, so you're not constantly having to keep the nav in sync with your content. It's about as simple as adding an aside with a special class to your template, and the component does the rest. As we see on this slide, our in-page navigation appears on the right side of the page with a default heading that reads On this page. In my experience using our site with this in-page navigation, I've found it much easier to understand the content of pages and more quickly get to just what I want. **Slide 16:** The other thing I'm really excited about is another simple but effective content type: a changelog. We've started rolling out changelogs to our pattern and component pages, and we'll be adding them to template pages and other content pages in the future. These changelogs, which we're calling Latest Updates, appear at the bottom of a page, and show how something has changed over time. If you want to see how a component has changed since you implemented it. This page shows the changelog for our banner component. We'll call out when we've made any meaningful changes to the component — changes to markup, styling, JavaScript, or guidance. We'll call out when we think we've made a breaking change — if using the changed package would cause the old package to stop working — and if the change affects the accessibility of the component. Both our guidance and our code will evolve over time, and these latest updates keep these changes obvious and transparent. This is another new part of our website that our team has found immediately useful. We hope you find it useful as well. -**Slide 17:** So now I'd like to take a quick look at all these new things together on our website. +**Slide 17:** So now I'd like to take a quick look at all these new things together on our website. [DEMO] -So, what can you do? Well, this new pattern guidance is the beginning of a new open-source collaborative resource. As more agencies use this guidance and contribute to its evolution, it will grow as a resource, address a broader range of individuals, and support a more inclusive government digital experience. +So, what can you do? Well, this new pattern guidance is the beginning of a new open-source collaborative resource. As more agencies use this guidance and contribute to its evolution, it will grow as a resource, address a broader range of individuals, and support a more inclusive government digital experience. So check out the report and share it with colleagues and clients that might find it useful. Read through our pattern guidance, think about how it might apply to your work, and if you have feedback, resources, or research that could help us make our work better, let us know — in our public Slack (#uswds-public), as an email to our team, or an issue in our GitHub repo. **Slide 18:** We say it again and again at these events, but it always bears repeating, especially as we talk about new components and new guidance: USWDS is a toolkit of best practices and existing solutions, to help teams focus their time, energy, and resources on high-value unsolved problems — problems specific to your program, mission, and audience. We're a tool for designers, not a replacement for designers — and certainly not a replacement for knowing your audience. Our goal is not to make every site and service look like default USWDS, but to make it easier for any team to adopt human centered design practices — to help teams be more nimble, get up to speed faster, understand key context and constraints more easily, and focus on delivery from sprint to sprint. Folks may look at USWDS and see a set of blueprints for a product — it's not unreasonable! — to see the plans for shiny new fleet of airplanes. But from our perspective, we aren't the airplane, or even the plans, but the runway. We're here to help give teams the tools to accelerate, get off the ground, and point toward their own destinations. -**Slide 19:** While government digital teams are serious about improving the experience of their websites and services, no single team can do it all, talk with every individual, or test with every audience. As digital teams actively seek to understand and address usability, accessibility, diversity, and inclusion in their digital services, they shouldn't have to go it alone. Our new pattern guidance is the beginning of a new open-source collaborative resource that digital teams can use and build from instead of starting from scratch. As more agencies use this guidance and contribute to its evolution, it will grow as a resource, address a broader range of individuals, and support a more inclusive government digital experience. +**Slide 19:** While government digital teams are serious about improving the experience of their websites and services, no single team can do it all, talk with every individual, or test with every audience. As digital teams actively seek to understand and address usability, accessibility, diversity, and inclusion in their digital services, they shouldn't have to go it alone. Our new pattern guidance is the beginning of a new open-source collaborative resource that digital teams can use and build from instead of starting from scratch. As more agencies use this guidance and contribute to its evolution, it will grow as a resource, address a broader range of individuals, and support a more inclusive government digital experience. Working together, agencies can continue to improve the public's digital experience with the federal government. @@ -113,19 +112,19 @@ Hi, I'm Jona Decker, and I'm a Technologist on the Inclusive Patterns team. My p **Slide 23:** Finally, we’re pleased to have Austin Hernandez, a senior product designer within TTS’ 18F program. Austin, can you tell us a little about yourself? -Hi, I'm Austin Hernandez, and I'm a Senior Product Designer at 18F. I use he/him or they/them pronouns. I am a masculine presenting, Mexican-American person with brown skin and thick dark brown hair full of secrets. I have freckles, a septum piercing, and a million dollar smile. +Hi, I'm Austin Hernandez, and I'm a Senior Product Designer at 18F. I use he/him or they/them pronouns. I am a masculine presenting, Mexican-American person with brown skin and thick dark brown hair full of secrets. I have freckles, a septum piercing, and a million dollar smile. 18F is in the Technology Transformation Services offices within the General Services Administration and it lives alongside the design system. 18F is a technology and design consultancy for the U.S. Government, inside the government. And we partner with agencies to improve the user experience of government services by helping them build and buy technology. I've been working in the web design field for 15 years now and just had my 6th year anniversary at 18F. Happy to be here! **Slide 24:** We all know that a website is more than just components on a page — the whole reason all those components are there is to help someone do something. And what we're talking about again this month: patterns, or, essentially, interactions, are the human-centered link between components, and services. How do we help a user — how do we help an individual — to do something: review a complex form, enter their name, choose the language they prefer, or share important personal information like gender identity and sex. -**Slide 25:** Patterns and pattern guidance have the opportunity to give any designer a head start to understanding their specific audience and needs. And for USWDS, effective patterns have a responsibility to reduce barriers to participation through every interaction. +**Slide 25:** Patterns and pattern guidance have the opportunity to give any designer a head start to understanding their specific audience and needs. And for USWDS, effective patterns have a responsibility to reduce barriers to participation through every interaction. What does this mean when it comes to the important ways that we describe ourselves, such as race and ethnicity, sex and gender, and pronouns? What barriers might this information introduce? Before we look at the patterns themselves, I'd like to pass it to Austin to talk about why these are critical issues, why we need to get it right. **Slide 26:** I started looking into inclusive form design as a passion project about a year ago for a few reasons. 1. I design a lot of government forms for different agencies I work with at 18F. Some forms have to meet certain guidelines, the form data needs to be actionable and relevant for the people reviewing it, so I want relevant, uniform, clean data 2. I’m a designer. I’ve looked at a ton of form patterns over my 15 year career. Forms need to be designed well, not only visually, but they need to be plain language, explanatory, feel safe, not feel overwhelming, be relevant, etc.—for users to fill them out. And lastly, very personally, I was tired of my identity not being an option forcing me to choose inaccurate, arbitrary identifiers that are either plain wrong or downright offensive. And I’m not alone in this. When I started asking people in my community who work with intake forms in healthcare and nonprofits, they shared similar challenges and frustrations—Not only in how to identify themselves, but being confused when certain questions were asked or what is the “right” way to ask. -**Slide 27:** This slide shows 3 examples of exclusionary form design. I run into tons of forms like these either at work or filling them out. From left to right. There’s a title or honorific dropdown with 19 options. 3 are asking if you are a wed or unwed woman. A few are if I'm maybe some kind of European royalty? And only professional titles like Rabbi or Dr. are gender neutral. The next form asks for my gender as either male or female, which excludes people with unspecified or other gender identities. Last, there’s a race and ethnicity form with 7 options. 2 checkboxes ask you to clarify if you are US Black or Carribean Black and the only option for Hispanic is White (Hispanic or non-Hispanic), so only “other” applies to me. +**Slide 27:** This slide shows 3 examples of exclusionary form design. I run into tons of forms like these either at work or filling them out. From left to right. There’s a title or honorific dropdown with 19 options. 3 are asking if you are a wed or unwed woman. A few are if I'm maybe some kind of European royalty? And only professional titles like Rabbi or Dr. are gender neutral. The next form asks for my gender as either male or female, which excludes people with unspecified or other gender identities. Last, there’s a race and ethnicity form with 7 options. 2 checkboxes ask you to clarify if you are US Black or Carribean Black and the only option for Hispanic is White (Hispanic or non-Hispanic), so only “other” applies to me. For many people I’m sure these work just fine. Maybe you are a Viscount American Indian male, but for others it’s not how we are seen by the world or how we see ourselves which is a bad user experience and makes the data less useful. @@ -147,13 +146,13 @@ So if you identify as Middle Eastern, what would you select for race? The answer **Slide 34:** Another problem is that many people identify as multiple races. [In 2020, just over 10% of the American population reported multiple races](https://www.census.gov/library/stories/2021/08/improved-race-ethnicity-measures-reveal-united-states-population-much-more-multiracial.html). That’s almost 34 million people. When you factor in the “Some other race” option the number of folks who are multiracial or don’t feel their race is represented on Census forms is closer to 50 million people. -**Slide 35:** And when you layer ethnicity into the mix, it can be even more confusing. OMB currently offers two choices for categorizing ethnicity: Hispanic or Latino, or Not Hispanic or Latino. +**Slide 35:** And when you layer ethnicity into the mix, it can be even more confusing. OMB currently offers two choices for categorizing ethnicity: Hispanic or Latino, or Not Hispanic or Latino. Austin, you’ve written quite a bit about the challenges of collecting race and ethnicity information. Can you expand on this a bit? -**Slide 36:** For sure. Slide 36. So because of this form dilemma, I decided to do DNA genetic testing for ancestry. The results were pretty much what I expected. They are common results for people with brown skin that live in what is now known as the American Southwest and Central America. The chart on the screen shows that I’m 45% Spanish, 41% Native American, and the rest is from all over the huge, diverse continent of Africa. +**Slide 36:** For sure. Slide 36. So because of this form dilemma, I decided to do DNA genetic testing for ancestry. The results were pretty much what I expected. They are common results for people with brown skin that live in what is now known as the American Southwest and Central America. The chart on the screen shows that I’m 45% Spanish, 41% Native American, and the rest is from all over the huge, diverse continent of Africa. -**Slide 37:** However, forms rarely allow this answer for a few reasons. This slide has a screenshot of a form I tried to fill out within the last year. It uses a dropdown form pattern where I’m only allowed to choose 1 option from a dropdown for race AND ethnicity. I’m glad it has the gender inclusive Latinx option, but I have to choose between my racial identity or ethnic background. +**Slide 37:** However, forms rarely allow this answer for a few reasons. This slide has a screenshot of a form I tried to fill out within the last year. It uses a dropdown form pattern where I’m only allowed to choose 1 option from a dropdown for race AND ethnicity. I’m glad it has the gender inclusive Latinx option, but I have to choose between my racial identity or ethnic background. Latino and Hispanic can be any race or racial combination and that’s something people miss a lot. @@ -173,7 +172,7 @@ Jona? **Slide 44:** So what does that mean for our pattern guidance today? Leaning heavily on Census’ research, we recommend you. -Don’t separate race from ethnicity, but ask about them together. That doesn’t mean combining them into a single question, but treating them as a two-parter. +Don’t separate race from ethnicity, but ask about them together. That doesn’t mean combining them into a single question, but treating them as a two-parter. This is something we expect to see some exploration around as Census tests different ways of approaching this before the 2030 Decennial Census, so don’t be surprised if this guidance evolves. @@ -181,9 +180,9 @@ This is something we expect to see some exploration around as Census tests diffe **Slide 46:** And if possible, allow users to self-identify their ethnicity. -**Slide 47:** And, as always, explain why you are collecting the information and what it will be used for. +**Slide 47:** And, as always, explain why you are collecting the information and what it will be used for. -I want to call out that a number of agencies are working on this. There’s a lot of research, analysis and thinking that has been put into how to best ask for and capture this information, so while our guidance is based on our current understanding of these best practices, we fully expect these recommendations to change and evolve, especially as we get closer to the 2030 Decennial Census. +I want to call out that a number of agencies are working on this. There’s a lot of research, analysis and thinking that has been put into how to best ask for and capture this information, so while our guidance is based on our current understanding of these best practices, we fully expect these recommendations to change and evolve, especially as we get closer to the 2030 Decennial Census. And now I’m going to turn it over to Meghan. **Slide 48:** Next up, we want to talk about asking a user for gender identity and sex. This is not only challenging from an information collection perspective, but potentially alienating for the people completing the form. What if they don’t see themselves in the list provided? How might that omission undermine the information collection effort, lessen the effectiveness of the program or service, and cause harm to the people themselves? @@ -196,7 +195,7 @@ Austin, can you talk a bit about this? **Slide 51:** Terms change. For example, trans activists of the 70s used the word transexual to identify themselves, but that word has fallen out of favor and it’s more acceptable to use the word transgender. There didn’t used to be an option for intersex, but now there is. Advancements in medical research confirm there’s more nuance to biology than we understood previously. -**Slide 52:** Look, this is such a complicated topic being distilled into one form field. It’s a deeply personal identity we are just now as a society coming to understand. One person or one opinion from the LGBTQ+ community is not the unquestioned truth. USWDS isn’t the unquestioned truth. This is the best we have right now, and everything is iterative. It’s important to be empathetic and listen but use guidance from communities that are more widely accepted. Even in person, if you use the wrong term, it’s ok to say “oops sorry, thanks for letting me know!” +**Slide 52:** Look, this is such a complicated topic being distilled into one form field. It’s a deeply personal identity we are just now as a society coming to understand. One person or one opinion from the LGBTQ+ community is not the unquestioned truth. USWDS isn’t the unquestioned truth. This is the best we have right now, and everything is iterative. It’s important to be empathetic and listen but use guidance from communities that are more widely accepted. Even in person, if you use the wrong term, it’s ok to say “oops sorry, thanks for letting me know!” **Slide 53:** It’s important to people’s identity. The issue of gender is sometimes seen as a controversial and divisive issue because it’s becoming more mainstream. It doesn’t need to be. These identities have been here, this whole time, it just wasn’t being counted or there was no language for it. This is just one visible sign of social change and progress. At one point women couldn’t vote, schools were racially segregated, interracial marriages were illegal, same-sex relations were a crime —and some of things are still true across the world. But, several offices within the federal government, in academia, and in communities across the world are saying here are the ways people identify themselves, let’s count them! @@ -215,7 +214,7 @@ While the definition used for the “X” choice is a little muddy, blurring the **Slide 58:** [Social Security recently announced that they will allow individuals to self-select their sex on their Social Security number (SSN) record](https://www.ssa.gov/news/press/releases/2022/#10-2022-3). [CDC has developed guidelines for their programs](https://www.cdc.gov/nchs/nhis/sexual_orientation/background.htm)). And the [Federal Committee on Statistical Methodology, an interagency working group, has published some excellent research](https://www.fcsm.gov/groups/sogisc/). OMB is also looking at how best to ask about sexual orientation and gender identity. -So research is ongoing and there are a lot of smart folks trying to figure out how we can ask about sex and gender in a way that +So research is ongoing and there are a lot of smart folks trying to figure out how we can ask about sex and gender in a way that - Supports programs’ abilities to serve people - Captures information needed for identity validation and reporting requirements @@ -237,19 +236,19 @@ So what does this mean for the USWDS pattern guidance? **Slide 65:** So that's sex. What about gender identity? Gender identity is how the person wants to be represented. There are some environments, such as health care, where this is important information in addition to sex listed at birth. -**Slide 66:** There was much discussion about whether the correct term was “gender identity” or just “gender.” There really isn’t a consensus on this. But we were persuaded by some of the work done by OMB and CDC that “gender” is the construct, while “gender identity” is how someone wants to be represented. +**Slide 66:** There was much discussion about whether the correct term was “gender identity” or just “gender.” There really isn’t a consensus on this. But we were persuaded by some of the work done by OMB and CDC that “gender” is the construct, while “gender identity” is how someone wants to be represented. **Slide 67:** As Austin shared, there are a great many gender identities. So our recommendation is that you allow people to specify their gender identity in whatever way they choose. Don't make them select from a list that might not include them – or provide so many options that it becomes overwhelming. Let them self-identify. **Slide 68:** And let people indicate that they prefer not to answer. There are many reasons people may choose not to provide their gender identity, and we need to be respectful of that. -**Slide 69:** If you do need to ask for both gender identity and sex, consider asking for gender identity first, since this is the designation that determined an individual’s sense of self. And [consider phrasing the question in the same way the CDC does](https://www.cdc.gov/nchs/nhis/sexual_orientation/background.htm): I think of myself as…. This is also a place where “prefer not to answer” might be a viable option for sex — the CDC recommends this, and while we generally discourage it, it is an important option when you are asking for both sex and gender especially in a patient-provider relationship where trust is so important. +**Slide 69:** If you do need to ask for both gender identity and sex, consider asking for gender identity first, since this is the designation that determined an individual’s sense of self. And [consider phrasing the question in the same way the CDC does](https://www.cdc.gov/nchs/nhis/sexual_orientation/background.htm): I think of myself as…. This is also a place where “prefer not to answer” might be a viable option for sex — the CDC recommends this, and while we generally discourage it, it is an important option when you are asking for both sex and gender especially in a patient-provider relationship where trust is so important. **Slide 70:** Now let’s look at guidance around Pronouns. **Slide 71:** Pronouns are closely related to gender identity, but they aren’t exactly the same thing. -**Slide 72:** One thing we do know, though, is that a name, sex, or gender identity is not indicative of the pronouns a person uses. And when we use someone’s preferred pronouns we help create an environment where they feel seen, and are less likely to feel frustrated or alienated. And besides being the right thing to do, respecting someone’s pronouns is – again – an important component of building trust and ultimately program success. +**Slide 72:** One thing we do know, though, is that a name, sex, or gender identity is not indicative of the pronouns a person uses. And when we use someone’s preferred pronouns we help create an environment where they feel seen, and are less likely to feel frustrated or alienated. And besides being the right thing to do, respecting someone’s pronouns is – again – an important component of building trust and ultimately program success. As with the other patterns we learned a lot from our colleagues in the federal space on how they are approaching pronouns, and we also looked at best practices elsewhere. @@ -265,11 +264,11 @@ As with the other patterns we learned a lot from our colleagues in the federal s **Slide 78:** As we’ve discussed before, our work was based on the input from many digital teams across the federal space, in addition to research from thought leaders outside of the federal government. Each of the patterns was reviewed by key stakeholders and revisions were made as necessary. The patterns provide guidance around our current understanding of this space, and considerations for creating effective and inclusive user experiences. -**Slide 79:** But you know your audience best. On this slide we have an array of people with different skin colors, hair styles, and clothing. USWDS cannot know all the subtleties of your audience, and we recommend you test your design and content to ensure they work for you. +**Slide 79:** But you know your audience best. On this slide we have an array of people with different skin colors, hair styles, and clothing. USWDS cannot know all the subtleties of your audience, and we recommend you test your design and content to ensure they work for you. This is a fast moving space–so buckle up! There will be changes. Dan? -**Slide 80:** This is Dan. Thanks Meghan, and thanks Jona and Austin. This patterns project has been a large collaborative effort, and while we've published this work to our website, providing good up-to-date guidance is an ongoing initiative. While these patterns and components are designed based on extensive research, we expect them to evolve as the equity and inclusivity landscape, and general best-practices evolve and as we learn more from you. We invite you to share your input in #USWDS-public slack, GitHub issues, or by emailing the USWDS team. +**Slide 80:** This is Dan. Thanks Meghan, and thanks Jona and Austin. This patterns project has been a large collaborative effort, and while we've published this work to our website, providing good up-to-date guidance is an ongoing initiative. While these patterns and components are designed based on extensive research, we expect them to evolve as the equity and inclusivity landscape, and general best-practices evolve and as we learn more from you. We invite you to share your input in #USWDS-public slack, GitHub issues, or by emailing the USWDS team. So use this guidance to get up to speed on inclusive interactions, and, like the airplane departure emoji on this slide, take off and point your project into the future. Onward we go! @@ -285,15 +284,14 @@ Many of the digital solutions we create rely on collecting personal information, We'll continue looking at personal user profile patterns, including: date of birth, race and ethnicity, biological sex and gender, and pronouns. We'll also take a look at our guidance, and discuss how an inclusive approach to these patterns can reduce barriers to participation. - -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2022/11/2022-11-09-usagov-usability-test-reports.md b/content/events/2022/11/2022-11-09-usagov-usability-test-reports.md index e1f80b702c..f77c763f55 100644 --- a/content/events/2022/11/2022-11-09-usagov-usability-test-reports.md +++ b/content/events/2022/11/2022-11-09-usagov-usability-test-reports.md @@ -5,9 +5,6 @@ summary: Join us for an overview of usability test reports on the next version of USA.gov. host: User Experience Community of Practice and Multilingual Community of Practice event_organizer: Digital.gov -cop_events: - - user-experience - - multilingual registration_url: https://www.eventbrite.com/e/usagov-usability-test-reports-tickets-464623089167 captions: https://www.streamtext.net/player?event=BIS-GSA-JY date: 2022-11-15 14:00:00 -0500 @@ -24,7 +21,6 @@ slug: usagov-usability-test-reports # zoom, youtube_live, adobe_connect, google event_platform: zoom primary_image: usagov-ux-test-reports-title-card - --- {{< asset-static file="usagov-usability-test-reports.pptx" label="View the slides (PowerPoint presentation, 5.7 MB, 26 pages)" >}} @@ -35,14 +31,14 @@ In this session, you'll learn about the parameters of USA.gov’s usability test ## Speaker -* **Joanne McGovern**—General Services Administration (GSA) +- **Joanne McGovern**—General Services Administration (GSA) ## Moderator -* **Jean Fox**—Bureau of Labor Statistics (BLS) +- **Jean Fox**—Bureau of Labor Statistics (BLS) -- - - +--- -*The [UX Community of Practice](https://digital.gov/communities/user-experience/) is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies.* +_The [UX Community of Practice](https://digital.gov/communities/user-experience/) is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies._ -*The [Multilingual Community of Practice](https://digital.gov/communities/multilingual/) is a group of federal, state, and local government digital professionals working to expand and improve digital content in languages other than English.* +_The [Multilingual Community of Practice](https://digital.gov/communities/multilingual/) is a group of federal, state, and local government digital professionals working to expand and improve digital content in languages other than English._ diff --git a/content/events/2022/12/2022-12-01-uswds-monthly-call-december-2022.md b/content/events/2022/12/2022-12-01-uswds-monthly-call-december-2022.md index d8b11a18e8..3df4b79a53 100644 --- a/content/events/2022/12/2022-12-01-uswds-monthly-call-december-2022.md +++ b/content/events/2022/12/2022-12-01-uswds-monthly-call-december-2022.md @@ -5,7 +5,6 @@ kicker: USWDS summary: A look back at what took place in the Design System in 2022. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://www.eventbrite.com/e/uswds-monthly-call-2022-year-in-review-dec-2022-tickets-479345193377 captions: https://www.streamtext.net/player?event=BIS-GSA-JY date: 2022-12-15 14:00:00 -0500 @@ -43,8 +42,8 @@ For those of you who find the chat distracting, you’re welcome to close or hid So thanks! And, with that, let's get started! -**Slide 3:** So what's our agenda for today? -Well this month we're looking at our year in review for 2022. We'll start with a few of the big things you may have heard about, and then we'll move on to a few other items we're proud of and didn't want to fall through the cracks! +**Slide 3:** So what's our agenda for today? +Well this month we're looking at our year in review for 2022. We'll start with a few of the big things you may have heard about, and then we'll move on to a few other items we're proud of and didn't want to fall through the cracks! Like transparent workflows on our new Project Boards Telling the story of code through process documentation Adapting to user settings in Windows High Contrast Mode @@ -78,7 +77,7 @@ The report is available at [designsystem.digital.gov/together](https://designsys **Slide 15:** And if you've been to any of the monthly calls in the last four or five months, you'll know that last month, in November, we launched our inclusive design patterns projects. Our inclusive design patterns report landing page is here on this slide. -**Slide 16:** We wanted to learn from the experience of our peers and collect and develop guidance that helps any government team provide fair, equitable, respectful, and inclusive experiences for broad, diverse audiences. Our team talked to over 35 people from over 20 government agencies and programs as a part of a project to help expand our guidance to support not just components, but the interactions these components support. Things like complex forms, creating a user profile, and language selection. +**Slide 16:** We wanted to learn from the experience of our peers and collect and develop guidance that helps any government team provide fair, equitable, respectful, and inclusive experiences for broad, diverse audiences. Our team talked to over 35 people from over 20 government agencies and programs as a part of a project to help expand our guidance to support not just components, but the interactions these components support. Things like complex forms, creating a user profile, and language selection. We published a report that talks about what we did and what we found. We launched a new patterns section on our website with comprehensive guidance for 17 interactions. And we released three new components to support these interactions. To read more about this, the best place to start is at the report itself, at [designsystem.digital.gov/together](https://designsystem.digital.gov/together/). @@ -106,25 +105,25 @@ Thank you Jacline! You'll hear more from the team as we go on. But I'd like to s **Slide 24:** We have a new Github Project board that organizes and prioritizes our issues, pull requests, and more as data that we can display across a number of views. This slide shows a tab in our project data called Leaderboard, where we can see all the open issues across our repos, assign them a weight (or priority), and complexity, and a status. From the leaderboard, we can grab issues, and collect them into sprints of work. -**Slide 25:** This slide shows the Sprint Sequencing tab of our project board, where we assign issues to sprint and to team members. We use this every two weeks for sprint planning. If you ever want to know what we're working on right now, this is where to look. +**Slide 25:** This slide shows the Sprint Sequencing tab of our project board, where we assign issues to sprint and to team members. We use this every two weeks for sprint planning. If you ever want to know what we're working on right now, this is where to look. **Slide 26:** And work from our sprints is packaged and distributed as releases. This slide shows the Release Planning tab on our project board, where we collect issues and pull requests into coherent releases. This helps us be smart about our planning, and really helps speed up the process as we finalize releases and collect release notes. If you want to know more about what's coming up for the design system, this is the tab for you. -**Slide 27:** And finally, it is technically a different project board, but we also collect our high level goals in a public Roadmap board. This board helps us plan 3 to 8 months into the future. +**Slide 27:** And finally, it is technically a different project board, but we also collect our high level goals in a public Roadmap board. This board helps us plan 3 to 8 months into the future. **Slide 28:** Our new project board has been super effective in helping us work better and faster in 2022. And it's not just an internal resource for the team. It's important to us that we're always clear and open about what we're doing and why. Come and see what we're doing at github.com/orgs/uswds/projects/8. **Slide 29:** **The story of the code: Improving Issues, pull requests, and changelogs** -**Slide 30:** Hello again. This is Amy and I'm here today with James and Charlie to discuss the story of the code – the things we did this year to improve how we document our work. +**Slide 30:** Hello again. This is Amy and I'm here today with James and Charlie to discuss the story of the code – the things we did this year to improve how we document our work. -Specifically we will be talking about our strategy for writing up GitHub issues and pull requests – or PRs as we’ll call them later in this talk – as well as our approach for our newly added changelogs. +Specifically we will be talking about our strategy for writing up GitHub issues and pull requests – or PRs as we’ll call them later in this talk – as well as our approach for our newly added changelogs. Improving our process documentation has already had a big impact on how our team works – and we’ll explain how we hope it can also benefit you as community members, users, and contributors. **Slide 31:** Just like with the project board Dan just spoke about, one of the primary benefits of this effort is that it increases transparency. By focusing on thoughtful, thorough writeups, we are able to expose more of our thought process and standards to the public. -**Slide 32:** Second, we saw the opportunity to speed up our workflow. I’m sure anyone who has worked in a project management tool knows and understands this at a deep level. By sharing and receiving more information, we can assess, assign, prioritize, and review work faster, and better, than before. +**Slide 32:** Second, we saw the opportunity to speed up our workflow. I’m sure anyone who has worked in a project management tool knows and understands this at a deep level. By sharing and receiving more information, we can assess, assign, prioritize, and review work faster, and better, than before. **Slide 33:** And finally, we saw the opportunity to help out our future selves — and those that come after us — by adding to a comprehensive project history with every issue and pull request. This is a long-term project. Better process documentation lets us see the context and reasoning behind each change and will make it easier to build on existing work in the future. @@ -137,7 +136,7 @@ The second thread is: Remember that a human – probably a busy one – is going This is the high level. Now, let’s dig in. Charlie is going to walk you through some of the things we learned about creating quality issue writeups. Take it away, Charlie. -**Slide 35:** Thanks, Amy. Hi everyone, this is Charlie. Even if you’ve never seen or interacted with a GitHub issue, you are probably familiar with the concept. Issues are where we plan and track work on GitHub – they are similar to tickets, stories, bug reports, etc that you might find in other project management tools. It's a record of something that should be done, and why. +**Slide 35:** Thanks, Amy. Hi everyone, this is Charlie. Even if you’ve never seen or interacted with a GitHub issue, you are probably familiar with the concept. Issues are where we plan and track work on GitHub – they are similar to tickets, stories, bug reports, etc that you might find in other project management tools. It's a record of something that should be done, and why. Austin, you’ve written quite a bit about the challenges of collecting race and ethnicity information. Can you expand on this a bit? @@ -155,12 +154,13 @@ This year, based on user research, we introduced two updated issue templates: on 7. Lastly, Additional Context. A place to leave any other notes, ideas, or considerations related to the bug before wrapping up the report. **Slide 38:** A good issue needs to make the case for the work. A good writeup explains why this request matters. A good issue writeup should answer: -1. Who is affected? Who benefits? -2. Is there a workaround? -3. How much effort is required to work around it? + +1. Who is affected? Who benefits? +2. Is there a workaround? +3. How much effort is required to work around it? 4. What is the effect if nothing is done? -Each of these questions allows us to measure the weight of work and the benefit it will add. These new fields come together and help set the stage for quality, speedy problem resolution. +Each of these questions allows us to measure the weight of work and the benefit it will add. These new fields come together and help set the stage for quality, speedy problem resolution. Now I’ll pass it back to Amy to discuss the next step in our workflow: pull requests @@ -174,21 +174,21 @@ We recently updated our PR template in GitHub to help make it easier to write an **Slide 41:** Hey there, it’s James. Let’s take a look at what makes a good PR. -The first step is to include a summary. The summary provides a brief, 1-2 sentence overview of what you’re proposing. The summary should be easy to understand at a glance. In this example, you’ll see that we highlight the benefit first (*"Updated the aria-label in English versions of usa-banner."*) and then add a high-level explanation of what’s changed: +The first step is to include a summary. The summary provides a brief, 1-2 sentence overview of what you’re proposing. The summary should be easy to understand at a glance. In this example, you’ll see that we highlight the benefit first (_"Updated the aria-label in English versions of usa-banner."_) and then add a high-level explanation of what’s changed: -We updated the banner component's aria-label to read *"Official website of the United States government"* to minimize potential screen reader ambiguity between *"An official"* and *"Unofficial"*. +We updated the banner component's aria-label to read _"Official website of the United States government"_ to minimize potential screen reader ambiguity between _"An official"_ and _"Unofficial"_. This example also shows that the PR has been connected to its related issue. (Fixes #4419) By connecting the PR to the issue, we give the reviewer the opportunity to learn more about the problem from the source. This additional context can be crucial, so please don’t forget to include it. **Slide 42:** After that, we’ll move on to the problem statement. A successful problem statement conveys the desired state, the actual state, and the effects of remaining in the current state. In this example, the problem statement summarizes what’s happening and the risk of leaving it unchanged. -When read out on a screen reader, the statement *"An official website of the United States government"* can sound like *"UNofficial website of the United States government"*. This introduces the risk of conveying a meaning opposite of the intended meaning. +When read out on a screen reader, the statement _"An official website of the United States government"_ can sound like _"UNofficial website of the United States government"_. This introduces the risk of conveying a meaning opposite of the intended meaning. **Slide 43:** Next up is the solution statement. This is where you can outline the changes that the PR is proposing. It can be helpful to share what the solution is, why this approach was chosen, how you implemented the change, and possible limitations of this approach and alternatives you’ve considered. In this example, we say: -Updating the aria-label gives us the ability to reduce confusion for those using screen readers without creating inconsistency in the visual presentation. +Updating the aria-label gives us the ability to reduce confusion for those using screen readers without creating inconsistency in the visual presentation. -For more complicated pull requests, the solution statement could be a bulleted list of individual tasks with links to related commits. +For more complicated pull requests, the solution statement could be a bulleted list of individual tasks with links to related commits. With any approach, the goal is to make it easy for a reviewer to understand what you did. @@ -198,28 +198,28 @@ In this example, we see: This component was tested on VoiceOver on Safari, Chrome, Firefox, and Edge for Mac, and on Windows Narrator. -Please test on your available screen readers to confirm that the component is introduced as *"Official website of the United States Government"*. +Please test on your available screen readers to confirm that the component is introduced as _"Official website of the United States Government"_. -**Slide 45:** As we discuss reviews, it is important to highlight that how we write review comments is as important as how we write PR descriptions. Some key things to keep in mind when writing comments are to be kind, thoughtful, and don’t be afraid to make suggestions. -The PR review process can make or break a code base. Make sure you are giving reviewers everything they need to do their job well so that the code changes are the best they can be. +**Slide 45:** As we discuss reviews, it is important to highlight that how we write review comments is as important as how we write PR descriptions. Some key things to keep in mind when writing comments are to be kind, thoughtful, and don’t be afraid to make suggestions. +The PR review process can make or break a code base. Make sure you are giving reviewers everything they need to do their job well so that the code changes are the best they can be. Now that we have completed the pull request process, it is time to talk about changelogs. And for that, I’ll pass it back to Amy. -**Slide 46:** Hi, it’s Amy again. We are now at the final stop in our workflow: Changelogs. +**Slide 46:** Hi, it’s Amy again. We are now at the final stop in our workflow: Changelogs. Changelogs are a record of the notable changes made to a product. They are a new addition to USWDS – something we started adding to our site just last month. Now, every time a change is released in USWDS – or merged into our documentation site – we will make a new changelog entry. -**Slide 47:** If you look through enough repos or code bases, you’ll see that changelogs can take on a range of formats. For USWDS, our aim was simple: make a helpful history – for humans. +**Slide 47:** If you look through enough repos or code bases, you’ll see that changelogs can take on a range of formats. For USWDS, our aim was simple: make a helpful history – for humans. -**Slide 48:** Changelogs give us the ability to tell a story over time. GitHub is great for tracking changes, but if you’ve ever had to dig through a commit history, you’ll find quickly that it can be hard to tell what is meaningful. +**Slide 48:** Changelogs give us the ability to tell a story over time. GitHub is great for tracking changes, but if you’ve ever had to dig through a commit history, you’ll find quickly that it can be hard to tell what is meaningful. Changelogs allow us to highlight the things that affect you and give you the information you need to get the full story – all without leaving the site. No more hunting, digging, or knowledge of Github required! **Slide 49:** One of our top priorities was to make our changelogs easy to find, so we added them to the bottom of the pages on our documentation website. You can access them quickly by clicking the “Latest updates” link in the secondary navigation. Second, we tried to include only the items and data that would have meaning. -As you can see in this example, we first include the date that the change was merged into the system. We also identify and provide a link to the related USWDS version number. The aim here is to give a timeline and create a reference for what you might have missed since you last updated. +As you can see in this example, we first include the date that the change was merged into the system. We also identify and provide a link to the related USWDS version number. The aim here is to give a timeline and create a reference for what you might have missed since you last updated. -We’ve also tagged our changelog items with a set of labels that describe what type of content has been affected, as well as identify if the change is breaking. You’ll see that we highlighted the “Accessibility” and “Breaking” tags in yellow and red for extra attention. +We’ve also tagged our changelog items with a set of labels that describe what type of content has been affected, as well as identify if the change is breaking. You’ll see that we highlighted the “Accessibility” and “Breaking” tags in yellow and red for extra attention. Next, we provide a brief description of the change. You’ll notice a lot of similarities between this summary and the one found in our pull requests. That’s because when we write a good PR summary, we can reuse it in our changelogs. And finally, we provide a link to the related pull request so that you can easily get more information if needed. @@ -252,9 +252,9 @@ If this mode was making some of our components virtually unusable, we needed to The new forced-colors media query allows for responsive design, detecting if the user is using Windows High Contrast or another forced color mode. Within these media queries we can use a number of special forced-color keywords to tell the operating system how to style our component with the forced color palette. -**Slide 57:** So in the end we were able to fix the radio buttons, the date picker, and 11 more components that previously broke in forced colors mode. +**Slide 57:** So in the end we were able to fix the radio buttons, the date picker, and 11 more components that previously broke in forced colors mode. -On the left you can see the green and white radio button component with all the radio buttons visible. On the right, you can see the green and white date range picker with a visible icon and a visible selected range. +On the left you can see the green and white radio button component with all the radio buttons visible. On the right, you can see the green and white date range picker with a visible icon and a visible selected range. USWDS also now supports all of the new system color tokens for forced color modes, making it easier for other developers to use these styles to improve their websites when using custom theming. @@ -269,7 +269,7 @@ last 2 versions IE 11 not dead** -Speaking of not dead, we’re still including IE11 in our Autoprefixer settings *for now*. But this will probably change next year. And when it does, we'll update USWDS Compile as well. Using USWDS Compile pretty much means not having to think about USWDS stylesheet requirements. And that can be nice. +Speaking of not dead, we’re still including IE11 in our Autoprefixer settings _for now_. But this will probably change next year. And when it does, we'll update USWDS Compile as well. Using USWDS Compile pretty much means not having to think about USWDS stylesheet requirements. And that can be nice. **Slide 61:** Because these requirements matter. Autoprefixer settings make a difference. At the top we see an example of a banner without using autoprefixing. It has a blue rectangle instead of the usual down caret. The example on the bottom shows the proper display of the banner. This isn't just an aesthetic issue, it affects the usability of the banner. @@ -283,7 +283,7 @@ Speaking of not dead, we’re still including IE11 in our Autoprefixer settings **Slide 66:** [DEMO] -So now I'd like to do a brief demo of how to use USWDS compile to create a custom icon sprite. +So now I'd like to do a brief demo of how to use USWDS compile to create a custom icon sprite. On the screen we have the default sprite with all USWDS icons. You can compile a smaller sprite by only pulling in the icons you plan to use. @@ -293,7 +293,7 @@ In our gulpfile we’ll add two settings to customize the sprite so we only keep Now when we compile again, our sprite.svg will only have these five arrow icons. -Our sprite has been slimmed down from 71KB to 4KB. A lot of the previous icons have been removed. +Our sprite has been slimmed down from 71KB to 4KB. A lot of the previous icons have been removed. You can use this technique to add your own project icons on top of the defaults too. Just make sure to set the projectIconsOnly flag to false, instead of true. @@ -309,7 +309,7 @@ You can learn more about integrating compile in [Phase Two of the Getting Starte Component guidance Component compliance to section 508 -Learn about design tokens… and +Learn about design tokens… and Code and guidance changes We'll be reaching out to you, our audience, to help us get from this long list to a shorter list. @@ -332,14 +332,14 @@ Thank you, and see you next month - in 2023! What things — small and large — made 2022 a great year for the Design System? This month, we’ll hear members of the Core Team share their favorite Design System updates from 2022. Join us as we look back at the year — you never know what you might have missed! -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/01/2023-01-04-continuously-improve-your-website-by-using-customer-feedback-and-web-analytics-an-irs-case-study.md b/content/events/2023/01/2023-01-04-continuously-improve-your-website-by-using-customer-feedback-and-web-analytics-an-irs-case-study.md index 9a3737f2b3..452c325c72 100644 --- a/content/events/2023/01/2023-01-04-continuously-improve-your-website-by-using-customer-feedback-and-web-analytics-an-irs-case-study.md +++ b/content/events/2023/01/2023-01-04-continuously-improve-your-website-by-using-customer-feedback-and-web-analytics-an-irs-case-study.md @@ -5,7 +5,6 @@ kicker: Web Managers & Web Analytics summary: Get tips and lessons learned from the Internal Revenue Service on how they collect user feedback and use web analytics to improve applications. host: Web Managers Community of Practice and Web Analytics Community of Practice event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/webinar/register/WN__6nJIJvoQUu2T5R7E0BtQQ end_date: 2023-01-25 14:00:00 -0500 # See all topics at https://digital.gov/topics @@ -27,7 +26,6 @@ primary_image: 2023-jan-irs-event-title-card # YouTube ID youtube_id: 8zkHN3rxXHw youtube_title: "Continuously improve your website by using customer feedback and web analytics: An IRS case study" - --- {{< asset-static file="2023-jan-irs-free-file-presentation.pptx" label="View the slides (PowerPoint presentation, 4.1 MB, 31 pages)" >}} @@ -36,29 +34,29 @@ Join user experience gurus from the Internal Revenue Service as they share how t In this session, you’ll learn how to: -* Design a user feedback survey -* Continuously monitor, analyze, and use user feedback and web analytics to make better decisions -* Make the case for changes to managers and others who who may not have analytics expertise -* Turn actionable data into insights and make enhancements to your website and digital services -* Ensure your team has the key skills in place to do this type of work +- Design a user feedback survey +- Continuously monitor, analyze, and use user feedback and web analytics to make better decisions +- Make the case for changes to managers and others who who may not have analytics expertise +- Turn actionable data into insights and make enhancements to your website and digital services +- Ensure your team has the key skills in place to do this type of work **This event is best suited for:** All levels of experience, from beginners to experts ## Speakers -* **Samuel Chapman —** Digital User Experience Analyst, Internal Revenue Service -* **Kira Prin —** Product Development Specialist, Internal Revenue Service +- **Samuel Chapman —** Digital User Experience Analyst, Internal Revenue Service +- **Kira Prin —** Product Development Specialist, Internal Revenue Service ## Related Resources -* How to Redesign a 19-Year-old Legacy Application Using Agile and User Experience Methodologies +- How to Redesign a 19-Year-old Legacy Application Using Agile and User Experience Methodologies {{< asset-static file="redesign-old-legacy-application-ux-summit-22.pptx" label="View the slides (PowerPoint presentation, 7.4 MB, 39 pages)" >}} {{< youtube id="cl6sVFjzZG4" title="How to Redesign a 19-Year-old Legacy Application Using Agile and UX Methodologies" >}} -- - - +--- -*The Web Managers Community of Practice is a group of government employees who manage government websites and digital services. They work to create a trusted, seamless online experience for all. [Join the Web Managers Community](https://digital.gov/communities/web-content-managers/).* +_The Web Managers Community of Practice is a group of government employees who manage government websites and digital services. They work to create a trusted, seamless online experience for all. [Join the Web Managers Community](https://digital.gov/communities/web-content-managers/)._ -*The Web Analytics Community aims to uncover best practices, case studies, tips, and tools for web analytics and optimization. We are federal website analysts, developers, content strategists, user experience (UX) designers, communications professionals, or any and everyone else who use data to improve the public’s interaction with federal sites. [Join the Web Analytics and Optimization Community](https://digital.gov/communities/web-analytics-and-optimization/).* +_The Web Analytics Community aims to uncover best practices, case studies, tips, and tools for web analytics and optimization. We are federal website analysts, developers, content strategists, user experience (UX) designers, communications professionals, or any and everyone else who use data to improve the public’s interaction with federal sites. [Join the Web Analytics and Optimization Community](https://digital.gov/communities/web-analytics-and-optimization/)._ diff --git a/content/events/2023/01/2023-01-05-uswds-monthly-call-january-2023.md b/content/events/2023/01/2023-01-05-uswds-monthly-call-january-2023.md index 0fc3237d64..61a4b786f3 100644 --- a/content/events/2023/01/2023-01-05-uswds-monthly-call-january-2023.md +++ b/content/events/2023/01/2023-01-05-uswds-monthly-call-january-2023.md @@ -5,7 +5,6 @@ kicker: USWDS summary: Join the Design System team as we tackle your most commonly-asked questions. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItceqrrDsuEhxA7eoRggB3Cf4RRjcrMjU captions: https://www.streamtext.net/player?event=BIS-GSA-JY date: 2023-01-19 14:00:00 -0500 @@ -68,7 +67,7 @@ Thanks Amy. I'm glad to have both you and James here with me today! **Slide 7:** **First, do we test components with real users before releasing?** -**Slide 8:** So, the answer here is yes and no. There are a few things that we always do when it comes to testing our components. There are a few things that we've started to do more recently, and there are some plans that we have for the near future. When it comes to getting the most comprehensive view of our component usability, we can always do better. +**Slide 8:** So, the answer here is yes and no. There are a few things that we always do when it comes to testing our components. There are a few things that we've started to do more recently, and there are some plans that we have for the near future. When it comes to getting the most comprehensive view of our component usability, we can always do better. **Slide 9:** We always do a thorough internal review that includes manual accessibility testing across browsers and screen readers. Any component we release has been through a landscape analysis, live prototyping, and is most often drawn from existing government and non-government solutions. We favor proven solutions from government services. @@ -78,7 +77,7 @@ Thanks Amy. I'm glad to have both you and James here with me today! **Slide 12:** And what we've learned from starting this level of testing is that it's extremely valuable, and it's not replaceable. This level of testing allows our team to be more proactive, and especially when it comes to assistive technology, it helps us to better understand the expectations and conventions of real-world users — and how those expectations and conventions differ from manual accessibility testing and conformance with accessibility standards. It's helped us understand that while conformance with standards is critically important and a key heuristic when it comes to usability, it doesn't typically tell the whole story. -**Slide 13:** Since the beginning of the design system, we've relied on a reactive strategy for continuous improvement of our code, guidance, and components. And the way that it works is that we provide a baseline of testing for what we release, and we always respond to issues in our code repo — which is another way of saying that we rely on downstream usability testing from teams that use the design system to help us fill in the blanks and understand how our components are performing in the real world. This is also critically important. We don't typically have insight into how teams are using the design system. We're not building the applications. We're not directly exposed to your audiences. And occasionally, we miss things that subsequent testing reveals. As an example, we heard from an issue in our repo that some screen reader users were misinterpreting the vocalization of our banner text, hearing "An official website" as "Unofficial website". This was something our own testing hadn't revealed, and we were able to update the vocalized text in the banner to remove the ambiguity. +**Slide 13:** Since the beginning of the design system, we've relied on a reactive strategy for continuous improvement of our code, guidance, and components. And the way that it works is that we provide a baseline of testing for what we release, and we always respond to issues in our code repo — which is another way of saying that we rely on downstream usability testing from teams that use the design system to help us fill in the blanks and understand how our components are performing in the real world. This is also critically important. We don't typically have insight into how teams are using the design system. We're not building the applications. We're not directly exposed to your audiences. And occasionally, we miss things that subsequent testing reveals. As an example, we heard from an issue in our repo that some screen reader users were misinterpreting the vocalization of our banner text, hearing "An official website" as "Unofficial website". This was something our own testing hadn't revealed, and we were able to update the vocalized text in the banner to remove the ambiguity. **Slide 14:** We depend on our users and the community to be reactive, and that feedback is always going to be important. Knowing what you've found from your own tests and experiments will continue to drive the design system forward. But we need to be more proactive as well. Testing with real users on the design system side needs to be an ongoing part of a component’s lifecycle. Not only before release, but after release as well. A component's lifecycle doesn't end at release, so we're working to better operationalize real-world testing before and after release. @@ -102,13 +101,13 @@ Thanks Amy. I'm glad to have both you and James here with me today! **Slide 24:** So when it comes to Tabs, the proposal uncovered the places where our process needed work. We've been able to elevate those process improvements into upcoming roadmap items, so we're ready to start moving forward with deliberation. We appreciate your patience here, as do what we need to do to be fair, practical, and repeatable. -**Slide 25:** **Next up: When will the design kit be updated?** +**Slide 25:** **Next up: When will the design kit be updated?** **Slide 26:** Basically, we update the design kit (otherwise known as our Sketch and Adobe XD assets) after every USWDS release that has a design change, like a visual change to a component or a change to a color. Because of the realities of our production cycle, it often follows about a month behind the USWDS release. So, because we didn't make any visual updates to the design system with USWDS 3.0, we didn't publish a new version of the design kit. We did however, add some new components in the last USWDS release, USWDS 3.3.0, and we're in the process of finalizing the design kit for that release now. The holidays slowed down our progress, but the newest components should be available by the end of the month. Now this isn't the only time we update the design kit — at a minimum we'll update it when there's a design change in the USWDS codebase, but there may be more releases if we find a bug or an inconsistency in the design kit as well. In general, though, the design kit has far fewer releases than the USWDS code. -**Slide 27:** Relatedly, while we've supported Sketch and Adobe XD in our design kit for the last few years, we know that those aren't the only tools that design teams use. This year, we're adding Figma support to our short term roadmap. There are community implementations that we've linked to from our documentation site and our repo,that you can use in the interim, but we now have USWDS in Figma planned. +**Slide 27:** Relatedly, while we've supported Sketch and Adobe XD in our design kit for the last few years, we know that those aren't the only tools that design teams use. This year, we're adding Figma support to our short term roadmap. There are community implementations that we've linked to from our documentation site and our repo,that you can use in the interim, but we now have USWDS in Figma planned. **Slide 28:** So look for a component release to the existing design assets later this month, and a Figma design kit coming later this spring. You can find the USWDS design kit at [github.com/uswds/uswds-for-designers](http://github.com/uswds/uswds-for-designers). @@ -130,8 +129,8 @@ Now this isn't the only time we update the design kit — at a minimum we'll upd **Slide 37:** Well, we've got a setting for that. And to talk more about these settings and tokens, I'd like to pass it over to Amy. -**Slide 38:** Thanks, Dan. And hello again, this is Amy speaking. We recommend using standard USWDS tokens whenever possible, but we understand that sometimes customizations *need* to be made to fit project needs. The Design System is built with these needs in mind and can accommodate both custom colors and fonts. -The solutions and considerations are a bit different for each type of customization – so to start – we’ll talk about colors. +**Slide 38:** Thanks, Dan. And hello again, this is Amy speaking. We recommend using standard USWDS tokens whenever possible, but we understand that sometimes customizations _need_ to be made to fit project needs. The Design System is built with these needs in mind and can accommodate both custom colors and fonts. +The solutions and considerations are a bit different for each type of customization – so to start – we’ll talk about colors. **Slide 39:** **USWDS color tokens** @@ -141,7 +140,7 @@ We call these colors – like red-50 and blue-cool-50-V – [system tokens](http These system tokens are not editable — the value of a system color like red-50 will be the same in any USWDS installation. -**Slide 40:** Theming USWDS means editing the values of a *different* set of color tokens: [theme tokens](https://designsystem.digital.gov/design-tokens/color/theme-tokens/). +**Slide 40:** Theming USWDS means editing the values of a _different_ set of color tokens: [theme tokens](https://designsystem.digital.gov/design-tokens/color/theme-tokens/). Theme tokens are the colors we actually use in our component stylesheets. They're type-based, where BASE is used primarily for text, PRIMARY is for your project primary colors, SECONDARY is the secondary color, and so on. @@ -161,7 +160,7 @@ Now, whenever you want to use this custom hex color, you simply reference the In contrast, if you were to add your hex value directly into a custom Sass rule, none of these checks will happen. This means that accessibility checks would be your responsibility entirely. For this reason, we recommend always adding colors via your settings configuration. -And that’s it for adding a custom color. Let’s move on to fonts. +And that’s it for adding a custom color. Let’s move on to fonts. **Slide 43:** Out of the box, USWDS provides and supports 10 different [font families](https://designsystem.digital.gov/design-tokens/typesetting/font-family/). We provide these as a recommended set, but the system also has the capacity to accept new fonts. @@ -171,7 +170,7 @@ Today I’ll give a high-level overview to show what is possible, but we’ll al **Slide 44:** First up: If you want to add a font that is hosted from a service, you’ll need to complete the following steps. -First, you’ll add a reference to the JavaScript and CSS according to the instructions given by the font hosting service. This is typically done in the head of your HTML files. +First, you’ll add a reference to the JavaScript and CSS according to the instructions given by the font hosting service. This is typically done in the head of your HTML files. Second, you’ll create a new font token in your settings configuration, and then use the new token in your theme. We’ll walk you through these last two steps on the next slide. @@ -179,13 +178,13 @@ Second, you’ll create a new font token in your settings configuration, and the This example shows that you’ll need to ONE reference the display name and TWO declare which fonts you want in your font stack. In this setting, there is also an opportunity to adjust your font’s cap height, but that is fine to leave for now – we’ll get into that more in just a bit. -Once you have your new token, you’ll need to assign its value to its related theme setting. In the example, you’ll see that we have assigned Lato to theme-font-type-sans. This means that wherever the system is told to use the “sans” font type, it will use your new Lato token. +Once you have your new token, you’ll need to assign its value to its related theme setting. In the example, you’ll see that we have assigned Lato to theme-font-type-sans. This means that wherever the system is told to use the “sans” font type, it will use your new Lato token. -**Slide 46:** Alternatively, if you want to host additional fonts in your own project, there are a few more steps to do in addition to creating your own token. +**Slide 46:** Alternatively, if you want to host additional fonts in your own project, there are a few more steps to do in addition to creating your own token. You also need to assign this new token to its font type, and then add custom path information for this font type before using the new font type token in your stylesheet. -**Slide 47:** Configuring the theme-font-custom-source settings variable provides the custom path information that lets the system create new font-face rules in your CSS. +**Slide 47:** Configuring the theme-font-custom-source settings variable provides the custom path information that lets the system create new font-face rules in your CSS. In this setting, you will first tell the system where to find the fonts in your project. Second, you’ll specify which weights you want the system to use and third you’ll identify the file name for each font weight. It will look something like this example. @@ -193,9 +192,9 @@ Note that there are several theme-font-custom-source settings variables — one If you self-host your own custom font, you'll need to provide the woff, woff2, and ttf versions of the font for the @font-face rules to build correctly. -Once these font-face rules are created, you can repeat the steps we did in earlier slides to create a new font token and associate the token with your theme. +Once these font-face rules are created, you can repeat the steps we did in earlier slides to create a new font token and associate the token with your theme. -And those are the steps for adding a custom font to USWDS! For reference, you can find full instructions on our site. We’ll also throw the [link](https://designsystem.digital.gov/design-tokens/typesetting/font-family/#adding-fonts-to-uswds) in the chat to make it easier. +And those are the steps for adding a custom font to USWDS! For reference, you can find full instructions on our site. We’ll also throw the [link](https://designsystem.digital.gov/design-tokens/typesetting/font-family/#adding-fonts-to-uswds) in the chat to make it easier. **Slide 48:** Before we wrap up the section, I want to note that there are some considerations that should be made when adding fonts to your project. @@ -209,11 +208,11 @@ To normalize your new font, you’ll simply need to adjust the cap-height when y **Slide 49:** **Our next question is "How do I stop the banner from flashing unstyled content?"** -**Slide 50:** If you use the banner, header, or modal component on your site, there is a chance you noticed that the component will momentarily *flash* open for a few milliseconds before closing again as expected. If you experience this on your site, there is an easy fix. You simply need to use uswds-init.js. +**Slide 50:** If you use the banner, header, or modal component on your site, there is a chance you noticed that the component will momentarily _flash_ open for a few milliseconds before closing again as expected. If you experience this on your site, there is an easy fix. You simply need to use uswds-init.js. USWDS-init is a JavaScript file that checks to see that all page content is loaded before allowing the open content to be visible. This prevents the component from flashing open on the screen. -**Slide 51:** Adding it to your project is easy. Just copy the uswds-init.js file into your site’s asset directory from either the *dist* directory in our downloadable zip file or from the uswds-core package in npm. We’ll also post a [link](https://github.com/uswds/uswds/blob/develop/packages/uswds-core/src/js/uswds-init.js) to the file in GitHub in the chat. +**Slide 51:** Adding it to your project is easy. Just copy the uswds-init.js file into your site’s asset directory from either the _dist_ directory in our downloadable zip file or from the uswds-core package in npm. We’ll also post a [link](https://github.com/uswds/uswds/blob/develop/packages/uswds-core/src/js/uswds-init.js) to the file in GitHub in the chat. Once you have added the file to your site, the only thing left to do is reference the USWDS-init in the head of your HTML files. @@ -226,14 +225,15 @@ More information about uswds-init can be found in the [link](https://designsyste If you're interested in community-supported solutions for any individual framework or project, check out our USWDS [Implementations page](https://designsystem.digital.gov/documentation/implementations/) before getting started. **Slide 54:** There aren’t many technical requirements to using USWDS. The recommended requirements to using the design system are: + - **NodeJS (LTS version 16)**: to download the code and stay up-to-date with the design system. -- **SASS (with load paths)**: to be able to customize and compile your SASS to CSS successfully. -We offer a tool called [USWDS/Compile](https://www.npmjs.com/package/@uswds/compile), available on NPM, that can compile USWDS code with minimal configuration and help you stay up-to-date with the design system. +- **SASS (with load paths)**: to be able to customize and compile your SASS to CSS successfully. + We offer a tool called [USWDS/Compile](https://www.npmjs.com/package/@uswds/compile), available on NPM, that can compile USWDS code with minimal configuration and help you stay up-to-date with the design system. - **Autoprefixer**: for CSS compatibility across all browsers. An optional requirement is a javascript bundler if you’re looking to import individual component JS. Keep in mind that USWDS currently uses CommonJS syntax. We have a migration to ES Modules in the works, but ESM support in the NodeJS environment is a little quirky and our work is still in the early stages. -**Slide 55:** **Known issues with frameworks.** We’re doing our best to make sure USWDS works everywhere, but there are always things to improve. For example, some frameworks might require special configuration to get USWDS setup properly. +**Slide 55:** **Known issues with frameworks.** We’re doing our best to make sure USWDS works everywhere, but there are always things to improve. For example, some frameworks might require special configuration to get USWDS setup properly. There are also some interactive components that don't always initialize or behave as expected. Especially in dynamic frameworks. @@ -243,7 +243,7 @@ We’re actively looking for ways to improve this experience and the documentati **Slide 57:** I mentioned earlier that USWDS javascript uses the commonJS require syntax for importing scripts. Please keep in mind that you’ll need a bundler in your project. There are two ways to import USWDS javascript. -**Slide 58:** One way is to use the default **import**, which includes all component code, and then destructure, so import USWDS and then extract accordion to later initialize: +**Slide 58:** One way is to use the default **import**, which includes all component code, and then destructure, so import USWDS and then extract accordion to later initialize: import USWDS from “@uswds/uswds/js”; const { accordion } = USWDS; @@ -266,30 +266,30 @@ Join the Design System team as we tackle your most commonly-asked questions. In this session, we’ll answer questions like: -* Can and should I theme USWDS? -* What's the component testing process? -* How do I set custom fonts? -* How do I use USWDS with my technology stack? -* How do I update my project setup after moving to USWDS 3? -* When should I expect updates to the USWDS design kit? -* When will new components be released? +- Can and should I theme USWDS? +- What's the component testing process? +- How do I set custom fonts? +- How do I use USWDS with my technology stack? +- How do I update my project setup after moving to USWDS 3? +- When should I expect updates to the USWDS design kit? +- When will new components be released? **This event is best suited for:** Designers and developers who use the U.S. Web Design System plus those who are planning to use it. ## Speakers -* **Dan Williams -** Product Lead, USWDS -* **James Mejia -** Engineer, USWDS Contractor -* **Amy Leadem -** Front-End Developer, USWDS Contractor +- **Dan Williams -** Product Lead, USWDS +- **James Mejia -** Engineer, USWDS Contractor +- **Amy Leadem -** Front-End Developer, USWDS Contractor -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/01/2023-01-18-increasing-public-participation-in-user-research.md b/content/events/2023/01/2023-01-18-increasing-public-participation-in-user-research.md index 327e24babe..03d00e2f19 100644 --- a/content/events/2023/01/2023-01-18-increasing-public-participation-in-user-research.md +++ b/content/events/2023/01/2023-01-18-increasing-public-participation-in-user-research.md @@ -5,7 +5,6 @@ summary: Join GSA’s 10x team as they share their report on creative incentives and tools for increased public participation in user research. host: User Experience Community of Practice and Web Managers Community of Practice event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/webinar/register/WN__TonoRZPTaixg8Wo98rijA end_date: 2023-02-07 14:00:00 -0500 # See all topics at https://digital.gov/topics @@ -25,15 +24,15 @@ youtube_title: "Increasing public participation in user research" {{< asset-static file="2023-10x-event-slides.pptx" label="View the slides (PowerPoint presentation, 7.5 MB, 37 pages)" >}} -Join GSA's 10x team as they discuss using creative incentives to increase public participation in user research.  +Join GSA's 10x team as they discuss using creative incentives to increase public participation in user research. In this session, we'll cover: -* Common barriers to conducting research with the public -* What 10x discovered about creative incentives, including paid compensation -* How incentives support agencies' diversity, equity, and inclusion goals -* Possible risks of public participation in user research -* Successful approaches to compensation by teams at GSA/TTS +- Common barriers to conducting research with the public +- What 10x discovered about creative incentives, including paid compensation +- How incentives support agencies' diversity, equity, and inclusion goals +- Possible risks of public participation in user research +- Successful approaches to compensation by teams at GSA/TTS The 10x team will also discuss what they have planned for the next phase and answer your questions. @@ -41,21 +40,21 @@ The 10x team will also discuss what they have planned for the next phase and ans ## Speakers -* **Matt Dobson -** Product Manager, 10x -* **Robert Jolly -** Product Manager, 10x +- **Matt Dobson -** Product Manager, 10x +- **Robert Jolly -** Product Manager, 10x ## Moderator -* **Beth Martin -** Digital Services Expert (UX Designer), Office of Personnel Management (OPM) +- **Beth Martin -** Digital Services Expert (UX Designer), Office of Personnel Management (OPM) ## You may also be interested in: -* [Doing research at TTS: Compensating user research participants](https://handbook.tts.gsa.gov/18f/how-18f-works/research-guidelines/)  -* [18F Methods: Compensation, a - foundational method for practicing design research](https://methods.18f.gov/fundamentals/compensation/) -* [Paying incentives for federal user research](https://digital.gov/2016/02/10/paying-incentives-for-federal-user-research/) +- [Doing research at TTS: Compensating user research participants](https://handbook.tts.gsa.gov/18f/how-18f-works/research-guidelines/) +- [18F Methods: Compensation, a - foundational method for practicing design research](https://methods.18f.gov/fundamentals/compensation/) +- [Paying incentives for federal user research](https://digital.gov/2016/02/10/paying-incentives-for-federal-user-research/) -- - - +--- -*The UX Community of Practice is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies. [Join the UX Community](https://digital.gov/communities/user-experience/).* +_The UX Community of Practice is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies. [Join the UX Community](https://digital.gov/communities/user-experience/)._ -*The Web Managers Community of Practice is a group of government employees who manage government websites and digital services. They work to create a trusted, seamless online experience for all. [Join the Web Managers Community](https://digital.gov/communities/web-content-managers/).* +_The Web Managers Community of Practice is a group of government employees who manage government websites and digital services. They work to create a trusted, seamless online experience for all. [Join the Web Managers Community](https://digital.gov/communities/web-content-managers/)._ diff --git a/content/events/2023/01/2023-01-30-uswds-monthly-call-february-2023.md b/content/events/2023/01/2023-01-30-uswds-monthly-call-february-2023.md index 7c6168a2a0..8e02dc1494 100644 --- a/content/events/2023/01/2023-01-30-uswds-monthly-call-february-2023.md +++ b/content/events/2023/01/2023-01-30-uswds-monthly-call-february-2023.md @@ -7,7 +7,6 @@ summary: "Join us as we take a deep dive into USWDS design tokens. We’ll cover needs." host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItdOitrTIjG0pADR0k0Ij_xeiSBknpJyE captions: https://www.streamtext.net/player?event=BIS-GSA-JY date: 2023-02-16 14:00:00 -0500 @@ -22,40 +21,39 @@ event_platform: zoom primary_image: 2023-uswds-monthly-call-feb-title-card # YouTube ID youtube_id: ObqPeagLZ5o -youtube_title: "Using USWDS design tokens (2023)" +youtube_title: "Using USWDS design tokens (2023)" --- {{< asset-static file="uswds-monthly-call-february-2023.pptx" label="View the slides (PowerPoint presentation, 1.4 MB, 67 pages)" >}} Join us as we take a deep dive into USWDS design tokens. What are they? How are they used? How can they be adapted to agencies’ branding needs? -In this session, you’ll learn how to: - -* Get started with tokens -* Set your own custom values -* Make accessible choices +In this session, you’ll learn how to: +- Get started with tokens +- Set your own custom values +- Make accessible choices **This event is best suited for:** Designers of all levels and skill sets plus front-end developers. ## Speakers -* **Dan Williams -** Product Lead, USWDS -* **James Mejia -** Engineer, USWDS Contractor -* **Amy Leadem -** Front-End Developer, USWDS Contractor +- **Dan Williams -** Product Lead, USWDS +- **James Mejia -** Engineer, USWDS Contractor +- **Amy Leadem -** Front-End Developer, USWDS Contractor ## Related Resources -* [https://designsystem.digital.gov/design-tokens/](https://designsystem.digital.gov/design-tokens/) +- [https://designsystem.digital.gov/design-tokens/](https://designsystem.digital.gov/design-tokens/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/02/2023-02-16-working-with-the-public-to-improve-digital-forms-a-gsa-case-study.md b/content/events/2023/02/2023-02-16-working-with-the-public-to-improve-digital-forms-a-gsa-case-study.md index 74bb74dab5..a1064b93c3 100644 --- a/content/events/2023/02/2023-02-16-working-with-the-public-to-improve-digital-forms-a-gsa-case-study.md +++ b/content/events/2023/02/2023-02-16-working-with-the-public-to-improve-digital-forms-a-gsa-case-study.md @@ -4,7 +4,6 @@ summary: GSA’s Office of Evaluation Sciences shares how five offices worked wi the public to improve digital forms. host: Web Analytics Community of Practice and Web Managers Community of Practice event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/webinar/register/WN_D6O0LEvrR3qPRJ0k_cDgbA end_date: 2023-03-02 14:00:00 -0500 # See all topics at https://digital.gov/topics @@ -16,38 +15,37 @@ date: 2023-03-02 13:00:00 -0500 # zoom, youtube_live, adobe_connect, google event_platform: zoom primary_image: 2023-march-oes-event-title-card - --- {{< asset-static file="2023-march-oes-event.pptx" label="View the slides (PowerPoint presentation, 8.8 MB, 38 pages)" >}} -The Foundations for Evidence-Based Policymaking Act of 2018 (Evidence Act) requires federal agencies to undertake a number of activities to build and use evidence.  +The Foundations for Evidence-Based Policymaking Act of 2018 (Evidence Act) requires federal agencies to undertake a number of activities to build and use evidence. Join GSA’s Office of Evaluation Sciences (OES) as they present their digital forms evaluation project and share how five GSA offices and the public worked together to improve federal forms. **In this session, we’ll discuss:** -* How to build and use evidence in the federal government -* How to evaluate the impact of form changes -* Key takeaways and next steps in form evaluation +- How to build and use evidence in the federal government +- How to evaluate the impact of form changes +- Key takeaways and next steps in form evaluation **We’ll also share two case studies:** -* Proof-of-concept evaluation with a model form -* Evaluation of a form change in the field +- Proof-of-concept evaluation with a model form +- Evaluation of a form change in the field This event is best suited for web managers, forms managers, and evaluators of all levels of experience — from beginners to experts. ## Speakers -* **Mary Clair Turner** - Behavioral Scientist, Office of Evaluation Sciences, GSA -* **Stephanie Permut** - Associate Fellow, Office of Evaluation Sciences, GSA -* **Blair Read** - Associate Fellow, Office of Evaluation Sciences, GSA +- **Mary Clair Turner** - Behavioral Scientist, Office of Evaluation Sciences, GSA +- **Stephanie Permut** - Associate Fellow, Office of Evaluation Sciences, GSA +- **Blair Read** - Associate Fellow, Office of Evaluation Sciences, GSA You may also be interested in learning more about the [digital forms project](https://oes.gsa.gov/projects/digital-forms/) and [Evidence Act](https://oes.gsa.gov/toolkits/). -- - - +--- -*The Web Analytics Community aims to uncover best practices, case studies, tips, and tools for web analytics and optimization. We are federal website analysts, developers, content strategists, user experience (UX) designers, communications professionals, or any and everyone else who use data to improve the public’s interaction with federal sites. [Join the Web Analytics and Optimization Community](https://digital.gov/communities/web-analytics-and-optimization/).* +_The Web Analytics Community aims to uncover best practices, case studies, tips, and tools for web analytics and optimization. We are federal website analysts, developers, content strategists, user experience (UX) designers, communications professionals, or any and everyone else who use data to improve the public’s interaction with federal sites. [Join the Web Analytics and Optimization Community](https://digital.gov/communities/web-analytics-and-optimization/)._ -*The Web Managers Community of Practice is a group of government employees who manage government websites and digital services. They work to create a trusted, seamless online experience for all. [Join the Web Managers Community](https://digital.gov/communities/web-content-managers/).* +_The Web Managers Community of Practice is a group of government employees who manage government websites and digital services. They work to create a trusted, seamless online experience for all. [Join the Web Managers Community](https://digital.gov/communities/web-content-managers/)._ diff --git a/content/events/2023/02/2023-02-28-the-plain-language-tie-to-translating-digital-content.md b/content/events/2023/02/2023-02-28-the-plain-language-tie-to-translating-digital-content.md index 49499d0a51..96a359d9b0 100644 --- a/content/events/2023/02/2023-02-28-the-plain-language-tie-to-translating-digital-content.md +++ b/content/events/2023/02/2023-02-28-the-plain-language-tie-to-translating-digital-content.md @@ -5,7 +5,6 @@ kicker: PLAIN LANGUAGE AND MULTILINGUAL summary: "Join us to discuss the plain language and cultural components of effectively translating digital content into multiple languages." host: Plain Language Community of Practice and Multilingual Community of Practice event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/webinar/register/WN_xy4JG7MsQIecNXA-arLz9w date: 2023-03-08 14:00:00 -0500 end_date: 2023-03-08 15:00:00 -0500 @@ -25,7 +24,6 @@ primary_image: "2023-the-plain-language-tie-title-card" # YouTube ID youtube_id: ZpHzs9jGnnw youtube_title: "The plain language tie to translating digital content" - --- {{< asset-static file="2023-march-tie-to-plain-event.pptx" label="View the slides (PowerPoint presentation, 3.6 MB, 10 pages)" >}} @@ -40,28 +38,28 @@ This event is best suited for all levels of [plain language](https://digital.gov In this session, you’ll learn about: -* The Department of Justice’s call to action and the connection between language access and equity. -* The connection between plain language and translation into non-English languages. -* The importance of effectively incorporating both technology and human skills into the translation process. +- The Department of Justice’s call to action and the connection between language access and equity. +- The connection between plain language and translation into non-English languages. +- The importance of effectively incorporating both technology and human skills into the translation process. ## Speakers -* **Christine Stoneman** - Chief, Federal Coordination and Compliance Section, Civil Rights Division, DOJ +- **Christine Stoneman** - Chief, Federal Coordination and Compliance Section, Civil Rights Division, DOJ ## Moderators -* **Katherine Spivey** - Plain Language Community Lead -* **Laura Godfrey** - Multilingual Community Lead +- **Katherine Spivey** - Plain Language Community Lead +- **Laura Godfrey** - Multilingual Community Lead ## Resources -* [LEP.gov](https://www.lep.gov/) -* [PlainLanguage.gov](https://www.plainlanguage.gov/) -* [Top 10 best practices for multilingual websites](https://digital.gov/resources/top-10-best-practices-for-multilingual-websites/) -* [Tips to create, maintain, and present non-English digital content](https://digital.gov/2022/05/23/10-tips-to-create-maintain-and-present-non-english-digital-content-a-qa-with-michael-mule/) +- [LEP.gov](https://www.lep.gov/) +- [PlainLanguage.gov](https://www.plainlanguage.gov/) +- [Top 10 best practices for multilingual websites](https://digital.gov/resources/top-10-best-practices-for-multilingual-websites/) +- [Tips to create, maintain, and present non-English digital content](https://digital.gov/2022/05/23/10-tips-to-create-maintain-and-present-non-english-digital-content-a-qa-with-michael-mule/) --- -*The Plain Language Action and Information Network (PLAIN) is a group of federal employees from different agencies and specialties who support the use of clear communication in government writing. [Join the Plain Language Community](https://digital.gov/communities/plain-language/).* +_The Plain Language Action and Information Network (PLAIN) is a group of federal employees from different agencies and specialties who support the use of clear communication in government writing. [Join the Plain Language Community](https://digital.gov/communities/plain-language/)._ -*The Multilingual Community of Practice is a group of government digital professionals working to expand and improve digital content in languages other than English. [Join the Multilingual Community](https://digital.gov/communities/multilingual/)*  +_The Multilingual Community of Practice is a group of government digital professionals working to expand and improve digital content in languages other than English. [Join the Multilingual Community](https://digital.gov/communities/multilingual/)_ diff --git a/content/events/2023/03/2023-03-28-uswds-monthly-call-march-2023.md b/content/events/2023/03/2023-03-28-uswds-monthly-call-march-2023.md index 48bb7a2eff..f2f367f227 100644 --- a/content/events/2023/03/2023-03-28-uswds-monthly-call-march-2023.md +++ b/content/events/2023/03/2023-03-28-uswds-monthly-call-march-2023.md @@ -3,7 +3,6 @@ title: USWDS Monthly Call - March 2023 summary: "Making sense: Cognition, perception, and design" host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItceqgqjwoHl_zCE4rfcQlOhV1ePPSqjg end_date: 2023-03-28 15:00:00 -0500 # See all topics at https://digital.gov/topics @@ -48,14 +47,16 @@ We ought to have some time left at the end for Q&A. So let's get right into it. **Slide 4:** Since the last monthly call, we've published both USWDS 3.4.0 and 3.4.1. Due to a sequencing error in our release process, we inadvertently left a couple new features out of USWDS 3.4.0 when we released it, so we quickly released a patch version, 3.4.1, that includes all the features and bugfixes we intended to release in 3.4.0. **Slide 5:** Here's a bit of what you get in this feature-filled release: + - Since we no longer directly support IE11 post-USWDS 3.0, as of USWDS 3.4.1 we now no longer reference woff and ttf font files in our @font-face rules — we only reference woff2 fonts. This means if you self-host a custom font in your project that only includes woff2 files, our built-in font face generator will work for you. It was time. But if your project still has to support IE11, we have a new setting you can pass that will output the woff and ttf fonts as well. - This release will also improve contrast of incomplete step indicator steps - It will allow full-page width headers - It will remove grid dependency from usa-banner package -- And properly vocalize secondary navigation items +- And properly vocalize secondary navigation items - And it will Improve wrapping of external links and icons **Slide 6:** In addition, USWDS 3.4.1 will also + - Allow date pickers inside modals - Improve URL display for in-page navigation links - Allow any spacing unit in alert padding settings @@ -64,7 +65,7 @@ We ought to have some time left at the end for Q&A. So let's get right into it. **Slide 7:** And that's USWDS 3.4.1. It's out now. -**Slide 8:** So I'd like to take a little bit of a step back this month and discuss something that I've often considered one of the fundamentals of design, learning a bit about how our brains make sense of the world. +**Slide 8:** So I'd like to take a little bit of a step back this month and discuss something that I've often considered one of the fundamentals of design, learning a bit about how our brains make sense of the world. After we published our pattern guidance, we got some good feedback that while we were starting to get into patterns and interactions, we still didn't have any information about general rules of UX. We definitely should! And as I was thinking through the kinds of things that we might consider general rules of UX, I kept coming back to some of the ideas we'll talk about today — and as the USWDS team starts to think about how we want to address general rules of UX, we might start with some observations about human cognition that are more than 100 years old, but continue to be proven by neuroscience today. @@ -76,7 +77,7 @@ So let me take a swing at trying to make something that's interesting to me, int **Slide 11:** By and large, at the end of the day, we're designing for people. In some ways we support machines and other processes, but our end users are typically the humans we center our design process around. -**Slide 12:** So one of the things that connects many design disciplines is human interaction. We're creating tools and spaces — predominant digital spaces — for people to do things. So one thing I'd like to assert is that in our world of designing for human interaction, we designers are engineers of human attention. +**Slide 12:** So one of the things that connects many design disciplines is human interaction. We're creating tools and spaces — predominant digital spaces — for people to do things. So one thing I'd like to assert is that in our world of designing for human interaction, we designers are engineers of human attention. Just as electrical engineers deal with electricity and structural engineers work with materials like steel, concrete, wood, plastic, and water, human interaction digital designers (to use a broad term) deal with human attention: conserving, supporting, sustaining, and rewarding the attention of the people who use our sites and services to do something that they need or want to do. @@ -86,13 +87,13 @@ Just as electrical engineers deal with electricity and structural engineers work **Slide 15:** Attention is coordinated in the brain, and in part directed by the sense of self we hold in our brains, which we might call the mind. We can consciously direct our focus — direct our attention — in different ways (in different physical or mental directions) based on a conscious goal, or intention. When we're goal seeking, our intention directs our attention. -For instance, if we want to make breakfast, we might direct our attention (our sensory focus) toward navigating our body to the kitchen, asking ourself what we want to eat, then checking the cabinet for cereal, the refrigerator for milk, and the shelf for bowl, and so on. +For instance, if we want to make breakfast, we might direct our attention (our sensory focus) toward navigating our body to the kitchen, asking ourself what we want to eat, then checking the cabinet for cereal, the refrigerator for milk, and the shelf for bowl, and so on. For many of the tasks we attend to in our day-to-day lives, this type of attention — of using our senses and our memory to follow a chain or flow of navigation and decision making — is simple and frictionless, and takes little energy. **Slide 16:** And this is good, since it turns out that we humans have somewhat little energy to spend on decision making. Our brains have evolved to become extremely efficient at navigating huge amounts of sensory information to accomplish tasks, and the primary way our brains do this is by forgetting and ignoring. We are very good at forgetting and ignoring! -**Slide 17:** Attention is as much about ignoring as it is about focusing. We spend energy on attention so we don't spend it trying to understand everything that's happening around us. +**Slide 17:** Attention is as much about ignoring as it is about focusing. We spend energy on attention so we don't spend it trying to understand everything that's happening around us. Forgetting is the job of what we call working memory. Working memory is not entirely dissimilar to the random access memory we have in our computer — type of temporary buffer memory that helps us make the decision we need to make at the moment then move on to something else. We don't typically store vast quantities of sensory data directly in our brains the way a digital camera might. What we store in working memory is only stored for somewhere between a fraction of a second to just a few seconds. @@ -104,7 +105,7 @@ In another hour, will we remember whether the door was locked when we let out th **Slide 18:** Our brains are optimized to be just-in-time systems. We acquire and store just enough information to get us on to the next thing. And only, over time, if there are significant internal or external consequences to a particular action do we begin to form longer-term associations that we call long-term memories. -**Slide 19:** In fact, if we look around our room, we can easily recognize it as our room — but if we were asked to draw or describe specific features of the room, like whether there was specific shirt or book here or there — or certainly something like how many stripes are on the rug — it might be hard to conjure those specifics. We often only get the gist of a situation, and selectively use our senses and our attention only when we need it to draw out specifics. A principle of cognition is that "the world is its own memory" — we are beings that are built to live in a kind of consistent, coherent, and continuous reality. It's important that we can trust that if we have a chair in our room, for instance, it'll be there until we move it. It doesn't just disappear. The world is its own memory, its continuity and consistency are the foundation that we as humans depend on to work properly. +**Slide 19:** In fact, if we look around our room, we can easily recognize it as our room — but if we were asked to draw or describe specific features of the room, like whether there was specific shirt or book here or there — or certainly something like how many stripes are on the rug — it might be hard to conjure those specifics. We often only get the gist of a situation, and selectively use our senses and our attention only when we need it to draw out specifics. A principle of cognition is that "the world is its own memory" — we are beings that are built to live in a kind of consistent, coherent, and continuous reality. It's important that we can trust that if we have a chair in our room, for instance, it'll be there until we move it. It doesn't just disappear. The world is its own memory, its continuity and consistency are the foundation that we as humans depend on to work properly. **Slide 20:** We're constantly toggling from gist to specific — trying to maintain a general model that can allow us to navigate to something specific when we need it. The relationship between gist and specific is what allows us to use our attention and our working memory efficiently and effectively to navigate a world of infinite information without requiring infinite resources. @@ -124,11 +125,11 @@ It's perhaps important to say that when it comes to understanding how we live, t **Slide 26:** Gestalt psychology proposes that our minds function not as recording devices, or accumulators of data. We do accumulate data, but what our brains store most effectively are models, organizational concepts that allow us to store group information — a kind of compression algorithm that allows us to avoid data redundancy. We don't need to know what every single iteration of an apple looks like, we only need to hold the concept of an apple and sample the details from case to case as our intention and attention demands. -**Slide 27:** Gestalt theory proposes that our minds are built to form groups — that we perform certain kinds of grouping automatically — and cognitive science has ample evidence that this is true. I'd like to show some types of grouping identified by gestalt theorists. You may have some familiarity with them already, they're called the **Gestalt Principles of Grouping**. These are visual examples, but grouping is not an exclusively visual phenomenon. Think of how we perceive something like rhythm in music: we hear or even feel the rhythm as a complete structure — a wholeness — instead of simply a sequence of individual notes or beats. +**Slide 27:** Gestalt theory proposes that our minds are built to form groups — that we perform certain kinds of grouping automatically — and cognitive science has ample evidence that this is true. I'd like to show some types of grouping identified by gestalt theorists. You may have some familiarity with them already, they're called the **Gestalt Principles of Grouping**. These are visual examples, but grouping is not an exclusively visual phenomenon. Think of how we perceive something like rhythm in music: we hear or even feel the rhythm as a complete structure — a wholeness — instead of simply a sequence of individual notes or beats. Today, we're going to look at seven principles of grouping. This is a living field, some of these principles are the originals identified by the original Gestalt theorists, and some have been added by subsequent studies. -**Slide 28:** The first concept is somewhat meta, and it's the concept that we want to find meaning by grouping. We tend to group stimuli in a way that preserves and enhances some type of meaning, preferring the simplest explanation. This is called the **principle of Prägnanz** — whose exact translation is precision, but might better be translated as elegance, in the way that a solution to a problem might be considered elegant. We're inclined to find an elegant explanation to describe a collection of data. +**Slide 28:** The first concept is somewhat meta, and it's the concept that we want to find meaning by grouping. We tend to group stimuli in a way that preserves and enhances some type of meaning, preferring the simplest explanation. This is called the **principle of Prägnanz** — whose exact translation is precision, but might better be translated as elegance, in the way that a solution to a problem might be considered elegant. We're inclined to find an elegant explanation to describe a collection of data. A common example of this principle is anthropomorphization: the way we might see an elephant in a cloud or a face in the splotches on your toast. In a more practical sense, it helps us orient to unusual perspective or lighting — seeing a cat in a curving pattern of shadows on the bed at night, for instance. Or in the example on this slide, we can see what might be considered a complex pattern of arcs and intersections, but the principle of Prägnanz predicts that most of us will quickly interpret this image as six overlapping circles. @@ -156,11 +157,11 @@ Gradual incremental change improves group identity, in a large-scale sense, this Indication that more information exists off-screen. Used in slider and carousel, but also in standard vertical scrolling. The inverse is the "illusion of completeness" when there is more content off-screen, but there's no indication that you should scroll, there are no partial elements you want to complete. -**Slide 35:** Just as our brains are inclined to group elements by characteristics that imply a group identity, we're equally inclined to identify differences between a single element and other elements in the same perceptual field, groups of one. You could think about this perception of difference as contrast since contrast is measurement of the degree of difference. We're all familiar with color contrast and what's required by Section 508 and WCAG, which is a difference in luminance, but there are lots of other ways to perceive difference. +**Slide 35:** Just as our brains are inclined to group elements by characteristics that imply a group identity, we're equally inclined to identify differences between a single element and other elements in the same perceptual field, groups of one. You could think about this perception of difference as contrast since contrast is measurement of the degree of difference. We're all familiar with color contrast and what's required by Section 508 and WCAG, which is a difference in luminance, but there are lots of other ways to perceive difference. -When there are groups of one with sufficient difference, the result is something called the pop-out effect. In the pop-out effect, the element that is different pops out of its context and captures primary attention. Often only after we attend to the element isolated by the pop-out effect can we attend to other groupings and other characteristics of an environment. The pop-out effect can be a powerful driver of attention and, as such, can also be super distracting. Sometimes the power of the pop-out effect can overwhelm the attention and capture all the resources in working memory, at least until it can be actively ignored. Use it intentionally and be on the lookout for any unintentional pop-outs. +When there are groups of one with sufficient difference, the result is something called the pop-out effect. In the pop-out effect, the element that is different pops out of its context and captures primary attention. Often only after we attend to the element isolated by the pop-out effect can we attend to other groupings and other characteristics of an environment. The pop-out effect can be a powerful driver of attention and, as such, can also be super distracting. Sometimes the power of the pop-out effect can overwhelm the attention and capture all the resources in working memory, at least until it can be actively ignored. Use it intentionally and be on the lookout for any unintentional pop-outs. -Here are a few characteristics that can trigger the pop-out effect. +Here are a few characteristics that can trigger the pop-out effect. Some are more dramatic than others, and all of them depend on the degree of difference. @@ -188,7 +189,7 @@ Some are more dramatic than others, and all of them depend on the degree of diff When possible we want to structure our experiences so each individual step a user takes is as meaningful and as simple as it can be. -**Slide 47:** Using meaningful groupings is like creating a navigable decision tree. The first groupings we notice are our first decision —in which grouping should I focus my attention first? Then we sample a detail from that grouping. What's the purpose of that grouping? Did it confirm my assumption about its purpose? Does it have the information I'm looking for? If not, we go to the next grouping. Then, when we find a relevant grouping we look inside it to make our next decision. At each step we want to limit the amount of decision-making we expect of the user. Studies show that people have a much harder time if they're trying to decide from between more than seven choices. More than seven, you may want to reorganize groupings so users can make a simpler choice first. +**Slide 47:** Using meaningful groupings is like creating a navigable decision tree. The first groupings we notice are our first decision —in which grouping should I focus my attention first? Then we sample a detail from that grouping. What's the purpose of that grouping? Did it confirm my assumption about its purpose? Does it have the information I'm looking for? If not, we go to the next grouping. Then, when we find a relevant grouping we look inside it to make our next decision. At each step we want to limit the amount of decision-making we expect of the user. Studies show that people have a much harder time if they're trying to decide from between more than seven choices. More than seven, you may want to reorganize groupings so users can make a simpler choice first. **Slide 48:** And of course, these groupings should be meaningful. Remember the mystery house example from before —structure that gave the appearance of meaning without meaningful organization was even more frustrating than no structure at all! Beware of miscellaneous, grab-bag sections in your sites and services, like a sidebar that contains a half-dozen unrelated modules. @@ -200,21 +201,21 @@ Blind users certainly use focused attention and working memory, and have limited **Slide 51:** Other perceptual differences like color blindness and limited field of vision highlight the importance of layering methods of grouping and difference. Don't leave critical functionality ungrouped; with something like screen magnifiers, the field of vision is constrained, need to visually connect functionality. -**Slide 52:** And finally, many of the principles of grouping and distinction are critically important to content design. Chapters, sections, paragraphs, sentences and lists are common structural groupings that are considered the building blocks of writing. +**Slide 52:** And finally, many of the principles of grouping and distinction are critically important to content design. Chapters, sections, paragraphs, sentences and lists are common structural groupings that are considered the building blocks of writing. -The techniques of Plain Language filter these building blocks through the lens of cognitive load and simplicity. +The techniques of Plain Language filter these building blocks through the lens of cognitive load and simplicity. -- Use clear headings. -- Keep paragraphs short. -- Use lists instead of paragraphs when possible. +- Use clear headings. +- Keep paragraphs short. +- Use lists instead of paragraphs when possible. - Stick to the point. -- Use parallel structure to highlight the differences between clauses. +- Use parallel structure to highlight the differences between clauses. Each of these guidelines helps users easily scan to find the meaning of a group of text. In so many ways, our overall grouping structures of layout and design exist to support text. Our layout grouping should be informed by our content, and our content should, itself, be meaningfully grouped. **Slide 53:** At the end of the day, all of this somewhat academic content is in the service of helping us better and more completely understand the people we serve. For us designers, none of this information is useful independent of user experience, no design is better because it better implements Gestalt groupings, no designer is more effective because they think of themselves as an engineer of attention. A design is better because it addresses user needs more effectively. If information about some of what we understand to be fundamentals of cognition helps us stay engaged with our audience, and helps us understand what kind of design decisions to try when we have a problem, then that, I hope, is also something of value. -**Slide 54:** For more information, you can find a number of good resources online. Here are a few things to search for: +**Slide 54:** For more information, you can find a number of good resources online. Here are a few things to search for: - Gestalt principles of grouping - Max Wertheimer @@ -235,26 +236,26 @@ Thank you, and see you next month! Join the Design System team as we take a step back and explore how our design decisions both support and are supported by the ways our bodies and brains perceive order and make sense of the world. -In this session, we'll discuss: +In this session, we'll discuss: -* How does grouping affect perception? -* What is cognitive load? -* How can we use principles of cognition in the service of design decisions? +- How does grouping affect perception? +- What is cognitive load? +- How can we use principles of cognition in the service of design decisions? **This event is best suited for:** Designers of all levels ## Speakers -* **Dan Williams -** Product Lead, USWDS +- **Dan Williams -** Product Lead, USWDS -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/03/2023-03-29-uswds-monthly-call-april-2023.md b/content/events/2023/03/2023-03-29-uswds-monthly-call-april-2023.md index db7ce3e8cb..d6d7d32592 100644 --- a/content/events/2023/03/2023-03-29-uswds-monthly-call-april-2023.md +++ b/content/events/2023/03/2023-03-29-uswds-monthly-call-april-2023.md @@ -5,7 +5,6 @@ deck: "Top tasks: What the U.S. Web Design System team did and what they found." summary: "Tune-in to learn more about what your feedback is doing for the U.S. Web Design System." host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIsd-yprz0iHLdpaMaMneN1Iseo26Pd-mA # See all topics at https://digital.gov/topics topics: @@ -32,11 +31,11 @@ This month we're celebrating Earth Day, which is this Saturday (with our logo in First, I'd like to mention that we'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't show us on camera. Unfortunately, while we are recording this call, we currently aren't able to share the video publicly. -I’d also like to remind you that by voluntarily attending this Digital.gov event, you agree to abide by Digital.gov’s community guidelines at [digital.gov/communities/community-guidelines/](https://digital.gov/communities/community-guidelines/) — you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat. +I’d also like to remind you that by voluntarily attending this Digital.gov event, you agree to abide by Digital.gov’s community guidelines at [digital.gov/communities/community-guidelines/](https://digital.gov/communities/community-guidelines/) — you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat. If you are in the Zoom app, you can use integrated live captioning by selecting the “CC” button on the bottom of the screen. If you prefer live captioning in a separate window, we've posted a link to the live captioning in the chat. -We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. +We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. For 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&A session at the end of this call. @@ -51,7 +50,7 @@ We ought to have some time left at the end for Q&A. So let's just get right into If you use USWDS 2.13.3 and will not be upgrading to 3.0, consider updating to USWDS 2.14.0. But also consider updating to USWDS 3.0! -**Slide 5:** Secondly, check your inboxes at the end of the month for the 2023 FAS Customer Loyalty Survey. This survey, from GSA's Federal Acquisition Service, isn't spam — it's the primary mechanism by which we determine the design system's Net Promoter Score, or a rough measurement of how likely design system users are to recommend the design system to others. The more we hear from you on this survey, the better information we get about how well we're doing, and the better adjustments we can make moving forward. +**Slide 5:** Secondly, check your inboxes at the end of the month for the 2023 FAS Customer Loyalty Survey. This survey, from GSA's Federal Acquisition Service, isn't spam — it's the primary mechanism by which we determine the design system's Net Promoter Score, or a rough measurement of how likely design system users are to recommend the design system to others. The more we hear from you on this survey, the better information we get about how well we're doing, and the better adjustments we can make moving forward. So take a minute when you see this survey appear. It's not just a random data call, it's something we actually value and use. @@ -67,50 +66,50 @@ You can think of the tasks associated with your service as this grid of dots. A **Slide 9:** Since not all tasks are equally critical to your audience, how do you get a sense of which ones are those critical tasks? You have a diverse audience with diverse needs, is there any way to generalize? In our grid of dots, we see some of them getting bigger and some of them getting smaller, but how do we know which of these dots should be big and which small? -**Slide 10:** How do we identify the tasks that our audience values? How do we identify those tasks we consider key metrics for the success of our service? How do we know where to spend limited resources? In our grid of dots, how do we know which of these dots turn gold and get special attention? +**Slide 10:** How do we identify the tasks that our audience values? How do we identify those tasks we consider key metrics for the success of our service? How do we know where to spend limited resources? In our grid of dots, how do we know which of these dots turn gold and get special attention? Well we were interested in getting answers like this for the design system, and we think that the technique we ended up using to get our answers is practical, achievable, and one that could benefit all sorts of teams. Today we're going to talk about what we did and what we learned, and how you could do this for your own team. **Slide 11:** Some of you may remember taking a survey of ours recently with a lot of checkboxes. That survey was the key data instrument in a research project we’ve been working on over the last few months using a popular technique called Top Tasks. Thank you for taking the time to fill out the survey. We received a great response and your participation was critical to making the project a success. -**Slide 12:** So what are we talking about when we talk about Top Tasks? +**Slide 12:** So what are we talking about when we talk about Top Tasks? **Slide 13:** Well, the short answer is that top tasks are the things that matter most to a majority of your users. They are the key things users are trying to accomplish on your website or app. **Slide 14:** People are fairly task-driven when it comes to interacting with websites - they are trying to get something done. -Think of when you need to book a flight for a trip. So… you might go to a flight search aggregator site that shows you options for multiple airlines. Typically, some main things you want to do are specify your travel locations, your dates of travel, compare prices and fees, compare flight times, and maybe filter by nonstop flights. Those are examples of what might be top tasks. +Think of when you need to book a flight for a trip. So… you might go to a flight search aggregator site that shows you options for multiple airlines. Typically, some main things you want to do are specify your travel locations, your dates of travel, compare prices and fees, compare flight times, and maybe filter by nonstop flights. Those are examples of what might be top tasks. -Now, let’s say you are bringing your cat — let's call her Toonces — with you on your flight, and you need to find the policy for carry-on cat carriers. That might not be a top task. +Now, let’s say you are bringing your cat — let's call her Toonces — with you on your flight, and you need to find the policy for carry-on cat carriers. That might not be a top task. -It’s not that it isn’t important. It's important for you! And it should be easy for people to find that type of information. But until cat transport is the primary reason for air travel, it's not something that's important to a majority of airline travelers. +It’s not that it isn’t important. It's important for you! And it should be easy for people to find that type of information. But until cat transport is the primary reason for air travel, it's not something that's important to a majority of airline travelers. **Slide 15:** A Top Tasks exercise helps you figure out what the top **ten or fewer** things people need to do so you can be sure you continually address the experience of those top things. It’s especially useful if you have limited time and resources to improve the UX of your site. If you can get your website’s top tasks right, you're serving the majority of your users and you can be confident that you're meeting these needs as you also address other important tasks. **Slide 16:** We chose this method because we wanted to get an idea of what matters to our audience. Top tasks is a tool to help your team focus on what matters most. -**Slide 17:** Top Tasks research is a method invented by Gerry McGovern, a highly regarded consultant, speaker, and leader advocating for customer-centricity in the online world as well as for reducing digital waste. He's worked with the EPA, the State Department, HHS, and HUD as well as the governments of Canada, Norway, Ireland, and the UK, among others. +**Slide 17:** Top Tasks research is a method invented by Gerry McGovern, a highly regarded consultant, speaker, and leader advocating for customer-centricity in the online world as well as for reducing digital waste. He's worked with the EPA, the State Department, HHS, and HUD as well as the governments of Canada, Norway, Ireland, and the UK, among others. -Gerry has a great **Deep Dive in Top Tasks video** available on [Digital.gov](https://digital.gov/). +Gerry has a great **Deep Dive in Top Tasks video** available on [Digital.gov](https://digital.gov/). **Slide 18:** The results from a Top Tasks survey can be used to: - prioritize features and content -- design more effective information architecture +- design more effective information architecture - implement meaningful metrics that can be used to monitor how well your top tasks perform over time **Slide 19:** How did we do it? At a high level, there are 3 main stages in the top tasks method: -- First, you create a very long list (for example, 300 or 500) of all the potential tasks users may be trying to do with your website. -- Next, you trim that down to a "short" list of no more than 70 tasks. +- First, you create a very long list (for example, 300 or 500) of all the potential tasks users may be trying to do with your website. +- Next, you trim that down to a "short" list of no more than 70 tasks. - Finally, you ask users to vote on their most important tasks through a survey. -It's conceptually pretty straightforward, but there’s a lot to consider each step of the way. For instance, how do we create this long list of tasks? Who decides what the final short list looks like? And does PRA fit into all of this? +It's conceptually pretty straightforward, but there’s a lot to consider each step of the way. For instance, how do we create this long list of tasks? Who decides what the final short list looks like? And does PRA fit into all of this? Let’s talk about what went into actually doing this work. **Slide 20:** First, the long list of potential tasks. You want to consult sources of actual evidence to help with this. Here are the sources we consulted. -We looked at user behavior on the site with website analytics over a year - what pages are people clicking on? What paths are they taking? What keywords are they searching with? We looked at what questions people are asking us in our email inbox and community channels. I had 1:1 conversations with everyone on the team to see what they think users are doing on our site. I combed through past UX research done at USWDS, and also checked out other design systems to help me create a long list of potential tasks. +We looked at user behavior on the site with website analytics over a year - what pages are people clicking on? What paths are they taking? What keywords are they searching with? We looked at what questions people are asking us in our email inbox and community channels. I had 1:1 conversations with everyone on the team to see what they think users are doing on our site. I combed through past UX research done at USWDS, and also checked out other design systems to help me create a long list of potential tasks. **Slide 21:** Things to keep in mind while creating your long list: Figuring out the level of task can be tricky. It shouldn’t be too broad (like, ‘checking the ‘About us’ page which usually contains a lot of subtasks that people are trying to do when they go to ‘about us’; And it shouldn’t be too specific. For example - we don’t need to list every component we have in the design system as a task (for example ‘find button component; find accordion component, etc.’). Instead, we want to aim for universality of a task. So, ‘Browse components’ is the right level. @@ -118,19 +117,19 @@ We looked at user behavior on the site with website analytics over a year - what **Slide 23:** I’m showing a small portion of the spreadsheet we used on this slide. At the top we see the columns labeled “Task, Category, and Source” The rows in the first Task column show content like “Ask a question, help with errors, FAQs, report a bug, tutorials, request service” and those all belong to the “Help” category. Assigning tasks to categories helps organize your list and helps with trimming it down to a short list later. It also shows the source where those tasks came from, which is important to document. Sources could be anything from stakeholder interviews,to past UX research, or emails our users have sent to us. -**Slide 24:** The next step is starting to consolidate similar and duplicative tasks. That’s relatively easy and it's your first pass at trimming the list. +**Slide 24:** The next step is starting to consolidate similar and duplicative tasks. That’s relatively easy and it's your first pass at trimming the list. -What can be a bit more tricky is that you also want the tasks to be at approximately the same level of information architecture of your site. By "level" I mean that you don’t want to include parent content and child content in the same list. +What can be a bit more tricky is that you also want the tasks to be at approximately the same level of information architecture of your site. By "level" I mean that you don’t want to include parent content and child content in the same list. -Think about something like shopping for clothes online. If you were creating a task list for an online merchant, it wouldn’t make sense to include both “Shop for clothes” and “Shop for jeans” in the list since jeans are a subcategory of clothes. Including both in your list undermines your final results and can make it confusing for users when they vote. +Think about something like shopping for clothes online. If you were creating a task list for an online merchant, it wouldn’t make sense to include both “Shop for clothes” and “Shop for jeans” in the list since jeans are a subcategory of clothes. Including both in your list undermines your final results and can make it confusing for users when they vote. Our final “long list” was 166 tasks. Next, we began working on getting to our short list. **Slide 25:** Trimming down to a short list should be a collaborative process, and we involved the entire core team. We all met for several weeks, with each shortlisting session taking about 1.5-2 hours. Admittedly, this was the part of the project that took much longer than anticipated. Since it involves the whole team, you’re contending with busy schedules and outright fatigue since the sessions require a lot of brain power and decision making. -**Slide 26:** We worked in a collaborative whiteboard tool during these meetings. Basically, I showed all the raw tasks grouped under each category and then we all worked together to determine what the final task or tasks would be. This image shows a sample of the board we worked off of. +**Slide 26:** We worked in a collaborative whiteboard tool during these meetings. Basically, I showed all the raw tasks grouped under each category and then we all worked together to determine what the final task or tasks would be. This image shows a sample of the board we worked off of. -There are two high level categories shown here, which are Tokens and Updates. Under each broad category are some yellow sticky notes that are the raw tasks from our long task list. So for Tokens, the raw tasks were: Learn about tokens, Learn about design tokens, Find specific design tokens (color, flex, etc.), Implement design tokens, and Find or reference specific token information. We discussed what the final tasks should be from these raw tasks - the pink sticky notes show ideas generated from the team, and the purple stickies show the final tasks we settled on (which, we also used dot voting to come to consensus). For the tokens category we decided on 2 final tasks: Learn about design tokens, and Token reference. +There are two high level categories shown here, which are Tokens and Updates. Under each broad category are some yellow sticky notes that are the raw tasks from our long task list. So for Tokens, the raw tasks were: Learn about tokens, Learn about design tokens, Find specific design tokens (color, flex, etc.), Implement design tokens, and Find or reference specific token information. We discussed what the final tasks should be from these raw tasks - the pink sticky notes show ideas generated from the team, and the purple stickies show the final tasks we settled on (which, we also used dot voting to come to consensus). For the tokens category we decided on 2 final tasks: Learn about design tokens, and Token reference. These meetings were full of rich discussions and we also had to decide how final tasks should be worded, which can be tricky. @@ -138,7 +137,7 @@ These meetings were full of rich discussions and we also had to decide how final Our final short list came out to 63 tasks that we included in our survey. -**Slide 28:** We built the survey in [Touchpoints](https://touchpoints.digital.gov/) since we already had access to the software. We asked 7 questions (only 3 of which were required). We asked people about their professional roles, experience with using USWDS, how often they’ve used it, how proficient they feel they are using it, and most importantly, asked about their top tasks. +**Slide 28:** We built the survey in [Touchpoints](https://touchpoints.digital.gov/) since we already had access to the software. We asked 7 questions (only 3 of which were required). We asked people about their professional roles, experience with using USWDS, how often they’ve used it, how proficient they feel they are using it, and most importantly, asked about their top tasks. So, the first question in our survey was… @@ -158,7 +157,7 @@ Ok, so we have everything almost ready to go to launch the survey to users, but **Slide 34:** You need PRA approval if you’re planning to survey more than 9 people and if you include participants who are not federal government employees. -If you are not familiar with the PRA — the Paperwork Reduction Act — and how that impacts research efforts, I highly recommend you check out the resources we’re dropping in the chat. +If you are not familiar with the PRA — the Paperwork Reduction Act — and how that impacts research efforts, I highly recommend you check out the resources we’re dropping in the chat. - [https://pra.digital.gov/about/](https://pra.digital.gov/about/) - [https://digital.gov/resources/paperwork-reduction-act-fast-track-process/](https://digital.gov/resources/paperwork-reduction-act-fast-track-process/) @@ -170,7 +169,7 @@ The fast-track process can be used by agencies with generic clearance for resear **Slide 36:** Methods that potentially fall under the fast track process include: customer satisfaction qualitative surveys; moderated and unmoderated usability studies; focus groups, etc. In other words, it includes a lot of UX research activities that are qualitative. Our survey was largely qualitative and we were not looking for statistical rigor, which was one of the reasons it qualified for the fast track PRA approval process. -**Slide 37:** Again, please look into PRA requirements and how it might affect your specific project. You can check if your agency has generic clearance in place to see if you might be able to use the fast track process as well as find your PRA contact with the links we’re putting in the chat. +**Slide 37:** Again, please look into PRA requirements and how it might affect your specific project. You can check if your agency has generic clearance in place to see if you might be able to use the fast track process as well as find your PRA contact with the links we’re putting in the chat. Once we had all of our materials finalized (like our research plan, survey instrument, and communications plan), we were ready to send off the materials to our PRA contact for review. @@ -182,25 +181,25 @@ Once we had PRA clearance, we were ready to launch our survey. **Slide 40:** We analyzed the survey data and pulled out insights. Let’s take a look at what we found. -**Slide 41:** The graph on this slide shows that we had 132 valid responses on this survey. This was a great response and more than enough to feel confident in our results. +**Slide 41:** The graph on this slide shows that we had 132 valid responses on this survey. This was a great response and more than enough to feel confident in our results. So what do we know about the folks that took the survey in terms of their roles and their experience with USWDS. **Slide 42:** The graph on this slide shows that designers made up a large proportion of respondents (30%), but there was good representation of various professional roles, including: developers (20%), leaders (11%), and many in other roles (20%) such as IT Specialists, Information Architects, Content Strategists, etc. About 50% of respondents self-describe as designers, developers or engineers, or a mix between designer and developer. -**Slide 43:** The graph on this slide shows that we found a decent mix of proficiency levels, from novice to expert. Nearly 50% of respondents consider themselves novice or beginner users of the design system. About another 50% self-describe as either competent or proficient, and only about 4% of our modest users describe themselves as expert. +**Slide 43:** The graph on this slide shows that we found a decent mix of proficiency levels, from novice to expert. Nearly 50% of respondents consider themselves novice or beginner users of the design system. About another 50% self-describe as either competent or proficient, and only about 4% of our modest users describe themselves as expert. **Slide 44:** Let’s take a look at what our overall top tasks were. **Slide 45:** The graph on this slide shows the 681 total votes we received in the survey, equally distributed between each of the 63 tasks in the survey. If each of the tasks got the same number of votes, this is what it would look like, just a long flat bar. This distribution would have made for some tricky analysis. -**Slide 46:** But the graph on this slide shows the actual vote distribution between the tasks, with a steep curve at the left of the graph and a long tail to the right. This is close to what's sometimes called a power-law distribution, common to many types of data, where 80% of the outcomes are consolidated in 20% of the items. +**Slide 46:** But the graph on this slide shows the actual vote distribution between the tasks, with a steep curve at the left of the graph and a long tail to the right. This is close to what's sometimes called a power-law distribution, common to many types of data, where 80% of the outcomes are consolidated in 20% of the items. There are seven tasks in our data that were the clear positive outliers, each was selected by more than 20% of respondents. -**Slide 47:** The graph on this slide shows those seven tasks highlighted in gold. Collectively, these seven items received almost half of the total votes, 48%. +**Slide 47:** The graph on this slide shows those seven tasks highlighted in gold. Collectively, these seven items received almost half of the total votes, 48%. -**Slide 48:** Here are the seven overall USWDS Top Tasks. Obtaining guidance was really important to people (general usability at the top, then design patterns, and components). I was surprised that design pattern guidance was so high since patterns are so new on our site. +**Slide 48:** Here are the seven overall USWDS Top Tasks. Obtaining guidance was really important to people (general usability at the top, then design patterns, and components). I was surprised that design pattern guidance was so high since patterns are so new on our site. We also see that browsing components is a top task (not surprising). Something that was interesting was how critical accessibility is to users. Understanding Section 508/WCAG conformance for components and for the design system in general both were top tasks. Finally, we see design kits made the list. @@ -238,7 +237,7 @@ We know that… **Slide 55:** **Browsing components** is a key task. Our research shows that some users struggle to navigate component pages. -**Slide 56:** **General usability guidance** is a top task, but guidance is scattered across the site, attached to specific components, patterns, and templates. There is demand to provide general usability guidance and best practices in one place. +**Slide 56:** **General usability guidance** is a top task, but guidance is scattered across the site, attached to specific components, patterns, and templates. There is demand to provide general usability guidance and best practices in one place. **Slide 57:** **Patterns** are important to our users, with design pattern guidance being a top task.). We understand patterns are a big need so we need to continue to focus on adding new patterns. @@ -265,7 +264,7 @@ We know that… **Slide 68:** So, to quickly sum things up, The Top Tasks process really worked for us. - It delivered on its promise -- The process — starting with creating a long list of tasks, trimming it down to a shortlist, and surveying users — was all practical, achievable, and resulted in a number of good team discussions. +- The process — starting with creating a long list of tasks, trimming it down to a shortlist, and surveying users — was all practical, achievable, and resulted in a number of good team discussions. - Getting PRA approval should not be seen as a barrier. - We got some hard data and some actionable next steps, such as a focus on talking about accessibility conformance. @@ -275,7 +274,7 @@ We know that… - A Deep Dive into Top Tasks with Gerry McGovern - Digital.gov - Using Top Tasks to be Top-Notch - Digital.gov -- Search for “top tasks research” +- Search for “top tasks research” **Slide 71:** Q&A @@ -285,30 +284,30 @@ Thank you, and see you next month! {{< /accordion >}} -Join us this month as we discuss how and why the U.S. Web Design System (USWDS) team performed their Top Tasks research, as well as what they learned and what they'll do next. Tune-in to learn more about what your feedback is doing for the Design System.  +Join us this month as we discuss how and why the U.S. Web Design System (USWDS) team performed their Top Tasks research, as well as what they learned and what they'll do next. Tune-in to learn more about what your feedback is doing for the Design System. In this session, you’ll learn: -* Why the Design System team conducted this research -* Their research methodology -* Some preliminary findings -* Next steps +- Why the Design System team conducted this research +- Their research methodology +- Some preliminary findings +- Next steps **This event is best suited for:** all users of USWDS, especially user experience practitioners. ## Speakers -* **Dan Williams -** Product Lead, USWDS -* **Jacline Contrino -** User Experience Researcher, USWDS +- **Dan Williams -** Product Lead, USWDS +- **Jacline Contrino -** User Experience Researcher, USWDS -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/04/2023-04-12-incorporating-user-experience-practices-into-data-driven-development-of-a-biomedical-software-tool.md b/content/events/2023/04/2023-04-12-incorporating-user-experience-practices-into-data-driven-development-of-a-biomedical-software-tool.md index 66106c9faf..132dcad027 100644 --- a/content/events/2023/04/2023-04-12-incorporating-user-experience-practices-into-data-driven-development-of-a-biomedical-software-tool.md +++ b/content/events/2023/04/2023-04-12-incorporating-user-experience-practices-into-data-driven-development-of-a-biomedical-software-tool.md @@ -4,8 +4,6 @@ kicker: User Experience summary: Join the National Cancer Institute and a university-based researcher to discuss interpreting complex data. host: User Experience Community of Practice event_organizer: Digital.gov -cop_events: - - user-experience registration_url: https://gsa.zoomgov.com/webinar/register/WN_gPr80ezlSXeArAQvbBwUNw date: 2023-05-03 14:00:00 -0500 end_date: 2023-05-03 15:00:00 -0500 @@ -35,21 +33,21 @@ Mary Goldman, an NCI grantee from the University of California Santa Cruz Genomi In this session, you’ll learn about: -* Building for a scientific user -* Thinking about the user from the beginning -* The power of prototyping for both yourself and user testing +- Building for a scientific user +- Thinking about the user from the beginning +- The power of prototyping for both yourself and user testing **This event is best suited for**: User experience and data science professionals who struggle to find ways to interpret complex data, especially those with limited resources. ## Speakers -* **Dr. David Miller**, Program Director \[Modeling, Visualization, Interactive Media], National Cancer Institute, National Institutes of Health -* **Mary Goldman**, Design and Outreach Engineer, UC Santa Cruz Genomics Institute +- **Dr. David Miller**, Program Director \[Modeling, Visualization, Interactive Media], National Cancer Institute, National Institutes of Health +- **Mary Goldman**, Design and Outreach Engineer, UC Santa Cruz Genomics Institute ## Moderator -* **Natalie Buda Smith**, Community co-lead, User Experience community +- **Natalie Buda Smith**, Community co-lead, User Experience community -- - - +--- -*The UX Community of Practice is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies. [Join the UX Community](https://digital.gov/communities/user-experience/).* +_The UX Community of Practice is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies. [Join the UX Community](https://digital.gov/communities/user-experience/)._ diff --git a/content/events/2023/04/2023-04-26-uswds-monthly-call-may-2023.md b/content/events/2023/04/2023-04-26-uswds-monthly-call-may-2023.md index e1c308ef80..2aa8a9e59f 100644 --- a/content/events/2023/04/2023-04-26-uswds-monthly-call-may-2023.md +++ b/content/events/2023/04/2023-04-26-uswds-monthly-call-may-2023.md @@ -6,7 +6,6 @@ summary: Join us as we observe Global Accessibility Awareness Day and talk about the real-world experience of blind users on the web. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIsc-6tpzIsHMfAzbOrvIBDAiCipibdW7w captions: https://www.streamtext.net/player?event=BIS-GSA-2133 date: 2023-05-18 14:00:00 -0500 @@ -20,7 +19,7 @@ event_platform: zoom primary_image: "2023-uswds-monthly-call-may-title-card" # YouTube ID youtube_id: SG6Bbv-uKeg -youtube_title: "Real-world accessibility: USWDS hears from Eric Yarberry of World Services for the Blind" +youtube_title: "Real-world accessibility: USWDS hears from Eric Yarberry of World Services for the Blind" --- {{< asset-static file="uswds-monthly-call-may-2023.pptx" label="View the slides (PowerPoint presentation, 5.4 MB, 23 pages)" >}} @@ -33,11 +32,11 @@ This month we're celebrating Mothers Day, which was this last weekend, as I'm su First, I'd like to mention that we'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't show us on camera. Unfortunately, while we are recording this call, we currently aren't able to share the video publicly. -I’d also like to remind you that by voluntarily attending this Digital.gov event, you agree to abide by Digital.gov’s community guidelines at [digital.gov/communities/community-guidelines/](https://digital.gov/communities/community-guidelines/) — you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat. +I’d also like to remind you that by voluntarily attending this Digital.gov event, you agree to abide by Digital.gov’s community guidelines at [digital.gov/communities/community-guidelines/](https://digital.gov/communities/community-guidelines/) — you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat. If you are in the Zoom app, you can use integrated live captioning by selecting the “CC” button on the bottom of the screen. If you prefer live captioning in a separate window, we've posted a link to the live captioning in the chat. -We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. +We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. For 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&A session at the end of this call. @@ -64,17 +63,17 @@ And then we'll have some time left at the end for Q&A. So let's get right into i - **Consistency and legibility of disabled form elements.** We updated and normalized disabled styling across our form elements, making disabled styles more distinct from active styles, and increasing the visibility of disabled elements. We also applied consistent styling to forced colors and high contrast mode, and are phasing out class-based disabled styling. When possible, teams should work to move away from disabled styling on form elements and toward other validation workflows, but in the meantime, we'll do what we can to assure that disabled functionality is obvious and clear. - **File input experience for voice and screen readers.** We made some important improvements to the file input component that improve its ability to interact as expected with voice command, and to better announce its status to screen readers. -- **Space bar trigger to links styled as buttons.** There isn't any clear consensus on whether sighted users make a distinction between types of actions a button triggers: whether there's a meaningful difference between buttons that follow a link or buttons that trigger a non-link action like form submission. But from the USWDS perspective, we want to make sure that if it looks like a button, you can trigger it like a button, with the spacebar. And in USWDS 3.5.0, now it does. +- **Space bar trigger to links styled as buttons.** There isn't any clear consensus on whether sighted users make a distinction between types of actions a button triggers: whether there's a meaningful difference between buttons that follow a link or buttons that trigger a non-link action like form submission. But from the USWDS perspective, we want to make sure that if it looks like a button, you can trigger it like a button, with the spacebar. And in USWDS 3.5.0, now it does. -But is a link styled as a button actually a button? +But is a link styled as a button actually a button? Screen readers will not know whether a link looks like a link or looks like a button. It's parsed as the role we assign it. For these users, we should be as clear as possible about what the element is. If it's a link, it should vocalize as a link, if it's a button, it should vocalize as a button. Screen readers have a more direct connection to what the element is, and our markup should reflect that. So this is why we also want to be clear that **role="button"** is reserved only for button elements and not link elements. So, with USWDS 3.5.0, if it looks like a button you can trigger it as you would a button. And as it's been for some time in the design system, only button elements should get a role of button. -- **Updated Identifier accessibility link.** Next, we'll be updating our Identifier's Accessibility Statement link. The Identifier is meant to link out to a service or agency's Accessibility Statement as required by OMB policy. Currently the link reads Accessibility Support, but to align the component more closely with policy, we'll be changing it to Accessibility Statement. +- **Updated Identifier accessibility link.** Next, we'll be updating our Identifier's Accessibility Statement link. The Identifier is meant to link out to a service or agency's Accessibility Statement as required by OMB policy. Currently the link reads Accessibility Support, but to align the component more closely with policy, we'll be changing it to Accessibility Statement. -- **And finally, in USWDS 3.5.0, we're updating our form guidance to finally suggest labeling both required fields and optional fields.** This guidance has been a bit behind standards and norms, and we're finally updating and clarifying this guidance so we recommend that almost all forms — particularly those of three or more fields — label whether a each individual field is optional or required. +- **And finally, in USWDS 3.5.0, we're updating our form guidance to finally suggest labeling both required fields and optional fields.** This guidance has been a bit behind standards and norms, and we're finally updating and clarifying this guidance so we recommend that almost all forms — particularly those of three or more fields — label whether a each individual field is optional or required. - And those are the noteworthy updates in USWDS 3.5.0. But there are a few more nice developer-centered improvements that we'll leave to the release notes! @@ -92,13 +91,13 @@ In general, we consider our design system components to be Section 508 and WCAG **Slide 13:** But when it comes to documenting the conformance of our components, we think the answer isn't just a green checkmark or a simple badge like the silly badge on this slide that reads "Section 508 Inside!" -That does have some value, but we think there's a next level of value, beyond the signal of conformance, that comes from how we made this assessment — of what accessibility and usability tests we consider critical to the success of a component. +That does have some value, but we think there's a next level of value, beyond the signal of conformance, that comes from how we made this assessment — of what accessibility and usability tests we consider critical to the success of a component. We want teams not only to be confident in the accessibility and usability features built into our components, but to be empowered to test the success of their own implementations — especially since there are some aspects to accessibility and usability (like using the appropriate heading level in some components) that are impossible to test before implementation. **Slide 14:** We're thinking of this documentation tool as component-based "critical checklists" for every component in the design system. Our minimum viable product here — or “phase one” if you will — will outline the relevant WCAG 2.1 requirements for each component, along with how to test this requirement, and when we last tested. And as the critical checklist project matures, it could expand to include other aspects of best-practice component accessibility and usability that aren't yet captured in any formal standard. -**Slide 15:** The critical checklists will be easy-to-check functional accessibility and usability tests. +**Slide 15:** The critical checklists will be easy-to-check functional accessibility and usability tests. We know teams can feel overwhelmed with accessibility. And we also know plenty of folks are on lean teams with limited technical resources. As much as possible, these critical checklists will be designed for anyone with modest technical skills to follow. They'll be written in nontechnical plain language, and focused on outcomes instead of on technical markup. **Slide 16:** Critical checklists should outline what all of us can do to validate (and revalidate!) component functionality, both internally at USWDS and for project re-validation. When it comes to accessibility, the more evaluation the better! @@ -107,9 +106,9 @@ It's also possible that as we move forward with these checklists, we'll identify We think there's an excellent opportunity here to not only be accurate and transparent about documenting what goes into our components, but also to be a resource for project teams, and perhaps to point in the direction of future improvements. -**Slide 17:** We aim to publish at least one of these checklists by next month’s call and to establish a publishing schedule for the rest of them as well. +**Slide 17:** We aim to publish at least one of these checklists by next month’s call and to establish a publishing schedule for the rest of them as well. -These checklists will also play an important role in a couple of other related process documents we're developing: a component maturity model, a component proposal framework, and a component acceptance framework. +These checklists will also play an important role in a couple of other related process documents we're developing: a component maturity model, a component proposal framework, and a component acceptance framework. **Slide 18:** As we develop this content and start to publish our first drafts, we'll be reaching out to Feds who've expressed interest in providing usability feedback to the design system in order to solicit input on our checklist approach; so be on the lookout for some communication from us over the next month. @@ -117,24 +116,24 @@ These checklists will also play an important role in a couple of other related p Dan: Thanks Amy. I think there's a lot of promise in these checklists — sharing and building practical accessibility awareness from a number of different angles both here a the design system and across project teams. -**Slide 20:** For the next half an hour, let's talk about real-world accessibility. Specifically, What’s it like to be blind and use the web here in 2023. +**Slide 20:** For the next half an hour, let's talk about real-world accessibility. Specifically, What’s it like to be blind and use the web here in 2023. **Slide 21:** Joining me today is Eric Yarberry, an educator, an advocate for the blind and visually impaired, and the president and CEO at World Services for the Blind. Eric is blind, and as we get started I wanted to mention something that will be a little different about this chat. I will be occasionally unmuting as we speak together to provide the type of "yeahs", "oks", and other social cues that we sometimes keep muted and convey gesturally or with facial expression in video conferences. So while this may be a little different and a little distracting, I hope you can get used to it since it's important to a good conversation. Which I can wait to get into! **Eric — welcome — it's great to have you with us today. To get started, can you take a sec and tell us a bit about who you are and what you do.** -**ANSWER:** My name is Eric. I'm the President and CEO at World Services for the Blind. I've been blind my entire life and so I'm honored to be representing our community on this call today. It's fun getting to provide services to blind and visually impaired individuals. A lot of what I do is working with adults who lose their vision later in life. As you'll hear, in our call we will talk about teaching blind or visually impaired individuals how to use the internet and some of the things that impact us blind individuals in our day-to-day lives. +**ANSWER:** My name is Eric. I'm the President and CEO at World Services for the Blind. I've been blind my entire life and so I'm honored to be representing our community on this call today. It's fun getting to provide services to blind and visually impaired individuals. A lot of what I do is working with adults who lose their vision later in life. As you'll hear, in our call we will talk about teaching blind or visually impaired individuals how to use the internet and some of the things that impact us blind individuals in our day-to-day lives. **QUESTION:** You're an educator. What kind of advice (or warnings!) do you give to newly blind students learning about how to interact with digital sites and services? -**ANSWER:** One of the first things I always tell folks is that you've got to re-learn the internet. The internet is visually based. I teach them to understand that the website content appearing on the screen when you first open it is the most important content. It’s the same as the concept of “above the fold” when you read a newspaper. +**ANSWER:** One of the first things I always tell folks is that you've got to re-learn the internet. The internet is visually based. I teach them to understand that the website content appearing on the screen when you first open it is the most important content. It’s the same as the concept of “above the fold” when you read a newspaper. We have to teach them how a screen reader actually reads a website. I encourage people to stay motivated and positive about it by finding a website that they really like to use. They can go back to that site to build their skills. Often, we encourage individuals who have just lost their vision to pick up a mobile device and learn to use the accessibility tools built on a mobile device, and then gradually build up to a desktop computer. **QUESTION:** I was wondering, can you think back to a time when you had a website experience that was frustrating to you? Can you describe that experience, and how you dealt with it? **ANSWER:** I was cooking and pulled up a recipe on my phone. The website had an ad on a timer. You may have seen an ad that ticks down from 15 to 0 seconds. Normally it’s not frustrating because it means the ad will change, and you can ignore it. But for someone using screen reader software, every second that changes it announces that second. So, I’m trying to read this recipe, and it just keeps reading the timer. Or sometimes I open a website and an automatic video starts playing. -I’m starting to see more and more websites where the video is automatically muted, which is awesome. But even when the ads aren’t audible, they still have that timer, and I think that’s the most frustrating thing. More advanced screen reader users can find workarounds like scrolling down on the website, taking a screenshot, and importing it into an ocular character recognition app. It’s a lot of workaround to read a recipe. +I’m starting to see more and more websites where the video is automatically muted, which is awesome. But even when the ads aren’t audible, they still have that timer, and I think that’s the most frustrating thing. More advanced screen reader users can find workarounds like scrolling down on the website, taking a screenshot, and importing it into an ocular character recognition app. It’s a lot of workaround to read a recipe. Especially being blind, you just get used to piecing things together and problem solving. **QUESTION:** Do you find websites more usable and accessible today then they were in the past? What's better? What's worse? @@ -162,13 +161,13 @@ A red flag is a website that just seems like a field of links, with forms that a **QUESTION:** Do you follow "accessibility" links and provide feedback when you find accessibility issues on sites? What do you hope to find on an accessibility page? -**ANSWER:** Absolutely. If I have an issue or if I notice the website is really well done, I think it's important. A lot of the people that we work with are frustrated, and someone has got to speak up. +**ANSWER:** Absolutely. If I have an issue or if I notice the website is really well done, I think it's important. A lot of the people that we work with are frustrated, and someone has got to speak up. We’ll start off with the positive. One thing that's great is if I can access the accessibility link and a field for suggestions where I can actually share my contact information. I like to see a statement on the efforts of the organization and if possible a name of someone who is in charge of the accessibility efforts. If I fill out that form, a response within the first 48 hours would be awesome. -When I’m accessing that form I am doing it because I intend to actually use the website. If the website isn’t accessible and I could go find that information somewhere else, I’m just going to go somewhere else. But in some cases it’s for work, and I like the services, but it’s just not accessible. I am there to work with those folks to make it accessible. I don't want to come across as a nuisance; trust me, it's not my intention. I didn't choose to be blind. It's just the fact of the matter. I want to come across as respectful, and I teach the folks I work with to be respectful. I know that it’s not people’s first intention to be inaccessible. +When I’m accessing that form I am doing it because I intend to actually use the website. If the website isn’t accessible and I could go find that information somewhere else, I’m just going to go somewhere else. But in some cases it’s for work, and I like the services, but it’s just not accessible. I am there to work with those folks to make it accessible. I don't want to come across as a nuisance; trust me, it's not my intention. I didn't choose to be blind. It's just the fact of the matter. I want to come across as respectful, and I teach the folks I work with to be respectful. I know that it’s not people’s first intention to be inaccessible. **QUESTION:** What's something you wish more people knew about how blind people use the web? -**ANSWER:** The fact that blind people do use the internet, I think that shocks people. I will make comments on websites like, “Hey, I appreciate that from a blind perspective.” And I'll get replies to my comments such as, “Well, how are you blind? You're using the internet.” I think, oh, man, here we go. I don't go round and round with people anymore because it's not my goal to educate the world. But I appreciate this opportunity to get to share my experiences with you. Know that blind people do access the internet. +**ANSWER:** The fact that blind people do use the internet, I think that shocks people. I will make comments on websites like, “Hey, I appreciate that from a blind perspective.” And I'll get replies to my comments such as, “Well, how are you blind? You're using the internet.” I think, oh, man, here we go. I don't go round and round with people anymore because it's not my goal to educate the world. But I appreciate this opportunity to get to share my experiences with you. Know that blind people do access the internet. Especially with technology; that’s how we do our jobs. And that's keeping blind and visually impaired folks employed, and actually providing meaningful lives. We could go down that rabbit hole, but I think it's just important to know that we do access the internet, and we do appreciate the adjustments you make to your websites and your content. It helps so much. It really does. **Slide 22:** Q&A @@ -179,44 +178,46 @@ Thank you, see you next month, and as Mike Horton at the Section 508 program say {{< /accordion >}} -Join us as we observe Global Accessibility Awareness Day and talk about the real-world experience of blind users on the web.  +Join us as we observe Global Accessibility Awareness Day and talk about the real-world experience of blind users on the web. In this session, we’ll: -* Learn from the real-life experience of blind users of screen readers. -* Understand the most common frustrations blind users have with their experience of the web. -* Dig into some of the differences between manual testing and real-world use. -* Discuss design system goals for including accessibility in future monthly calls. +- Learn from the real-life experience of blind users of screen readers. +- Understand the most common frustrations blind users have with their experience of the web. +- Dig into some of the differences between manual testing and real-world use. +- Discuss design system goals for including accessibility in future monthly calls. **This event is best suited for:** Designers and developers of all levels, leadership ## Speakers -* **Dan Williams -** Product Lead, USWDS -* **Amy Cole -** Accessibility Specialist, USWDS -* **Eric Yarberry -** President & CEO, World Services for the Blind +- **Dan Williams -** Product Lead, USWDS +- **Amy Cole -** Accessibility Specialist, USWDS +- **Eric Yarberry -** President & CEO, World Services for the Blind ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) + +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) ## Resources -* [Accessibility resources — Digital.gov](https://digital.gov/topics/accessibility/) -* [Accessibility: Usability for every ability — USWDS](https://designsystem.digital.gov/documentation/accessibility/) -* [Create Accessible Digital Products — Section508.gov](https://www.section508.gov/create/) -* [Find your federal agency’s Section 508 Program Manager](https://www.section508.gov/tools/program-manager-listing/) -* [How to Test Websites for Accessibility (with video)](https://digital.gov/resources/how-test-websites-for-accessibility/) -* [Accessible Digital Content: Tips and Tricks (Digital.gov video playlist)](https://www.youtube.com/watch?v=CL6lOwJEMGQ&list=PLd9b-GuOJ3nFHykZgRBZ7_bzwfZ526rxm&index=22) -* [Accessibility for Teams](https://accessibility.digital.gov/) -*This 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.* +- [Accessibility resources — Digital.gov](https://digital.gov/topics/accessibility/) +- [Accessibility: Usability for every ability — USWDS](https://designsystem.digital.gov/documentation/accessibility/) +- [Create Accessible Digital Products — Section508.gov](https://www.section508.gov/create/) +- [Find your federal agency’s Section 508 Program Manager](https://www.section508.gov/tools/program-manager-listing/) +- [How to Test Websites for Accessibility (with video)](https://digital.gov/resources/how-test-websites-for-accessibility/) +- [Accessible Digital Content: Tips and Tricks (Digital.gov video playlist)](https://www.youtube.com/watch?v=CL6lOwJEMGQ&list=PLd9b-GuOJ3nFHykZgRBZ7_bzwfZ526rxm&index=22) +- [Accessibility for Teams](https://accessibility.digital.gov/) + +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/05/2023-05-08-2023-government-ux-summit.md b/content/events/2023/05/2023-05-08-2023-government-ux-summit.md index dd9d6a9db2..f81989d7f4 100644 --- a/content/events/2023/05/2023-05-08-2023-government-ux-summit.md +++ b/content/events/2023/05/2023-05-08-2023-government-ux-summit.md @@ -6,9 +6,6 @@ summary: User experience (UX) experts across the federal government will share c host: User Experience Community of Practice event_organizer: Digital.gov -cop_events: - - user-experience - - web-managers registration_url: https://gsa.zoomgov.com/webinar/register/WN_moRmnMLtQpmmrvtFgR6qiw captions: "https://www.streamtext.net/player?event=BIS-GSA-5334455" @@ -34,21 +31,20 @@ event_platform: zoom youtube_id: "" primary_image: "title-card-2023-government-ux-summit" - --- On June 14, 2023, Digital.gov will bring together user experience (UX) practitioners to share case studies and best practices from across the federal government with the theme of driving innovation through inclusion. Hear from our speakers about their experiences and lessons learned as they apply UX principles and methodologies in line with the [President’s Management Agenda](https://www.performance.gov/pma/) (PMA) to deliver results for all Americans. At this year’s summit, you will hear from speakers at eight U.S. federal agencies: -* Department of Defense (DOD) -* Department of Health and Human Services (HHS) -* Department of Homeland Security (DHS) -* Department of the Interior (DOI) -* Department of Labor (DOL) -* Department of Veterans Affairs (VA) -* General Services Administration (GSA) -* Office of Personnel Management (OPM) +- Department of Defense (DOD) +- Department of Health and Human Services (HHS) +- Department of Homeland Security (DHS) +- Department of the Interior (DOI) +- Department of Labor (DOL) +- Department of Veterans Affairs (VA) +- General Services Administration (GSA) +- Office of Personnel Management (OPM) The summit is virtual. There will be a short break after each session, and for an hour at noon, Eastern. Reserve your virtual seat today! @@ -86,14 +82,14 @@ In this presentation, we will share actionable tips about managing project logis **Speakers** -* **Kelly Wisneski**—Design Researcher, USAJOBS, OPM -* **McKenna Cole**—Design Researcher, The Lab at OPM -* **Patricia Morris**—Design Strategist, The Lab at OPM -* **Simone Saldanha**—Design Researcher, The Lab at OPM +- **Kelly Wisneski**—Design Researcher, USAJOBS, OPM +- **McKenna Cole**—Design Researcher, The Lab at OPM +- **Patricia Morris**—Design Strategist, The Lab at OPM +- **Simone Saldanha**—Design Researcher, The Lab at OPM **Moderator** -* **UX Community co-lead, Natalie Buda Smith**—Director of Digital Strategy, Library of Congress +- **UX Community co-lead, Natalie Buda Smith**—Director of Digital Strategy, Library of Congress --- @@ -117,17 +113,17 @@ Presenters will share a stakeholder feedback model that user experience professi **Key takeaways from this session will include:** -* Methods for engaging with stakeholders and gathering feedback to produce more inclusive and accessible user experiences. -* A model for gathering, categorizing, prioritizing, implementing, and measuring stakeholder feedback in user experience design and methods to apply in your own work. +- Methods for engaging with stakeholders and gathering feedback to produce more inclusive and accessible user experiences. +- A model for gathering, categorizing, prioritizing, implementing, and measuring stakeholder feedback in user experience design and methods to apply in your own work. **Speakers** -* **Jennifer Shelley**—Health Communications Strategist, Division of Communications, NIH -* **Leslie Westendorf**—Contractor, UX Strategy, NIH +- **Jennifer Shelley**—Health Communications Strategist, Division of Communications, NIH +- **Leslie Westendorf**—Contractor, UX Strategy, NIH **Moderator** -* **Laura Lourenco**—Business Informatics Specialist, U.S. Food & Drug Administration (FDA) +- **Laura Lourenco**—Business Informatics Specialist, U.S. Food & Drug Administration (FDA) --- @@ -151,18 +147,18 @@ In 2022, the VA launched the [Health and Benefits flagship mobile app](https://n **In this session, we will share:** -* How we set up the research -* How we conducted accessibility-first synthesis sessions within the team -* How research findings led to improvements in the app +- How we set up the research +- How we conducted accessibility-first synthesis sessions within the team +- How research findings led to improvements in the app **Speakers** -* **Martha Wilkes**—Accessibility Strategist, VA Office of the Chief Technology Officer (CTO) -* **Elizabeth Straghalis**—Contractor, Staff Researcher, VA +- **Martha Wilkes**—Accessibility Strategist, VA Office of the Chief Technology Officer (CTO) +- **Elizabeth Straghalis**—Contractor, Staff Researcher, VA **Moderator** -* **David Tucker**—Experience Strategist, U.S. Department of State +- **David Tucker**—Experience Strategist, U.S. Department of State #### 2. Operation Rising Tide: Cognitive disability accommodations for the workforce @@ -182,12 +178,12 @@ The presenters will brief Operation Rising Tide, which is an initiative intended **Speakers** -* **Gordon Banks**—General Engineer, Defense Threat Reduction Agency (DTRA) -* **MAJ Kirk Shoemaker**—Nuclear and Countering Weapons of Mass Destruction Officer, U.S. Army, DTRA +- **Gordon Banks**—General Engineer, Defense Threat Reduction Agency (DTRA) +- **MAJ Kirk Shoemaker**—Nuclear and Countering Weapons of Mass Destruction Officer, U.S. Army, DTRA **Moderator** -* **David Tucker**—Experience Strategist, U.S. Department of State +- **David Tucker**—Experience Strategist, U.S. Department of State --- @@ -209,19 +205,19 @@ Alex (an engineer) and Laura (a designer) love that the right phrase can transla **In this session we will:** -* Discuss the value and importance of understanding, interrogating, and improving our metaphors. -* Help you listen for and track the existing metaphors invisibly shaping your workplace. -* Help you reflect on their strengths, weaknesses, and impacts. -* Offer methods to quickly generate new metaphors and refresh those that have grown stale. +- Discuss the value and importance of understanding, interrogating, and improving our metaphors. +- Help you listen for and track the existing metaphors invisibly shaping your workplace. +- Help you reflect on their strengths, weaknesses, and impacts. +- Offer methods to quickly generate new metaphors and refresh those that have grown stale. **Speakers** -* **Alex Bielen**—Engineering Supervisor at 18F, GSA -* **Laura Nash**—Design Supervisor at 18F, GSA +- **Alex Bielen**—Engineering Supervisor at 18F, GSA +- **Laura Nash**—Design Supervisor at 18F, GSA **Moderator** -* **Jonella Culmer**—User Experience Designer, Federal Election Commission (FEC) +- **Jonella Culmer**—User Experience Designer, Federal Election Commission (FEC) #### 2. Simplifying user experiences for complex content at USAGov @@ -243,19 +239,19 @@ We’ll explain the process of how our [Scams Wizard](https://www.usa.gov/where- **Key takeaways from this session include:** -* An example of simplifying complex content for people in an emotional state. -* Our process, which involved content design, prototyping, and comparative usability testing with underserved communities. -* How we put together a mini product team. -* Launching imperfect tools and making iterative improvements based on data. +- An example of simplifying complex content for people in an emotional state. +- Our process, which involved content design, prototyping, and comparative usability testing with underserved communities. +- How we put together a mini product team. +- Launching imperfect tools and making iterative improvements based on data. **Speakers** -* **Joanne McGovern**—UX Researcher, USAGov, GSA -* **Mercedita Andrew**—Contractor, UX Researcher, GSA +- **Joanne McGovern**—UX Researcher, USAGov, GSA +- **Mercedita Andrew**—Contractor, UX Researcher, GSA **Moderator** -* **Jonella Culmer**—User Experience Designer, Federal Election Commission (FEC) +- **Jonella Culmer**—User Experience Designer, Federal Election Commission (FEC) --- @@ -279,26 +275,26 @@ This panel includes user and customer experience specialists from three very dif {{< img-right src="dol-svg-seal" >}} -* Is the signed form a requirement that builds or reduces inclusion? -* What other options do we have? -* What power dynamics do we have with our participants when providing government services? And how do consent forms play into those power dynamics? +- Is the signed form a requirement that builds or reduces inclusion? +- What other options do we have? +- What power dynamics do we have with our participants when providing government services? And how do consent forms play into those power dynamics? **Speakers** -* **Dana Chisnell**—Acting Director for Customer Experience, DHS -* **Erin Elzi**—Digital Services Specialist, Office of Natural Resources Revenue, DOI -* **Shannon McHarg**—User Experience Designer, Office of the Chief Information Officer (CIO), DOL +- **Dana Chisnell**—Acting Director for Customer Experience, DHS +- **Erin Elzi**—Digital Services Specialist, Office of Natural Resources Revenue, DOI +- **Shannon McHarg**—User Experience Designer, Office of the Chief Information Officer (CIO), DOL **Moderator** -* **UX Community co-lead, Jaime Kern**—Strategic Communications Lead, Office of Enterprise Strategy Management, GSA +- **UX Community co-lead, Jaime Kern**—Strategic Communications Lead, Office of Enterprise Strategy Management, GSA ## Resources -* [Digital.gov 2022 Government UX Summit](https://digital.gov/event/2022/06/07/2022-government-ux-summit/) -* [How to Redesign a 19-Year-old Legacy Application Using Agile and User Experience Methodologies (video)](https://youtu.be/cl6sVFjzZG4) -* [Designing Digital Products for Adults With Low Literacy (video)](https://youtu.be/d1MDLbZoEwQ) +- [Digital.gov 2022 Government UX Summit](https://digital.gov/event/2022/06/07/2022-government-ux-summit/) +- [How to Redesign a 19-Year-old Legacy Application Using Agile and User Experience Methodologies (video)](https://youtu.be/cl6sVFjzZG4) +- [Designing Digital Products for Adults With Low Literacy (video)](https://youtu.be/d1MDLbZoEwQ) -- - - +--- -*The UX Community of Practice is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies. [Join the UX Community](https://digital.gov/communities/user-experience/).* +_The UX Community of Practice is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies. [Join the UX Community](https://digital.gov/communities/user-experience/)._ diff --git a/content/events/2023/05/2023-05-15-strengthening-information-accessibility-for-consumers-with-limited-english-proficiency.md b/content/events/2023/05/2023-05-15-strengthening-information-accessibility-for-consumers-with-limited-english-proficiency.md index 86007655cd..ec9519b4e4 100644 --- a/content/events/2023/05/2023-05-15-strengthening-information-accessibility-for-consumers-with-limited-english-proficiency.md +++ b/content/events/2023/05/2023-05-15-strengthening-information-accessibility-for-consumers-with-limited-english-proficiency.md @@ -7,10 +7,6 @@ summary: Tune in to learn what the Consumer Financial Protection Bureau (CFPB) i host: Multilingual Community of Practice and Communicators Community of Practice event_organizer: Digital.gov -cop_events: - - multilingual - - communicators - registration_url: "https://gsa.zoomgov.com/webinar/register/WN_aPfczIYrQ_KwmKQ4ZTYDoQ" captions: https://www.streamtext.net/player?event=BIS-GSA-5351062 @@ -32,7 +28,6 @@ slug: strengthening-information-accessibility-for-consumers-with-limited-english event_platform: zoom primary_image: "cfpb-lep-may-2023-title-card" - --- {{< asset-static file="2023-05-24-strengthening-information-accessibility-slides.pptx" label="View the slides (PowerPoint presentation, 1.3 MB, 18 pages)" >}} @@ -47,24 +42,24 @@ This event is best suited for all levels of multilingual practitioners. Those wh ## Speakers -* **Carmen Cruz** - Financial Education Program Analyst, CFPB -* **Stephanie Osan** - Product Owner and Designer, CFPB +- **Carmen Cruz** - Financial Education Program Analyst, CFPB +- **Stephanie Osan** - Product Owner and Designer, CFPB ## Moderators -* **Fedora Braverman** - Multilingual Community Lead -* **Laura Godfrey** - Multilingual Community Lead +- **Fedora Braverman** - Multilingual Community Lead +- **Laura Godfrey** - Multilingual Community Lead ## Resources -* [Strengthening information accessibility for consumers with limited English proficiency](https://www.consumerfinance.gov/about-us/blog/strengthening-information-accessibility-for-consumers-limited-english-proficiency/) -* [LEP.gov](https://www.lep.gov/) -* [PlainLanguage.gov](https://www.plainlanguage.gov/) -* [Top 10 best practices for multilingual websites](https://digital.gov/resources/top-10-best-practices-for-multilingual-websites/) -* [Tips to create, maintain, and present non-English digital content](https://digital.gov/2022/05/23/10-tips-to-create-maintain-and-present-non-english-digital-content-a-qa-with-michael-mule/) +- [Strengthening information accessibility for consumers with limited English proficiency](https://www.consumerfinance.gov/about-us/blog/strengthening-information-accessibility-for-consumers-limited-english-proficiency/) +- [LEP.gov](https://www.lep.gov/) +- [PlainLanguage.gov](https://www.plainlanguage.gov/) +- [Top 10 best practices for multilingual websites](https://digital.gov/resources/top-10-best-practices-for-multilingual-websites/) +- [Tips to create, maintain, and present non-English digital content](https://digital.gov/2022/05/23/10-tips-to-create-maintain-and-present-non-english-digital-content-a-qa-with-michael-mule/) --- -*The Multilingual Community of Practice is a group of government digital professionals working to expand and improve digital content in languages other than English. [Join the Multilingual Community](https://digital.gov/communities/multilingual/)*  +_The Multilingual Community of Practice is a group of government digital professionals working to expand and improve digital content in languages other than English. [Join the Multilingual Community](https://digital.gov/communities/multilingual/)_ -*The Communicators Community of Practice is a group of federal employees from different agencies and specialties who support the use of clear communication in government writing. [Join the Communicators Community](https://digital.gov/communities/communicators/)* +_The Communicators Community of Practice is a group of federal employees from different agencies and specialties who support the use of clear communication in government writing. [Join the Communicators Community](https://digital.gov/communities/communicators/)_ diff --git a/content/events/2023/06/2023-06-08-uswds-monthly-call-june-2023.md b/content/events/2023/06/2023-06-08-uswds-monthly-call-june-2023.md index 239c8f1814..37a9c1e094 100644 --- a/content/events/2023/06/2023-06-08-uswds-monthly-call-june-2023.md +++ b/content/events/2023/06/2023-06-08-uswds-monthly-call-june-2023.md @@ -5,7 +5,6 @@ summary: Developing and evaluating content for manual accessibility and user experience (UX) tests host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItceGprT0tHyOpdv40WB6ome7t20p6EHQ date: 2023-06-15 14:00:00 -0500 end_date: 2023-06-15 15:00:00 -0500 @@ -31,11 +30,11 @@ youtube_title: "Developing and evaluating content for manual accessibility and u First, I'd like to mention that we'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't show us on camera. Unfortunately, while we are recording this call, we currently aren't able to share the video publicly. -I’d also like to remind you that by voluntarily attending this Digital.gov event, you agree to abide by Digital.gov’s community guidelines at [digital.gov/communities/community-guidelines/](https://digital.gov/communities/community-guidelines/) — you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat. +I’d also like to remind you that by voluntarily attending this Digital.gov event, you agree to abide by Digital.gov’s community guidelines at [digital.gov/communities/community-guidelines/](https://digital.gov/communities/community-guidelines/) — you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat. If you are in the Zoom app, you can use integrated live captioning by selecting the “CC” button on the bottom of the screen. If you prefer live captioning in a separate window, we've posted a link to the live captioning in the chat. -We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. +We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. For 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&A session at the end of this call. @@ -53,11 +52,11 @@ And then we'll have some time left at the end for Q&A. So let's get right into i **Slide 5:** So, there are a number of key improvements in USWDS 3.5.0 that we outlined last month: -- **Consistency and legibility of disabled form elements.** We updated and normalized disabled styling across our form elements, making disabled styles more distinct from active styles, and increasing the visibility of disabled elements. We also applied consistent styling to forced colors and high contrast mode, and are phasing out class-based disabled styling. +- **Consistency and legibility of disabled form elements.** We updated and normalized disabled styling across our form elements, making disabled styles more distinct from active styles, and increasing the visibility of disabled elements. We also applied consistent styling to forced colors and high contrast mode, and are phasing out class-based disabled styling. - **File input experience for voice and screen readers.** We made some important improvements to the file input component that improve its ability to interact as expected with voice command, and to better announce its status to screen readers. - **Space bar trigger to links styled as buttons.** With USWDS 3.5.0, if it looks like a button you can trigger it as you would a button, whether it's a button element or a link styled as usa-button. -- **Updated Identifier accessibility link.** We also updated our Identifier's Accessibility Statement link. To align the component more closely with policy we're updating the text of the link from Accessibility Support to Accessibility Statement. -- **And in USWDS 3.5.0, we're updating our form guidance to finally suggest labeling both required fields and optional fields.** +- **Updated Identifier accessibility link.** We also updated our Identifier's Accessibility Statement link. To align the component more closely with policy we're updating the text of the link from Accessibility Support to Accessibility Statement. +- **And in USWDS 3.5.0, we're updating our form guidance to finally suggest labeling both required fields and optional fields.** So in addition to those changes, we have a few more notable updates in this release. @@ -66,9 +65,9 @@ So in addition to those changes, we have a few more notable updates in this rele - **Stopped using font smoothing.** Font smoothing was a technique that resulted in thinner fonts when displaying light text on dark backgrounds. It's a technique that's no longer in favor and can compromise legibility and readability, so we've removed it from the limited cases where we used it. - **Labeled external links for screen readers.** Now screen readers will announce links that use the external link icon as external links. It will also announce links that open in a new tab. - **Updated individual Sass map settings without affecting defaults.** Previously, changing a USWDS setting that was part of a Sass map — like utility output settings — meant you had to explicitly set every other value in the map as well, or else they'd get set to false. Now you can update only the map setting you want to change, and every other value in the map will retain its default settings. -- **Added two new settings to customize accordion background colors.** Now you can change the background color of accordions site-wide using settings. +- **Added two new settings to customize accordion background colors.** Now you can change the background color of accordions site-wide using settings. - **Removed unused utility builder comments from compiled CSS.** Depending on how you compile your Sass, these comments could take up dozens of K. Now they're gone! -- **Fixed an issue with large file previews in File Upload.** Adding large files into the file upload could result in an infinite spinner for the file's preview. Now the component can better handle large files. +- **Fixed an issue with large file previews in File Upload.** Adding large files into the file upload could result in an infinite spinner for the file's preview. Now the component can better handle large files. - **And finally, we fixed a bug that prevented links that start with a number from scrolling when clicked in In-page navigation.** Now you can use numbers at the beginning of page headings and the in-page navigation will be able to properly link and scroll to them. **Slide 7:** And that's a lot of what's new in USWDS 3.5.0. It's out now, so check it out! @@ -103,7 +102,7 @@ Amy: Thanks for the introduction, Dan. I appreciate the time everyone is taking **Slide 16:** When it comes to accessibility testing, and critical checklists, the first thing we asked ourselves is what's our opportunity? **How can we be useful?** -**Slide 17:** As someone who has worked on a small state-funded web design team, I understand that many of you who work on a government project team have multiple roles and responsibilities. For example, designers are sometimes asked to do development work, developers to be designers, or to pitch in with writing. We often wear multiple hats. We can’t all be accessibility or Section 508 specialists, but we can all contribute to accessibility testing. That's where USWDS can help. +**Slide 17:** As someone who has worked on a small state-funded web design team, I understand that many of you who work on a government project team have multiple roles and responsibilities. For example, designers are sometimes asked to do development work, developers to be designers, or to pitch in with writing. We often wear multiple hats. We can’t all be accessibility or Section 508 specialists, but we can all contribute to accessibility testing. That's where USWDS can help. **Slide 18:** We take our role as accessibility supporters seriously. Our aim is to help scale specialized skills and expertise so that even the smallest team can benefit from the collective expertise of designers, developers, and accessibility specialists across government. It's our responsibility to help ensure that your websites and services meet the needs of your users and the letter of the law. Even if your team does have Section 508 support — and especially if you do not — you may rely on USWDS engineering, usability, and accessibility guidance to help direct your work. @@ -161,7 +160,7 @@ And as we move through the content sections in the next few slides, each section **Slide 34:** **Section 3: Our testing protocols for USWDS components.** The third section outlined the steps USWDS takes to test accessibility on its components. These include: -- Automated tests used in our continuous integration +- Automated tests used in our continuous integration - Manual high contrast mode testing in Windows & Chrome - Browser based accessibility tools for image accessibility - Manual keyboard and voice assistant and screen reader testing @@ -190,7 +189,7 @@ Each section had started with some general guidance about how to approach that c **Slide 39:** **Section 9: Support.** The content ended with short support information and the date we last updated the page. -**Slide 40:** Upon reflection, there was a lot of content in this test! But as we will learn, it gave us a good opportunity to see what was most of interest to our users. I’ll pass things over to Jacline now and she can share how we approached content testing for this first draft of critical checklists. +**Slide 40:** Upon reflection, there was a lot of content in this test! But as we will learn, it gave us a good opportunity to see what was most of interest to our users. I’ll pass things over to Jacline now and she can share how we approached content testing for this first draft of critical checklists. Jacline: Thanks Amy! We just heard how we developed our content and the type of content we were testing. @@ -236,7 +235,7 @@ Our primary goals with the content test were pretty varied. **Slide 57:** This was a fairly lightweight study that we were able to get done (from planning to execution to findings) within about 3 weeks. -**Slide 58:** We reached out to our community of testers for this study to invite them to participate. For those that were interested, we scheduled 30 minute testing sessions. We also informed participants ahead of time of what to expect from the session and how their information would be protected. We also asked for permission to record the session and reiterated that participation is completely voluntary. Following ethical research practices is very important to us. +**Slide 58:** We reached out to our community of testers for this study to invite them to participate. For those that were interested, we scheduled 30 minute testing sessions. We also informed participants ahead of time of what to expect from the session and how their information would be protected. We also asked for permission to record the session and reiterated that participation is completely voluntary. Following ethical research practices is very important to us. **Slide 59:** As mentioned before, the sessions were semi-structured interviews and we carried them out with 4 USWDS users individually. In the session, before we presented the content to participants, we first asked them what they expect to find in an Accordion Accessibility page on our website. This would help us discover if the way they think about accordion accessibility support documentation lined up with how we were thinking about it, and where there might be any gaps. @@ -247,13 +246,13 @@ Then, we gave them about 7 minutes to thoroughly read through the entire documen **Slide 60:** Some of the questions we asked were: - Would you please summarize the information on that page in your own words? -- What was easy or difficult to understand? Why? +- What was easy or difficult to understand? Why? - What questions do you have after reading that content? - What is missing that you’d like to see? Also, what might you change and why? -These questions helped us tease out where we might need to make improvements to our Critical Checklists. +These questions helped us tease out where we might need to make improvements to our Critical Checklists. -**Slide 61:** If there’s anything we’d change for next time we run a test like this, there’s one that comes to mind. +**Slide 61:** If there’s anything we’d change for next time we run a test like this, there’s one that comes to mind. One of the questions we asked folks was to summarize the information on the page in their own words. We found that this was not very effective with such a long document containing a lot of complex, detailed information. It forced participants to answer at a generalized high level, so it might have been more helpful to focus on one section of the content to ask users to summarize. We ended up leaving this question out in later sessions, and instead asked participants “what questions do you have after reading that information?” Overall, the sessions went really well and we got some excellent feedback. It’s always good to get more input on your ideas before building it out too much! @@ -264,7 +263,7 @@ Overall, the sessions went really well and we got some excellent feedback. It’ **Slide 64:** We discovered that we are on the right track with the content, mostly. -**Slide 65:** Overall, it meets or exceeds user expectations — the quote you see on this slide shows one user saying, "*I think that's it's hard to think of all the pieces of accessibility… and I think this does a really good job (at a) high level, considering all of the pieces and also encouraging testing. Even showing or telling them how to test, (the) tools to use. It's very well put together*.” +**Slide 65:** Overall, it meets or exceeds user expectations — the quote you see on this slide shows one user saying, "_I think that's it's hard to think of all the pieces of accessibility… and I think this does a really good job (at a) high level, considering all of the pieces and also encouraging testing. Even showing or telling them how to test, (the) tools to use. It's very well put together_.” **Slide 66:** So, participants were really excited about it and felt that it’d help them feel more confident that the accordion component checks all the accessibility boxes while also empowering them to test their own implementations. The content was also fairly complete — there were a few suggestions for content to add, but overall, the document covered most of what users seemed to need. @@ -281,9 +280,9 @@ Finally, we learned that there is an appetite for more detailed information on t **Slide 68:** **What are we going to do next?** -**Slide 69:** We got some great feedback through these content test sessions. We were thrilled that, overall, people were excited and happy with the content of these Critical Checklists, but we are taking the areas of opportunity into careful consideration as we work towards the next iteration of these checklists. All the raw material is there, so now how might we package it so that it meets the identified needs of users? How might we present the information on the site so that users can easily interact with it and get what they need out of it? +**Slide 69:** We got some great feedback through these content test sessions. We were thrilled that, overall, people were excited and happy with the content of these Critical Checklists, but we are taking the areas of opportunity into careful consideration as we work towards the next iteration of these checklists. All the raw material is there, so now how might we package it so that it meets the identified needs of users? How might we present the information on the site so that users can easily interact with it and get what they need out of it? -These are the questions that are guiding our next phase. We will soon begin prototyping our ideas for what these Critical Checklists might look like and how they might be structured on our site, and we hope to test those ideas again with our community of testers. We hope to roll out these checklists in the coming weeks, so stay tuned! +These are the questions that are guiding our next phase. We will soon begin prototyping our ideas for what these Critical Checklists might look like and how they might be structured on our site, and we hope to test those ideas again with our community of testers. We hope to roll out these checklists in the coming weeks, so stay tuned! Dan: Thanks Jacline! This is Dan again. We learned a lot by pushing ourselves — perhaps — a little bit out of our comfort zone and testing something while it was still very new. @@ -326,42 +325,42 @@ Join us as we talk about the easy-to-follow, manual accessibility and user exper In this session, you’ll learn how we're approaching `Critical Checklists`: -* Our vision for `Critical Checklists` -* How `Critical Checklists` address [Web Content Accessibility Guidelines (WCAG) 2.1](https://www.w3.org/TR/WCAG21/) requirements -* How we're evaluating checklist content -* How `Critical Checklists` can support your own accessibility testing +- Our vision for `Critical Checklists` +- How `Critical Checklists` address [Web Content Accessibility Guidelines (WCAG) 2.1](https://www.w3.org/TR/WCAG21/) requirements +- How we're evaluating checklist content +- How `Critical Checklists` can support your own accessibility testing **This event is best suited for:** Designers, developers, and accessibility specialists at all levels. ## Speakers -* **Dan Williams** — Product Lead, USWDS -* **Amy Cole** — Accessibility Specialist, USWDS -* **Jacline Contrino** — UX Researcher, USWDS +- **Dan Williams** — Product Lead, USWDS +- **Amy Cole** — Accessibility Specialist, USWDS +- **Jacline Contrino** — UX Researcher, USWDS ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) ## Resources -* [Accessibility resources — Digital.gov](https://digital.gov/topics/accessibility/) -* [Accessibility: Usability for every ability — USWDS](https://designsystem.digital.gov/documentation/accessibility/) -* [Create Accessible Digital Products — Section508.gov](https://www.section508.gov/create/) -* [Find your federal agency’s Section 508 Program Manager](https://www.section508.gov/tools/program-manager-listing/) -* [How to Test Websites for Accessibility (with video)](https://digital.gov/resources/how-test-websites-for-accessibility/) -* [Accessible Digital Content: Tips and Tricks (Digital.gov video playlist)](https://www.youtube.com/watch?v=CL6lOwJEMGQ&list=PLd9b-GuOJ3nFHykZgRBZ7_bzwfZ526rxm&index=22) -* [Accessibility for Teams](https://accessibility.digital.gov/) +- [Accessibility resources — Digital.gov](https://digital.gov/topics/accessibility/) +- [Accessibility: Usability for every ability — USWDS](https://designsystem.digital.gov/documentation/accessibility/) +- [Create Accessible Digital Products — Section508.gov](https://www.section508.gov/create/) +- [Find your federal agency’s Section 508 Program Manager](https://www.section508.gov/tools/program-manager-listing/) +- [How to Test Websites for Accessibility (with video)](https://digital.gov/resources/how-test-websites-for-accessibility/) +- [Accessible Digital Content: Tips and Tricks (Digital.gov video playlist)](https://www.youtube.com/watch?v=CL6lOwJEMGQ&list=PLd9b-GuOJ3nFHykZgRBZ7_bzwfZ526rxm&index=22) +- [Accessibility for Teams](https://accessibility.digital.gov/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/07/2023-07-05-supporting-inclusive-language-through-automation.md b/content/events/2023/07/2023-07-05-supporting-inclusive-language-through-automation.md index 758e97a43a..cecd58020b 100644 --- a/content/events/2023/07/2023-07-05-supporting-inclusive-language-through-automation.md +++ b/content/events/2023/07/2023-07-05-supporting-inclusive-language-through-automation.md @@ -4,8 +4,6 @@ kicker: Communicators summary: "Join us as we learn about our Inclusion Bot and how it helps to create an inclusive culture in the workplace." host: Communicators Community of Practice event_organizer: Digital.gov -cop_events: - - communicators registration_url: "https://gsa.zoomgov.com/webinar/register/WN_K_Q-mZ0URjypymxmVl8OMA" date: 2023-07-19 13:00:00 -0500 end_date: 2023-07-19 14:00:00 -0500 @@ -28,7 +26,6 @@ primary_image: 2023-july-inclusion-bot-event-title-card # YouTube ID youtube_id: 4xwC2q8G4J8 youtube_title: "Supporting inclusive language through automation" - --- {{< asset-static file="2023-digitalgov-inclusive-language-support-through-automation-event-final.pptx" label="View the slides (PowerPoint presentation, 4 MB, 29 pages)" >}} @@ -43,18 +40,18 @@ Over time, the team found this bot could use some improvements. So starting in 2 In this session, you’ll learn how to: -* Use technology to promote more inclusive language in the workplace. -* Establish a common language and clear workplace expectations. -* Build a shared understanding of concepts, values, and norms that are essential in building inclusive teams. -* Implement inclusive automation. -* Make iterative improvements to inclusion automation, including the words that trigger a reminder. +- Use technology to promote more inclusive language in the workplace. +- Establish a common language and clear workplace expectations. +- Build a shared understanding of concepts, values, and norms that are essential in building inclusive teams. +- Implement inclusive automation. +- Make iterative improvements to inclusion automation, including the words that trigger a reminder. ## Resources -* [Hacking inclusion: How we customized a bot to gently correct people who use the word 'guys' (2016)](https://18f.gsa.gov/2016/01/12/hacking-inclusion-by-customizing-a-slack-bot/) -* [Improving inclusion, continuously: how we iterated on our bot to promote more inclusive and thoughtful language (2022)](https://18f.gsa.gov/2022/11/14/improving-inclusion-continuously-how-we-iterated-on-our-bot-to-promote-more-inclusive-and-thoughtful-language/) -* [Executive Order on Diversity, Equity, Inclusion, and Accessibility in the Federal Workforce](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/06/25/executive-order-on-diversity-equity-inclusion-and-accessibility-in-the-federal-workforce/) +- [Hacking inclusion: How we customized a bot to gently correct people who use the word 'guys' (2016)](https://18f.gsa.gov/2016/01/12/hacking-inclusion-by-customizing-a-slack-bot/) +- [Improving inclusion, continuously: how we iterated on our bot to promote more inclusive and thoughtful language (2022)](https://18f.gsa.gov/2022/11/14/improving-inclusion-continuously-how-we-iterated-on-our-bot-to-promote-more-inclusive-and-thoughtful-language/) +- [Executive Order on Diversity, Equity, Inclusion, and Accessibility in the Federal Workforce](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/06/25/executive-order-on-diversity-equity-inclusion-and-accessibility-in-the-federal-workforce/) --- -*The Communicators Community of Practice is a group of federal employees from different agencies and specialties who support the use of clear communication in government writing. [Join the Communicators Community](https://digital.gov/communities/communicators/)* +_The Communicators Community of Practice is a group of federal employees from different agencies and specialties who support the use of clear communication in government writing. [Join the Communicators Community](https://digital.gov/communities/communicators/)_ diff --git a/content/events/2023/08/2023-08-03-uswds-monthly-call-august-2023.md b/content/events/2023/08/2023-08-03-uswds-monthly-call-august-2023.md index eafb8cb77e..0300f8651c 100644 --- a/content/events/2023/08/2023-08-03-uswds-monthly-call-august-2023.md +++ b/content/events/2023/08/2023-08-03-uswds-monthly-call-august-2023.md @@ -5,7 +5,6 @@ kicker: USWDS product roadmap updates summary: What's in the newest iteration of the U.S. Web Design System's product roadmap. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItce2vqT4oG9uTweWBp0zBt9111H3ovcc captions: "" date: 2023-08-17 14:00:00 -0500 @@ -30,28 +29,28 @@ Oh, there's one. And welcome back after our July break. Thanks for being back with us today! -**Slide 2:** My name is Dan Williams, he/him, and I'm the USWDS product lead — and here on-screen is my avatar: dark hair, blue sweater, collared shirt. Today my physical self is wearing a light blue collared shirt. What you can't see is that it's hot here in the pacific northwest and my offscreen wardrobe features shorts. And I feel it's important to note that while my current heat at home is unpleasant, my heart goes out to those who are truly suffering in Hawaii. +**Slide 2:** My name is Dan Williams, he/him, and I'm the USWDS product lead — and here on-screen is my avatar: dark hair, blue sweater, collared shirt. Today my physical self is wearing a light blue collared shirt. What you can't see is that it's hot here in the pacific northwest and my offscreen wardrobe features shorts. And I feel it's important to note that while my current heat at home is unpleasant, my heart goes out to those who are truly suffering in Hawaii. I'd also like to note that when we introduce ourselves in these calls, you'll hear things like self-descriptions and pronouns — these help everyone share the same context and know a bit more about who we are, whether or not you know us or can see us. First, I'd like to mention that we'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't show us on camera. Unfortunately, while we are recording this call, we currently aren't able to always share the video publicly. That said, we are making progress on being able to share videos and we're building the capacity to slowly release more and more of these monthly calls publicly. So stay tuned for more updates. When we do post videos publicly, they'll be available via the Digital.gov event page. -I’d also like to remind you that by voluntarily attending this Digital [dot] gov event, you agree to abide by Digital.gov’s community guidelines at digital.gov/communities/community-guidelines/ —you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat. +I’d also like to remind you that by voluntarily attending this Digital [dot] gov event, you agree to abide by Digital.gov’s community guidelines at digital.gov/communities/community-guidelines/ —you can leave the meeting at any time if you do not agree to abide by these guidelines. We’ve posted a link to the community guidelines in the chat. If you are in the Zoom app, you can use integrated live captioning by selecting the “CC” button on the bottom of the screen. If you prefer live captioning in a separate window, we've posted a link to the live captioning in the chat. -We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. +We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. For 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&A session at the end of this call. So thanks! And, with that, let's get started! -**Slide 3:** So what's our agenda for today? +**Slide 3:** So what's our agenda for today? First we'll look at a new site launch Then I'll highlight some product updates -And then we’ll spend the rest of the time checking out our roadmap for the rest of 2023 and into 2024. +And then we’ll spend the rest of the time checking out our roadmap for the rest of 2023 and into 2024. We'll be leaving time for Q&A at the end so stick around! @@ -93,7 +92,7 @@ But before we talk about what we're planning, I'd like to take a moment and look **Slide 16:** But all the time growing, growing, growing. Since USWDS 2.0 — around the time we started keeping reliable usage metrics — design system usage has about tripled. -**Slide 17:** In the last four years, sites using USWDS from 103 to 461. +**Slide 17:** In the last four years, sites using USWDS from 103 to 461. **Slide 18:** The pageviews per month on USWDS-powered sites, as measured with the Digital Analytics Program (or DAP) has grown from 390 million to 1.1 billion. @@ -139,7 +138,7 @@ But before we talk about what we're planning, I'd like to take a moment and look **Slide 39:** What are these costs of change? -**Slide 40:** There are two general types of cost associated with a design system change. +**Slide 40:** There are two general types of cost associated with a design system change. **Slide 41:** The first is perhaps the simplest to understand: implementation cost. Which you can think of as the design and development time it takes to actually update to a new version and modify your project templates to reflect changes to the USWDS codebase. And because of the way we distribute our codebase, any change to the markup of a component necessitates a downstream change to a project implementation. @@ -198,15 +197,15 @@ Anne: Hi! I’m Anne, my pronouns are they/them, and I’m the U.S. Web Design S The U.S. Web Design System right now is giving me “first, invent the universe” vibes here. We need the underlying structure and commonalities of the design system to support the government’s digital universe. But it needs to be both flexible and consistent enough to support everyone’s needs, from agencies and products to end users and what they need to get done. -**Slide 67:** So how do we start — or really, continue — doing this big job? +**Slide 67:** So how do we start — or really, continue — doing this big job? -Our roadmap is part of that: showing how we get from where we are to where we want to be. We know our challenges are big ones, as Dan covered. Those challenges are also opportunities, especially if we can use one to support the other. +Our roadmap is part of that: showing how we get from where we are to where we want to be. We know our challenges are big ones, as Dan covered. Those challenges are also opportunities, especially if we can use one to support the other. -We’ll need to make fundamental shifts — foundational architectural and process changes — to make the future we want possible, especially with the continuous work we need to do to support the system as a living product. This move lets us more fully satisfy what a design system is supposed to solve for its users. These are fundamental platform basics that are necessary before we can expand our view in the roadmap’s next iteration. Part of that is figuring out the mechanics of how we change so we can be ready for those shifts. +We’ll need to make fundamental shifts — foundational architectural and process changes — to make the future we want possible, especially with the continuous work we need to do to support the system as a living product. This move lets us more fully satisfy what a design system is supposed to solve for its users. These are fundamental platform basics that are necessary before we can expand our view in the roadmap’s next iteration. Part of that is figuring out the mechanics of how we change so we can be ready for those shifts. And what we have for you today is about the next year’s worth of what we’re calling a roadmap but may not quite count in the way most product managers would define it. -**Slide 68:** Our roadmap today is what we’d call a minimum viable product, or MVP. We wanted to communicate as much as we have as soon as we have it, to help you understand changes that are coming. So today’s roadmap is fairly near-term. Year-term, you might say. So how we got to this roadmap and the items on it leans a little bit on our old process: most recently, estimating the effort and impact of each future need and mapping those to what will both get us to the future we need to head toward, and also satisfy current needs. We’ll get into the detail of these in just a few minutes. +**Slide 68:** Our roadmap today is what we’d call a minimum viable product, or MVP. We wanted to communicate as much as we have as soon as we have it, to help you understand changes that are coming. So today’s roadmap is fairly near-term. Year-term, you might say. So how we got to this roadmap and the items on it leans a little bit on our old process: most recently, estimating the effort and impact of each future need and mapping those to what will both get us to the future we need to head toward, and also satisfy current needs. We’ll get into the detail of these in just a few minutes. So that’s how we did this prioritization this time. But this isn’t the ideal more long-term thinking we’d like to do. We’re moving from a continuous MVP model to considering our broader mission and vision, and making sure our direction aligns with those. More to come on that too. @@ -225,7 +224,7 @@ So that’s how we did this prioritization this time. But this isn’t the ideal - Establish our ongoing accessibility-focused usability testing - Publish updated guidance for using disabled styles - Create critical checklists for components -- Develop USWDS web components, and +- Develop USWDS web components, and - Convert design tokens to JSON and CSS variables Some of these are interdependent on each other, so we’ll get to more detail on each of these next. @@ -240,19 +239,19 @@ The milestones we’ve set out include first: identifying key metrics and collec **Slide 77:** This item shows you, our community, as well as the public, the process of how our components move from being a proposal you or someone else makes, all the way to being published as part of the design system, as well as what happens after that, like ongoing testing, and also what happens when a component needs major changes. -So why this item? We want to make it clear to everyone what every design system component has to have to be included. This also brings consistency and transparency to our decision making, and builds a common understanding and predictable process to how components develop and change. +So why this item? We want to make it clear to everyone what every design system component has to have to be included. This also brings consistency and transparency to our decision making, and builds a common understanding and predictable process to how components develop and change. These items are part of what’s typically called governance — a funny term here maybe — which is really important for process consistency and continuity. -We’ve started on this one too, and as a preview, we anticipate in the proposal process we’ll be asking for things like a summary of your proposed component, why it would benefit end users and the system, details about its functionality and implementation, accessibility considerations, any documentation or evidence you might have, potential drawbacks or alternatives you considered, things like that. +We’ve started on this one too, and as a preview, we anticipate in the proposal process we’ll be asking for things like a summary of your proposed component, why it would benefit end users and the system, details about its functionality and implementation, accessibility considerations, any documentation or evidence you might have, potential drawbacks or alternatives you considered, things like that. -Getting this in place has been holding up some current proposals, so we want to note it’s taken certainly longer than we’d like to get back to people there. We apologize for that, but we’re happy to share that they are still moving. +Getting this in place has been holding up some current proposals, so we want to note it’s taken certainly longer than we’d like to get back to people there. We apologize for that, but we’re happy to share that they are still moving. The milestones here are first defining the proposal process, as well as documenting the complete component lifecycle, from that proposal phase all the way to maybe being retired in the future. Next we’ll share that information and ask for feedback from you, along with trying out this process with a prototype. After that, we’ll publish both the proposal process and the lifecycle publicly. **Slide 78:** Our next item is establishing ongoing accessibility-focused usability testing of components. -**Slide 79:** This one operationalizes our usability testing with people who use assistive technology and those with disabilities as a sustainable, repeatable process that we do in an ongoing way, and which could serve as a model that other teams could adopt. +**Slide 79:** This one operationalizes our usability testing with people who use assistive technology and those with disabilities as a sustainable, repeatable process that we do in an ongoing way, and which could serve as a model that other teams could adopt. Our reasoning here should hopefully be pretty evident due to how it aligns with our design principles, which Dan mentioned earlier. This supports at least two of them very directly, arguably more — helping us better understand how our components work for real people, including those with disabilities, and help us be more proactive in finding and fixing any usability issues. We’d also like to be able to share this, again, so other teams can use it. @@ -262,9 +261,9 @@ First off here is creating our process for recruiting, managing information, com **Slide 81:** Which, as a spoiler, after some research will include discouraging using disabled styles in most cases, and also helps us create another new process that we should point out too — this process focuses on documenting and publishing our research. The research in question here happens to be what we did to support our decisions in this guidance, but how we did this could apply to other research we do. -Why here — again supporting our design principles — well, this improves the usability and accessibility of our forms, and establishes a repeatable process for publishing our guidance, along with the research and reasoning we used to get to those decisions. +Why here — again supporting our design principles — well, this improves the usability and accessibility of our forms, and establishes a repeatable process for publishing our guidance, along with the research and reasoning we used to get to those decisions. -We’re about halfway through these milestones: we’ve completed the research on this, and we’re in the midst of figuring out the scope of this updated guidance to publish on our site. Lastly, we’ll work on the repeatable process for publishing research generally. We have about three months left here. For the rest of the items, I’ll pass back over to Dan. +We’re about halfway through these milestones: we’ve completed the research on this, and we’re in the midst of figuring out the scope of this updated guidance to publish on our site. Lastly, we’ll work on the repeatable process for publishing research generally. We have about three months left here. For the rest of the items, I’ll pass back over to Dan. **Slide 82:** Dan: Thanks Anne. This is Dan again. @@ -282,13 +281,13 @@ And to improve the accessibility of sites and services **Here are some milestones for how we'll get there:** -First we'll establish component types and voice and tone +First we'll establish component types and voice and tone -Next we'll document heuristics for each of our components and prototype this content and format with our community +Next we'll document heuristics for each of our components and prototype this content and format with our community After that, we'll publish checklists to our website alongside a mechanism for updating -All-in-all we expect this to take about 6 months to finish. +All-in-all we expect this to take about 6 months to finish. **Slide 84:** The next one is the biggie. This is kinda one we've been thinking about and prepping for quite some time, one that I believe is a key milestone in the development of the design system: Developing USWDS web components. @@ -298,7 +297,7 @@ All-in-all we expect this to take about 6 months to finish. To simplify integrations and provide out-of-the box components… -To reduce time and cost of updating to minor and patch versions… +To reduce time and cost of updating to minor and patch versions… and to establish a documented API that teams can use with confidence. @@ -310,17 +309,17 @@ Next we'll work toward an alpha release of our core components (banner and ident After, we'll conduct a thorough beta program for development, feedback, and testing. We'll also be thoroughly documenting these components and their API on our website. This is very likely in support of a new major version of the design system. -When? In all, we expect that this process will take about a year. +When? In all, we expect that this process will take about a year. **Slide 86:** And finally, we want to convert design tokens to JSON and to CSS variables (or custom properties) -**Slide 87:** What does it mean to Convert design tokens to JSON and CSS variables? It means that we want to create a portable, canonical data format for USWDS design tokens, based on standard schemas. +**Slide 87:** What does it mean to Convert design tokens to JSON and CSS variables? It means that we want to create a portable, canonical data format for USWDS design tokens, based on standard schemas. **Why are we doing this?** We're doing this to allow more teams to be able to use our design tokens across frameworks and platforms -To reduce our dependency on specialized formats like Sass… +To reduce our dependency on specialized formats like Sass… To deliver design tokens in a modern, familiar format that teams expect… @@ -336,7 +335,7 @@ Afterwards, we'll convert the remaining tokens, define the JSON transformations In all, we expect this process to take 8 months. -And that's our product roadmap! +And that's our product roadmap! Anne, back to you! @@ -344,23 +343,23 @@ Anne, back to you! **Slide 89:** So, does what we shared just now in terms of features on our roadmap set us up for success? [pause] -Arguably it sets us up for the next year-ish, but we do intend to take a step back to figure out how we continue to do this better. +Arguably it sets us up for the next year-ish, but we do intend to take a step back to figure out how we continue to do this better. -I mentioned that this roadmap isn’t ideal, nor done the way we might want. Product managers looking at this version may look at it with some skepticism or twitch a little involuntarily. Roadmaps, by and large, should not be just a list of features to build. We need to get to a more strategic-mindset version, one that brings our mission and vision into focus and makes clear how we’ll move forward to accomplishing them. +I mentioned that this roadmap isn’t ideal, nor done the way we might want. Product managers looking at this version may look at it with some skepticism or twitch a little involuntarily. Roadmaps, by and large, should not be just a list of features to build. We need to get to a more strategic-mindset version, one that brings our mission and vision into focus and makes clear how we’ll move forward to accomplishing them. -We’re also learning how an agile roadmap may work, so we should also note that what we’re sharing today may change as we learn more. We’ll work to validate what we did in the roadmap you see today, or learn that we need to shift one of these goals. We’re also learning how we might improve as we go, think more strategically, and react as we learn new things, or essential parts of our landscape change. +We’re also learning how an agile roadmap may work, so we should also note that what we’re sharing today may change as we learn more. We’ll work to validate what we did in the roadmap you see today, or learn that we need to shift one of these goals. We’re also learning how we might improve as we go, think more strategically, and react as we learn new things, or essential parts of our landscape change. **Slide 90:** To help provide some grounding, I should note the typical cadence of change in systems like ours: a mission changes the least often. Your mission is your purpose, what you intend to accomplish, and why that’s important. By frequency of change, that’s followed by a vision, which could adjust a little as you learn more. Your vision describes broadly what’s in the future and how you hope to get there, from the point of view of the person who needs it. Most are aspirational but not unrealistic: what does the design system solve, for who, how does this help, and what’s the outcome? -After vision, the next thing that may change a little more frequently may be your polestar — how you do what you do to reach your vision. This is what you measure your actions against, your guiding mechanism for decision-making. It describes how the team should do the thing, motivating us all and showing how we contribute to the mission and vision. A polestar can also help you figure out if you’re about to prioritize something that doesn’t contribute to the core point of the organization. +After vision, the next thing that may change a little more frequently may be your polestar — how you do what you do to reach your vision. This is what you measure your actions against, your guiding mechanism for decision-making. It describes how the team should do the thing, motivating us all and showing how we contribute to the mission and vision. A polestar can also help you figure out if you’re about to prioritize something that doesn’t contribute to the core point of the organization. -What changes more frequently is your roadmap, which you’ll update as you accomplish goals that move you toward accomplishing your mission and vision. Then much more frequently, maybe your API. +What changes more frequently is your roadmap, which you’ll update as you accomplish goals that move you toward accomplishing your mission and vision. Then much more frequently, maybe your API. -But you can depend on the underlying principles, your mission especially. This prevents everything from changing all at once. +But you can depend on the underlying principles, your mission especially. This prevents everything from changing all at once. -**Slide 91:** So in the interest of supporting the universe of government digital products and sites, our goal here is to introduce structure, and refocus on our mission and vision to create a solid foundation and plan for the system itself, farther into the future, ultimately to serve your systems and products and sites, and thus your users. +**Slide 91:** So in the interest of supporting the universe of government digital products and sites, our goal here is to introduce structure, and refocus on our mission and vision to create a solid foundation and plan for the system itself, farther into the future, ultimately to serve your systems and products and sites, and thus your users. So this is how we go from the wild Cosmos universe, all randomly placed stars and cosmic dust, so flexible as to maybe not feel as supportive as it could, to a more consistent system that functionally supports your efforts in a continuous way. A foundation, or a roof, or a net. Here we’re using a geodesic dome at the bottom of the slide to show how all the dots connect here. For what’s next to create this structure, I’ll pass it back to Dan. diff --git a/content/events/2023/09/2023-09-12-cultivating-a-dynamic-career-in-ux.md b/content/events/2023/09/2023-09-12-cultivating-a-dynamic-career-in-ux.md index c07d36c0c0..ab249d140c 100644 --- a/content/events/2023/09/2023-09-12-cultivating-a-dynamic-career-in-ux.md +++ b/content/events/2023/09/2023-09-12-cultivating-a-dynamic-career-in-ux.md @@ -4,7 +4,6 @@ kicker: User Experience summary: Join us for a discussion on how to adapt your career in user experience (UX) to a quickly changing world. host: User Experience Community of Practice event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItdOmpqTgpEygCPS5a5zwjlr-_nNeqAR4 # See all topics at https://digital.gov/topics @@ -21,7 +20,6 @@ end_date: 2023-09-19 15:00:00 -0500 event_platform: zoom primary_image: "cultivating-a-dynamic-career-in-ux-title-card" - --- {{< asset-static file="2023-cultivating-a-dynamic-ux-career.pptx" label="View the slides (PowerPoint presentation, 1.3 MB, 25 pages)" >}} @@ -30,21 +28,21 @@ Join us as we explore what success can look like in a dynamic user experience (U In this session, you’ll learn how to: -* Identify skills that support a quick-moving UX career -* Apply these skills with career-enhancing activities -* Continue to evolve your career in UX +- Identify skills that support a quick-moving UX career +- Apply these skills with career-enhancing activities +- Continue to evolve your career in UX **This event is best suited for:** UX professionals of all levels ## Speakers -* **UX Community co-lead, Natalie Buda Smith** - Director of Digital Strategy, Library of Congress  -* **Michelle Zager** - TEI -* **Carlos Alvarado** - Senior UX Designer, Library of Congress +- **UX Community co-lead, Natalie Buda Smith** - Director of Digital Strategy, Library of Congress +- **Michelle Zager** - TEI +- **Carlos Alvarado** - Senior UX Designer, Library of Congress ## Moderator -* **UX Community co-lead, Jaime Kern** - Lead Strategist for the Federal Marketplace, GSA +- **UX Community co-lead, Jaime Kern** - Lead Strategist for the Federal Marketplace, GSA ## Video Clips @@ -60,6 +58,6 @@ In this session, you’ll learn how to: {{< youtube id="UW8v-I8JM_U" title="Cultivating a dynamic career in UX" >}} -- - - +--- -*The UX Community of Practice is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies. [Join the UX Community](https://digital.gov/communities/user-experience/).* +_The UX Community of Practice is a group of managers, subject matter experts, designers, developers, writers and others interested in creating efficient, effective and useful technologies. [Join the UX Community](https://digital.gov/communities/user-experience/)._ diff --git a/content/events/2023/09/2023-09-18-uswds-monthly-call-september-2023.md b/content/events/2023/09/2023-09-18-uswds-monthly-call-september-2023.md index 502f1f5c70..21a9a55ead 100644 --- a/content/events/2023/09/2023-09-18-uswds-monthly-call-september-2023.md +++ b/content/events/2023/09/2023-09-18-uswds-monthly-call-september-2023.md @@ -6,7 +6,6 @@ summary: We'll explore what it means to pursue mission-centered design and decis host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIsdOygpzwqGGXfWANuR1VJ_0U8wGfc2Bc#/registration date: 2023-09-21 14:00:00 -0500 end_date: 2023-09-21 15:00:00 -0500 @@ -25,6 +24,7 @@ primary_image: 2023-uswds-monthly-call-september-title-card youtube_id: rl5hgoOK22o youtube_title: "Stepping back to look at the big picture" --- + {{< asset-static file="uswds-monthly-call-september-2023.pptx" label="View the slides (PowerPoint presentation, 3.4 MB, 99 pages)" >}} {{< accordion kicker="Slide by Slide" title="USWDS Monthly Call - Presentation Script for September 2023" icon="content_copy" >}}**Slide 1:** Thanks Jeannie, and welcome, everyone, to the U.S. Web Design System monthly call for September 2023, where we've celebrated Labor Day, shown here with a USWDS logo in red white and blue. And if you squint perhaps you can see the form of Rosie the Riveter, with her bicep, blue shirt, and red bandana? @@ -41,7 +41,7 @@ For those of you who find the chat distracting, you’re welcome to close or hid So thanks! And, with that, let's get started! -**Slide 3:** So what's our agenda for today? +**Slide 3:** So what's our agenda for today? First, we've got a nice new site launch, close to home. @@ -59,9 +59,9 @@ And finally we'll continue our discussion from last month, stepping back from ou **Slide 8:** Here are some of the key improvements in USWDS 3.6.1 -**Stacked responsive table reads properly in Safari.** We fixed a bug that prevented the stacked responsive table from announcing properly in the Safari browser. +**Stacked responsive table reads properly in Safari.** We fixed a bug that prevented the stacked responsive table from announcing properly in the Safari browser. -**Tile borders are less distracting.** We fixed a regression that unintentionally darkened the borders of radio tiles and checkbox tiles. +**Tile borders are less distracting.** We fixed a regression that unintentionally darkened the borders of radio tiles and checkbox tiles. **Wrapping breadcrumbs now wrap properly.** We updated breadcrumb wrapping to allow not only wrapping between elements, but wrapping within very long breadcrumb elements in the wrap variant. @@ -73,17 +73,17 @@ And finally, we **fixed a rare mobile menu bug in Safari** where for a small ran **Slide 9:** And that's USWDS 3.6.1. We're wrapping this release up now, and we'll get it out next week. -**Slide 10:** And now I'd like to talk about the USWDS mission, vision, and polestar. We'll talk a bit more about what these individual terms mean in a bit, but together they're a statement of guiding values. A strategic tool that helps us make valuable decisions. +**Slide 10:** And now I'd like to talk about the USWDS mission, vision, and polestar. We'll talk a bit more about what these individual terms mean in a bit, but together they're a statement of guiding values. A strategic tool that helps us make valuable decisions. It's been almost four years since we developed our existing mission and vision. As we plan for the future — in our existing roadmap and beyond — it's time to reevaluate and see whether our mission is still driving us forward in ways that help us deliver on the value teams expect from us. **Slide 11:** I'll be talking about these ideas today alongside Anne Petersen, the USWDS Experience Design Lead. Anne, can you introduce yourself for folks? -Anne: Hi everyone: I’m Anne, my pronouns are they/them, and I’m the U.S. Web Design System’s newest full-time federal employee, our Experience Design Lead. In the interest of inclusion and accessibility, I’m a white person with short brown hair and small brown glasses. I’m aiming for a fairly androgynous look if that helps. Again, very glad to be part of the team. +Anne: Hi everyone: I’m Anne, my pronouns are they/them, and I’m the U.S. Web Design System’s newest full-time federal employee, our Experience Design Lead. In the interest of inclusion and accessibility, I’m a white person with short brown hair and small brown glasses. I’m aiming for a fairly androgynous look if that helps. Again, very glad to be part of the team. Dan: Thanks Anne. They'll be joining me a little later, but first I'd like to set the stage and talk about where we are today and where we've been. -**Slide 12:** If you attended last month's call, I'd like to assure you that while we talked about some of our history in the context of our roadmap planning, I'm not simply going to cover the same ground we covered last week — but those who've been following along with the design system over time will likely recognize a few of the sights along the way. +**Slide 12:** If you attended last month's call, I'd like to assure you that while we talked about some of our history in the context of our roadmap planning, I'm not simply going to cover the same ground we covered last week — but those who've been following along with the design system over time will likely recognize a few of the sights along the way. So, USWDS, as a public product, turns eight next week. My son just turned seven, and I know that — at least in human terms — we aren't toddlers any more. We have some opinions, for sure, and are able to articulate them with increased clarity. But we're also very much the same as we've always been. @@ -93,27 +93,27 @@ So, USWDS, as a public product, turns eight next week. My son just turned seven, **Slide 15:** The post calls out a question that is still relevant today: “Is it possible to create a shared set of tools to provide consistent, beautiful, and easy-to-use government websites?” -It might seem disappointing that this question is still relevant today, but I'm not sure I see it that way. Here in 2023, we see an ongoing commitment to the challenge this blog post articulates. +It might seem disappointing that this question is still relevant today, but I'm not sure I see it that way. Here in 2023, we see an ongoing commitment to the challenge this blog post articulates. -It's noteworthy that USWDS still exists eight years later, and that there's an engaged human-centered design practice all across government that has only grown in its influence and output. Digital experience is a part of the law. Customer experience and a culture of design work that lowers the barriers to entry for government services is an Executive priority. +It's noteworthy that USWDS still exists eight years later, and that there's an engaged human-centered design practice all across government that has only grown in its influence and output. Digital experience is a part of the law. Customer experience and a culture of design work that lowers the barriers to entry for government services is an Executive priority. -We are shaping the future of government digital services every day with this work, and I'm humbled that this community, doing the work day in and day out, are engaged with what we do, pushing us forward, testing us, and inspiring us with the work you do, and adding to a common body of knowledge that subsequent teams can build from. +We are shaping the future of government digital services every day with this work, and I'm humbled that this community, doing the work day in and day out, are engaged with what we do, pushing us forward, testing us, and inspiring us with the work you do, and adding to a common body of knowledge that subsequent teams can build from. "Is it possible?" we asked on Day One. Yes. The work is slow, but the tortoise progresses. -**Slide 16:** Our first design principles, stated on Day One, still influence how we work. You'll probably recognize every item here as essentially common knowledge at this point. And here I'll read directly from the post: +**Slide 16:** Our first design principles, stated on Day One, still influence how we work. You'll probably recognize every item here as essentially common knowledge at this point. And here I'll read directly from the post: - **Make the best thing the easiest thing.** We believe that making tools that align with the values and needs of digital workers in the federal government will drive adoption. +**Make the best thing the easiest thing.** We believe that making tools that align with the values and needs of digital workers in the federal government will drive adoption. - **Be accessible out of the box.** We created tools that seamlessly meet the standards of 508 accessibility, from colors to code. +**Be accessible out of the box.** We created tools that seamlessly meet the standards of 508 accessibility, from colors to code. - **Design for flexibility.** We aim to give the American people a sense of familiarity when using government services, while allowing agencies to customize these tools to fit their unique needs. +**Design for flexibility.** We aim to give the American people a sense of familiarity when using government services, while allowing agencies to customize these tools to fit their unique needs. - **Reuse, reuse, reuse.** We reviewed, tested, evaluated, and repurposed existing patterns, code, and designs from dozens of government and private sector style guides to make use of tried-and-true best practices. +**Reuse, reuse, reuse.** We reviewed, tested, evaluated, and repurposed existing patterns, code, and designs from dozens of government and private sector style guides to make use of tried-and-true best practices. We didn't have an explicit mission or vision in those days, but you can see these principles in our current [design principles](https://designsystem.digital.gov/design-principles/) and our [product values](https://designsystem.digital.gov/about/product-values/). -**Slide 17:** In January 2018 we retired the name "Design Standards" to call ourselves what we actually are as a product: a "Design System," not requirements established by consensus and approved by a recognized body as a NIST Standard, but a collection of principles, guidance, and code that helps disparate teams align on common goals and design from common tools. +**Slide 17:** In January 2018 we retired the name "Design Standards" to call ourselves what we actually are as a product: a "Design System," not requirements established by consensus and approved by a recognized body as a NIST Standard, but a collection of principles, guidance, and code that helps disparate teams align on common goals and design from common tools. **Slide 18:** Twelve months later came the 21st Century Integrated Digital Experience Act, on December 20, 2018, two days before a month-long government shutdown, calling out the requirement for "a consistent appearance" for websites and digital services. @@ -129,11 +129,11 @@ We didn't have an explicit mission or vision in those days, but you can see thes To my eyes, this is a humble and practical mission statement that grows directly from the Day One design principles. It was, in fact, important for us to reiterate that we are a design system in our mission statement, and to use that space to reiterate key values also called out in the law: accessibility and mobile friendliness. -**Slide 23:** Our 2020 *vision* was really important to us. +**Slide 23:** Our 2020 _vision_ was really important to us. **We envision empowered agency digital teams who share solutions and use effective human-centered design practices.** -Process was the key here. This vision is all about the teams we support and is meant to echo the USWDS Design Principles: the foundation of what we build comes from starting with real user needs, earning trust, embracing accessibility, promoting continuity, and listening. +Process was the key here. This vision is all about the teams we support and is meant to echo the USWDS Design Principles: the foundation of what we build comes from starting with real user needs, earning trust, embracing accessibility, promoting continuity, and listening. Of all the progress I've seen in the last four years, that progress in the service of this vision has been the most heartening. I already mentioned it above, but if this is the foundation of what we want to accomplish, that foundation is strong and getting stronger. @@ -155,9 +155,9 @@ There's still plenty of opportunity to grow within this mission and vision, but **Slide 29:** I think the honest answer is yes and no. We've talked to a lot of teams in the last few months, and we've done a lot of planning for what we want to accomplish in the near term, and there are a couple of themes to what we've heard that fall somewhat outside the scope of our mission and vision. -**Slide 30:** The first is commonality — or the importance of the elements of *appearance*, of *experience*, of *familiarity* that we share as government services. +**Slide 30:** The first is commonality — or the importance of the elements of _appearance_, of _experience_, of _familiarity_ that we share as government services. -**Slide 31:** The second is value over time — how the value of using a design system shouldn't only be at the beginning, when you build, but ongoing: in how you stay up-to-date over time. +**Slide 31:** The second is value over time — how the value of using a design system shouldn't only be at the beginning, when you build, but ongoing: in how you stay up-to-date over time. **Slide 32:** I'd like to start with the idea of value over time and what's perhaps an obvious observation: That the design system should deliver value over the lifetime of a service. @@ -169,23 +169,23 @@ There's still plenty of opportunity to grow within this mission and vision, but **Slide 36:** In general, as we keep making improvements to the design system, it should be easier and easier to stay up to date. -**Slide 37:** In fact, we think that this is where the biggest value of the design system lies: after a site or service is launched instead of before. +**Slide 37:** In fact, we think that this is where the biggest value of the design system lies: after a site or service is launched instead of before. **Slide 38:** Eight years in, we now know that this is the beginning, and that we're committed to the long term. This project is a long-term process and USWDS is a long-term solution and partner. We will support long-term solutions and success, to be a service that will be here to support teams for the next eight years, ten years, twenty years. **Slide 39:** What will the future look like in eight years? Ten years? Twenty years? -**Slide 40:** We know that it will be different from today. And that together, we will shape it. Because that's what we've done and that's what we'll keep doing. This is why we're working toward solutions like web components, so we can continuously refine and redefine our solutions, based on real research with real users — and not just our own research, but research from across agencies and user journeys — then scale those improvements across the design system. Over time, we will see the increasing breadth and depth of our common knowledge as an incalculable asset, and an ever-improving case for common solutions. +**Slide 40:** We know that it will be different from today. And that together, we will shape it. Because that's what we've done and that's what we'll keep doing. This is why we're working toward solutions like web components, so we can continuously refine and redefine our solutions, based on real research with real users — and not just our own research, but research from across agencies and user journeys — then scale those improvements across the design system. Over time, we will see the increasing breadth and depth of our common knowledge as an incalculable asset, and an ever-improving case for common solutions. -**Slide 41:** A case for common solutions, common knowledge, *commonality*. +**Slide 41:** A case for common solutions, common knowledge, _commonality_. -**Slide 42:** As you recall, one of our Day One principles was **Design for flexibility**, which we described as "a sense of familiarity when using government services, while allowing agencies to customize these tools to fit their unique needs." +**Slide 42:** As you recall, one of our Day One principles was **Design for flexibility**, which we described as "a sense of familiarity when using government services, while allowing agencies to customize these tools to fit their unique needs." -If our services were cars, we'd want folks to be able to get into any of them and know how to drive. An accelerator and a brake pedal where you expect them. A steering wheel within arm's reach. Seat belts, windshield wipers, and air bags. +If our services were cars, we'd want folks to be able to get into any of them and know how to drive. An accelerator and a brake pedal where you expect them. A steering wheel within arm's reach. Seat belts, windshield wipers, and air bags. Some of these vehicles would be more rugged, some more fancy. Each would have their audience and their purpose, but each have the same familiar, easy-to-use fundamentals that mean that anyone could drive any of them. And maybe they'd all share the same kind of distinctive license plate as well. -Our *process* identifies, codifies, scales, and refines these commonalities. Experimentation, creativity, and research move them forward. The process of developing the design language of familiar, easy-to-use government services is an ongoing dynamic that shapes our evolution. +Our _process_ identifies, codifies, scales, and refines these commonalities. Experimentation, creativity, and research move them forward. The process of developing the design language of familiar, easy-to-use government services is an ongoing dynamic that shapes our evolution. **Slide 43:** So there were some key values that fell outside our mission and vision. We are maturing as a product, a team, and a community, and we felt that the time was right to revisit our mission and vision, and take a fresh look at how we think strategically. So, did we take that fresh look, Anne? @@ -205,15 +205,15 @@ So, we paired the two and worked on both. At times we prioritized one or the oth **Slide 50:** Your vision describes broadly what’s in the future and how you hope to get there. It’s your elevator pitch for the impact you could have, or how you summarize what you do to someone completely unfamiliar. -*Most* are aspirational but not unrealistic. So for us: what does the design system solve — for who — how does this help — and what’s the outcome in our ideal world? These can change every 5 years or so, but should be continuously looking into the future. If you’ve achieved your vision, you’re probably aiming too low. +_Most_ are aspirational but not unrealistic. So for us: what does the design system solve — for who — how does this help — and what’s the outcome in our ideal world? These can change every 5 years or so, but should be continuously looking into the future. If you’ve achieved your vision, you’re probably aiming too low. -It also *explains* more than the mission. For us, the mission is the briefest encapsulation of what we do, whereas the vision shows what we want to accomplish, broadly. +It also _explains_ more than the mission. For us, the mission is the briefest encapsulation of what we do, whereas the vision shows what we want to accomplish, broadly. -But also, having a mission and vision is great, but how do we put them into action? *That’s* where your polestar comes in, and later your roadmap. But first, to polestars: +But also, having a mission and vision is great, but how do we put them into action? _That’s_ where your polestar comes in, and later your roadmap. But first, to polestars: **Slide 51:** Polestar. This is what you measure your actions against, your guiding mechanism for decision-making. It describes how the team should **do** the thing, motivating us all and showing how we contribute to the mission and vision. A polestar can also help you figure out if you’re about to prioritize something that doesn’t contribute to the core point of the organization. -**Slide 52:** Now, to move to our guiding principles *for this work*. First, we wanted to eliminate jargon and stick to plain language, with a fairly broad definition of both, in order to achieve clarity. We want *anyone* to be able to understand our mission and vision. Polestars, on the other hand, bring a little more clarity *internally* than externally — including for those who know and use the system, in our case — so can have just a smidge more technicality to them. +**Slide 52:** Now, to move to our guiding principles _for this work_. First, we wanted to eliminate jargon and stick to plain language, with a fairly broad definition of both, in order to achieve clarity. We want _anyone_ to be able to understand our mission and vision. Polestars, on the other hand, bring a little more clarity _internally_ than externally — including for those who know and use the system, in our case — so can have just a smidge more technicality to them. **Slide 53:** The often-used measure you may have heard before is if a family member might understand. I like to use the measure of “would anyone you just met understand?” Someone you **just met** — who you don’t know the expertise of necessarily — so you need to make it as simple as possible before you hear from them what angle they might be interested in, if they’re interested enough to learn more. Simple, and clear. @@ -227,19 +227,19 @@ But also, having a mission and vision is great, but how do we put them into acti **Slide 58:** Speaking of time, and to help provide some grounding, I should note the typical cadence of change for these tools. A **mission** changes the least often. It’s your purpose; it’s why you’re here. It’s enduring. We can fine-tune it rarely, but it shouldn’t change often. -By frequency of change, that’s followed by **vision**, which you can adjust a little as you learn more or your landscape changes. +By frequency of change, that’s followed by **vision**, which you can adjust a little as you learn more or your landscape changes. -After vision, the next thing that may change a little more frequently may be your polestar — **how** you do what you do to reach your vision, which can change as you find and create new, improved and more efficient methods and processes. +After vision, the next thing that may change a little more frequently may be your polestar — **how** you do what you do to reach your vision, which can change as you find and create new, improved and more efficient methods and processes. But back to your core — your mission and vision. You can **rely** on these underlying principles, your mission especially, which should not change with the direction the wind’s blowing. **Slide 59:** Maybe most importantly at this point, we need to avoid mentioning specific technologies. Not only are they jargon, but they also limit us. What if in four years or eight years a technology we mention is no longer used or available? -**Slide 60:** This is a list of some *exact* words of phrases we wanted to avoid for various reasons — either they’re jargon, or they mean different things to different people, or they’re a specific technology or approach that would *limit* our ability to adjust as we needed to. Things like playbook, template, standards, sustainable, code, mobile, continuous improvement, universal design — even design system and agile. +**Slide 60:** This is a list of some _exact_ words of phrases we wanted to avoid for various reasons — either they’re jargon, or they mean different things to different people, or they’re a specific technology or approach that would _limit_ our ability to adjust as we needed to. Things like playbook, template, standards, sustainable, code, mobile, continuous improvement, universal design — even design system and agile. **Slide 61:** This slide says Who, What, How and Why. To start on this process of uncovering and articulating these key concepts, we got the core team together for a workshop. In this workshop, we started with these core questions: **Who** is the U.S. Web Design System’s audience? **What** are our goals for the system? **How** can we achieve those goals? **Why** is it important that we do? That is, what’s the design system’s **impact**? -**Slide 62:** We then used *those* as source material for thinking about our purpose — that is, our mission — and what we want to accomplish — that is, our vision — creating two fields of variously colored virtual sticky notes, all of them unreadable at this scale. +**Slide 62:** We then used _those_ as source material for thinking about our purpose — that is, our mission — and what we want to accomplish — that is, our vision — creating two fields of variously colored virtual sticky notes, all of them unreadable at this scale. **Slide 63:** But then we refined to get fewer, more focused ideas. @@ -247,13 +247,13 @@ But back to your core — your mission and vision. You can **rely** on these und **Slide 65:** Sometimes we had to take a step back for a wider view, reaching back into earlier versions to pick up concepts that we thought at the time weren’t working. But sometimes those earlier ideas helped us make connections or get to an approach we hadn’t considered yet. -**Slide 66:** This process honestly got frustrating — showing here even more different sizes and colors of stickies with labels and also a select few that appear in frames — but since I’ve done this kind of missioning and visioning a few times before, I could tell everyone that that’s incredibly normal. Happens *every time* in this process. At this point we could tell we didn’t have it yet, but we didn’t know what “it” *was*, quite. +**Slide 66:** This process honestly got frustrating — showing here even more different sizes and colors of stickies with labels and also a select few that appear in frames — but since I’ve done this kind of missioning and visioning a few times before, I could tell everyone that that’s incredibly normal. Happens _every time_ in this process. At this point we could tell we didn’t have it yet, but we didn’t know what “it” _was_, quite. -**Slide 67:** So we looked at some other examples, while doing essentially a really intense, long session of *working through our wording*. Fine-tuning through to *just* the *right* **word**. Improve or adapt or define or refine. They’re *different*, and words matter. +**Slide 67:** So we looked at some other examples, while doing essentially a really intense, long session of _working through our wording_. Fine-tuning through to _just_ the _right_ **word**. Improve or adapt or define or refine. They’re _different_, and words matter. -**Slide 68:** But here, where we concluded, are just three colored stickies with labels in navy blue, medium blue, and red, still unreadable. But this is where we wrapped up. What they *actually* came out to be… well, that’s next. I’ll pass it over to Dan. +**Slide 68:** But here, where we concluded, are just three colored stickies with labels in navy blue, medium blue, and red, still unreadable. But this is where we wrapped up. What they _actually_ came out to be… well, that’s next. I’ll pass it over to Dan. -**Slide 69:** Dan: Thanks Anne. Yes, I think I used the words "dark night of the soul" as we passed through one of the more despairing parts of the process. And there were some. You know, we really value talking about the process of design work — of which writing work is very much a part — since we like to show our work. But it isn't always pretty. +**Slide 69:** Dan: Thanks Anne. Yes, I think I used the words "dark night of the soul" as we passed through one of the more despairing parts of the process. And there were some. You know, we really value talking about the process of design work — of which writing work is very much a part — since we like to show our work. But it isn't always pretty. Doing this kind of work can be like watching dreams be born and die. And that dark period between death and rebirth is where you can really question your choices. @@ -285,7 +285,7 @@ So what did we find? **Slide 80:** And that's where we found our mission: **Shaping the future of government digital services**. Something we do together, over time. It's a very small point, but many mission statements begin with "we" and this one does not, intended to point not back at ourselves but to be inclusive of everyone involved in our process. -**Slide 81:** So as we address the future, what's in that future? +**Slide 81:** So as we address the future, what's in that future? **Slide 82:** We identified some descriptive words that describe our best future. Words like **Empowered**, **Centered**, **Equitable**, **Trustworthy**, **Familiar**, **Reliable**, and **Better**. @@ -301,23 +301,23 @@ So what did we find? **Slide 88:** And finally, what are we doing in support of this mission and vision? -**Slide 89:** We identified some descriptive words that describe our activities. Words like **Help**, **Develop**, **Research**, **Design**, **Support**, **Maintain**, and **Improve**. +**Slide 89:** We identified some descriptive words that describe our activities. Words like **Help**, **Develop**, **Research**, **Design**, **Support**, **Maintain**, and **Improve**. -**Slide 90:** And we also thought about what we try to help teams do: **Design**, **Align**, **Explore**, **Maintain**, **Contribute**, **Research**, and **Update**. +**Slide 90:** And we also thought about what we try to help teams do: **Design**, **Align**, **Explore**, **Maintain**, **Contribute**, **Research**, and **Update**. **Slide 91:** And this resulted in our polestar: **We help government teams align, design, and keep their websites and services up to date.** **Slide 92:** This polestar begins to more fully capture the breadth of the how teams work with the design system: getting started and building alignment; designing, building, and redesigning; and the continuous process of staying up to date and improving over time. -**Slide 93:** Together, this USWDS mission, vision, and polestar function as a better strategic tool as we evolve as a product and as the expectations teams and the public have for us evolve as well. +**Slide 93:** Together, this USWDS mission, vision, and polestar function as a better strategic tool as we evolve as a product and as the expectations teams and the public have for us evolve as well. Our mission — **Shaping the future of government services** — keeps the future always in front of us, focused on a dynamic, collaborative creative process. Our vision — **Empowered and supported digital service teams Familiar and easy-to-use digital services.** — helps us more fully understand our value and the goals of this process. -Our polestar — **We help government teams align, design, and keep their websites and services up to date** — helps us understand how we deliver against valuable, sometimes measurable, outcomes. +Our polestar — **We help government teams align, design, and keep their websites and services up to date** — helps us understand how we deliver against valuable, sometimes measurable, outcomes. -For alignment, how are we doing for driving adoption, building consensus, providing evidence, and delivering common solutions that teams actually use. +For alignment, how are we doing for driving adoption, building consensus, providing evidence, and delivering common solutions that teams actually use. For design, how are we doing for improving the design and development speed; are we delivering all the components, patterns, and guidance that teams need, and are these tools flexible, modular, and reliable @@ -335,7 +335,7 @@ Right now, I know it's working because I feel the potential and the terror. I fe **Slide 98:** Q&A -**Slide 99:** We'll be back in October where we hope to talk about our Product Values, as well as progress on new component proposals. +**Slide 99:** We'll be back in October where we hope to talk about our Product Values, as well as progress on new component proposals. If you have a question we weren't able to answer in the call, or thought of later, please head into our public Slack and ask it there. We'll be around after the call to answer questions. @@ -347,36 +347,36 @@ It's been eight years since the first public release of the U.S. Web Design Syst We’ll discuss: -* USWDS mission and vision -* What we've learned from talking with teams -* A mission-focused future +- USWDS mission and vision +- What we've learned from talking with teams +- A mission-focused future **This event is best suited for:** Anyone who uses the U.S. Web Design System. ## Speakers -* **Dan Williams** **—** Product Lead, USWDS -* **Anne Petersen** **—** Experience Design Lead, USWDS +- **Dan Williams** **—** Product Lead, USWDS +- **Anne Petersen** **—** Experience Design Lead, USWDS ## Related resources -Last month, we talked about what’s on the Design System’s product roadmap. Check out the [slides from the Design System roadmap discussion](https://digital.gov/event/2023/08/17/uswds-monthly-call-august-2023/).  +Last month, we talked about what’s on the Design System’s product roadmap. Check out the [slides from the Design System roadmap discussion](https://digital.gov/event/2023/08/17/uswds-monthly-call-august-2023/). Also, take a look at the [USWDS product roadmap](https://github.com/orgs/uswds/projects/13/views/1?visibleFields=%5B%22Title%22%2C%22Labels%22%5D) to learn more about what the team is working on for the rest of 2023 and into 2024. ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/09/2023-09-27-backlogs-and-why-every-website-needs-one.md b/content/events/2023/09/2023-09-27-backlogs-and-why-every-website-needs-one.md index 40e37d5f23..b57088a237 100644 --- a/content/events/2023/09/2023-09-27-backlogs-and-why-every-website-needs-one.md +++ b/content/events/2023/09/2023-09-27-backlogs-and-why-every-website-needs-one.md @@ -7,7 +7,6 @@ summary: Join us as we discuss the concept and importance of backlogs and hear programs. host: Web Managers Community of Practice event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItf--rrzMpHTwORod8Ppd5YEJphF-PLpk date: 2023-10-12 14:00:00 -0500 end_date: 2023-10-12 15:00:00 -0500 @@ -19,36 +18,37 @@ slug: backlogs-and-why-every-website-needs-one event_platform: zoom primary_image: "backlogs-and-why-every-website-needs-one-title-card" --- + {{< asset-static file="backlogs-and-why-every-website-needs-one-slides.pptx" label="View the slides (PowerPoint presentation, 5.8 MB, 43 pages)" >}} Come learn about backlogs and how they can support iterative development practices that focus on delivering value to users. Speakers will share case studies from [Touchpoints](https://touchpoints.digital.gov/), [GSA SmartPay](https://smartpay.gsa.gov/), and [Search.gov](https://search.gov/). In this session, we’ll discuss: -* What is a backlog? -* Why is a backlog necessary? -* How is a backlog managed? +- What is a backlog? +- Why is a backlog necessary? +- How is a backlog managed? This event is best suited for: web managers, product managers, program managers, designers and developers at all levels. ## Speakers -* **Ryan Wold** - Innovation Specialist, Touchpoints, GSA -* **Andrew Lee** - Business Management Specialist, SmartPay, GSA -* **Dawn McCleskey** - Program Manager, Search.gov, GSA\*\* +- **Ryan Wold** - Innovation Specialist, Touchpoints, GSA +- **Andrew Lee** - Business Management Specialist, SmartPay, GSA +- **Dawn McCleskey** - Program Manager, Search.gov, GSA\*\* ## Moderator -* **Web Managers** **Community co-lead, Beth A. Martin** - Digital Services Expert (UX Designer), Office of Personnel Management (OPM) +- **Web Managers** **Community co-lead, Beth A. Martin** - Digital Services Expert (UX Designer), Office of Personnel Management (OPM) ## You may also be interested in: -* [Agile fundamentals](https://agile.18f.gov/agile-fundamentals/) -* [Foundations of Agile, Part I](https://digital.gov/event/2019/11/04/foundations-agile-i/) -* [Foundations of Agile, Part II](https://digital.gov/event/2019/11/05/foundations-agile-ii/) -* [Search.gov roadmap](https://search.gov/about/updates/roadmap/) -* [U.S. Web Design System roadmap: August 2023 monthly call](https://digital.gov/event/2023/08/17/uswds-monthly-call-august-2023/) +- [Agile fundamentals](https://agile.18f.gov/agile-fundamentals/) +- [Foundations of Agile, Part I](https://digital.gov/event/2019/11/04/foundations-agile-i/) +- [Foundations of Agile, Part II](https://digital.gov/event/2019/11/05/foundations-agile-ii/) +- [Search.gov roadmap](https://search.gov/about/updates/roadmap/) +- [U.S. Web Design System roadmap: August 2023 monthly call](https://digital.gov/event/2023/08/17/uswds-monthly-call-august-2023/) -- - - +--- -*The Web Managers Community of Practice is a group of government employees who manage government websites and digital services. They work to create a trusted, seamless online experience for all. [Join the Web Managers Community](https://digital.gov/communities/web-content-managers/).* +_The Web Managers Community of Practice is a group of government employees who manage government websites and digital services. They work to create a trusted, seamless online experience for all. [Join the Web Managers Community](https://digital.gov/communities/web-content-managers/)._ diff --git a/content/events/2023/10/2023-10-11-uswds-monthly-call-october-2023.md b/content/events/2023/10/2023-10-11-uswds-monthly-call-october-2023.md index c5f35fd577..524c7b9ddf 100644 --- a/content/events/2023/10/2023-10-11-uswds-monthly-call-october-2023.md +++ b/content/events/2023/10/2023-10-11-uswds-monthly-call-october-2023.md @@ -5,7 +5,6 @@ kicker: Conducting user research with people with disabilities summary: This month, we'll share progress and findings from our recent effort to improve our ongoing research practice. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItd-quqDMoHlDxTzhAa_JdKCvcWG7ccyA#/registration date: 2023-10-19 14:00:00 -0500 end_date: 2023-10-19 15:00:00 -0500 @@ -25,6 +24,7 @@ primary_image: 2023-uswds-monthly-call-oct-title-card youtube_id: _uNXQpu6Dwg youtube_title: "How to develop a sustainable, repeatable research process" --- + {{< asset-static file="uswds-monthly-call-october-2023.pptx" label="View the slides (PowerPoint presentation, 9.2 MB, 111 pages)" >}} {{< accordion kicker="Slide by Slide" title="USWDS Monthly Call - Presentation Script for October 2023" icon="content_copy" >}}**Slide 1:** Thanks Jeannie, and welcome, everyone, to the U.S. Web Design System monthly call for October 2023, where some of us on the western half of the continental United States, just this weekend got to watch our little old moon pass right between us and our Sun and through some kind of cosmic coincidence, even though about 450 moons could fit across the diameter of the Sun, to us they look almost exactly the same size, and one can pretty much perfectly conceal the other, just as your thumb can cover up a mountain every once and a while. And just as we see the USWDS logo fading from yellow to black and back again. @@ -41,7 +41,7 @@ For those of you who find the chat distracting, you’re welcome to close or hid So thanks! And, with that, let's get started! -**Slide 3:** So what's our agenda for today? +**Slide 3:** So what's our agenda for today? First, we've got a few nice new site launches from close to home. @@ -91,9 +91,9 @@ And there are a few other nice bugfixes and improvements in 3.7.0. If you're int **Slide 15:** So now I'd like to talk about some work we've done toward operationalizing user research and a user research practice on our team, and about usability research with people with disabilities as an explicit focus. -**Slide 16:** A couple weeks ago, our team was talking through some of what we'll discuss later in the call: where to collect research artifacts and how to organize older research reports. In general, how we can better work to document ongoing and existing research. And one of our team members suggested that we might use our existing research page. *We have an existing research page?* +**Slide 16:** A couple weeks ago, our team was talking through some of what we'll discuss later in the call: where to collect research artifacts and how to organize older research reports. In general, how we can better work to document ongoing and existing research. And one of our team members suggested that we might use our existing research page. _We have an existing research page?_ -**Slide 17:** Oh. It can be somewhat embarrassing to realize just what you don't know about what you do, and there are some parts of our website that I don't know as well as others. I don't know why this had escaped my attention for so long — and points to the value of the content audit that we're also working to finish in our roadmap — but taking a look through our research page was like looking into a time capsule, back into the earliest days of the design system, before I was a part of it. +**Slide 17:** Oh. It can be somewhat embarrassing to realize just what you don't know about what you do, and there are some parts of our website that I don't know as well as others. I don't know why this had escaped my attention for so long — and points to the value of the content audit that we're also working to finish in our roadmap — but taking a look through our research page was like looking into a time capsule, back into the earliest days of the design system, before I was a part of it. Like a fly preserved in amber, this research page gave an unusual look back at the past, and it shows how we've been thinking about research from the start, what progress we've made and what challenges we still face. @@ -121,7 +121,7 @@ And lately, before we released our last batch of components, we performed user a And then afterwards, we rely on open source community feedback to drive further changes. When you notice bugs or usability issues, you tell us — either though issues, discussions, or emails, and we're able to make the necessary changes and push them out into new releases. -**Slide 23:** But the reality is that we still need to be more proactive. This research is great, but we don't think it's enough. +**Slide 23:** But the reality is that we still need to be more proactive. This research is great, but we don't think it's enough. **Slide 24:** For one, our research is only getting older. While some findings can be evergreen and some guidance will be as well, people change, the web changes, and expectations change. We need to keep checking in, and we need to be ahead of changes in behavior and expectation. We need to better know where there's usability friction as early as possible. @@ -129,7 +129,7 @@ And then afterwards, we rely on open source community feedback to drive further **Slide 26:** And this is why, as we spoke about a couple months ago, it's on our roadmap to conduct inclusive research, and to work to operationalize it in our program and on our team. -**Slide 27:** And this is why we also see the necessity of conducting inclusive research called out in the new OMB policy guidance, M-23-22, delivering a digital-first public experience. This is a good idea, and it's also what we all need to be doing. +**Slide 27:** And this is why we also see the necessity of conducting inclusive research called out in the new OMB policy guidance, M-23-22, delivering a digital-first public experience. This is a good idea, and it's also what we all need to be doing. **Slide 28:** So how do we conduct inclusive research? And how can we do it again and again? @@ -153,7 +153,7 @@ PRA and Privacy **Slide 36:** Common challenges teams face -**Slide 37:** We needed help getting over the finish line +**Slide 37:** We needed help getting over the finish line **Slide 38:** We needed help developing repeatable processes @@ -202,7 +202,7 @@ And we're really intent on sharing what we've learned within our 10x program's e **Slide 57:** Ultimately what we want to do is support the people who use what we build. We want to support the public. And so we really feel like the public - and in particular, around accessibility - the sole arbiters of accessibility and usability are people that use assistive technologies or that have needs that we may not be bringing to bear in our work directly. So Jacline's going to talk a little bit more about how the US Web Design System team is helping that to take shape in their research efforts. Thank you. -**Slide 58:** Jacline: Hi everyone. This is Jacline Contrino, she/her. I am a white woman with brown wavy shoulder length hair wearing a black blouse. I’m the UX Researcher and contractor on the core USWDS team. In this next section, let’s talk about our most recent round of usability testing with participants with disabilities. How did we approach it, what’d we do, and what did we learn? +**Slide 58:** Jacline: Hi everyone. This is Jacline Contrino, she/her. I am a white woman with brown wavy shoulder length hair wearing a black blouse. I’m the UX Researcher and contractor on the core USWDS team. In this next section, let’s talk about our most recent round of usability testing with participants with disabilities. How did we approach it, what’d we do, and what did we learn? **Slide 59:** First, some quick background: Not only were we wanting to test drive the PROCESS of HOW we operationalize usability research, we also wanted to assess how a few of our components perform for people with visual impairments who use assistive technology. But how did we decide which components to test? @@ -220,7 +220,7 @@ And we're really intent on sharing what we've learned within our 10x program's e **Slide 66:** Finally, I wanted to mention that we compensated participants $100 for their time through virtual gift cards emailed to them. We obtained approval to do this through the GSA micropurchase program, which took a couple of months from application to final approval. -**Slide 67:** Ok, so what did we learn? How did the components we were testing perform? Let’s dive into the findings. +**Slide 67:** Ok, so what did we learn? How did the components we were testing perform? Let’s dive into the findings. **Slide 68:** So, this slide is showing that the most friction experienced by participants centered around about 4 components tested, including combobox, date picker, input mask, and validation. 2 other components tested fairly well with only minor friction, including character count and file input. And 2 components performed well with virtually no friction - those include the accordion and step indicator. And even though we weren’t testing the banner component or links being styled as buttons, we still received feedback from users about them. We need more research for those - more on that later. @@ -230,7 +230,7 @@ Ok, so let’s dig into the details! **Slide 69:** Starting with the components where we saw the most friction for participants. -**Slide 70:** Let’s begin with what we found with the input mask component. We found that the current input mask component does not give proper feedback when disallowed characters are typed. So basically, if a user types a letter where only numbers are allowed, there is no clear indication that anything is wrong. Furthermore, it is unclear whether the character was typed at all for someone using a screen reader. Let’s take a look at what I mean. +**Slide 70:** Let’s begin with what we found with the input mask component. We found that the current input mask component does not give proper feedback when disallowed characters are typed. So basically, if a user types a letter where only numbers are allowed, there is no clear indication that anything is wrong. Furthermore, it is unclear whether the character was typed at all for someone using a screen reader. Let’s take a look at what I mean. **Slide 71:** I’m going to play a short video clip to demonstrate what we saw with input mask. @@ -238,9 +238,9 @@ Ok, so let’s dig into the details! So, we could see there that folks felt unsure of whether the characters they typed were being accepted or not, and it just wasn’t giving them any error communication. We already knew about this feedback issue, so this testing was validation that it is something to improve in the near future. -**Slide 72:** Let’s move on to discuss findings for date picker. We saw that all screen reader users that we tested with (3…we ran out of time with 1) had difficulty using the date picker. First, the keyboard controls did not work as expected. They could only use up and down arrows, not left or right or page up or down. +**Slide 72:** Let’s move on to discuss findings for date picker. We saw that all screen reader users that we tested with (3…we ran out of time with 1) had difficulty using the date picker. First, the keyboard controls did not work as expected. They could only use up and down arrows, not left or right or page up or down. -We also learned that there were some issues around formatting and feedback. For example, users weren’t sure if the slashes would be entered for them or if they had to type them. And actually, we also discovered that it’d be beneficial for the slashes to be automatically entered for them. One person had a lot of difficulty typing the slashes and kept making mistakes, leaving him pretty frustrated. +We also learned that there were some issues around formatting and feedback. For example, users weren’t sure if the slashes would be entered for them or if they had to type them. And actually, we also discovered that it’d be beneficial for the slashes to be automatically entered for them. One person had a lot of difficulty typing the slashes and kept making mistakes, leaving him pretty frustrated. Finally, when manually entering dates, if users enter a disallowed format, there was no feedback given. For example, typing 10/1/2023 instead of the acceptable format of 10/01/2023 would not give any error message to the user. @@ -258,15 +258,15 @@ A positive note about combobox is that one person really appreciated that it giv **Slide 78:** So, we tested file input and for the most part, this component is usable to folks. We did see some indication that it could be beneficial to offer some kind of instruction on how to choose a file, since some participants struggled with actually choosing and uploading the file . And one user thought it was confusing to have the ‘drag file here or choose from folder’ contained together within one element (a button), when it might make more sense to separate them into their own elements. -**Slide 79:** Ok, let’s talk about character count. Overall, it was very well received from participants. They liked how the component offered delayed feedback, which was an enhancement since the last testing round. Before, it would announce how many characters were left immediately after users type a character which was a bit jarring. We implemented a delay so the screen reader announces how many characters are left after a short pause in typing. Participants liked this feature. One participant commented: +**Slide 79:** Ok, let’s talk about character count. Overall, it was very well received from participants. They liked how the component offered delayed feedback, which was an enhancement since the last testing round. Before, it would announce how many characters were left immediately after users type a character which was a bit jarring. We implemented a delay so the screen reader announces how many characters are left after a short pause in typing. Participants liked this feature. One participant commented: -“Oh, it worked really well. It was…giving me updates. It wasn't like being overzealous with it and trying to tell me how many characters there were every single time I typed a character like it was waiting until it was done. I think that works pretty well.” +“Oh, it worked really well. It was…giving me updates. It wasn't like being overzealous with it and trying to tell me how many characters there were every single time I typed a character like it was waiting until it was done. I think that works pretty well.” They also liked how it let them know when they had gone over the character limit. -**Slide 80:** Interestingly, we also heard from participants that they prefer a hard cutoff when they reach the character count limit. In other words, they want to be prevented from typing once they reach the limit. They said it’s annoying to type a lot of text in a box, not being told you’ve gone over the limit until you stop typing. It’s especially annoying for fast typers. Having to go back and see where to edit and cut content is a pain, so they’d rather just be prevented from exceeding the limit in the first place. +**Slide 80:** Interestingly, we also heard from participants that they prefer a hard cutoff when they reach the character count limit. In other words, they want to be prevented from typing once they reach the limit. They said it’s annoying to type a lot of text in a box, not being told you’ve gone over the limit until you stop typing. It’s especially annoying for fast typers. Having to go back and see where to edit and cut content is a pain, so they’d rather just be prevented from exceeding the limit in the first place. -**Slide 81:** We also learned that users need more visual cues when they have reached the limit, such as outlining the box in red. This was feedback received from the person using only screen magnification. Let’s take a look at the brief video clip. +**Slide 81:** We also learned that users need more visual cues when they have reached the limit, such as outlining the box in red. This was feedback received from the person using only screen magnification. Let’s take a look at the brief video clip. video clip plays @@ -278,47 +278,47 @@ video clip plays **Slide 85:** A couple of things came up in the research that we want to dig into more with future research. Let’s talk briefly about that. -**Slide 86:** First, a major pain point for every participant using a screen reader had to do with the "Next Step" and "Sign in" buttons in our prototype. The problem was that since this was only a prototype and not a real form, we used links styled as buttons for these actions. +**Slide 86:** First, a major pain point for every participant using a screen reader had to do with the "Next Step" and "Sign in" buttons in our prototype. The problem was that since this was only a prototype and not a real form, we used links styled as buttons for these actions. We hadn't anticipated all the usability problems this would introduce for our participants, and it isn't something we'd ever do in a real form. It would be against our button guidance — and common sense — to use a link instead of a submit button to move from page to page in a real form with real data, but that was the case here. The result was that we observed participants really struggling to complete some interactions. -We saw all participants who use a screen reader having trouble finding and interacting with the sign-in link. They expect a ‘submit’ or ‘sign in’ button to be an actual button, so that's what they looked for. And often, screen reader users use keyboard shortcuts to navigate to certain elements (like “b” to find all the buttons). Since our fake button was coded as a link, they missed it. +We saw all participants who use a screen reader having trouble finding and interacting with the sign-in link. They expect a ‘submit’ or ‘sign in’ button to be an actual button, so that's what they looked for. And often, screen reader users use keyboard shortcuts to navigate to certain elements (like “b” to find all the buttons). Since our fake button was coded as a link, they missed it. Users of assistive technology are often far more aware of and sensitive to markup semantics than other users, so we are discussing links styled as buttons with our team and need to design some experiments for future usability research. **Slide 87:** Something else we want to research further has to do with the banner component. [explain image] We weren’t intentionally testing it, but it came up. 2 users were confused by the banner component. One user confused it for a header. She said: -“I was thinking it might be more menu options. Because usually any buttons that are collapsed at the top of the page like that are usually menu, navigation things.” +“I was thinking it might be more menu options. Because usually any buttons that are collapsed at the top of the page like that are usually menu, navigation things.” Another participant who has some vision commented that it was another example of something labeled as a button that wasn’t a button. She said it looks more like a drop down menu/combobox, or a link. -Dan: So, I just want to jump in here and say that we have overstuffed this meeting with too many potatoes in this bag and we're almost at the end of time. We've tried to answer a lot of questions in the chat that we have seen in the chat. We also have a lot of next steps we've done in response to this and a lot of stuff that's still to come but I guess we'll save this for the next monthly call and we can also talk about it in public Slack or otherwise. But there's a lot that's still to come and I apologize for not getting to it. +Dan: So, I just want to jump in here and say that we have overstuffed this meeting with too many potatoes in this bag and we're almost at the end of time. We've tried to answer a lot of questions in the chat that we have seen in the chat. We also have a lot of next steps we've done in response to this and a lot of stuff that's still to come but I guess we'll save this for the next monthly call and we can also talk about it in public Slack or otherwise. But there's a lot that's still to come and I apologize for not getting to it. But we learned a lot, we did a lot, we're doing a lot and we will be following up on this next month and with folks, anyone who reaches out directly. So I apologize for overloading this presentation and not getting to all the Q&A at the end but we'll return to this and be talking about it again next month. {{< /accordion >}} -One of our roadmap goals is to conduct more user research with people with disabilities — and to ensure we’re doing so regularly. +One of our roadmap goals is to conduct more user research with people with disabilities — and to ensure we’re doing so regularly. Over the last few months, we've made a lot of progress. This month we'll share our progress and report on findings from our first round of this research: conducting usability tests on [Design System components](https://designsystem.digital.gov/components/overview/) focused on users with visual impairments. We’ll discuss: -* How we're working with GSA’s [10x program](https://10x.gsa.gov/) to develop a sustainable, repeatable research process -* Steps to operationalize research with people with disabilities -* Our work to recruit users of assistive technology to participate in user research -* Our usability testing process -* Findings from our recent usability testing -* Where we go from here +- How we're working with GSA’s [10x program](https://10x.gsa.gov/) to develop a sustainable, repeatable research process +- Steps to operationalize research with people with disabilities +- Our work to recruit users of assistive technology to participate in user research +- Our usability testing process +- Findings from our recent usability testing +- Where we go from here **This event is best suited for:** Anyone who uses the U.S. Web Design System. This event will have an accessibility and usability focus. ## Speakers -* **Dan Williams** **—** Product Lead, USWDS -* **Anne Petersen** **—** Experience Design Lead, USWDS -* **Robert Jolly** **—** Product Manager and Accessibility Advocate, 10x -* **Jacline Contrino** **—** UX Researcher, USWDS +- **Dan Williams** **—** Product Lead, USWDS +- **Anne Petersen** **—** Experience Design Lead, USWDS +- **Robert Jolly** **—** Product Manager and Accessibility Advocate, 10x +- **Jacline Contrino** **—** UX Researcher, USWDS ## Related resources @@ -330,17 +330,17 @@ We’ll discuss: ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2023/11/2023-11-13-uswds-monthly-call-november-2023.md b/content/events/2023/11/2023-11-13-uswds-monthly-call-november-2023.md index 4020e9f381..c05fe0724c 100644 --- a/content/events/2023/11/2023-11-13-uswds-monthly-call-november-2023.md +++ b/content/events/2023/11/2023-11-13-uswds-monthly-call-november-2023.md @@ -6,7 +6,6 @@ summary: The USWDS team will continue sharing our progress to improve ongoing research, publishing results and addressing recent findings. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIsceupqj0pE-Dt8ojRN1yCeZHcM0jWgO8#/registration date: 2023-11-16 14:00:00 -0500 end_date: 2023-11-16 15:00:00 -0500 diff --git a/content/events/2024/01/2024-01-10-uswds-monthly-call-january-2024.md b/content/events/2024/01/2024-01-10-uswds-monthly-call-january-2024.md index 97714a1d08..e34b330fa9 100644 --- a/content/events/2024/01/2024-01-10-uswds-monthly-call-january-2024.md +++ b/content/events/2024/01/2024-01-10-uswds-monthly-call-january-2024.md @@ -5,7 +5,6 @@ kicker: USWDS summary: This month the Design System team will talk about the development and rollout of their new accessibility tests for components. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIsd-2upjwsHjfq2qWtf_LN9pVV8YV6SX8 date: 2024-01-18 14:00:00 -0500 end_date: 2024-01-18 15:00:00 -0500 @@ -53,38 +52,43 @@ We should also have some time for Q&A at the end of the hour. **Slide 8:** First, USWDS 3.8.0, featuring a focus on community PRs. We get a lot of good contributions from the community, and we're happy to publish a number of these contributions in this new release. **Slide 9:** Key improvements in USWDS 3.8.0 include: -* Adding support for sticky headers in tables. -* Better text wrapping and alignment in button groups (especially with longer button text). -* We're also improving icon alignment in buttons as well. -* We're giving teams more control over the headings included in in-page navigation, if you need to be more specific about which heading levels should be pulled into the in-page navigation. -* We're also adding contrast checking for disabled elements. Technically disabled or inactive elements don't have the same contrast requirements as active elements, but teams increasingly want to deliver designs that go beyond the requirements, and this release will help teams understand any potential low-contrast elements. -* And finally, indeterminate checkboxes. It turns out there can be three potential states for a checkbox: checked, unchecked, and indeterminate, for when, in a multi-level checklist, a parent checkbox contains child checkboxes in both checked and unchecked states. It's a bit of a complex case, but a real one, and we're happy to be able to support it. + +- Adding support for sticky headers in tables. +- Better text wrapping and alignment in button groups (especially with longer button text). +- We're also improving icon alignment in buttons as well. +- We're giving teams more control over the headings included in in-page navigation, if you need to be more specific about which heading levels should be pulled into the in-page navigation. +- We're also adding contrast checking for disabled elements. Technically disabled or inactive elements don't have the same contrast requirements as active elements, but teams increasingly want to deliver designs that go beyond the requirements, and this release will help teams understand any potential low-contrast elements. +- And finally, indeterminate checkboxes. It turns out there can be three potential states for a checkbox: checked, unchecked, and indeterminate, for when, in a multi-level checklist, a parent checkbox contains child checkboxes in both checked and unchecked states. It's a bit of a complex case, but a real one, and we're happy to be able to support it. **Slide 10:** Those features, and others, make up USWDS 3.8.0, coming soon: by the end of the month. **Slide 11:** Next, I wanted to take a couple minutes to give an update on the items in our development roadmap. Currently we're on a planning cadence where we update our roadmap and schedule once a quarter, and we just finished planning for this quarter. Going forward, we expect to give these roadmap updates every three months. **Slide 12:** So, first up, web components. We expect to deliver a mature beta of USWDS web components by this fall, October 2024. Upcoming milestones include: -* This month we're planning for a web components working group: identifying folks who can actively help us through this process, and also planning for sequencing and scheduling. -* In February, we'll finish a requirements draft for Web Components. -* In March, we'll have an alpha of a couple core components, most likely banner and identifier. -* By June, we'll get to form components, with the goal of a mature web components beta by October of this year. + +- This month we're planning for a web components working group: identifying folks who can actively help us through this process, and also planning for sequencing and scheduling. +- In February, we'll finish a requirements draft for Web Components. +- In March, we'll have an alpha of a couple core components, most likely banner and identifier. +- By June, we'll get to form components, with the goal of a mature web components beta by October of this year. **Slide 13:** Relatedly, JSON tokens: This is moving our tokens data from Sass into the more portable JSON data format. This is related to web components and shares a similar milestone: a mature beta in October. -* This month, we're finishing a landscape analysis of how tokens are stored and used in other design systems, and finalizing a data structure for the JSON. -* By April, we hope to use some of these new tokens internally and power our site with them. -* By May, we'll complete theme and state tokens and be ready to demo color tokens + +- This month, we're finishing a landscape analysis of how tokens are stored and used in other design systems, and finalizing a data structure for the JSON. +- By April, we hope to use some of these new tokens internally and power our site with them. +- By May, we'll complete theme and state tokens and be ready to demo color tokens Together with web components, this begins to define the shape of a new major version of the design system, one that's tested with a long-term beta to make sure we're getting things right. Right now we think that a new major version could be on track for Spring 2025, but that's a bit too far in the future to really know for sure. **Slide 14:** Now for a few things that are shorter term: starting with publishing a component lifecycle model — describing how we develop components, how they’re proposed, and how they mature. We'll talk a lot more about this next month! -* This month we're thinking about a proposal status page prototype and clarifying roles and responsibilities throughout the lifecycle. -* Next month we'll be codifying our software lifecycle definitions, establishing a GitHub repo for component proposals, and presenting our work at a monthly call. -* By March, all this documentation should be up on our site! + +- This month we're thinking about a proposal status page prototype and clarifying roles and responsibilities throughout the lifecycle. +- Next month we'll be codifying our software lifecycle definitions, establishing a GitHub repo for component proposals, and presenting our work at a monthly call. +- By March, all this documentation should be up on our site! **Slide 15:** We're also working to operationalize usability research, specifically component and pattern usability research with people with disabilities. -* This month we're finishing a research plan for our second round of research (called "Zebra" in our GitHub issues) and publishing a recruitment page. -* In February we'll perform this research, in March, we'll document the findings, and by April we should be planning for Round 3 with a repeatable process to get us through Rounds 4, 5, and beyond. + +- This month we're finishing a research plan for our second round of research (called "Zebra" in our GitHub issues) and publishing a recruitment page. +- In February we'll perform this research, in March, we'll document the findings, and by April we should be planning for Round 3 with a repeatable process to get us through Rounds 4, 5, and beyond. **Slide 16:** We're working to finish up tasks related to a website content audit. By next month we should have the page-level analysis complete, and have a set of success metrics for key pages. We'll finish this roadmap item up in March by documenting a repeatable process for managing and evaluating our content. @@ -98,9 +102,9 @@ Next month we'll be finalizing these guidance updates. In April, we'll finish ou **Slide 19:** And finally, critical checklists. We’ve been talking about this since last summer. As of today in January, we’re publishing our first tests. And now we're on a roll! -* We'll do the next round of usability testing in March, all the while continuing on the first pass of testing, and finally documentation, which we should complete in July. -* Each month we'll also be doing a second round of testing as well, and publishing new component checklists as we finish this work. -* By August this should all be complete! +- We'll do the next round of usability testing in March, all the while continuing on the first pass of testing, and finally documentation, which we should complete in July. +- Each month we'll also be doing a second round of testing as well, and publishing new component checklists as we finish this work. +- By August this should all be complete! **Slide 20:** As you can see, there's a lot on our plate right now! And you can check out the full roadmap over at GitHub at [github.com/orgs/uswds/projects/8/views/31](http://github.com/orgs/uswds/projects/8/views/31). And you don't have to write that down, we're pasting it into the chat. @@ -122,7 +126,7 @@ Next month we'll be finalizing these guidance updates. In April, we'll finish ou **Slide 29:** So we've renamed Critical Checklists to Accessibility Tests. -**Slide 30:** So here we go! Let's take a look at one of the three component accessibility test pages we published today, Accordion, at [designsystem.digital.gov/components/accordion](http://designsystem.digital.gov/components/accordion). One of the first things you'll notice is that every component that has an accessibility tests page, now has an accessibility status badge. This is up at the top of the page, and this accordion badge reads "Passed WCAG 2.1 AA". The side navigation on this page also includes a link to "Accordion accessibility tests". +**Slide 30:** So here we go! Let's take a look at one of the three component accessibility test pages we published today, Accordion, at [designsystem.digital.gov/components/accordion](http://designsystem.digital.gov/components/accordion). One of the first things you'll notice is that every component that has an accessibility tests page, now has an accessibility status badge. This is up at the top of the page, and this accordion badge reads "Passed WCAG 2.1 AA". The side navigation on this page also includes a link to "Accordion accessibility tests". **Slide 31:** Further down the page, in the accessibility section, you'll find a callout to test the accordion in your own project, and a call-to-action link to "Use accordion accessibility tests". We're trying to stress here and on the accessibility tests page as well, that it's also important to perform these tests on your own site, since any implementation will necessarily be different from the environment in which we perform our tests. @@ -156,7 +160,7 @@ If there were a fail state, we'd note it similarly on that page and link to the **Slide 40:** So before I pass it to my colleagues to dig into how we got here, let's check back in on our goals. First and foremost, we're interested in making accessibility more accessible to anyone working on the web. If you're working on a project, you can be a part of its accessibility. -**Slide 41:** Next, we're interested in establishing a baseline for change. As the design system grows and changes, we want to make sure that we establish a continuity of accessible functionality-that-teams-can-trust and that we can check from release to release. +**Slide 41:** Next, we're interested in establishing a baseline for change. As the design system grows and changes, we want to make sure that we establish a continuity of accessible functionality-that-teams-can-trust and that we can check from release to release. **Slide 42:** And finally, this can be another great example of using the design system to scale expertise: It takes a fair amount of time to develop these tests and understand what to look for. To write in plain language. To make things simpler. It can be pretty complicated to make something simple! We're trying to do a lot of that hard work, so we can deliver not only accessible components, but a way to manually test components that takes minutes instead of hours or days. It took us hours and days so that it can take you only minutes! That's the hope at least. @@ -204,7 +208,7 @@ Dan: Thanks Anne **Slide 57:** As I mentioned earlier, we realize that we are testing these components in isolation; but you won’t be. You might need to piece together multiple checks per page or perform a more comprehensive page-level test. In the future we hope to bring you guidance on how to do those tests, too. For now, we recommend you use these checks as prompts to begin a conversation or bring awareness to accessibility at a fundamental level. Anyone new to accessibility should feel welcome to try using the checks themselves. We hope they help reduce any reservations you might feel about testing web accessibility and expand your knowledge of the testing process. -**Slide 58:** We want you to feel comfortable sharing suggestions and feedback on these checks. They, along with everything we do, are a work in progress, and we want to invite you to contribute to the accessibility of the design system. If you feel a check could be worded better, or if we overlooked something or you just want to give us feedback, there are buttons for submitting an issue or suggesting a check on each page. We can’t claim to have thought of everything, but that’s where you come in! In the future we hope to expand these pages to include color contrast, design and other manual checks. This will help us ensure all audiences have equal access to our work. And speaking of audiences, it’s important that you use these checks in conjunction with usability testing. Something that doesn’t technically pass a check might actually work better for your particular audience. It’s important to know that distinction and include your audience in your process. And speaking of testing, I’m going to hand it off to Jacline to talk about how we tested prototypes of our new accessibility test pages. +**Slide 58:** We want you to feel comfortable sharing suggestions and feedback on these checks. They, along with everything we do, are a work in progress, and we want to invite you to contribute to the accessibility of the design system. If you feel a check could be worded better, or if we overlooked something or you just want to give us feedback, there are buttons for submitting an issue or suggesting a check on each page. We can’t claim to have thought of everything, but that’s where you come in! In the future we hope to expand these pages to include color contrast, design and other manual checks. This will help us ensure all audiences have equal access to our work. And speaking of audiences, it’s important that you use these checks in conjunction with usability testing. Something that doesn’t technically pass a check might actually work better for your particular audience. It’s important to know that distinction and include your audience in your process. And speaking of testing, I’m going to hand it off to Jacline to talk about how we tested prototypes of our new accessibility test pages. **Slide 59:** Jacline: Thanks Amy - hi everyone, this is Jacline again. It’s important to us that WHAT we build is useful and usable to you, the USWDS community. So, before launching this page, we tested it with some of you. I’m going to talk a little bit about what we did, what we learned, and how it influenced the design of our new component Accessibility Tests pages. @@ -219,10 +223,11 @@ And now, we just launched these new pages and we plan to test them again in Marc **Slide 61:** Our main goals for testing the prototype were to gauge first impressions, discover what’s confusing, get a sense of how the structure and presentation of information was working for people, and just generally discover what improvements need to be made before launch. Some specific research questions we were trying to answer were: -* Is the purpose of the page clear? Do they know what it can help them do? -* Is it useful and usable to someone who’s not an accessibility expert? -* Is the page where they expect to find it? -* What page title makes the most sense to users? + +- Is the purpose of the page clear? Do they know what it can help them do? +- Is it useful and usable to someone who’s not an accessibility expert? +- Is the page where they expect to find it? +- What page title makes the most sense to users? Getting more insights into these areas would help us gauge if we are on the right track with our design choices and decide what changes to make. @@ -292,7 +297,7 @@ All that to say: if you’re not doing manual accessibility testing alongside au Much like with our recent usability testing with people with visual disabilities from our last call in November, and this round of testing on these new pages, ensuring you’re informed means talking it about it here, but also means publishing our research, getting that connected logically on our website, and continuing to talk with you, our community, as we keep making our process more understandable and showing the progress we’ve made, which then supports your decision-making on when and how to use USWDS components. -**Slide 83:** *And* showing we rarely start where we end up. We improve things in small cycles along the way. +**Slide 83:** _And_ showing we rarely start where we end up. We improve things in small cycles along the way. Iterating — that is, learning and changing as we go, continuously — is key to our work. Amy talked about it in the audit, when we changed how we were explaining those tests. Jacline talked about it in our usability testing of these pages, when we changed those tests to include exploration of the page title, as well as changing the design of the prototype, to gather feedback on both. @@ -322,33 +327,33 @@ Join the U.S. Web Design System (USWDS) team as they continue to highlight acces In this session, you will learn: -* How the Design System team documents their accessibility testing -* The new checklists to conduct your own accessibility testing -* Our schedule for publishing additional component accessibility tests -* Locating known issues for some Design System components +- How the Design System team documents their accessibility testing +- The new checklists to conduct your own accessibility testing +- Our schedule for publishing additional component accessibility tests +- Locating known issues for some Design System components **This event is best suited for:** Designers, accessibility specialists, developers, and content managers (all levels) ## Speakers -* **Dan Williams** **—** Product Lead, USWDS -* **Anne Petersen** **—** Experience Design Lead, USWDS -* **Amy Cole** **—** Accessibility Specialist, USWDS Contractor -* **Jacline Contrino** **—** UX Researcher, USWDS Contractor +- **Dan Williams** **—** Product Lead, USWDS +- **Anne Petersen** **—** Experience Design Lead, USWDS +- **Amy Cole** **—** Accessibility Specialist, USWDS Contractor +- **Jacline Contrino** **—** UX Researcher, USWDS Contractor ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2024/02/2024-02-07-uswds-monthly-call-february-2024.md b/content/events/2024/02/2024-02-07-uswds-monthly-call-february-2024.md index 078f0cd834..5828f76d6c 100644 --- a/content/events/2024/02/2024-02-07-uswds-monthly-call-february-2024.md +++ b/content/events/2024/02/2024-02-07-uswds-monthly-call-february-2024.md @@ -6,7 +6,6 @@ summary: Learn about the USWDS component lifecycle, and how you can suggest a new component. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIsceyvpz4iGws79NmQy1Dj0BUoDVtPKzs#/registration date: 2024-02-15 14:00:00 -0500 end_date: 2024-02-15 15:00:00 -0500 @@ -47,11 +46,11 @@ We’ve got a couple nice new site and feature launches, a couple product update **Slide 4:** Let's get into it with site launches. -**Slide 5:** First, [simpler.grants.gov](https://www.google.com/url?q=https://simpler.grants.gov&sa=D&source=docs&ust=1711052748736300&usg=AOvVaw2YSQ8xGM91WUdioPsTCZMY), an exciting new initiative from the grants.gov team at the Department of Health and Human Services. +**Slide 5:** First, [simpler.grants.gov](https://www.google.com/url?q=https://simpler.grants.gov&sa=D&source=docs&ust=1711052748736300&usg=AOvVaw2YSQ8xGM91WUdioPsTCZMY), an exciting new initiative from the grants.gov team at the Department of Health and Human Services. Grants.gov provides a centralized location for grant seekers to find and apply for federal funding opportunities. Simpler.grants.gov is a new site from the grants.gov team that's using a transparent, iterative, and agile process to document their progress modernizing and improving the grants.gov service. It's an exciting project where they'll be building software out in the open, and I for one, am pretty interested in their approach and their progress! The simpler.grants.gov homepage features a simple, text-focused layout, with a large blue hero field and the words "We're building a simpler Grants.gov!" -**Slide 6:** Next, [Search.gov](https://www.google.com/url?q=https://search.gov&sa=D&source=docs&ust=1711052748730824&usg=AOvVaw3N-xMZKFbY9VHxVGWKAjS-) is starting to roll out hosted search results pages powered by USWDS code. +**Slide 6:** Next, [Search.gov](https://www.google.com/url?q=https://search.gov&sa=D&source=docs&ust=1711052748730824&usg=AOvVaw3N-xMZKFbY9VHxVGWKAjS-) is starting to roll out hosted search results pages powered by USWDS code. You know search.gov, right? It's the search engine by and for the federal government, a free service powering search results on over 2,000 websites. Earlier this year they released a beta of a USWDS-based redesign of their hosted results page. Now Digital.gov is the first site to be able to use it, hosting a USWDS-powered search result layout! Search.gov and DigitalGov — a real chocolate and peanut butter combination in my book. @@ -89,7 +88,7 @@ Well, a component lifecycle is not just for devs and pedants. Today we'd like to **Slide 20:** You know, I hate to be the person to tell you this, but our government is big. -And collectively, in the aggregate, we know a lot. There's incredible skill, talent, sensitivity, craftsmanship, and care across our teams, our agencies, and our products. +And collectively, in the aggregate, we know a lot. There's incredible skill, talent, sensitivity, craftsmanship, and care across our teams, our agencies, and our products. If you take a long view of what we, together, are building, I believe it's inarguable that government digital services are improving — and I would argue further that government digital services are improving faster than the internet as a whole. If government is the tortoise in the race between the tortoise and the hare, I'd say the tortoise has the momentum these days. @@ -97,14 +96,13 @@ If government is the tortoise in the race between the tortoise and the hare, I'd **Slide 21:** And I'd say _that's_ because of a real mission-driven commitment to human centered design and to our inclination to pitch in, to help out, to share what we know with each other, and keep pushing forward. Because for sure, while momentum may be on our side, there's a long way to go, and honestly there's never really a finish line. - **Slide 22:** It's long been our challenge here at USWDS to facilitate collaboration and contribution, to share and scale effective solutions from anywhere in government. To convert the skill and experience that we clearly have in the aggregate into a common infrastructure that supports and elevates any team and product. And that's been a tough nut to crack. **Slide 23:** Today we're going to get started on this challenge through the angle of splitting bigger problems into smaller problems, and trying to build a framework for solving complex problems — and building complex solutions — a little at a time. Lowering the barriers to participation in the service of delivering high quality finished work. We're going to approach this from two angles: one which you might call the food truck scenario, and the other which you might call finding the elephant. Or, _you_ might not yet call it that, yet, but _I_ am! -**Slide 24:** First, the food truck scenario — or simply that it is hard to start something really big like a restaurant. It's complicated, expensive, and can take a huge amount of resources and risk to even consider building an operation like that. It really limits who can participate. +**Slide 24:** First, the food truck scenario — or simply that it is hard to start something really big like a restaurant. It's complicated, expensive, and can take a huge amount of resources and risk to even consider building an operation like that. It really limits who can participate. I live in Portland, and one solution to this problem that's popular here and now pretty much is popular everywhere else as well, is the food truck. What if you could begin to reduce the resources and risk to participate? What if you could prove an idea at a smaller scale? Or like a pop-up restaurant that exists for only a week, using an existing restaurant and kitchen. All these smaller-scale solutions to the problem of the restaurant — of getting food — still need to be safe, they still need to be up to code, and they still need to _deliver_ good food. @@ -141,13 +139,13 @@ The overall shape is a bit like the rising and falling shape we see on the slide **Slide 34:** These main phases in our component lifecycle may seem familiar to you. They are: -* **Proposal:** These components are under consideration for development through public discussion and a formal proposal. This part of the shape is now colored gold. +- **Proposal:** These components are under consideration for development through public discussion and a formal proposal. This part of the shape is now colored gold. -* **Development:** These are the components undergoing active design, development, testing, and documentation before public release. This part of the shape is now colored blue. +- **Development:** These are the components undergoing active design, development, testing, and documentation before public release. This part of the shape is now colored blue. -* **Released:** These are the components we've released to the public in our distribution package and documented on the USWDS website. This part of the shape is now colored green. +- **Released:** These are the components we've released to the public in our distribution package and documented on the USWDS website. This part of the shape is now colored green. -* **Deprecated:** These are the components that do not meet requirements or are no longer needed. This part of the shape is now colored pink. +- **Deprecated:** These are the components that do not meet requirements or are no longer needed. This part of the shape is now colored pink. **Slide 35:** But what's perhaps less familiar are the sub-phases (or steps) within these larger lifecycle groupings. We're putting a lot of work into establishing smaller steps with clearer transitions between steps. @@ -157,17 +155,17 @@ Establishing sub-phase steps allows us to know precisely what is happening — a The Experimental step of the Released phase — now colored in darker green in our diagram — is a bit of a pilot. To Dan's earlier point, we're considering Experimental to be something of the food truck to the brick-and-mortar of stable USWDS components. We're hoping we can use an Experimental step to release promising components earlier to help collect more real-world usability research. These components might have fewer documentation requirements, less research backup, maybe a few unanswered questions — along with the expectation that they might change more than stable components. But they would include accessibility tests and would be OK to use in production websites. -Today, we've published an overview of all of these phases and steps on our new component lifecycle page on our website. Let’s take a look. +Today, we've published an overview of all of these phases and steps on our new component lifecycle page on our website. Let’s take a look. **Slide 37:** Our new component lifecycle page gives an overview of each phase and step of the component lifecycle. This page covers: - * What happens in each step, - - * When each step starts and ends, - - * How you can contribute during each step, - - * Where you can find the components that are in each step. +- What happens in each step, + +- When each step starts and ends, + +- How you can contribute during each step, + +- Where you can find the components that are in each step. You can find this new page at [designsystem.digital.gov/components/lifecycle](https://designsystem.digital.gov/components/lifecycle). And now, since every component — from idea and proposal to stable and deprecation — is in one of the steps of the life cycle, we've also been able to build a new component status page to help you know what's happening with both components we've released in the design system and components that aren't in the design system yet. @@ -262,19 +260,19 @@ But really, the discussions are where the action will be. So let’s take a look This discussion board has a lot of the tools folks expect for managing discussions: - * There are threaded comments to help organize different topics of conversation. - - * There are simple ways to sort and filter discussions, and labeling as well. - - * And discussions also offer native upvoting functionality, which gives everyone an easy method for expressing interest in a component, and gives the USWDS team an easy - method of assessing that interest. +- There are threaded comments to help organize different topics of conversation. + +- There are simple ways to sort and filter discussions, and labeling as well. + +- And discussions also offer native upvoting functionality, which gives everyone an easy method for expressing interest in a component, and gives the USWDS team an easy + method of assessing that interest. **Slide 62:** What do you need to know to start a discussion? Really, just two things: - * Are you interested in suggesting a new component? - - * And, is there already an existing discussion about that new component? - +- Are you interested in suggesting a new component? + +- And, is there already an existing discussion about that new component? + If you are, and there isn't, go ahead and start a new discussion! **Slide 63:** Discussions are meant to be **incremental**. You can start with a lot or a little. The person who authors the discussion doesn't need to know everything. We'll work it all out together eventually. @@ -297,53 +295,53 @@ We've been converting existing component-request issues into discussions, and th **Slide 67:** First, we want to address some general information about the proposed component: - * What's the common name (or names) of this component? - - * What gap does it fill in the design system? And how is this different from existing USWDS components? - - * And does this component directly support any federal laws, guidance, or policies? - +- What's the common name (or names) of this component? + +- What gap does it fill in the design system? And how is this different from existing USWDS components? + +- And does this component directly support any federal laws, guidance, or policies? + **Slide 68:** As well as potential design ideas and context: - * What's the potential core functionality of this component? - - * Are there any examples of how the component might work? +- What's the potential core functionality of this component? + +- Are there any examples of how the component might work? **Slide 69:** We'll want to address what this component is _used_ for. We want to outline the appropriate use cases: - * What common interactions does this component support? +- What common interactions does this component support? + +- What does this component need to do to be successful and effective? - * What does this component need to do to be successful and effective? - - * What kind of content — that is, information inside it — would be ideal for this component? +- What kind of content — that is, information inside it — would be ideal for this component? **Slide 70:** And also scenarios where this component would _not_ be the appropriate choice: - * Are there common ways this type of component is misused? - - * Are there similar interactions that would be better supported by other components? - - * What kind of content should teams not use with this component? +- Are there common ways this type of component is misused? + +- Are there similar interactions that would be better supported by other components? + +- What kind of content should teams not use with this component? **Slide 71:** We also want to understand any usability considerations, with supporting evidence if possible. From a usability or UX perspective, we want to understand: - * What are the characteristics of a successful interaction with this component? How does that interaction go? - - * What would make this component less usable? - - * What are common pitfalls or implementation mistakes associated with this component? - - * How might the mobile context affect how folks use this component? +- What are the characteristics of a successful interaction with this component? How does that interaction go? + +- What would make this component less usable? + +- What are common pitfalls or implementation mistakes associated with this component? + +- How might the mobile context affect how folks use this component? **Slide 72:** From the accessibility perspective we want to understand: - * Will this component cause difficulty for people who use any assistive technologies? - - * And could this component be difficult for any other audiences? +- Will this component cause difficulty for people who use any assistive technologies? + +- And could this component be difficult for any other audiences? **Slide 73:** And finally, we want to identify potential stakeholders, advocates, and volunteers related to the component. These are folks willing to help design, develop, or test the component, and any significant support from an agency or group. @@ -368,7 +366,7 @@ And I'd like to acknowledge that getting this far has been a really big team eff This is important because this process stuff is what everything else is built from. I think what we're beginning to develop here is the nervous system for the design system, and perhaps, by extension, a nervous system for digital service practitioners across government — helping a complex system move with coordination and intention because we've connected activities and information from across the network. -**Slide 79:** We're still working to take baby steps, but this is really what it's all about when I think about the USWDS mission: Shaping the future of government digital services. This process of shaping is complex and interesting and can be really challenging and satisfying. And it's something we can only effectively do together. And I know if we keep at it, there's going to be an elephant in there… somewhere. +**Slide 79:** We're still working to take baby steps, but this is really what it's all about when I think about the USWDS mission: Shaping the future of government digital services. This process of shaping is complex and interesting and can be really challenging and satisfying. And it's something we can only effectively do together. And I know if we keep at it, there's going to be an elephant in there… somewhere. **Slide 80:** Q&A @@ -384,31 +382,31 @@ Join the U.S. Web Design System (USWDS) team to learn more about the complete li In this session, you will learn: -* How to suggest a new component -* What to expect throughout the proposal process -* What comes next in the component’s lifecycle +- How to suggest a new component +- What to expect throughout the proposal process +- What comes next in the component’s lifecycle **This event is best suited for:** Developers and designers (all levels) ## Speakers -* **Dan Williams** **—** Product Lead, USWDS -* **Anne Petersen** **—** Experience Design Lead, USWDS -* **Amy Leadem** **—** Developer, USWDS Contractor +- **Dan Williams** **—** Product Lead, USWDS +- **Anne Petersen** **—** Experience Design Lead, USWDS +- **Amy Leadem** **—** Developer, USWDS Contractor ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@support.digitalgov.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@support.digitalgov.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2024/03/2024-02-27-spring-2024-community-summit.md b/content/events/2024/03/2024-02-27-spring-2024-community-summit.md index babb6b08c4..da88742bb6 100644 --- a/content/events/2024/03/2024-02-27-spring-2024-community-summit.md +++ b/content/events/2024/03/2024-02-27-spring-2024-community-summit.md @@ -5,7 +5,6 @@ kicker: Annual Gathering summary: Digital service experts across the federal government will share case studies and best practices on delivering a digital-first public experience. event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/webinar/register/WN_fS46iSeTSG6ww_VNpzUPeQ @@ -40,24 +39,23 @@ end_date: 2024-03-13 16:00:00 -0500 event_platform: zoom primary_image: "spring-2024-community-title-card" - --- On March 13, 2024, the Digital.gov Spring Community Summit will bring together web and digital service practitioners to talk about the many facets of delivering a digital-first public experience. Federal Chief Information Officer, [Clare Martorana](https://www.cio.gov/about/members-and-leadership/martorana-clare/), will deliver the opening keynote. Join us for a day of inspiration and collaboration as leading voices across 16 U.S. federal government agencies share stories of innovation and excellence in every phase of the digital project journey. Topics include: -* Recruiting the right talent -* Uncovering impactful solutions -* Crafting quality content -* Navigating seamless acquisitions -* Figuring out what to do after launch +- Recruiting the right talent +- Uncovering impactful solutions +- Crafting quality content +- Navigating seamless acquisitions +- Figuring out what to do after launch This is your chance to: -* Uncover approaches to building accessibility into every step of the process. -* Gain practical insights from case studies and real-world experiences. -* Witness the forefront of thought leadership during panel discussions. +- Uncover approaches to building accessibility into every step of the process. +- Gain practical insights from case studies and real-world experiences. +- Witness the forefront of thought leadership during panel discussions. **This event is best suited for:** Anyone and everyone invested in advancing federal digital services. @@ -87,11 +85,11 @@ Hear from a panel of experts on making the case for building a digital team with **Speakers** -* **Jacquelyn Dolezal Morales** — Digital Communications Specialist, Inter-American Foundation (IAF) -* **Lindsay Goldstein** — Digital Services Specialist, Office of Natural Resources Revenue (ONRR), U.S. Department of the Interior (DOI) -* **Robert Jolly** — Product Manager, 10x, U.S. General Services Administration (GSA) -* **Vicki McFadden** — Product Manager, Service Delivery Team, GSA -* **Gregory Your** — Director of Website Management, U.S. Agency for International Development (USAID) +- **Jacquelyn Dolezal Morales** — Digital Communications Specialist, Inter-American Foundation (IAF) +- **Lindsay Goldstein** — Digital Services Specialist, Office of Natural Resources Revenue (ONRR), U.S. Department of the Interior (DOI) +- **Robert Jolly** — Product Manager, 10x, U.S. General Services Administration (GSA) +- **Vicki McFadden** — Product Manager, Service Delivery Team, GSA +- **Gregory Your** — Director of Website Management, U.S. Agency for International Development (USAID) @@ -113,11 +111,11 @@ In this session, a panel of experts will share insights, methods, and strategies **Speakers** -* **Kristen Lohman** — Design Strategist, Service Delivery Team, GSA -* **Beth A. Martin** — Digital Services Expert (UX Designer), U.S. Office of Personnel Management (OPM) -* **Mark Meyer** — Software Developer, Digital Service Team, GSA -* **Christopher Patten** — Human-Centered Designer, U.S. Department of Homeland Security (DHS) -* **Martha Wilkes** — Lead Accessibility Strategist, U.S. Department of Veterans Affairs (VA) +- **Kristen Lohman** — Design Strategist, Service Delivery Team, GSA +- **Beth A. Martin** — Digital Services Expert (UX Designer), U.S. Office of Personnel Management (OPM) +- **Mark Meyer** — Software Developer, Digital Service Team, GSA +- **Christopher Patten** — Human-Centered Designer, U.S. Department of Homeland Security (DHS) +- **Martha Wilkes** — Lead Accessibility Strategist, U.S. Department of Veterans Affairs (VA)
@@ -144,10 +142,10 @@ Join us for an engaging panel discussion on content strategy development, conten **Speakers** -* **Joe Galbo** — Social Media Specialist, U.S. Consumer Product Safety Commission (CPSC) -* **Sally Harris** — Managing Director, Digital Media and Creative Services, U.S. Department of Education (ED) -* **Ryan Johnson** — Content Strategist, Service Delivery Team, GSA -* **Rosamund Lannin** — Content Strategist, Service Delivery Team, GSA +- **Joe Galbo** — Social Media Specialist, U.S. Consumer Product Safety Commission (CPSC) +- **Sally Harris** — Managing Director, Digital Media and Creative Services, U.S. Department of Education (ED) +- **Ryan Johnson** — Content Strategist, Service Delivery Team, GSA +- **Rosamund Lannin** — Content Strategist, Service Delivery Team, GSA
@@ -167,11 +165,11 @@ In this panel discussion, you’ll learn the key factors that contribute to the **Speakers** -* **Anthony Burley** — IT Management, Court Services & Offender Supervision Agency for the District of Columbia (CSOSA) -* **Laura Larrimore** — Senior Digital Strategist, U.S. Department of State (DOS) -* **Andrew Nielson** — Director, Government-wide IT Accessibility Program, GSA -* **Ashley Owens** — Senior Digital Acquisition Strategist, Service Delivery Team, GSA -* **Justen Proctor** — Senior Contracting Officer, GSA +- **Anthony Burley** — IT Management, Court Services & Offender Supervision Agency for the District of Columbia (CSOSA) +- **Laura Larrimore** — Senior Digital Strategist, U.S. Department of State (DOS) +- **Andrew Nielson** — Director, Government-wide IT Accessibility Program, GSA +- **Ashley Owens** — Senior Digital Acquisition Strategist, Service Delivery Team, GSA +- **Justen Proctor** — Senior Contracting Officer, GSA
@@ -191,10 +189,10 @@ Don’t miss the opportunity to hear from a panel of experts on experiences in s **Speakers** -* **Tori Garten** — Chief of New Media and Web Policy Branch, National Institute of Allergy and Infectious Diseases (NIAID), National Institutes of Health (NIH), U.S. Department of Health and Human Services (HHS) -* **Michael Horton** — Accessible Design & Development Advisor, GSA -* **Gloria Huang** — Digital Engagement and Analytics Branch Chief, Federal Emergency Management Agency (FEMA), DHS -* **Jessica Marine** — Product Manager, Service Delivery Team & Digital Experience (DX) lead, GSA +- **Tori Garten** — Chief of New Media and Web Policy Branch, National Institute of Allergy and Infectious Diseases (NIAID), National Institutes of Health (NIH), U.S. Department of Health and Human Services (HHS) +- **Michael Horton** — Accessible Design & Development Advisor, GSA +- **Gloria Huang** — Digital Engagement and Analytics Branch Chief, Federal Emergency Management Agency (FEMA), DHS +- **Jessica Marine** — Product Manager, Service Delivery Team & Digital Experience (DX) lead, GSA
@@ -220,12 +218,12 @@ Closing remarks with Ann Lewis, Director, Technology Transformation Services (TT ## Resources -* [Digital service delivery](https://digital.gov/topics/digital-service-delivery/) -* [Requirements for delivering a digital-first public experience](https://digital.gov/resources/delivering-digital-first-public-experience/) -* [Timeless top 10 best practices for great government websites](https://digital.gov/2024/02/09/timeless-top-10-best-practices-for-great-government-websites/) -* [Sunrise to sunset: Building a customer-centric digital ecosystem](https://digital.gov/2022/10/14/sunrise-to-sunset-building-a-customer-centric-digital-ecosystem/) -* [Taking a design-led approach to digital modernization](https://digital.gov/2022/10/07/taking-a-design-led-approach-to-digital-modernization/) +- [Digital service delivery](https://digital.gov/topics/digital-service-delivery/) +- [Requirements for delivering a digital-first public experience](https://digital.gov/resources/delivering-digital-first-public-experience/) +- [Timeless top 10 best practices for great government websites](https://digital.gov/2024/02/09/timeless-top-10-best-practices-for-great-government-websites/) +- [Sunrise to sunset: Building a customer-centric digital ecosystem](https://digital.gov/2022/10/14/sunrise-to-sunset-building-a-customer-centric-digital-ecosystem/) +- [Taking a design-led approach to digital modernization](https://digital.gov/2022/10/07/taking-a-design-led-approach-to-digital-modernization/) -- - - +--- Collaborate and share resources with other communities across government who are focused on building better digital experience in government. [Join a Digital.gov Community of Practice](https://digital.gov/communities/). diff --git a/content/events/2024/03/2024-03-21-uswds-monthly-call-march-2024.md b/content/events/2024/03/2024-03-21-uswds-monthly-call-march-2024.md index 1362b3cfaf..b773dad30d 100644 --- a/content/events/2024/03/2024-03-21-uswds-monthly-call-march-2024.md +++ b/content/events/2024/03/2024-03-21-uswds-monthly-call-march-2024.md @@ -5,7 +5,6 @@ kicker: USWDS summary: Join the U.S. Web Design System team for a lesson on customizing and extending the design system. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIsdu6pqzwuH6ocAtOZ2fI_hHryn0lQ9es date: 2024-03-21 14:00:00 -0500 end_date: 2024-03-21 15:00:00 -0500 @@ -30,7 +29,7 @@ youtube_title: "How to build with U.S. Web Design System tools (2024)" As Jeannie mentioned, we are recording this call, and I'm happy to say we've started to be able to share the recordings of these monthly calls publicly. You can find pretty much everything from the last year's worth of monthly calls — back to January 2023 — on our website, at [designsystem.digital.gov/about/monthly-calls/](https://designsystem.digital.gov/about/monthly-calls/). 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've posted a link to our monthly call page in the chat. -We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. +We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. For 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&A session at the end of this call. @@ -51,16 +50,17 @@ We’ve got a very relevant new site launch, a couple product updates, and then **Slide 8:** First USWDS 3.8.0. We've mentioned it the last couple monthly calls, and it is finally out now. I won't go into the details of 3.8.0 since we've discussed it so much recently, but check out the release notes for lots of details. We're pasting the direct link in the chat, it's with all our other releases and release notes at [github.com/uswds/uswds/releases](https://github.com/uswds/uswds/releases/tag/v3.8.0). **Slide 9:** Next, new component discussions. We spent last month talking about our new component discussions, proposals, and the component lifecycle model. Well, we now have ten active component discussions on our discussion board: -* Common feedback -* CUI banner -* Glossary -* Spinner -* Tabs -* Toast -* Toggle -* Quote with attribution -* Skipto -* Sidebar primary navigation + +- Common feedback +- CUI banner +- Glossary +- Spinner +- Tabs +- Toast +- Toggle +- Quote with attribution +- Skipto +- Sidebar primary navigation If you're interested in any of these components and would like to be part of the discussion that helps make the case for the component, head over to our discussion board at [github.com/uswds/uswds/discussions](http://github.com/uswds/uswds/discussions), then go to "Component proposals". We hope you get involved! @@ -68,7 +68,7 @@ If you're interested in any of these components and would like to be part of the **Slide 11:** And finally, getting your feedback is critical for us to be able to deliver a design system that works for you. To that end, we’ve created a new webpage and signup form for federal employees who might like to participate in usability research with us. -You can find this new information on our website at [designsystem.digital.gov/about/research/recruitment/general-fed](http://designsystem.digital.gov/about/research/recruitment/general-fed) — and of course, the link is also in the chat. +You can find this new information on our website at [designsystem.digital.gov/about/research/recruitment/general-fed](http://designsystem.digital.gov/about/research/recruitment/general-fed) — and of course, the link is also in the chat. We're looking for federal employees who serve as designers, developers, content strategists, accessibility specialists, UX leaders, or in any UX/CX-adjacent role and have any level of experience and proficiency with the design system, from being an absolute beginner to a seasoned expert. @@ -82,7 +82,7 @@ First, James Mejia, a contractor and a front-end engineer on the USWDS core team James: Hey there everyone, my name is James Mejia. Like Dan said, I'm a contracted engineer and I'm wearing a brown jacket for this chilly weather and I have short dark hair. -Dan: Cool, thanks James. +Dan: Cool, thanks James. **Slide 14:** And I'd also like to introduce Charlie Mahoney, a contractor and a front-end engineer on the USWDS core team. Charlie, can you introduce yourself and give a brief self description? @@ -132,7 +132,7 @@ James: Okay, so I paste it in my new settings and I think I recognize two of th Charlie: So this border-radius-large allows us to update the sizing token for the large that we will be using in theme card border radius. It's a little bit larger than the standard large token and this will allow us to have a slightly more curved hard radius. -James: Okay, if you don't mind I'm going to swap over to the preview just to see what it looks like before and then I'll jump back to the code, give that a save and then see what changed. Hey, they got rounder. +James: Okay, if you don't mind I'm going to swap over to the preview just to see what it looks like before and then I'll jump back to the code, give that a save and then see what changed. Hey, they got rounder. Charlie: Look at that, I like it, it's very modern looking. @@ -214,7 +214,7 @@ Charlie: That's right, the first step of adding our custom styles is going to be James: Okay, I like the sound of that. -Charlie: Yeah, let's jump back over into your editor and we have a card, that html file, that is housing all of our component markup at this time. +Charlie: Yeah, let's jump back over into your editor and we have a card, that html file, that is housing all of our component markup at this time. James: Okay, I found card html and it looks like the standard markup in the code example on the website. @@ -222,7 +222,7 @@ Charlie: Exactly. This is exactly what you would copy and paste over if you were James: That sounds good to me. So you said I wouldn't want to use "usa-card" to add my custom styles. -Charlie: Yeah, that's right. It could just lead into specificity issues down the road, unintended changes, and you know if we make an update to what the "usa-card" styles are, it might wipe out your custom styles and you wouldn't want that. +Charlie: Yeah, that's right. It could just lead into specificity issues down the road, unintended changes, and you know if we make an update to what the "usa-card" styles are, it might wipe out your custom styles and you wouldn't want that. James: Oh no, not at all. That sounds pretty bad. @@ -250,7 +250,7 @@ Charlie: So if we want to make use of a lot of the tools that USWDS has to offer James: So copy the same file, "uswds-core" in step 5, right? -Charlie: That's right, if you want to give that a copy and go back to our editor, we can paste it at the top using the Sass use directive and we're using it as *, the all selector. This allows us to use these with their name given to them by USWDS without having to prefix it with uswds-core color for example. You can just call the color function using color. +Charlie: That's right, if you want to give that a copy and go back to our editor, we can paste it at the top using the Sass use directive and we're using it as \*, the all selector. This allows us to use these with their name given to them by USWDS without having to prefix it with uswds-core color for example. You can just call the color function using color. James: That's convenient, what's next? @@ -258,7 +258,7 @@ Charlie: Let's hop back over to the demo and you'll see a couple styles that we' James: Alright, we're going to override the background of the card container, right? -Charlie: That's right. +Charlie: That's right. James: Because we didn't have a setting that was available to us. @@ -310,7 +310,7 @@ Charlie: Alrighty, back on the demo page we have some text for you to use as the James: Okay, it's kind of a core requirement of the testimonial huh? -Charlie: Yeah, I'd say so and it's like it took the words right out of your mouth. Next let's go ahead and let's populate the footer section we have a little image for a profile photo for our +Charlie: Yeah, I'd say so and it's like it took the words right out of your mouth. Next let's go ahead and let's populate the footer section we have a little image for a profile photo for our "quotee" as well as a profile section to give them a name and a title. James: Alright, "Mr. J" fake name. @@ -403,7 +403,7 @@ Charlie: Exactly. Just another way that you can use the theme settings available James: Yeah, I can just take what I need. So I've gotten rid of the padding setting that I set previously and I'm using the mixin now. I hit save and I really want to peek and see what it looks like now. Charlie: I think we should. -James: Okay, oh look at that. +James: Okay, oh look at that. Charlie: Looks good. Looks just like the card right above it. Now let's play with some of the colors. Go ahead and let's copy those we're going to change the background color and the color and similar to what we were talking about in the theme setting. We're going to use these token names so we don't have to worry about indigo 10 we're simply going to change the color the text color to primary light and the background color to primary dark and keep things on brand with this tutorial. @@ -455,17 +455,17 @@ James: I'd say so, look at how beautiful that is. Charlie: I like it. What do you think Dan? How do you like our new component? -Dan: Thanks Charlie, this is Dan and I really do think that this is one of the best USWDS tutorials I've followed all the way to the end. This is all part of a USWDS tutorial repo that we posted a link to in the chat and we'll call back again later. Like James and Charlie mentioned part one of the tutorial and this is something we did about a year ago when we looked at part one and part one is really about like getting up to speed with the design system, installing it into a project and beginning to connect it to your project's existing styles so you can add USWDS incrementally into a project. And then as you follow along into part two, this part that we just looked at today, is like okay what if we want to begin to build more stuff with USWDS and begin to develop a higher level of integration between the design system and our project. So when you go and you visit that tutorial and you try to do it yourself you'll start from the very beginning and go all the way from nothing to building your own simple USWDS components. Now I'm going to share my screen and pop back over to the slides. +Dan: Thanks Charlie, this is Dan and I really do think that this is one of the best USWDS tutorials I've followed all the way to the end. This is all part of a USWDS tutorial repo that we posted a link to in the chat and we'll call back again later. Like James and Charlie mentioned part one of the tutorial and this is something we did about a year ago when we looked at part one and part one is really about like getting up to speed with the design system, installing it into a project and beginning to connect it to your project's existing styles so you can add USWDS incrementally into a project. And then as you follow along into part two, this part that we just looked at today, is like okay what if we want to begin to build more stuff with USWDS and begin to develop a higher level of integration between the design system and our project. So when you go and you visit that tutorial and you try to do it yourself you'll start from the very beginning and go all the way from nothing to building your own simple USWDS components. Now I'm going to share my screen and pop back over to the slides. -**Slide 17:** Thank you James and thank you Charlie! There's a lot of stuff enclosed in that tutorial and if you're interested it does make sense to just go and do it yourself to get a sense of of doing it and what we're actually talking about here. But when we're building with USWDS there are a few things I think we want to keep in mind. First, that we want to use USWDS tokens whenever possible when we're setting colors, when we're setting font sizes, when we're setting spacing units, use those tokens, use those pallets to build your new stuff. That's the fundamental and lowest level way that we can begin to connect to all of our sites together by using the same same pallets. And get familiar with settings. There's a lot of power in settings and there's a lot that you can begin to do in your project to tailor it to what your project needs without even modifying a lot of CSS. Just with a few settings you can do some meaningful things. It's important to override our USWDS Sass, our stylesheets with project classes just like we made "my-card" that allows us to move our overrides into a separate section so it doesn't risk getting clobbered by updating USWDS, helps with specificity, keeps everything organized and separated. And that you can you can build with existing components that when we were looking at developing our testimonial component there are things that we could take from card. +**Slide 17:** Thank you James and thank you Charlie! There's a lot of stuff enclosed in that tutorial and if you're interested it does make sense to just go and do it yourself to get a sense of of doing it and what we're actually talking about here. But when we're building with USWDS there are a few things I think we want to keep in mind. First, that we want to use USWDS tokens whenever possible when we're setting colors, when we're setting font sizes, when we're setting spacing units, use those tokens, use those pallets to build your new stuff. That's the fundamental and lowest level way that we can begin to connect to all of our sites together by using the same same pallets. And get familiar with settings. There's a lot of power in settings and there's a lot that you can begin to do in your project to tailor it to what your project needs without even modifying a lot of CSS. Just with a few settings you can do some meaningful things. It's important to override our USWDS Sass, our stylesheets with project classes just like we made "my-card" that allows us to move our overrides into a separate section so it doesn't risk getting clobbered by updating USWDS, helps with specificity, keeps everything organized and separated. And that you can you can build with existing components that when we were looking at developing our testimonial component there are things that we could take from card. -We can use buttons in other things, we can use the grid, we can- when we're building new things, how can we use some of the existing design system components to give ourselves a starting point for something new. And really just to experiment with confidence that the design system really is meant to be building new things and to be really trying to engage with your audience and to keep pushing. There are some things we like to do consistently again and again using USWDS tokens, using the banner, using other common components, but there is room for experimentation and you should experiment with confidence with the design system. +We can use buttons in other things, we can use the grid, we can- when we're building new things, how can we use some of the existing design system components to give ourselves a starting point for something new. And really just to experiment with confidence that the design system really is meant to be building new things and to be really trying to engage with your audience and to keep pushing. There are some things we like to do consistently again and again using USWDS tokens, using the banner, using other common components, but there is room for experimentation and you should experiment with confidence with the design system. **Slide 18:** You can follow this tutorial today. [github.com/uswds/uswds-tutorial](http://github.com/uswds/uswds-tutorial) **Slide 19:** Q&A -**Slide 20:** Thanks for joining today’s USWDS monthly call. We'll be back in April with an introduction to Web Components, the technology we're working toward as a design system. +**Slide 20:** Thanks for joining today’s USWDS monthly call. We'll be back in April with an introduction to Web Components, the technology we're working toward as a design system. If you have a question we weren't able to answer in the call, or thought of later, please head into our public Slack and ask it there. We'll be around after the call to answer questions. Have a great day and we'll see you next month! @@ -476,32 +476,32 @@ Join the U.S. Web Design System team for a lesson on customizing and extending U You’ll learn to: -* Work with design system settings -* Apply tokens consistently with Sass functions and mixins -* Avoid style conflicts when overriding defaults -* Use tools for ensuring proper color contrast in every context +- Work with design system settings +- Apply tokens consistently with Sass functions and mixins +- Avoid style conflicts when overriding defaults +- Use tools for ensuring proper color contrast in every context **This event is best suited for:** Developers who have basic to advanced familiarity with the design system. ## Speakers -* **Dan Williams** **-** Product Lead, USWDS -* **James Mejia** **-** Developer, USWDS Contractor -* **Charlie Mahoney** **-** Developer, USWDS Contractor +- **Dan Williams** **-** Product Lead, USWDS +- **James Mejia** **-** Developer, USWDS Contractor +- **Charlie Mahoney** **-** Developer, USWDS Contractor ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@gsa.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@gsa.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2024/04/2024-04-18-uswds-monthly-call-april-2024.md b/content/events/2024/04/2024-04-18-uswds-monthly-call-april-2024.md index 3339176f0f..02f9601af4 100644 --- a/content/events/2024/04/2024-04-18-uswds-monthly-call-april-2024.md +++ b/content/events/2024/04/2024-04-18-uswds-monthly-call-april-2024.md @@ -5,7 +5,6 @@ kicker: USWDS 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. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIscu2trTIvG5qnaDHtM3sylW5ysfzYq_Y date: 2024-04-18 14:00:00 -0500 end_date: 2024-04-18 15:00:00 -0500 @@ -30,13 +29,13 @@ youtube_title: "An introduction to Web Components" As Jeannie mentioned, we are recording this call, and I'm happy to say we've started to be able to share the recordings of these monthly calls publicly. You can find pretty much everything from the last year's worth of monthly calls — back to January 2023 — on our website, at [designsystem.digital.gov/about/monthly-calls](https://designsystem.digital.gov/about/monthly-calls/). 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've posted a link to our monthly call page in the chat. -We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. +We'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'll do so, otherwise there'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's nice to know who's here. It's good to have you here today. For 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&A session at the end of this call. So thanks! And, with that, let's get started! -**Slide 3:** So what's our agenda for today? +**Slide 3:** So what's our agenda for today? We've got a nice site launch, some product updates, and then we'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. @@ -59,32 +58,33 @@ And then hopefully we'll have plenty of time for Q&A. **Slide 11:** We'll have more to come on findings from this last round of research, but we learn a lot with every round, and we're gearing up for the next ones now. **Slide 12:** Next a quick update on component discussions. We're adding [a link to our new component proposal discussion board in the chat](https://github.com/uswds/uswds/discussions/categories/component-proposals) where we're working to solicit discussion on components teams hope to see in the design system. We've got ten active discussions right now: -* Common feedback -* CUI banner -* Glossary -* Spinner -* Tabs -* Toast -* Toggle -* Quote with attribution -* Skipto -* Sidebar primary navigation + +- Common feedback +- CUI banner +- Glossary +- Spinner +- Tabs +- Toast +- Toggle +- Quote with attribution +- Skipto +- Sidebar primary navigation We're also getting ready to get the tabs discussion into the formal proposal phase, converting the information we've gathered in the discussion into a formal proposal. When we've finished, we'll post an update into the tabs discussion, and ask any follow-up questions we have in there as well. We'll be talking more about component proposals and evaluation in the coming months. -**Slide 13:** And finally, I'd like to point to a couple other discussions on the borders right now. We've had some interesting conversation around the idea of "dull colors" or what we might think of as the "calm" equivalent of the "vivid" color variants we currently support. +**Slide 13:** And finally, I'd like to point to a couple other discussions on the borders right now. We've had some interesting conversation around the idea of "dull colors" or what we might think of as the "calm" equivalent of the "vivid" color variants we currently support. It's a good proposal, and is a thoughtful look at how we might provide an even fuller gamut of color token options. -There are also a couple other accessibility-related discussions that might be of interest. This month is recognized as National Stress Awareness Month, and we'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. +There are also a couple other accessibility-related discussions that might be of interest. This month is recognized as National Stress Awareness Month, and we'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. There 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! **Slide 14:** This month we'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's something called Web Components. Today we'll try to talk about what this technology is, and why we care so much — without getting too too technical. -We'll be talking about this a bunch more over the foreseeable future, and this is just the start. +We'll be talking about this a bunch more over the foreseeable future, and this is just the start. **Slide 15:** Have you ever "viewed source" on a website? You can do that for anything you can open in a web browser. There isn't much reason to do this — there are other ways to interact with the underlying code of a webpage, if you're a developer. But if you'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. @@ -94,13 +94,13 @@ Back when the web was young, this was one of the best ways to learn how the web **Slide 17:** This is what — technically — we refer to as "brackety stuff." -**Slide 18:** Or perhaps *more* technically, as *markup*. +**Slide 18:** Or perhaps _more_ technically, as _markup_. **Slide 19:** 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't be like reading a completely different language. It wouldn't even be as archaic as something like Old English. Since the earliest days, this common markup has been the stable foundation of the web. -**Slide 20:** In fact, it was in 1994 — still in the very early days of the web — that the web standards body known as the [W3C (World Wide Web Consortium)](https://www.w3.org/) was formed. By 1996, they'd assumed standardization responsibilities for this markup language. +**Slide 20:** In fact, it was in 1994 — still in the very early days of the web — that the web standards body known as the [W3C (World Wide Web Consortium)](https://www.w3.org/) was formed. By 1996, they'd assumed standardization responsibilities for this markup language. This 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. @@ -112,17 +112,17 @@ The stability, consistency, and dependability of standardization helped the inte **Slide 23:** And to understand why, it's worth thinking about something we talk about pretty often here at USWDS: and that's components. -**Slide 24:** 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. +**Slide 24:** 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. **Slide 25:** 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. -**Slide 26:** For modern websites, anything that appears again and again, like a component, is a great candidate for a *template* — like a stamp or a little printing press — that outputs that component wherever it's needed, with the proper content and data for *just* that instance: *just that* button, *just that* form field, *just that* breadcrumb trail, *just that* side navigation. Design this little component printing press once, and include it every time you need to output a component. +**Slide 26:** For modern websites, anything that appears again and again, like a component, is a great candidate for a _template_ — like a stamp or a little printing press — that outputs that component wherever it's needed, with the proper content and data for _just_ that instance: _just that_ button, _just that_ form field, _just that_ breadcrumb trail, _just that_ side navigation. Design this little component printing press once, and include it every time you need to output a component. **Slide 27:** So what does a template do? A template receives unique data and content as an input and outputs the HTML that the browser interprets. **Slide 28:** So just as you can think of a page as made of components… -**Slide 29:** 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. +**Slide 29:** 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. **Slide 30:** Essentially, template languages allow applications to output HTML dynamically, based on data and logic. You're not writing a bunch of HTML, you're writing logic and passing data, and letting the machine take care of the repetitive hassle of writing all that HTML. @@ -134,7 +134,7 @@ The stability, consistency, and dependability of standardization helped the inte **Slide 34:** 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. -**Slide 35:** 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 *additions* to HTML. +**Slide 35:** 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 _additions_ to HTML. **Slide 36:** To understand what this means, let's take a look at some HTML elements… @@ -142,27 +142,28 @@ The stability, consistency, and dependability of standardization helped the inte An 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. -If you look around at the grid of HTML elements on screen now (this isn't all of them, by the way!) you may see a bunch of things that look familiar: heading levels like `h1`-`h6`; `table`, `form`, `input`, and `button`; the paragraph `p`, and perhaps the hydrogen of the HTML elements… +If you look around at the grid of HTML elements on screen now (this isn't all of them, by the way!) you may see a bunch of things that look familiar: heading levels like `h1`-`h6`; `table`, `form`, `input`, and `button`; the paragraph `p`, and perhaps the hydrogen of the HTML elements… **Slide 38:** …the anchor link: `a`. Which we now see highlighted in the grid. `A` is a great element, and is the element that made the web what it is. Let's use the `a` element to look at the parts of an element. -**Slide 39:** So here's an element in the wild. Since most — but not all — elements are designed to structure content, they're designed with a two-part system, an opening tag and a closing tag that enclose some kind of content. +**Slide 39:** So here's an element in the wild. Since most — but not all — elements are designed to structure content, they're designed with a two-part system, an opening tag and a closing tag that enclose some kind of content. -Opening and closing tags are surrounded by angle brackets. The closing tag uses a forward slash to indicate that it's a closing tag, and the opening tag can also include **attributes**, or information about this specific instance of the element. +Opening and closing tags are surrounded by angle brackets. The closing tag uses a forward slash to indicate that it's a closing tag, and the opening tag can also include **attributes**, or information about this specific instance of the element. In this case, the attribute for the `a` element is one that's pretty critical for any anchor link, the hyperlink reference to the destination address, otherwise known as an `href`. So for an anchor link, you really just need two things: -* The text that serves as the link -* And the destination address for the link -That's what this element encodes. That's the *model* for a hyperlink. +- The text that serves as the link +- And the destination address for the link + +That's what this element encodes. That's the _model_ for a hyperlink. -**Slide 40:** On-screen, this is what we see. +**Slide 40:** On-screen, this is what we see. We 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's `href`. 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. -We *don't* see the element's tags, or any of the attributes, exactly. What we see is the browser's *interpretation* of the element model, with the content and data we specified. +We _don't_ see the element's tags, or any of the attributes, exactly. What we see is the browser's _interpretation_ of the element model, with the content and data we specified. **Slide 41:** HTML elements are the starting point for modeling components. But what about when a component doesn't have an analogous element? @@ -178,30 +179,32 @@ Let's look at a few instances of a breadcrumb to try to identify its key aspects On 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. -**Slide 46:** 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. +**Slide 46:** 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. **Slide 47:** At the start of each collection is a home, now highlighted on the screen. **Slide 48:** And at the end of each collection is the current page, now highlighted on the screen. **Slide 49:** So this might be our content model: -* A collection of links -* The first is always a link to a common home -* Then there can be any number of optional links -* And finally a link to the current page - + +- A collection of links +- The first is always a link to a common home +- Then there can be any number of optional links +- And finally a link to the current page + If you had just this content, you'd have everything you need to build a breadcrumb. **Slide 50:** 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: -* We've defined the breadcrumb as a `nav` navigation element. -* We've defined the collection of links as an ordered list. -* And we've defined a `class` attribute for each element, so we can write styles that target each of these unique classes. - -Our model can be very simple. Complex interpretation doesn't *require* a complex model. Our model doesn't have to answer the questions we address in the interpretation; it only has to sufficiently describe the content. + +- We've defined the breadcrumb as a `nav` navigation element. +- We've defined the collection of links as an ordered list. +- And we've defined a `class` attribute for each element, so we can write styles that target each of these unique classes. + +Our model can be very simple. Complex interpretation doesn't _require_ a complex model. Our model doesn't have to answer the questions we address in the interpretation; it only has to sufficiently describe the content. From this relatively simple model, we've developed a fairly complex bit of markup! -**Slide 51:** But USWDS doesn't deliver models or interpreters, it delivers only the final stage in this process: the markup. What we might call a markup *specification*. +**Slide 51:** But USWDS doesn't deliver models or interpreters, it delivers only the final stage in this process: the markup. What we might call a markup _specification_. **Slide 52:** So what does a project team do with what USWDS delivers; with this specification? @@ -223,11 +226,11 @@ Static content changes are often markup changes. **Slide 58:** This is work! Time, energy, resources! Multiplied by every team that's using the design system. You can see why not every team can keep up with our updates. -**Slide 59:** 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. +**Slide 59:** 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. The diversity of template languages has meant that we've never been able to support any of them directly, and we've been stuck delivering an HTML spec — even while we know that this isn't how teams build. -**Slide 60:** But what if — instead of the HTML spec — we could deliver the model directly, as some kind of custom element? +**Slide 60:** But what if — instead of the HTML spec — we could deliver the model directly, as some kind of custom element? **Slide 61:** Along with an element interpreter to translate the custom element into standard HTML? @@ -251,36 +254,37 @@ The diversity of template languages has meant that we've never been able to supp **Slide 71:** Or maybe there should be an option to omit the house icon altogether? -**Slide 72:** 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 *attributes* model as well. Attributes might include -* `font` -* `houseIcon` -* `separatorIcon` -* `hasHouse` +**Slide 72:** 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 _attributes_ model as well. Attributes might include + +- `font` +- `houseIcon` +- `separatorIcon` +- `hasHouse` But there could be other kinds of configuration options as well. **Slide 73:** 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've seen before… -**Slide 74:** …but potentially different presentations of Breadcrumb as well. Now I'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's possible that there's something that's either better than the current state, or becomes a user expectation. Our model describes *this potential* version of a breadcrumb *just as well as* the current version. And as long as breadcrumb stays, *conceptually*, as a collection of links that starts with Home and ends with the current page, our model doesn't have to change, and the way we interface with our custom element doesn't need to change either. +**Slide 74:** …but potentially different presentations of Breadcrumb as well. Now I'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's possible that there's something that's either better than the current state, or becomes a user expectation. Our model describes _this potential_ version of a breadcrumb _just as well as_ the current version. And as long as breadcrumb stays, _conceptually_, as a collection of links that starts with Home and ends with the current page, our model doesn't have to change, and the way we interface with our custom element doesn't need to change either. **Slide 75:** 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. -**Slide 76:** Because unlike a markup spec, developers can update element interpreters automatically. +**Slide 76:** Because unlike a markup spec, developers can update element interpreters automatically. **Slide 77:** Developers only have to care about the interface, only those elements of the model that need project-specific configuration. When we're thinking about developing custom element interfaces, we have four goals: make them clear, concise, consistent, and configurable. Let's take a look at a couple examples to get a sense of what I mean! -**Slide 78:** On this slide, we get a look at what the custom element interface might look like for a Breadcrumb Web Component. +**Slide 78:** On this slide, we get a look at what the custom element interface might look like for a Breadcrumb Web Component. -We want it to be *clear* and *concise*: 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 `usa-breadcrumb`. And it contains four unique anchor links. +We want it to be _clear_ and _concise_: 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 `usa-breadcrumb`. And it contains four unique anchor links. Why 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 "Home" if they don't have to? (Though I will say, as an aside, that it's a longer topic, but we do want to consider multilingual needs in here as well, and we'd build in the ability to do that…) And we also want to make the breadcrumb **configurable**. This example shows how you -might add a configuration option to add special RDFa metadata to the breadcrumb to improve search results and findability just by adding an RDFa attribute. +might add a configuration option to add special RDFa metadata to the breadcrumb to improve search results and findability just by adding an RDFa attribute. And finally, **consistency**: Since this custom element interface includes all the information the element interpreter needs to build all kinds of breadcrumbs, the custom elements interface doesn'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. @@ -297,10 +301,11 @@ In the end, you can see the difference between our new Web Component — and its What if it was closer to the clear, concise, configurable, and consistent six lines we see on this slide? This custom element, `usa-banner`, contains all the critical information a developer needs to set up and configure the banner: -* We can set the domain as "gov" so the rendered banner shows shows copy that refers to .gov domains -* We can set the background to dark, so it has a custom color. -* And we can use USWDS design tokens to set the width of the component to "widescreen" so the text extends the same width as the rest of the elements on the site. - + +- We can set the domain as "gov" so the rendered banner shows shows copy that refers to .gov domains +- We can set the background to dark, so it has a custom color. +- And we can use USWDS design tokens to set the width of the component to "widescreen" so the text extends the same width as the rest of the elements on the site. + And that's it. The element interpreter does the rest, and developers don't have to worry about 93 lines of custom markup, and copy that are subject to change and evolution over time! **Slide 83:** 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: `lang="es"`, and the banner updates to Spanish with just a single line of code. @@ -315,13 +320,13 @@ And that's it. The element interpreter does the rest, and developers don't have **Slide 88:** This can be things like markup, logic, accessibility support, metadata, static content, styling, and behaviors. -**Slide 89:** And this means a move to thinking about theming as *configuration* — 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's applied from an external stylesheet. +**Slide 89:** And this means a move to thinking about theming as _configuration_ — 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's applied from an external stylesheet. -**Slide 90:** 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'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… +**Slide 90:** 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'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… **Slide 91:** Making the design system easier to implement, and easier to stay up to date. -**Slide 92:** Because maintenance and maintainability *is just the baseline*. Not just for the design system, but for everyone who uses it. What would you do if you weren't focused on maintenance? What higher order questions could you begin to solve? What *mission-* and *user-* centered questions would you try to solve? +**Slide 92:** Because maintenance and maintainability _is just the baseline_. Not just for the design system, but for everyone who uses it. What would you do if you weren't focused on maintenance? What higher order questions could you begin to solve? What _mission-_ and _user-_ centered questions would you try to solve? **Slide 93:** 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're able to do with it. And that's a great question to start to ask. @@ -341,30 +346,30 @@ Web Components have been mentioned in a lot of recent discussions about the futu In this session, the USWDS team will: -* Explain Web Components technology in plain language -* Discuss the value of bringing modern web technologies to the design system -* Explore how using a new technology can affect any user of the design system, not just developers +- Explain Web Components technology in plain language +- Discuss the value of bringing modern web technologies to the design system +- Explore how using a new technology can affect any user of the design system, not just developers **This event is best suited for:** All design system users (all levels). This will be a technical discussion, but anyone can attend as it requires no specialized knowledge. Speakers -* **Dan Williams** **-** Product Lead, USWDS -* **James Mejia** **-** Developer, USWDS contractor +- **Dan Williams** **-** Product Lead, USWDS +- **James Mejia** **-** Developer, USWDS contractor ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@gsa.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@gsa.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2024/05/2024-05-02-uswds-monthly-call-may-2024.md b/content/events/2024/05/2024-05-02-uswds-monthly-call-may-2024.md index 7aa24fa416..2c3aaedaac 100644 --- a/content/events/2024/05/2024-05-02-uswds-monthly-call-may-2024.md +++ b/content/events/2024/05/2024-05-02-uswds-monthly-call-may-2024.md @@ -6,7 +6,6 @@ summary: The U.S. Web Design System (USWDS) team will chat with Center for Civic Design co-founder Whitney Quesenbery about designing accessible civic spaces. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItcO6qpjsiGK0hB4N06M49z5wbessGW2Y date: 2024-05-16 14:00:00 -0500 end_date: 2024-05-16 15:00:00 -0500 @@ -139,9 +138,9 @@ For people with disabilities, it’s the signal that their needs for accessibili **Slide 17:** It is a two-way matrix of bad and good experience vs. low and high expectations. -In the bottom left corner, there’s the black hole of low expectations and bad experience. It’s a *kind* of success: you’ve met their worst expectations! +In the bottom left corner, there’s the black hole of low expectations and bad experience. It’s a _kind_ of success: you’ve met their worst expectations! -Moving counterclockwise there’s the pleasant surprise when low expectations meet a good experience. It’s the moment the blue sky peeks out from behind the clouds. At this point, you can stop thinking about the basics of accessibility and start thinking about the needs that go along with *different* disabilities. And with different types of *users* with disabilities. +Moving counterclockwise there’s the pleasant surprise when low expectations meet a good experience. It’s the moment the blue sky peeks out from behind the clouds. At this point, you can stop thinking about the basics of accessibility and start thinking about the needs that go along with _different_ disabilities. And with different types of _users_ with disabilities. Next, you reach the goal, where high expectations meet a good experience. That’s where every site or app should be. @@ -171,11 +170,11 @@ The [ISO 9241](https://www.iso.org/standard/80709.html) series on **The ergonomi The new Part 20, on accessibility, ties accessibility and usability together, by defining accessibility as "The usability of a product, service, environment, or facility by people with the widest range of capabilities." -In other words: *usability for more people*. +In other words: _usability for more people_. Our goal is to make "usability for all" as wide as possible, and the edges of the curve where people need assistance as narrow as possible. -**Slide 21:** Or, more simply, usability for more people. When you look at a normal distribution curve, as you move out from the middle: from **usability** to **accessibility**, more people are included when our tools and apps are built with a wider range of capabilities in mind. +**Slide 21:** Or, more simply, usability for more people. When you look at a normal distribution curve, as you move out from the middle: from **usability** to **accessibility**, more people are included when our tools and apps are built with a wider range of capabilities in mind. But sometimes we can’t meet that goal. The next step out towards the ends is **accommodation**. That’s when there is an alternative that addresses accessibility needs, but it’s separate. Think about a ramp to a side door vs. everyone being able to reach the front door. Or a different- though perhaps equally good solution. @@ -209,8 +208,8 @@ I was the chair for human factors and privacy — including usability and access The official words in HAVA 301(a)(3) are that voting systems **shall be accessible** -* for individuals with disabilities, including **non=visual accessibility** for the blind and visually impaired, -* in a manner that provides the same opportunity for access and participation including **privacy and independence** as for other voters +- for individuals with disabilities, including **non=visual accessibility** for the blind and visually impaired, +- in a manner that provides the same opportunity for access and participation including **privacy and independence** as for other voters While I was on the committee, we wrote the first and most of the 1.1 version of the Voluntary Voting System Guidelines ([VVSG](https://www.eac.gov/voting-equipment/voluntary-voting-system-guidelines)). We started from an almost blank page: 2 existing requirements for accessibility, some preliminary work on an IEEE standards, and Section 508/WCAG. @@ -242,7 +241,7 @@ The real test, however, is in action. Do our designs help reduce the number of b We can get anecdotal evidence. But the only meaningful answer is in robust data collection from every state. That lets us look at a state over time or in comparison to others. -This is something else the EAC is mandated to do. The Election Administration Voting Survey (EAVS) collects data on even-year elections from all 55 states, DC, and territories. +This is something else the EAC is mandated to do. The Election Administration Voting Survey (EAVS) collects data on even-year elections from all 55 states, DC, and territories. The survey itself is designed in a process with public input. @@ -268,7 +267,7 @@ Whitney: This is Whitney. Let's talk about something the city of Los Angeles has **Slide 25:** LA started with the Votomatic InkaVote - an adapted punchcard system. -It took them 12 years to design and build and launch their new system. That seems like forever, but what they did was remarkable. +It took them 12 years to design and build and launch their new system. That seems like forever, but what they did was remarkable. They started with a [voter-focused process](https://vsap.lavote.gov/research/) with broad community and expert input. @@ -280,7 +279,7 @@ The vote by mail design came first – not just in English, but supporting 19 la **Slide 26:** The ballots are delightful. They are also designed following the recommendations from an EAC research project and the requirements of the VVSG. -In 2020, the voting system was launched – called the Voting System for All People or VSAP. It’s a ballot marking device. Following a universal design approach, it’s not the accessible voting system. It’s the voting system. +In 2020, the voting system was launched – called the Voting System for All People or VSAP. It’s a ballot marking device. Following a universal design approach, it’s not the accessible voting system. It’s the voting system. **Slide 27:** It has a tactile controller to complement the touch screen, audio in all 19 languages, and a ballot box at each station where the printed ballot is stored. It can be operated without the use of your hands. @@ -322,25 +321,25 @@ Join the U.S. Web Design System team on Global Accessibility Awareness Day. Gues **Speakers** -* **Dan Williams** **-** Product Lead, USWDS -* **Anne Petersen** **-** Experience Design Lead, USWDS -* **Amy Cole** **-** Accessibility Specialist, USWDS Contractor -* **Alex Hull** **-** Accessibility Specialist, USWDS Contractor -* **Whitney Quesenbery** **-** Co-founder, Center for Civic Design +- **Dan Williams** **-** Product Lead, USWDS +- **Anne Petersen** **-** Experience Design Lead, USWDS +- **Amy Cole** **-** Accessibility Specialist, USWDS Contractor +- **Alex Hull** **-** Accessibility Specialist, USWDS Contractor +- **Whitney Quesenbery** **-** Co-founder, Center for Civic Design ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@gsa.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@gsa.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2024/06/2024-06-20-uswds-monthly-call-june-2024.md b/content/events/2024/06/2024-06-20-uswds-monthly-call-june-2024.md index 1644a0be92..5abed78b89 100644 --- a/content/events/2024/06/2024-06-20-uswds-monthly-call-june-2024.md +++ b/content/events/2024/06/2024-06-20-uswds-monthly-call-june-2024.md @@ -5,7 +5,6 @@ kicker: USWDS summary: The U.S. Web Design System team will give an update on their work developing web components for the design system. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIscOyqrzsiHVsXeh0NaL14v3VGCFcbRgM date: 2024-06-20 14:00:00 -0500 end_date: 2024-06-20 15:00:00 -0500 @@ -21,7 +20,6 @@ event_platform: zoom primary_image: 2024-uswds-monthly-call-june-title-card youtube_id: yBCLyWO0yCo youtube_title: "A first look at working prototypes of U.S. Web Design System web components" - --- {{< asset-static file="uswds-monthly-call-june-2024.pptx" label="View the slides (Powerpoint presentation, 3 MB, 33 slides)">}} @@ -100,7 +98,7 @@ The **most successful tasks** were finding examples of other sites that use USWD It’s also hard for people to find the full showcase list of sites that use USWDS and there’s room to improve how to present that list, as well. -**Slide 16:** If we had to boil it down to one top takeaway from this study, it’s that **the way we name things doesn’t always match user expectations**. Participants often didn't intuitively understand the top-level navigation and weren’t sure what to expect in each category. +**Slide 16:** If we had to boil it down to one top takeaway from this study, it’s that **the way we name things doesn’t always match user expectations**. Participants often didn't intuitively understand the top-level navigation and weren’t sure what to expect in each category. **Slide 17:** So, we have some actionable insights and clear next steps to help make some of these Top Tasks easier for folks. We'll be getting new issues on our project board, and working on prioritizing some solutions. Some of these solutions are closer to low-hanging fruit, like increasing the prominence of design kit files, or adding better component synonyms on the component filter page. @@ -138,7 +136,7 @@ Matt: First, by way of disclaimer, I should say that — as Dan mentioned — ev This is going to be sort of a re-introduction to USWDS so let's go back to basics with the USWDS tutorial project that you might recognize from some of these monthly calls. I'm going to start with a clean install of the tutorial so you can see everything I'll need to do to get something working. You may have gone through this tutorial before, so it may be familiar. -Now just to prove there's nothing up my sleeve, here's a clean git status on the main branch of the tutorial. We originally developed this tutorial to walk through installing the design system and a couple components on a site that doesn't use USWDS. So not only does this fresh install not have USWDS on it already, but it's a great way for us to show how we might install a Web Components–based version of USWDS. +Now just to prove there's nothing up my sleeve, here's a clean git status on the main branch of the tutorial. We originally developed this tutorial to walk through installing the design system and a couple components on a site that doesn't use USWDS. So not only does this fresh install not have USWDS on it already, but it's a great way for us to show how we might install a Web Components–based version of USWDS. The first task the tutorial wants you to take on is adding the banner. This is the component you've probably worked with many many times that tells users that they're on an official government site, so it's a good place to start! Now let's get going and install the banner component. `# in uswds-tutorial project npm link @uswds-next/usa-banner` @@ -159,22 +157,22 @@ Now I’m going to go ahead and spin up the 11ty dev server. But now that we've `` -That's literally it. And the only reason we even needed to touch the eleventy configuration is because we installed a local copy of the component, so we needed to get that code out of the `node_modules` and into the website itself. +That's literally it. And the only reason we even needed to touch the eleventy configuration is because we installed a local copy of the component, so we needed to get that code out of the `node_modules` and into the website itself. If we were using a cloud-hosted version of the component, we wouldn't even need to do that, and all we would need to do is add the script tag and we could use the `` tag straight away. Now let's see what we get out of the box: -* The banner toggle just works. -* CSS is included. -* All of the images are part of the build. +- The banner toggle just works. +- CSS is included. +- All of the images are part of the build. Let's jump back over to the tutorial project to see what we _didn't_ have to do to get this working. We _didn't_: -* Install `@uswds/compile` -* Configure gulp -* Mess with theme settings -* Touch any image paths +- Install `@uswds/compile` +- Configure gulp +- Mess with theme settings +- Touch any image paths This is all done at build time when we bundled the package. @@ -187,7 +185,7 @@ _Simple!_ Now just to prove that this is just a plain-old HTML element, let's go `const banner = document.querySelector('usa-banner')` -See how we can grab the banner element with the same DOM API methods you use to do anything else with HTML. `toggle` is just a method on the `UsaBanner` class, and it's part of the public API for that class, so you can call it yourself programmatically if you need to, like so: +See how we can grab the banner element with the same DOM API methods you use to do anything else with HTML. `toggle` is just a method on the `UsaBanner` class, and it's part of the public API for that class, so you can call it yourself programmatically if you need to, like so: `banner.toggle()` @@ -235,9 +233,9 @@ So you might think you'd be able to just write some CSS like this: } ` -Alas, this doesn't work. And the reason it doesn't work is this `#shadow-root` thing. That link in there is part of what's called the Shadow DOM. +Alas, this doesn't work. And the reason it doesn't work is this `#shadow-root` thing. That link in there is part of what's called the Shadow DOM. -In a nutshell, Shadow DOM is just markup that the component writes. You can contrast shadow DOM with Light DOM, which is the markup you write. But what's important here is that styles from outside of the shadow DOM don't apply inside of it. A lot of the time, this is what we want! This provides a layer of encapsulation that protects your component from being styled by whatever styles happen to match it on whatever page your component ends up on. +In a nutshell, Shadow DOM is just markup that the component writes. You can contrast shadow DOM with Light DOM, which is the markup you write. But what's important here is that styles from outside of the shadow DOM don't apply inside of it. A lot of the time, this is what we want! This provides a layer of encapsulation that protects your component from being styled by whatever styles happen to match it on whatever page your component ends up on. But it also means that styling components is just a little bit trickier than you're used to. Fortunately, there are a couple of ways for styles to make their way into the shadow DOM. One of those is with CSS custom properties, or CSS variables. Unlike most CSS properties, the values of CSS variables do cascade into the Shadow DOM. So anything we set in a CSS variable will be available for our component to use. @@ -267,7 +265,7 @@ Let’s modify the lang field to `es` and watch the component change to the Span Next, let’s checkout the Custom Aria label story. -It’s hard to see here, but the `label` setting allows us to update the Banner’s aria label. This is useful when we’re using the custom content variant, which uses slots. If we were using a different language outside of English or Spanish, we can update the aria label to match the new language. +It’s hard to see here, but the `label` setting allows us to update the Banner’s aria label. This is useful when we’re using the custom content variant, which uses slots. If we were using a different language outside of English or Spanish, we can update the aria label to match the new language. If we click on the Custom Content Banner variant we’ll see even more controls. @@ -305,32 +303,32 @@ Join the U.S. Web Design System (USWDS) team to see their progress toward develo In this online session with the USWDS team, you will: -* See examples of working USWDS web components -* Learn how the USWDS team built these components -* Understand the design principles supporting this work -* Find out what's coming next for USWDS web components +- See examples of working USWDS web components +- Learn how the USWDS team built these components +- Understand the design principles supporting this work +- Find out what's coming next for USWDS web components **This event is best suited for:** Design system users of all levels. This will be a technical discussion geared toward developers, but anyone can attend; it requires no specialized knowledge. **Speakers** -* **Dan Williams** - Product Lead, USWDS -* **Matt Henry** - Engineering Lead, USWDS -* **James Mejia** - Developer, USWDS contractor +- **Dan Williams** - Product Lead, USWDS +- **Matt Henry** - Engineering Lead, USWDS +- **James Mejia** - Developer, USWDS contractor ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@gsa.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@gsa.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) diff --git a/content/events/2024/08/2024-08-15-uswds-monthly-call-august-2024.md b/content/events/2024/08/2024-08-15-uswds-monthly-call-august-2024.md index 5d166ffbf0..fef4d6196b 100644 --- a/content/events/2024/08/2024-08-15-uswds-monthly-call-august-2024.md +++ b/content/events/2024/08/2024-08-15-uswds-monthly-call-august-2024.md @@ -5,7 +5,6 @@ kicker: USWDS summary: The U.S. Web Design System team will answer community questions and give an update on their work developing web components for the design system. host: U.S. Web Design System event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJItcumgrzIoHjYBsYQS-9h1vFpz0KMCvHE date: 2024-08-15 14:00:00 -0500 end_date: 2024-08-15 15:00:00 -0500 @@ -24,7 +23,6 @@ youtube_id: duomgOmMwro youtube_title: "A look at beta web components" primary_image: 2024-uswds-monthly-call-aug-title-card - --- {{< asset-static file="uswds-monthly-call-august-2024.pptx" label="View the slides (Powerpoint presentation, 3.6 MB, 48 slides)">}} @@ -33,7 +31,7 @@ primary_image: 2024-uswds-monthly-call-aug-title-card **Slide 2** My name is Dan Williams, he/him, and I'm the USWDS project lead — and here on-screen is my avatar: dark hair, blue sweater, collared shirt. As of this month, the avatar now has glasses — matching real life me, who's wearing a gray shirt today, and yellow socks, approximately gold-30v. As Jeannie mentioned, we are recording this call, and I'm happy to say we've started to be able to share the recordings of these monthly calls publicly. You can find pretty much everything from the last year's worth of monthly calls, back to January 2023, on our website, at [designsystem.digital.gov/about/monthly-calls](https://designsystem.digital.gov/about/monthly-calls/). 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've also started collecting each month's Q&A as a GitHub discussion linked from the monthly calls page. We've posted a link to our monthly calls page in the chat. -We'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'll do so. Otherwise, there'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's nice to know who's here. It's good to have you here today. +We'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'll do so. Otherwise, there'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's nice to know who's here. It's good to have you here today. For 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&A session at the end of this call. So thanks! And, with that, let's get started! @@ -57,12 +55,12 @@ So thanks! And, with that, let's get started! **Slide 12** And we've also got USWDS 3.9.0 on the way. And this one has a number of good improvements. -**Slide 13** Here are a couple of the key improvements in USWDS 3.9.0: +**Slide 13** Here are a couple of the key improvements in USWDS 3.9.0: *Fixes a tab order bug in the mobile header *Fixes a keyboard/mouse interaction issue in date picker *Improves performance of input mask *Improves legibility of pagination links -*Adds the ability to add a custom breakpoint to utilities +\*Adds the ability to add a custom breakpoint to utilities **Slide 14** We're working hard on USWDS 3.9.0, and this release will be available by the end of August. @@ -96,22 +94,22 @@ So in terms of the current state of that process, we’ve received several sugge **Slide 25** We ask questions like: -* Does the component support a WCAG requirement? At what level (A, double AA, triple AAA)? -* What alternatives are there to fulfill that requirement? +- Does the component support a WCAG requirement? At what level (A, double AA, triple AAA)? +- What alternatives are there to fulfill that requirement? -* Does the component have a clear purpose and address a user need? +- Does the component have a clear purpose and address a user need? -* Is there an existing solution in USWDS that better meets the need than the proposed solution? If there is, we likely won’t move forward with that proposal. +- Is there an existing solution in USWDS that better meets the need than the proposed solution? If there is, we likely won’t move forward with that proposal. **Slide 26** And then we consider what might _not_ support this proposal. **Slide 27** We ask: -* Do the usability and accessibility _benefits_ outweigh any potential _risks_? +- Do the usability and accessibility _benefits_ outweigh any potential _risks_? -* Is this _particular_ solution needed by the USWDS community? +- Is this _particular_ solution needed by the USWDS community? -* Has it been requested, how often, _or_ to what extent is it already being used across the government digital landscape? Have teams or other agency design systems created their own, since they couldn’t find it in USWDS? +- Has it been requested, how often, _or_ to what extent is it already being used across the government digital landscape? Have teams or other agency design systems created their own, since they couldn’t find it in USWDS? **Slide 28** We document answers to these questions in a simple rubric that gives us a high level picture. This slide shows these questions with columns for yes, somewhat, and no. The answer to these questions needs to be “Yes” for most of them (except for the middle question about whether there’s an _existing_ solution to fulfill the need, which should be a “no”). If _so_, we’ll feel more confident moving ahead. @@ -133,7 +131,7 @@ We’ll do regular testing on every component, including this one, to make sure Dan: Thanks Anne. Dan here. We’ve been asked for years about modern design tool support. Now, as I get started, we talk about specific tools at these calls, and we do have to get into the nitty gritty of support for specific products, but, as it says on the box, all references to specific brands, products, and companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency. -There are a couple great open source USWDS Figma design kits out there and available, but we _do_ want to support some of these tools more directly for a couple key reasons. +There are a couple great open source USWDS Figma design kits out there and available, but we _do_ want to support some of these tools more directly for a couple key reasons. As we move forward into USWDS Web Components, we will be thinking hard about component configuration and the styling and functionality dials and switches you can set in your theme. The more configuration we build into our components, the closer our design assets will need to match the final functionality. We'll also need to be thinking not just from the code side but from the design side as well — when designers are using this kit, what types of flexibility do they need to support their projects? Today, design tools better support this connection between design and development. Since this connection is at the front of our mind in our shift to Web Components, it makes more and more sense for us to engage with these tools directly. @@ -161,7 +159,7 @@ With `add text` we can give it a size and a font connected to USWDS tokens. It s `open variables`: If I go into primary, I can set all the defaults and change things to be specific to your theme. You can define themes just like you would in code. The way we manipulate themes in the Figma kit is through layer modes, which are connected to modes in Figma. So we select a surrounding frame to assign a mode to a frame, and can see the colors change based on the new theme we applied. -Typefaces are hard to do consistently. But we support more than Public Sans, and have the ability now to change faces with normalization applied using layer modes. +Typefaces are hard to do consistently. But we support more than Public Sans, and have the ability now to change faces with normalization applied using layer modes. `font role heading to serif and back`: This all happens at the layer mode level, so you can experiment with looking at a design through different themes. So copy this over, and you can look at the original theme applied. `see all layouts updated to the proper sizes of Source Sans Pro` begins to put some of the ideas of theming that we have in design system code into the design assets, which will also apply to components. @@ -178,15 +176,15 @@ So this is important to us, and one of the key elements in our vision of empower **Slide 36** The USWDS Beta Design Kit in Figma will feature: -* Design tokens as variables +- Design tokens as variables -* Attribute-powered components +- Attribute-powered components -* Mode-based fonts and themes +- Mode-based fonts and themes -* Extensive examples and guidance +- Extensive examples and guidance -* And of course, auto layout, and other native functionality. +- And of course, auto layout, and other native functionality. More to come on this. We hope to begin publishing our work soon. @@ -210,7 +208,7 @@ Matt: Sure can. Hey yall, Matt Henry. Acting Engineering Lead for the design sys **Slide 43** Dan: Thanks Matt and Amy. This is Dan again. So we're expecting to get an initial package for this work out tomorrow via npm (at uswds/web-components). This will still feature alpha components, but the npm package will be a good way to track our progress — in addition to what you'll find at the project hub: [github.com/uswds/web-components](http://github.com/uswds/web-components). -**Slide 44** So what's next with this work? In the coming weeks, we'll be getting Banner, Identifier, and Link into the beta phase and publishing them via the web-components npm package. We'll be working on Button, Accordion, Card, Text Input, and Modal next. +**Slide 44** So what's next with this work? In the coming weeks, we'll be getting Banner, Identifier, and Link into the beta phase and publishing them via the web-components npm package. We'll be working on Button, Accordion, Card, Text Input, and Modal next. **Slide 45** And then, by the end of the fall, we should have at least a dozen components in stable Beta. We're working hard, and we'll be updating folks on our progress through all our usual channels. @@ -228,40 +226,40 @@ Have a great day and a great conclusion to your summer. We'll see you in Septemb {{< /accordion >}} -Join the U.S. Web Design System (USWDS) team to understand their progress toward developing beta web components. They’ll also answer questions and requests posted by the [community in the community choice discussion thread for the August monthly call on GitHub](https://github.com/uswds/uswds/discussions/5923). +Join the U.S. Web Design System (USWDS) team to understand their progress toward developing beta web components. They’ll also answer questions and requests posted by the [community in the community choice discussion thread for the August monthly call on GitHub](https://github.com/uswds/uswds/discussions/5923). In this online session with the USWDS team, you will: -* Learn how to use beta versions of our next batch of new web components -* Gain insight to the USWDS team’s progress on building a Figma design kit -* Get our answers to your community choice questions +- Learn how to use beta versions of our next batch of new web components +- Gain insight to the USWDS team’s progress on building a Figma design kit +- Get our answers to your community choice questions **This event is best suited for:** Design system users of all levels. This will be a technical discussion geared toward developers, but anyone can attend; it requires no specialized knowledge. **Speakers** -* **Dan Williams** - Product Lead, USWDS -* **Matt Henry** - Engineering Lead, USWDS -* **Anne Petersen** - Experience Design Lead, USWDS -* **Amy Leadem** - Developer, USWDS contractor +- **Dan Williams** - Product Lead, USWDS +- **Matt Henry** - Engineering Lead, USWDS +- **Anne Petersen** - Experience Design Lead, USWDS +- **Amy Leadem** - Developer, USWDS contractor ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@gsa.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@gsa.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) --- -*Disclaimer*: 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. +_Disclaimer_: 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. diff --git a/content/events/2024/09/2024-09-19-uswds-monthly-call-september-2024.md b/content/events/2024/09/2024-09-19-uswds-monthly-call-september-2024.md index c97bec6f01..62068fa797 100644 --- a/content/events/2024/09/2024-09-19-uswds-monthly-call-september-2024.md +++ b/content/events/2024/09/2024-09-19-uswds-monthly-call-september-2024.md @@ -2,9 +2,8 @@ title: USWDS Monthly Call - September 2024 deck: The landscape of Web Components kicker: USWDS -summary: The U.S. Web Design System team will share their exploration of Web Component-based design systems and best practices. +summary: The U.S. Web Design System team will share their exploration of Web Component-based design systems and best practices. event_organizer: Digital.gov -cop_events: "" registration_url: https://gsa.zoomgov.com/meeting/register/vJIsdemgrT8tHZvOdHYHRTKhveBs1rHPdBc date: 2024-09-19 14:00:00 -0500 end_date: 2024-09-19 15:00:00 -0500 @@ -22,7 +21,6 @@ slug: uswds-monthly-call-september-2024 event_platform: zoom primary_image: 2024-uswds-monthly-call-sep-title-card - --- {{< asset-static file="uswds-monthly-call-september-2024.pptx" label="View the slides (Powerpoint presentation, 6.7 MB, 75 slides)">}} @@ -53,11 +51,11 @@ For those of you who find the chat distracting, you’re welcome to close or hid **Slide 10:** As a reminder, here's some of [what's coming in USWDS 3.9.0](https://github.com/uswds/uswds/milestone/154). -* Fixes a tab order bug in the mobile header -* Fixes a keyboard/mouse interaction issue in date picker -* Improves performance of input mask -* Improves legibility of pagination links -* Adds ability to add custom breakpoints to utilities +- Fixes a tab order bug in the mobile header +- Fixes a keyboard/mouse interaction issue in date picker +- Improves performance of input mask +- Improves legibility of pagination links +- Adds ability to add custom breakpoints to utilities **Slide 11:** We're also continuing progress with publishing accessibility test pages. We've got three new ones up on the site now: Checkbox, Radio button, and Combo box. We're posting links to these new pages in the chat, _and_ we're working on three new component test pages for next month: TK. So stay tuned for those! @@ -81,7 +79,7 @@ Dan: Thanks Matt! **Slide 16:** I'd also like to introduce Jacline Contrino, our UX researcher, and a contractor on the USWDS team. Jacline, can you introduce yourself and give a quick self description? -Jacline: Sure. Hi everyone, I’m Jacline. I use she/her pronouns and today I’m wearing a pink and white striped button-up shirt and big gold hoop earrings. I have shoulder length brown curly hair. +Jacline: Sure. Hi everyone, I’m Jacline. I use she/her pronouns and today I’m wearing a pink and white striped button-up shirt and big gold hoop earrings. I have shoulder length brown curly hair. Dan: Thanks Jacline! Why don't you take it from here and talk about what we've been doing? @@ -97,12 +95,12 @@ And **performance**: How fast do they load? How much code do they require? How a **Slide 19:** Those are just a few of our questions — and since it’s nearly impossible to answer all of them with a single research approach, we’re using several methods, such as: -* A **landscape analysis** of design systems that offer Web Components. What are other design systems doing and what might we want to adopt? -* A **survey** to gauge government team size, staffing, tech stacks used, familiarity with certain programming languages, and more. -***Discussions** with teams that are already building with Web Components. -* Doing one-on-one **interviews** for more in-depth and technical conversations with experts to learn about their experiences and lessons learned. -* And finally, the **beta program** itself, and the feedback and issues you provide. -* We’re nearly done with the landscape analysis and have completed the survey. We’ve started interviewing folks individually and will continue to do that for the next few weeks. +- A **landscape analysis** of design systems that offer Web Components. What are other design systems doing and what might we want to adopt? +- A **survey** to gauge government team size, staffing, tech stacks used, familiarity with certain programming languages, and more. + **\*Discussions** with teams that are already building with Web Components. +- Doing one-on-one **interviews** for more in-depth and technical conversations with experts to learn about their experiences and lessons learned. +- And finally, the **beta program** itself, and the feedback and issues you provide. +- We’re nearly done with the landscape analysis and have completed the survey. We’ve started interviewing folks individually and will continue to do that for the next few weeks. **Slide 20:** So, let’s talk about what we found with our “Government teams and tools survey.” We sent out a survey last month to gauge team structures, resources, and technology of government digital or product teams. @@ -146,10 +144,10 @@ And finally, now that we know a bit more about the tech stacks used on many gove **Slide 33:** We were interested in a few specific categories: -* **Documentation**: What are other design systems prioritizing in terms of Web Component documentation? What types of content do we see? -* **Code structure**: How are other design systems building Web Components? What's their component model? How does content and data get into them? In general, from a developer's perspective: what does a component look like? -* **Code size and performance**: How big are these things? How much data does a browser have to load before the component loads? Is there any commonality around a component's footprint, when comparing similar components? -* and **Distribution**: How are these components getting from the design system to the project using it? How are they loaded onto the page? How straightforward is it to add a component to a project? +- **Documentation**: What are other design systems prioritizing in terms of Web Component documentation? What types of content do we see? +- **Code structure**: How are other design systems building Web Components? What's their component model? How does content and data get into them? In general, from a developer's perspective: what does a component look like? +- **Code size and performance**: How big are these things? How much data does a browser have to load before the component loads? Is there any commonality around a component's footprint, when comparing similar components? +- and **Distribution**: How are these components getting from the design system to the project using it? How are they loaded onto the page? How straightforward is it to add a component to a project? **Slide 34:** We’re approaching this landscape analysis in a collaborative way, since there's a lot of subject matter expertise required to collect and understand this information! Our three senior developers have been working with me, and we’re also working closely with our Product Lead (Dan) and Engineering Lead (Matt) on the fed side. @@ -165,9 +163,10 @@ This effort is still ongoing but here’s what we've learned so far, starting wi **Slide 37:** Essentially, documentation helps you do what you need to do. What were we trying to do? Well, we looked at a few tasks: -***Getting familiar with a component**: Kicking the tires, as it were - understanding how to work with a component as directly as possible. -* **Installing a component into a project**: How do you get it and use it? -* and **Configuring and customizing a component**: How can you make a component do what you need it to do? Either changing what it does or changing how it looks. +**\*Getting familiar with a component**: Kicking the tires, as it were - understanding how to work with a component as directly as possible. + +- **Installing a component into a project**: How do you get it and use it? +- and **Configuring and customizing a component**: How can you make a component do what you need it to do? Either changing what it does or changing how it looks. **Slide 38:** Let’s talk about the ways documentation can help users get familiar with a component. @@ -193,22 +192,22 @@ So we took note of how other design systems are documenting their Web Component **Slide 41:** When it comes to documenting an API, there are a number of common ways of interacting with components reflected in documentation. -* **Properties**: Settings passed to component markup. For example, an alert component may have a `variant` property that can be set to something like `warning`, `info`, or `error` depending on the type of alert. This property usually changes the color of the alert and its icon. -* **Events**: Data a component sends based on a component interaction. For example, an input component may have a `blur` event that the component emits (or "fires") when a user navigates away from the input and it loses focus. (It loses focus, thus, "blur"). -* **Slots**: Named content regions inside a component. For example, a Card component might have a slot named `footer` where you'd add the content that belongs at the bottom of the card. -* **Parts**: Subsections of a component, styleable with CSS. For example, an Accordion component might have a part for an individual item's open/close indicator. -* and **Tokens**: CSS variables that influence component styling. For example, an `card-border-radius` CSS variable might set the border radius for all application cards. +- **Properties**: Settings passed to component markup. For example, an alert component may have a `variant` property that can be set to something like `warning`, `info`, or `error` depending on the type of alert. This property usually changes the color of the alert and its icon. +- **Events**: Data a component sends based on a component interaction. For example, an input component may have a `blur` event that the component emits (or "fires") when a user navigates away from the input and it loses focus. (It loses focus, thus, "blur"). +- **Slots**: Named content regions inside a component. For example, a Card component might have a slot named `footer` where you'd add the content that belongs at the bottom of the card. +- **Parts**: Subsections of a component, styleable with CSS. For example, an Accordion component might have a part for an individual item's open/close indicator. +- and **Tokens**: CSS variables that influence component styling. For example, an `card-border-radius` CSS variable might set the border radius for all application cards. Pretty much every component has properties of some sort, and we see property documentation in any Web Components–based design system. The rest of the elements of an API can vary from system to system and component to component. Less common elements of an API, but still potentially useful include: -* **Methods**, which are JavaScript-specific controls for component interactivity. -* and **Content model**, which is a way to group properties that accept content together. +- **Methods**, which are JavaScript-specific controls for component interactivity. +- and **Content model**, which is a way to group properties that accept content together. **Slide 42:** We found that overall, Web Component API shared some structural commonalities. -* APIs are consistently organized using the categories we looked at in the previous slide. -* The API almost always appears on the same page as other component information, though it can occasionally appear in a page-level tab. -* API documentation is consistently organized using tables showing the names of the API items, the type of data they accept, and their default value. +- APIs are consistently organized using the categories we looked at in the previous slide. +- The API almost always appears on the same page as other component information, though it can occasionally appear in a page-level tab. +- API documentation is consistently organized using tables showing the names of the API items, the type of data they accept, and their default value. And all of this tends to be more understandable when it's tied either to some kind of example, or to an interactive component where you can try out the setting in the component. @@ -240,12 +239,12 @@ Across design systems, status tags serve as a kind of mini set of dashboard ligh **Slide 50:** Dan: This is Dan. Documentation is a huge subject, and while there are lots of ways to approach guidance across design systems, we've identified a few key common user stories related to technical guidance for components. We need to support: -* At-a-glance confirmation that a component is OK to use. -* An obvious location for Web Components documentation, connected to our existing documentation. -* The ability to interact with the component before installing it into a project. -* Succinct component-level installation instructions. -* Clear and logical API guidance alongside an interactive component. -* A documentation-driven approach that keeps documentation current with functionality. +- At-a-glance confirmation that a component is OK to use. +- An obvious location for Web Components documentation, connected to our existing documentation. +- The ability to interact with the component before installing it into a project. +- Succinct component-level installation instructions. +- Clear and logical API guidance alongside an interactive component. +- A documentation-driven approach that keeps documentation current with functionality. Back to you Jacline! @@ -321,11 +320,11 @@ It's still pretty early in our performance analysis, but we want to be really co First, our design principles: -* Start with real user needs -* Earn trust -* Embrace accessibility -* Promote continuity -* Listen +- Start with real user needs +- Earn trust +- Embrace accessibility +- Promote continuity +- Listen And next our mission, vision, and polestar: Helping government teams align, design, and keep their websites and services up to date. In the service of empowered and supported digital service teams and familiar and easy-to-use digital services. So, together we can shape the future of government digital services. @@ -335,44 +334,40 @@ These aren't abstract things, they influence what we do and our approach to judg {{< /accordion >}} - - - -This month, join the U.S. Web Design System (USWDS) team in exploring the landscape of Web Components. The team will share their recent landscape analysis of Web Components-based design systems and discuss how these findings set a course for future USWDS development. +This month, join the U.S. Web Design System (USWDS) team in exploring the landscape of Web Components. The team will share their recent landscape analysis of Web Components-based design systems and discuss how these findings set a course for future USWDS development. In this online session with the USWDS team, you will: -* Learn what’s new in USWDS 3.9 -* Explore how other design systems are approaching Web Components -* Gain insight to the team’s thoughts about where USWDS might fit in the broader landscape of modern design systems - +- Learn what’s new in USWDS 3.9 +- Explore how other design systems are approaching Web Components +- Gain insight to the team’s thoughts about where USWDS might fit in the broader landscape of modern design systems **This event is best suited for:** Design system users of all levels. This will be a technical discussion geared toward developers, but anyone can attend; it requires no specialized knowledge. **Speakers** -* **Dan Williams** - Product Lead, USWDS -* **Matt Henry** - Engineering Lead, USWDS -* **Anne Petersen** - Experience Design Lead, USWDS -* **Jacline Contrino** - UX Researcher, USWDS contractor +- **Dan Williams** - Product Lead, USWDS +- **Matt Henry** - Engineering Lead, USWDS +- **Anne Petersen** - Experience Design Lead, USWDS +- **Jacline Contrino** - UX Researcher, USWDS contractor ## Join our Communities of Practice -* [USWDS](https://designsystem.digital.gov/about/community/) -* [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) +- [USWDS](https://designsystem.digital.gov/about/community/) +- [Section 508 IT Accessibility](https://www.section508.gov/manage/join-the-508-community/) -*This 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.* +_This 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._ ## About the USWDS [The U.S. Web Design System](https://designsystem.digital.gov/) 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. -* [The U.S. Web Design System](https://designsystem.digital.gov/) -* [Contribute on GitHub](https://github.com/uswds/uswds/issues) -* [Email Us](mailto:uswds@gsa.gov) -* [Join our community](https://digital.gov/communities/uswds/) -* [Follow @uswds on Twitter](https://twitter.com/uswds) +- [The U.S. Web Design System](https://designsystem.digital.gov/) +- [Contribute on GitHub](https://github.com/uswds/uswds/issues) +- [Email Us](mailto:uswds@gsa.gov) +- [Join our community](https://digital.gov/communities/uswds/) +- [Follow @uswds on Twitter](https://twitter.com/uswds) --- -*Disclaimer*: 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. +_Disclaimer_: 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. diff --git a/content/events/2024/10/2024-10-01-multilingual-search-engine-optimization-seo.md b/content/events/2024/10/2024-10-01-multilingual-search-engine-optimization-seo.md index 21d26bd802..776fd5164b 100644 --- a/content/events/2024/10/2024-10-01-multilingual-search-engine-optimization-seo.md +++ b/content/events/2024/10/2024-10-01-multilingual-search-engine-optimization-seo.md @@ -3,41 +3,41 @@ title: "Multilingual search engine optimization (SEO)" deck: "Improve the findability of multilingual content" summary: "Understand how search engines work, how people search online, and who is your audience — while recognizing language and cultural differences." event_organizer: Digital.gov -cop_events: +event_cop: - multilingual registration_url: https://gsa.zoomgov.com/meeting/register/vJItduivpzgrHkrXVyxLGsQH_vE3xukqNG4#/registration slug: multilingual-search-engine-optimization-seo -date: 2024-10-10 14:00:00 -0500 -end_date: 2024-10-10 15:00:00 -0500 +date: 2024-10-20 14:00:00 -0500 +end_date: 2024-10-20 15:00:00 -0500 # zoom, youtube_live, adobe_connect, google event_platform: zoom primary_image: "2024-09-11-multilingual-webinar-seo-title-card" - --- + {{< asset-static file="2024-10-10-multilingual-webinar-slides.pptx" label="View the slides (PowerPoint presentation, 6.5 MB, 28 pages)" >}} -Search engine optimization (SEO) involves optimizing websites and their pages to be indexed and surfaced by search engines. +Search engine optimization (SEO) involves optimizing websites and their pages to be indexed and surfaced by search engines. -Join us for a webinar with the National Cancer Institute to discuss how to improve SEO for multilingual content. +Join us for a webinar with the National Cancer Institute to discuss how to improve SEO for multilingual content. In this session, you’ll learn how to: -* Kickstart your search engine optimization efforts by understanding SEO best practices -* Define SEO best practices in translation -* Implement page-level optimization practices for Spanish content +- Kickstart your search engine optimization efforts by understanding SEO best practices +- Define SEO best practices in translation +- Implement page-level optimization practices for Spanish content **This event is best suited for:** Intermediate web content managers and multilingual specialists. ## Speakers -* **Laura Godfrey** - Multilingual Community Lead -* **Linda Saucedo** - Translation Program Manager, NCI contractor +- **Laura Godfrey** - Multilingual Community Lead +- **Linda Saucedo** - Translation Program Manager, NCI contractor ## You may also be interested in: -* [Top 10 best practices for multilingual websites](https://digital.gov/resources/top-10-best-practices-for-multilingual-websites/) -* [Tips to create, maintain, and present non-English digital content](https://digital.gov/2022/05/23/10-tips-to-create-maintain-and-present-non-english-digital-content-a-qa-with-michael-mule/) +- [Top 10 best practices for multilingual websites](https://digital.gov/resources/top-10-best-practices-for-multilingual-websites/) +- [Tips to create, maintain, and present non-English digital content](https://digital.gov/2022/05/23/10-tips-to-create-maintain-and-present-non-english-digital-content-a-qa-with-michael-mule/) --- -*The Multilingual Community of Practice is a group of government digital professionals working to expand and improve digital content in languages other than English. [Join the Multilingual Community](https://digital.gov/communities/multilingual/)*  +_The Multilingual Community of Practice is a group of government digital professionals working to expand and improve digital content in languages other than English. [Join the Multilingual Community](https://digital.gov/communities/multilingual/)_ diff --git a/themes/digital.gov/layouts/partials/core/get-upcomingevents.html b/themes/digital.gov/layouts/partials/core/get-upcomingevents.html index e9c70de159..5633ea0c7c 100644 --- a/themes/digital.gov/layouts/partials/core/get-upcomingevents.html +++ b/themes/digital.gov/layouts/partials/core/get-upcomingevents.html @@ -1,24 +1,38 @@ -{{/* ====================================== - Get Upcoming Events by events with current date - ====================================== +{{/* ===== + Display upcoming events associated with a community of practice */}} -
- {{/* Gets the upcoming events */}} - {{- $upcoming_events := where (where .Site.RegularPages.ByDate.Reverse "Section" "events") ".Date.Unix" ">" now.Unix -}} - {{ $upcoming_events := $upcoming_events | intersect (where $upcoming_events "Date" ">" now) }} - {{ $total_events := where $upcoming_events ".Params.event_cop" "intersect" .Params.event_cop }} - {{ if $total_events }} -

Upcoming Events

-
+{{ end }} diff --git a/themes/digital.gov/static/workflow/config.yml b/themes/digital.gov/static/workflow/config.yml index 95a0647e42..6b920a9649 100644 --- a/themes/digital.gov/static/workflow/config.yml +++ b/themes/digital.gov/static/workflow/config.yml @@ -388,12 +388,22 @@ collections: widget: "string" default: "Digital.gov" - label: "Event Related CoP" - name: "cop_events" + name: "event_cop" widget: "select" - options: ["communicators", "multilingual", "plain-language", "web-managers", "web-analytics", "social-media", "user-experience"] + options: + [ + "contact-center", + "communicators", + "multilingual", + "plain-language", + "web-managers", + "web-analytics", + "social-media", + "user-experience", + ] collection: "events" default: "" - multiple: true + multiple: false required: false hint: "Associate any Community of Practices with the event" - label: "Registration URL" @@ -786,7 +796,6 @@ collections: required: false <<: *editorComponents - # SHORT LINK ======================= - <<: *defaults name: "shortlink" @@ -1047,11 +1056,15 @@ collections: - label: "File" name: "file" widget: "file" - pattern: ['.*\.(doc|docx|pdf|ppt|pptx|pptm|xls|xlsx)$', "Allowed files are .pdf, .xls/x, .doc/x, .ppt/x/m"] + pattern: + [ + '.*\.(doc|docx|pdf|ppt|pptx|pptm|xls|xlsx)$', + "Allowed files are .pdf, .xls/x, .doc/x, .ppt/x/m", + ] media_library: config: multiple: true - + # IMAGE UPLOAD ======================= - <<: *defaults name: "image-upload"