DEV Community: Liz Wait

From Dough to Deliverables: A Design System-Pizza Analogy

Liz Wait — Mon, 31 Jul 2023 23:29:33 +0000

Defining what a Design System is isn't the easiest thing to do. A design system depends on the purpose and goals of a team and brand.

"A design system is a set of interconnected patterns and shared practices coherently organized to serve the purpose of a digital product." -Alla Kholmatova

This quote by, Alla Knolmatova is a great overall definition of a Design System. We also get a pretty good idea of what a design system is simply by the definition of a system, which is a set of principles or procedures according to which something is done; an organized framework or method.

My interest in Design Systems came naturally due to my love for organization, meaningful documentation, and scalable solutions. I took a deep dive this past year and also presented a talk distinguishing similarities and differences of design systems for the Kansas City Developer Conference titled: "Web-Centric and Native Design Systems: How Different Are They?"

Part of this talk touched on elements of a Design System. Being an introduction and overview talk, I wanted to create a relatable comparison to these elements with something everyone already knows and loves - PIZZA!

Before we get started on the pizza analogies, let's touch on some design system benefits.

Benefits of a Design System

These are just a few benefits of using a Design System.
Design Systems bring order and consistency to your product and team.

Establishing patterns and principles to prevent reinventing the wheel and solve problems consistently.
Ensures collaboration between designers and developers with a single source of truth.
Provides clarity on design principles, purpose, and iterative improvements.

Consistency

Consistent style guides across different apps strengthen brand recognition. Users associate the same style with the brand, enhancing usability and recognition.

Scaling

They are also crucial for maintaining consistency and efficiency as products scale. Design Systems create a centralized location for UI and other design elements

Quality

Testing code, components, and tokens within a Design System ensure that there will be fewer quality issues when those elements are used for your products.

Resource Saving

Design systems help by saving development time by utilizing reusable components. They aid developers by helping them focus on complex problems, avoiding disorder and bugs.

New team members can explore established Design Systems for inspiration and learning.

Building upon existing ideas while creating a unique identity for your product.

Streamline Processes

Having shared terminology and vision for an entire product team including design, copy, development, program managers, etc is incredibly important. This ensures that as a team there's no question as to what our brand values and expected outcome are for our product.

Documentation

Good documentation is crucial for any project. Design systems ensure comprehensive documentation. This helps new project members onboard quickly and understand your system and processes.

Build Upon Existing Design Systems

Design Systems are iterative and versioned to create a system that can be improved upon, enhanced, and up-to-date with the newest technologies available.

Governance

A design system gives you guidelines on what you can and cannot do with your brand identity.

Now it's PIZZA TIME!

Design System Elements

When considering the order of design system elements, it's important to note that there is no one-size-fits-all approach, and the order may vary based on the specific needs and priorities of your design system.
Throughout these definitions and comparisons to pizza, I'll also add links to IBM's Carbon Design System for examples for each section.

When defining each of these design system elements, I'll compare it to a pizza-making analogy.

Brand Values

For our first example, Brand Values could shape the unique characteristics and flavors associated with a particular pizzeria. For example, a pizzeria that values authenticity might focus on traditional Italian ingredients and cooking techniques - while a pizzeria with a modern brand might experiment with innovative toppings and flavor combinations such as this pineapple, onion, olive, and corn pizza.

Start your Design System by establishing and defining the Brand Values. These values serve as the foundation for the design system and inform the overall visual identity, tone, and personality of the brand. Brand Values give our design system its unique character, setting it apart from others and providing us with a clear direction.

They aid in creating a Visual Identity. Brand Values guide the selection of colors, typography, and imagery, creating a consistent and cohesive look and feel.

Brand Values define how we communicate with users, whether it's playful, sophisticated, or a mix of both by setting a tone and voice.

Helps to establish a meaningful connection with users, evoking the desired emotions using the before mentioned tones and voice to build a purposeful bond.

Brand Values set us apart from the competition, making our design system strong, unique, and memorable.
IBM Carbon Design System Brand Values (Typography Example)

Accessibility

In the context of pizza, Accessibility guidelines would involve considering dietary restrictions or the preferences of customers.

For example, offering gluten-free or vegan options ensures that individuals with specific dietary needs can enjoy pizza without limitations. It involves catering to a diverse range of customers, just like Accessibility considerations in design systems aim to provide an inclusive user experience.

It's important to consider Accessibility early in the design system process. Accessibility should be integrated throughout a design system to ensure that it meets the needs of all users, regardless of disabilities or impairments.

When designing and developing a design system with Accessibility in mind, here are some common Accessibility guidelines and considerations that should be incorporated:

Making all interactive elements keyboard accessible for seamless navigation and interaction.
Proper HTML structure and headings for Accessibility. For example, utilize heading elements such as H1, H2, and H3 headers in order, to establish a logical hierarchy.
Using ARIA labels helps to improve a user's comprehension of custom components and interactive elements when using tech assistance.
Include descriptive alt text for images, icons, and other visuals that aren’t solely decorative to convey their purpose or meaning to users who cannot see them.
Maintain readable content for users with visual impairments by ensuring adequate color contrast between text and background elements.
Include captions or transcripts for multimedia content like videos and audio files.
Ensure a consistent and predictable layout and navigation structure.
Provide a visible focus indicator for interactive elements when they are active.

IBM Carbon Design System Accessibility Considerations

Design Tokens

Design Tokens in our pizza analogy would be the standardized measurements and ratios used in our secret recipes.

Just like Design Tokens define the visual properties in a design system, tokens in pizza-making could include specific measurements for ingredients such as cups of flour, teaspoons of yeast, grams of cheese, and dashes of spices. These tokens ensure consistent proportions and flavors in the pizza.

Design Tokens are the foundational building blocks of our design system. They are small, reusable pieces of design information that represent visual properties such as colors, typography, and spacing.

IBM Carbon Design System Design Tokens

Components

In the context of making pizza, Components would be similar to the individual ingredients that come together to create the final pizza product.

Design Components and Mise en place are surprisingly very similar!

Just as a chef prepares ingredients ahead of time to make building the pizza more seamless - We use design tokens to build Components.

Examples of Components for pizza could include dough, sauce, cheese mixes, and toppings. Each component plays a specific role and can be combined in many different ways to create various types of pizza.

Components are reusable UI elements that ensure consistent design and functionality across the product. Examples include buttons, forms, navigation bars, cards, and other building blocks. They promote efficiency, reduce redundancy, and maintain design and interaction consistency and predictability. Components streamline collaboration, enable scalability, and uphold brand identity.

By utilizing design Components within a design system, designers and developers can create interfaces more efficiently, maintain consistency, and improve collaboration across teams working on the same project or brand.

IBM Carbon Design System Components

Patterns

Pizza-making also involves Patterns that help achieve consistent results.

For instance, the process of stretching and shaping the dough into a round shape, spreading sauce evenly, and layering toppings in a specific order can be considered Patterns. These Patterns ensure a consistent pizza-making process and a predictable outcome.

Patterns are reusable design solutions that can be applied to different parts of a product or sections of a page.
Using established Patterns saves time and effort by providing ready-made solutions to common design challenges. Designers can streamline their processes and create efficient designs.
Patterns are informed by user research and testing, ensuring they meet user needs and preferences. By incorporating proven Patterns, designers can enhance the overall user experience.

IBM Carbon Design System Patterns

Style Guide

The last step in our pizza analogy is a Style Guide. This would be similar to a recipe book or a set of instructions that provides guidelines for making pizza.

It would include details such as the preferred type of dough, recommended cooking temperature and time, specific sauce recipes, and guidelines for selecting toppings.

Your recipe book or pizza Style Guide helps maintain consistency in the pizza-making process and ensures that pizzas adhere to an expected style or brand.

Think of a Style Guide as the blueprint for a specific building, it provides a framework for maintaining consistency in the visual identity and user experience across various applications, platforms, and touchpoints.

Overall, a Style Guide serves as a reference and resource for designers and developers working with a Design System. It ensures consistency, clarity, and efficiency in the implementation of the visual and design aspects of a product or brand.

IBM Carbon Design System Style Guide

This is just a taste (no pun intended) of what Design Systems have to offer.

I hope that this comparison has helped Design System elements resonate with you and helps kick off your own deep dive into Design Systems!

Importance of Incorporating Accessibility Considerations in Mobile Applications

Liz Wait — Sat, 13 May 2023 04:44:32 +0000

"According to the World Health Organization (WHO), over 1 billion people worldwide have some form of disability (57 million in the United States alone) - a number that is only increasing as the population ages." - World Health Organization Statistics

Don't Make Assumptions

"There can't be that many people with disabilities that use this app"

If one person with disabilities uses your app, you need to make accessibility considerations. It's important to consider situational and temporary disabilities as well.

Potential Disability Considerations

Mobility
Situational: Bruised knee
Arthritis, amputation, paralysis
Vision
Situational: Eye scratch, dilated pupils, you walked outside of a dark room on a sunny day
Color blindness, loss of vision, night blindness
Cognitive
Situational: Concussion
Memory loss, brain injury, dyslexia, ADHD
Hearing
Situational: Air pressure from flying in a plane, a night or morning after a concert, migraine.
Missing high-pitched or low-pitched sounds, total hearing loss in one or both ears

Adopting Accessibility Inclusion Early Will Save You Time and Money

If you've read or heard me talk on this subject before, I sound like a broken record. If we make accessibility considerations from the beginning of an app. This will take buy-in from the business as well but will save us budget in the long run and time.

Beginning of owning an app, audit the existing application to see what the current state of accessibility is and then make an effort to update accessibility as soon as possible. Create maintenance tickets to address these concerns and don't lose them in your backlog.

Avoid Lawsuits and Bad Practices

None of us want to get to this point. Having confidence that your team has been mindful of accessibility throughout your development lifecycle will ensure that your app will not be targeted by lawsuits.

Incorporate Accessibility Requirements Within Your Tickets

To ensure new features or updates to existing features include work for accessibility, it's important to include accessibility acceptance criteria such as adding labels, tags, screen reader enhancements, and dynamic fonts, to enhance and create the most accessible additions and updates to your project as possible.

Accessibility Acceptance Criteria Examples

Stick to clear gherkin scenarios
Provides Given > When > Then criteria

Stick to clear nomenclature
"Link component" or "video player"

Stick to clear action words
Focus, hear, click, scroll, hover

Stick to simple scenarios
More granularity is important here. If it's encompassed in a development effort, likely one scenario

As a **low-vision** user
GIVEN an image container
WHEN the user focuses on an image container
THEN the user can/should see alt-text on hover hear alt-text on screen reader

Add Accessibility Acceptance Criteria to Tickets

Example: Use the device screenreader to ensure the expected screen reader experience
Long-term - Short term - Situational As referenced earlier, there are severities when considering disabilities. Using the POUR principles - we can categorize these as well as note severity examples.

Stay True to Native Functionality and Consistency

Native functionality

Users become accustomed to the native behavior and appearance of their devices. Developers and Designers must consider native application behavior and appearance when creating, maintaining, and enhancing an application.
Straying too far from native behavior and appearance can confuse any user. This is also an accessibility issue.

Consistency

Piggybacking off of native functionality which is also a consistency concern, it's important to make sure your application is consistent throughout with functionality and design. You want to make sure that selections, forms, appearance, etc stay the same throughout the app.

Other Accessibility Concerns for Mobile Applications

Touch target sizes including button placement and size
Ensure text size is dynamic and can be enlarged or reduced in size with native accessibility options.
Important elements should appear on the screen before scrolling is necessary. Ensure scrolling is free from barriers.
Screenreader labels, switch tabbing, and alternative gestures work as expected.

Additional Resources for Mobile Accessibility

24 Hours Sitting in a Folding Chair and Other Hackathon Stories From a First-Timer

Liz Wait — Fri, 12 May 2023 21:10:43 +0000

Last summer, I attended my first in-person hackathon, Hack Midwest, with an amazing, all female developer team! I wasn't sure what to expect going into the experience but, I learned a lot and had a great time!

Did I pack things to bring I ended stuff using at all? YES.

Did I not pack things I should have? Also, YES.

Could I have prepared more? Heck yes.

A Bit About Hack Midwest

Hack Midwest is a yearly hackathon located in downtown Kansas City. It takes place over the course of a weekend, starting Saturday morning and ending on Sunday afternoon/early evening. You are more than welcome to stay overnight in the building to work on your projects if you'd like. I'd say about one-fourth of the attendees did this, maybe a bit more!

You cannot work on your projects away from the hackathon or prep much beforehand. We had some meetings settling on what tech stack we wanted to use, assigning roles, and getting things organized but the coding, designing, etc needed to be done while at the event itself.

Note: Scope out the surroundings of the event space. There was a TON of comfy couches and booths upstairs that were taken early on at our event.

What Should I Bring?

Besides the obvious, laptop, chargers, etc. - these things would really help your efficiency, hunger, and comfort while you code to your heart's content. Did I bring all of these things? -No but, I definitely will next time!

Small cooler - Snacks, energy drinks, fruit, cold water.
Blanket or a sweater - It was pretty chilly in the building. Also, if you want to take a li'l nap, this will be extremely helpful!
Notebook
Change of clothes, if you're staying overnight.
Yoga mat - Definitely bringing one next year. If you'd like a change of scenery or.... for naps, this would be great! Can't work too long on a cement floor!
A camping chair or chair cushion - If you decide to stay overnight or even stay pretty late in the evening, bringing your own chair or cushion would help a TON.

Event Timeline + Notes Along the Way

Including some Hack Midwest specific timelines and structure but, this may be pretty similar across the board.

Saturday
10:00 AM - Sign-in starts! Great time to get there early, check in, get settled (find a good spot) and tour the sponsor booths!
10:30 AM - Event starts roughly around this time - Create your repo and get started!

Sponsor Workshops

Sponsor workshops are presented throughout the day. These workshops are definitely optional but, may give you some extra knowledge on how to implement sponsorship technologies.

Sunday
10:00 AM - Hackathon ends! Judging begins after a short break.

Judging

Judges walk around to each team for short app demos. Your demo should be 3-5 minutes long. Plan ahead of time for what you want to say and plan out the user scenarios you'd like to show off during the demo. After the judges view demos from all teams - There will be a handful of finalists chosen to demo their apps in front of everyone.

There are several prizes! There's a grand prize but, also sponsorship prizes. I highly recommend adding one or more of the sponsors' technologies to your project, if you can.

If you have any other questions, let me know! Also, I really hope ya'll think about attending Hack Midwest (if you're in Kansas City) or, a hackathon in your area!

HTML Reporting for AxeCore

Liz Wait — Wed, 26 Jan 2022 15:59:58 +0000

Quick intro - I am a developer in test as well as an advocate for accessibility. I also drink too much coffee and love cats.

As a dev in test, automating and scaling "all of the things" is extremely important so we can focus on tasks that cannot be automated. I would say that accessibility as a whole cannot be completely automated. We still need manual checks from people to ensure that a site is accessible.

Recently I implemented Deque AxeCore within our automation test suite. Axe Core is used for many accessibility tools, including Lighthouse. The bare-bones AxeCore report is a JSON output that is not the easiest to read. I wanted to find a tool in which we could format this JSON report as HTML. With searching and great luck, I found such a tool, Axe HTML Reporter. HUGE thank you to Liliia Pelypenko (@lpelypenko ) for this great solution for AxeCore reporting!

I couldn't find a good step-by-step ReadMe that worked for my needs. So, I'm here to tell you how I implemented this HTML report to my AxeCore JSON output and, maybe it'll work for your needs too!

I'll also add that, this is to produce one HTML report and rewrite the report on each test run.

Before going on forever with backstory and making this look like a recipe blog, let's get to the good part!

The Good Part

After installing AxeCore, we'll now add the HTML reporting.
First, you'll want to install Axe HTML Reporter via NPM or, however you are most comfortable.
Once Axe HTML Reporter is installed, we'll first update the AxeHTMLReport.js file as follows:



import { createHtmlReport } from 'axe-html-reporter';
import { writeFileSync, readFileSync } from 'fs';

(() => {
    const rawAxeResults = JSON.parse(readFileSync('AxeResults.json', 'utf8'))
    createHtmlReport({
        results: rawAxeResults,
        //options available to further customize reports
        options: {
        }
    });
})();

I did leave the options area in case I wanted to add, well, options. Options are listed in the Axe HTML Report documentation.

This will grab your AxeCore JSON file, filter it through the HTML reporting and then output this HTML report accessibilityReport.html within an artifacts folder in your root project folder.

File Structure Example

Sample Test Output

Accessibility Tips for Your Twitch Channel!

Liz Wait — Wed, 03 Mar 2021 00:10:35 +0000

Visiting this post is the first step in creating an accessible Twitch channel! Thank you!

I've become very interested in accessibility within the past year or two (2020 counts as two years, right?). Ensuring your content is accessible for everyone is a win/win all around. Your viewers will have a great experience and in turn, you will gain more viewers!

Quick note - All references and tools linked below are free to use! If this changes in the future, I will try to update with new resources.

Also, accessibility is a very vast, ever-changing subject and super important! I don't have all the answers but, I hope this helps. If more things come to mind, I'll be sure to add more posts.

Alright, let's get to it!

Color Contrast

Try to refrain from light text against light backgrounds and dark text against dark backgrounds as much as possible. This also applied to illustrated and textured backgrounds. You will want to ensure your text is readable for everyone. It's also important to consider font size and boldness. There are cases where a larger font/boldness will allow for a lower contrast to be readable. This is a case-by-case basis though, not always guaranteed.

Consider this with your overlays, banner, panels, bot text color, etc.

Resources:

Color Contrast Analyzer (Chrome extension)
If you'd rather not use a plugin, I recommend WebAIM.org's Contrast Checker.
Not sure of the hex value of the colors you're checking? This Colorzilla Color Picker will come in very handy!

Screen Readers

Tabbing order and alt text are very important for users of screen readers. We aren't able to manipulate Twitch's UI but we can do our best with what we can add to our channels. One area we can change is the editable panels. Alt-text is not available for the image attachments for these panels right now. This will hopefully be available soon. For now, when adding an image, add the header or title of the panel to your text body.

Twitch panels allow for use of markdown so, you can make your headers bold, add lists, etc. This will help distinguish your content as well.

Using additional symbols in your text fields does affect screen readers and will confuse the user. Examples of this are:
~
(ﾉ'ヮ')ﾉ
✧
♡
--->
*

One more thing, adding descriptions to links is very helpful. Making your panel image clickable does not create a good user experience for screen readers. Adding the link to the panel text body with a description beforehand will be a much better experience.

Resources:

Screen reader for Mac - Apple VoiceOver
Screen reader for Windows - NVDA
Markdown Cheat Sheet

Flashing/Busy Overlays and Other Media

Keeping the focus on the streamer and the game/activity is very important! Adding gifs and overlays definitely helps show your personality as well as needed info about your stream. However, it's important to refrain from using too much flashing and movement when customizing your channel. This can be very distracting as well as make people uneasy and/or induce seizures.

Photosensitive Epilepsy Analysis Tool (PEAT)

Captioning

Captions are needed for many people. Whether it's because of a disability, your surroundings are too loud, you forgot your earbuds, or needing to keep the volume low. There are many reasons people use captions. This is just a summary of a few.

In-Game Captions

An easy accessibility fix for captions is in-game captions. Most games provide access to in-game captions through their game options.

Stream Captions Overlay

There are many different ways to add captions to your streams. First, adding a CC Twitch extension to your channel. There are a few of them available and have a relatively simple setup.

Stream Closed Captioner Extension

Using Your OBS to Create Captions

This is an excellent write-up by ScottInTokyo on some ways to add captions to Streamlabs OBS and OBS Studio.

Automatic Closed Captions on Twitch

Additional Caption Notes

Don't overlap captions - Be mindful of the orientation of your live captions and your in-game captions. If you can change the orientation of your in-game captions or live stream captions this can prevent overlap making one caption completely inaccessible.

Multiple speakers - for tabletop, talk shows, etc. At this moment, I'm not aware of a way to distinguish captions for speakers besides using a stenographer and prefixing captions with a name or having them color-coded. I would love to hear ideas as well as current projects in this space!

Be Descriptive

This suggestion is geared more towards IRL streams such as cooking, creative streams, etc. When you have the opportunity to describe your surroundings, what paint you are using, the sunset, do it. This will help those that are having trouble seeing what you're seeing or just really love the color of acrylic paint on your brush. Just something to think about. 🙂

Thank you!

Again, thanks so much for taking the time to read this. If you have any questions or have any feedback, please let me know! When I come across any more helpful accessibility tips, I'll be sure to let you know with a new post.