Saturday, July 25, 2020

Is Your Website Stressing Out Visitors?

Stress isn’t just something that makes people feel uncomfortable. It stimulates the urge to “fight” or “flight”. The very last thing you want is to design a website that stresses visitors out, leading them to dread the experience or abandon it entirely. There are many things that might invoke this response from your visitors, including the design. In the following guide, we’re going to look at some ways to de-stress your design.
Stress is a nasty thing and many of us deal with it on a regular basis. Our jobs, school, homes, relationships, and even things going on around the world can trigger feelings of panic, unease, and depression. And those are just chronic stressors. Think about the small things that send your body into instant fight-or-flight mode on a daily basis (e.g. traffic jams, unhelpful customer service reps, getting sick when you have a big project due).
The last thing you want is for someone to visit one of the websites you’ve built, only to feel like they:
  • Need to battle their way through it, or
  • Leave immediately and never come back.
There are a variety of ways a website can cause stress and leave visitors wondering if their response should be to fight or flight. Slow loading times. Overwhelming navigations. Excessive 404 errors. You get the point. But the design itself could be a problem, too.
If your bounce rates are really high and performance isn’t an issue, then this is something you need to look into. Today, we’re going to look at some ways for web designers to take traditional stress-busting tips and apply them to websites.

How To De-stress Your Web Design

Most stress relief guides provide a similar set of tips. But how exactly do you apply something like “Get outside for fresh air” to a website?
Here are some ideas:

1. Draw from Nature

There’s a reason why stress relief articles always suggest that people get outside. There’s something about nature that’s very calming.
If you think about the way we live our lives today — always on, always connected, always trying to make a better life for ourselves — it’s the exact opposite of nature. That’s probably why we’re so attracted to its simplicity and healing qualities in times of stress.
Companies with “natural” initiatives (think REI or CLIF) can get away with using imagery containing nature scenes and drawing on the feel-good vibes associated with them.

For other companies, however, you’re going to have to think outside the box as nature photographs won’t make sense for most.
Something I’d recommend instead is to look at your color palette.
One of the great things about spending time in nature is the abundance of color you’ll find. Look at any travel blog or social media account and you’ll find proof of this immediately.

There is such a vast array of colors in nature that you could draw from.
That said, nature’s colors aren’t always peaceful or safe. Take, for instance, aposematism. This is the ability animals have to signal that there’s danger here — and they do it with color.
“The function of aposematism is to prevent attack, by warning potential predators that the prey animal has defenses such as being unpalatable or poisonous.”
The most commonly seen colors in aposematism are:
  • Red,
  • Yellow,
  • Black,
  • White.
Generally, when these colors are used, it’s in high contrast to the surrounding colors and scenery, so it’s not like the actual appearance of red or black is alarming. It has to do with the context.
What I’d recommend is that you take a look at your website and note if there are any colors sending the wrong signals.
Does a dark mode-like design seem too ominous for the lighter personality of the brand? Are red accents reminiscent of blood against the stark white background? Does the bright yellow coloring feel out of place?

I suspect the web designer went out of their way to imbue the website with the sharp black and red accent colors that appear here. Bear Grylls doesn’t run some feel-good travel show. He’s always putting himself (and others) in life-or-death situations. So, in this case, the aposematism-inspired color palette is a good choice.
For your website, though, I highly doubt you want your visitors to associate the brand with danger or death. So, spend some time studying nature photography (the stuff that makes you feel good) as well as reading up on color psychology to fix the signals your website is sending to visitors.

2. Create a Predictable Rhythm

Yoga is one of those activities often recommended for people experiencing stress. As the Mayo Clinic explains:
“Yoga brings together physical and mental disciplines that may help you achieve peacefulness of body and mind. This can help you relax and manage stress and anxiety.”
At the core of yoga, is a composite of physical poses and steady breathing. If you’ve ever practiced it before, you know how good it feels when you get into the rhythm of it. Breathing in… and breathing out.
Yoga isn’t the only mindfulness practice that draws on steady breathing to calm the nerves.
If you’ve ever used a meditation app like Calm before, you’re familiar with breath exercises

As you focus on breathing in, holding that breath and releasing, your body and mind relax. Breathing exercises also help people calm hyperventilation and other erratic breathing patterns that get the heart rate up and send the mind racing.
So, how does this correlate to your website? Well, what we need to do is identify elements and interactions that feel unpredictable and shocking — ones that make visitors feel as if they have no control over the experience, like they can’t slow down and take it one bit at a time.
Rhythm and repetition play an important role in this, but you know this already. That’s why button shapes and colors are designed consistently site-wide. That’s why you choose no more than two or three fonts to establish a rhythm and dictate hierarchy in your content. That’s why you build mobile-first websites within a grid (even if the design sometimes appears asymmetrical).
The thing is, when new design patterns or elements become popular, it’s easy for these good and calming practices to go out the window.
Take, for instance, websites that use scroll-triggered animations like Unleashed.

While it’s certainly an attractive website and one that’s going to stand out from the competition, it presents an uneven experience from start to finish. Visitors are more likely to focus on the surprises that wait for them around the corner instead of on reading the content on the site (which is difficult with the way it’s presented).
This website is all about building anticipation; not value.

The big difference here is that hover-triggered animations don’t have to come at the expense of the predictability of the design or your visitors’ comfort levels.
Just be mindful of this. While it might seem like trying something new is what your site needs to stand out, don’t forget that you’re designing primarily for the user experience. And if users aren’t responding well to the creative choices you’ve made, it’s time to bring back a more stable rhythm to it.

3. Remove the Excess Noise

For a long time now, researchers have studied and reported on the damaging and stress-inducing effects environmental noise can have on people.
“Babisch established the modern noise reaction model, postulating an ‘indirect pathway,’ in which disturbance of sleep, communication and activity by low-level noise exposure causes changes of emotional and cognitive parameters and annoyance, followed by chronic stress reactions and adverse health effects.”
That’s no surprise to anyone who’s lived in a major city or visited one before. They’re polluted with sounds of people honking and shouting, loud buses or trains passing by, construction workers chipping away at the streets and buildings. At a certain point, it eventually gets to be too much.
This is one of the reasons why white noise machines, nature sounds and classical music are a popular means of drowning out the excess noise in our environments. They take all of the harshness and overwhelming nature of our surroundings and mute it or, at the very least, turn it down to a minimum.
When a website is designed with too much “noise”, a similar solution is needed.
But how do we define noise on websites? It’s not as though we all have auto-playing music on them anymore (at least, I hope not).
The big thing is to look for things that don’t belong there. If your design is overcrowded, remove the elements that contribute little to the user experience and conversion rate.
For example, how frequently do people engage with your live chat window? If it’s not happening frequently or the interactions aren’t meaningful, just get rid of it. The same goes for other non-essential elements. Banner ads. Auto-play on videos. Exit-intent pop-ups.
Is the interruption to the user’s experience really worth it?

When visitors enter the home page, they’re asked: “Do you want more traffic?”
Let’s say the answer to that is “no” because the visitor has come here to read more about marketing and SEO on the blog. However, the top of the blog page again asks them the same question.

Logic would dictate that clicking “No, I have enough traffic” would remove the banner from view since no “X” is available to dismiss it. Instead, visitors who click it are taken away from the blog and returned to the home page to start the loop all over again.
This type of website friction is no different than an environmental noise or irritant — kind of like a child asking “But why?” over and over again until you give them the answer they want. Eventually, visitors are going to get fed up with the pressure to convert and leave for good (maybe not in Patel’s case, but definitely on a website for lesser-known brands).
If you notice your visitors ignoring the noise you’ve placed before them on the website, don’t try and jam it down their throats even further. Just get rid of it.

They’re either going to suffer through the experience and be left with a sour taste in their mouth… or they’re going to immediately bounce off the site and be left with a sour taste in their mouth.
If you want to remove the stress from your web design, look to traditional stress relief activities to iron out the issues. If you can turn your website into a relaxing and welcoming environment — while still pushing all the right buttons to drive visitors to conversion — you’ll lower your bounce rates as well as visitors’ stress levels.

Friday, July 17, 2020

A Practical Guide To Testing React Applications With Jest

 Building a well-functioning application requires good testing; otherwise, knowing whether your application works as expected would be a matter of guesswork and luck. Jest is one of the best tools available for testing React applications. In this article, you will learn everything you need to create a solid test for your React components and application.


In this article, I’m going to introduce you to a React testing tool named Jest, along with the popular library Enzyme, which is designed to test React components. I’ll introduce you to Jest testing techniques, including: running tests, testing React components, snapshot testing, and mocking. If you are new to testing and wondering how to get started, you will find this tutorial helpful because we will start with an introduction to testing. By the end, you’ll be up and running, testing React applications using Jest and Enzyme. You should be familiar with React in order to follow this tutorial.

A Brief Introduction To Testing

Testing is a line-by-line review of how your code will execute. A suite of tests for an application comprises various bit of code to verify whether an application is executing successfully and without error. Testing also comes in handy when updates are made to code. After updating a piece of code, you can run a test to ensure that the update does not break functionality already in the application.

Why Test?

It’s good to understand why we doing something before doing it. So, why test, and what is its purpose?

  1. The first purpose of testing is to prevent regression. Regression is the reappearance of a bug that had previously been fixed. It makes a feature stop functioning as intended after a certain event occurs.
  2. Testing ensures the functionality of complex components and modular applications.
  3. Testing is required for the effective performance of a software application or product.

Testing makes an app more robust and less prone to error. It’s a way to verify that your code does what you want it to do and that your app works as intended for your users.


Let’s go over the types of testing and what they do.

Unit Test

In this type of test, individual units or components of the software are tested. A unit might be an individual function, method, procedure, module, or object. A unit test isolates a section of code and verifies its correctness, in order to validate that each unit of the software’s code performs as expected.

In unit testing, individual procedures or functions are tested to guarantee that they are operating properly, and all components are tested individually. For instance, testing a function or whether a statement or loop in a program is functioning properly would fall under the scope of unit testing.

Component Test

Component testing verifies the functionality of an individual part of an application. Tests are performed on each component in isolation from other components. Generally, React applications are made up of several components, so component testing deals with testing these components individually.

For example, consider a website that has different web pages with many components. Every component will have its own subcomponents. Testing each module without considering integration with other components is referred to as component testing.

Testing like this in React requires more sophisticated tools. So, we would need Jest and sometimes more sophisticated tools, like Enzyme, which we will discuss briefly later.

Snapshot Test

A snapshot test makes sure that the user interface (UI) of a web application does not change unexpectedly. It captures the code of a component at a moment in time, so that we can compare the component in one state with any other possible state it might take.

We will learn about snapshot testing in a later section.

Advantages and Disadvantages of Testing

Testing is great and should be done, but it has advantages and disadvantages.


  1. It prevents unexpected regression.
  2. It allows the developer to focus on the current task, rather than worrying about the past.
  3. It allows modular construction of an application that would otherwise be too complex to build.
  4. It reduces the need for manual verification.


  1. You need to write more code, as well as debug and maintain.
  2. Non-critical test failures might cause the app to be rejected in terms of continuous integration.

Introduction to Jest

Jest is a delightful JavaScript testing framework with a focus on simplicity. It can be installed with npm or Yarn. Jest fits into a broader category of utilities known as test runners. It works great for React applications, but it also works great outside of React applications.

Enzyme is a library that is used to test React applications. It’s designed to test components, and it makes it possible to write assertions that simulate actions that confirm whether the UI is working correctly.

Jest and Enzyme complement each other so well, so in this article we will be using both.

Process Of Running A Test With Jest

In this section, we will be installing Jest and writing tests. If you are new to React, then I recommend using Create React App, because it is ready for use and ships with Jest.

npm init react-app my-app

We need to install Enzyme ****and enzyme-adapter-react-16 with react-test-renderer (the number should be based on the version of React you’re using).

npm install --save-dev enzyme enzyme-adapter-react-16 react-test-renderer

Now that we have created our project with both Jest and Enzyme, we need to create a setupTest.js file in the src folder of the project. The file should look like this:

import { configure } from "enzyme";
import Adapter from "enzyme-adapter-react-16";
configure({ adapter: new Adapter() });

This imports Enzyme and sets up the adapter to run our tests.

Before continuing, let’s learn some basics. Some key things are used a lot in this article, and you’ll need to understand them.

  • it or test You would pass a function to this method, and the test runner would execute that function as a block of tests.
  • describe This optional method is for grouping any number of it or test statements.
  • expect This is the condition that the test needs to pass. It compares the received parameter to the matcher. It also gives you access to a number of matchers that let you validate different things. You can read more about it in the documentation.
  • mount This method renders the full DOM, including the child components of the parent component, in which we are running the tests.
  • shallow This renders only the individual components that we are testing. It does not render child components. This enables us to test components in isolation.

Creating A Test File

How does Jest know what’s a test file and what isn’t? The first rule is that any files found in any directory with the name __test__ are considered a test. If you put a JavaScript file in one of these folders, Jest will try to run it when you call Jest, for better or for worse. The second rule is that Jest will recognize any file with the suffix .spec.js or .test.js. It will search the names of all folders and all files in your entire repository.

Let’s create our first test, for a React mini-application created for this tutorial. You can clone it on GitHub. Run npm install to install all of the packages, and then npm start to launch the app. Check the file for more information.

Let’s open App.test.js to write our first test. First, check whether our app component renders correctly and whether we have specified an output:

it("renders without crashing", () => {
  shallow(<App />);

it("renders Account header", () => {
  const wrapper = shallow(<App />);
  const welcome = <h1>Display Active Users Account Details</h1>;

In the test above, the first test, with shallow, checks to see whether our app component renders correctly without crashing. Remember that the shallow method renders only a single component, without child components.

The second test checks whether we have specified an h1 tag output of “Display Active User Account” in our app component, with a Jest matcher of toEqual.

Now, run the test:

npm run test 
/* OR */
npm test

The output in your terminal should like this:

  PASS  src/App.test.js
  √ renders without crashing (34ms)
  √ renders Account header (13ms)

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        11.239s, estimated 16s
Ran all test suites related to changed files.

Watch Usage: Press w to show more.

As you can see, our test passed. It shows we have one test suite named App.test.js, with two successful tests when Jest ran. We’ll talk about snapshot testing later, and you will also get to see an example of a failed test.

Skipping Or Isolating A Test

Skipping or isolating a test means that when Jest runs, a specific marked test is not run.

it.skip("renders without crashing", () => {
  shallow(<App />);

it("renders Account header", () => {
  const wrapper = shallow(<App />);
  const header = <h1>Display Active Users Account Details</h1>;

Our first test will be skipped because we’ve used the skip method to isolate the test. So, it will not run or make any changes to our test when Jest runs. Only the second one will run. You can also use it.only().

It’s a bit frustrating to make changes to a test file and then have to manually run npm test again. Jest has a nice feature called watch mode, which watches for file changes and runs tests accordingly. To run Jest in watch mode, you can run npm test -- --watch or jest --watch. I would also recommend leaving Jest running in the terminal window for the rest of this tutorial.

Mocking Function

A mock is a convincing duplicate of an object or module without any real inner workings. It might have a tiny bit of functionality, but compared to the real thing, it’s a mock. It can be created automatically by Jest or manually.

Why should we mock? Mocking reduces the number of dependencies — that is, the number of related files that have to be loaded and parsed when a test is run. So, using a lot of mocks makes tests execute more quickly.

Mock functions are also known as “spies”, because they let you spy on the behavior of a function that is called directly by some other code, rather than only testing the output.

There are two ways to mock a function: either by creating a mock function to use it in test code, or by writing a manual mock to override a module dependency.

Manual mocks ****are used to stub out functionality with mock data. For example, instead of accessing a remote resource, like a website or a database, you might want to create a manual mock that allows you to use fake data.

We will use a mock function in the next section.


Testing React Components

The section will combine all of the knowledge we have gained so far in understanding how to test React components. Testing involves making sure the output of a component hasn’t unexpectedly changed to something else. Constructing components in the right way is by far the most effective way to ensure successful testing.

One thing we can do is to test components props — specifically, testing whether props from one component are being passed to another. Jest and the Enzyme API allow us to create a mock function to simulate whether props are being passed between components.

We have to pass the user-account props from the main App component to the Account component. We need to give user-account details to Account in order to render the active account of users. This is where mocking comes in handy, enabling us to test our components with fake data.

Let’s create a mock for the user props:

const user = {
  name: "Adeneye David",
  email: "",
  username: "Dave",

We have created a manual mock function in our test file and wrapped it around the components. Let’s say we are testing a large database of users. Accessing the database directly from our test file is not advisable. Instead, we create a mock function, which enables us to use fake data to test our component.

describe("", () => {
  it("accepts user account props", () => {
    const wrapper = mount(<Account user={user} />);
  it("contains users account email", () => {
    const wrapper = mount(<Account user={user} />);
    const value = wrapper.find("p").text();

We have two tests above, and we use a describe layer, which takes the component being tested. By specifying the props and values that we expect to be passed by the test, we are able to proceed.

In the first test, we check whether the props that we passed to the mounted component equal the mock props that we created above.

For the second test, we pass the user props to the mounted Account component. Then, we check whether we can find the <p> element that corresponds to what we have in the Account component. When we run the test suite, you’ll see that the test runs successfully.

We can also test the state of our component. Let’s check whether the state of the error message is equal to null:

it("renders correctly with no error message", () => {
  const wrapper = mount();

In this test, we check whether the state of our component error is equal to null, using a toEqual() matcher. If there is an error message in our app, the test will fail when run.

In the next section, we will go through how to test React components with snapshot testing, another amazing technique.

Snapshot Testing

Snapshot testing captures the code of a component at a moment in time, in order to compare it to a reference snapshot file stored alongside the test. It is used to keep track of changes in an app’s UI.

The actual code representation of a snapshot is a JSON file, and this JSON contains a record of what the component looked like when the snapshot was made. During a test, Jest compares the contents of this JSON file to the output of the component during the test. If they match, the test passes; if they don’t, the test fails.

To convert an Enzyme wrapper to a format that is compatible with Jest snapshot testing, we have to install enzyme-to-json:

npm install --save-dev enzyme-to-json

Let’s create our snapshot test. When we run it the first time, the snapshot of that component’s code will be composed and saved in a new __snapshots__ folder in the src directory.

it("renders correctly", () => {
  const tree = shallow(<App />);

When the test above runs successfully, the current UI component will be compared to the existing one.

Now, let’s run the test:

npm run test

When the test suite runs, a new snapshot will be generated and saved to the __snapshots__ folder. When we run a test subsequently, Jest will check whether the components match the snapshot.

As explained in the previous section, that shallow method from the Enzyme package is used to render a single component and nothing else. It doesn’t render child components. Rather, it gives us a nice way to isolate code and get better information when debugging. Another method, named mount, is used to render the full DOM, including the child components of the parent component, in which we are running the tests.

We can also update our snapshot, Let’s make some changes to our component in order to make our test fail, which will happen because the component no longer corresponds to what we have in the snapshot file. To do this, let’s change the <h3> tag in our component from <h3> Loading...</h3> to <h3>Fetching Users...</h3>. When the test runs, this what we will get in the terminal:

 FAIL  src/App.test.js (30.696s)
  × renders correctly (44ms)

  ● renders correctly

    Snapshot name: `renders correctly

    - Snapshot
    + Received

          Display Active Users Account Details
    -     Loading...
    +     Fetching Users...

       7 | it("renders correctly", ()
=> {
       8 |   const wrapper = shallow();
    >  9 |   expect(toJson(wrapper)).toMatchSnapshot();
         |                           ^      10 | });
      11 |
      12 | /* it("renders without crashing", () => {

      at Object. (src/App.test.js:9:27)

 › 1 snapshot failed.
Snapshot Summary
 › 1 snapshot failed from 1 test suite. Inspect your code changes or press `u` to update them.

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   1 failed, 1 total
Time:        92.274s
Ran all test suites related to changed files.

Watch Usage: Press w to show more.

If we want our test to pass, we would either change the test to its previous state or update the snapshot file. In the command line, Jest provides instruction on how to update the snapshot. First, press w in the command line to show more, and then press u to update the snapshot.

› Press u to update failing snapshots.

When we press u to update the snapshot, the test will pass.


I hope you’ve enjoyed working through this tutorial. We’ve learned some Jest testing techniques using the Enzyme testing library. I’ve also introduced you to the process of running a test, testing React components, mocking, and snapshot testing. If you have any questions, you can leave them in the comments section below, and I’ll be happy to answer every one and work through any issues with you.

Resources And Further Reading



Saturday, July 11, 2020

Accessible Images For When They Matter Most

Creating accessible images seems like a simple topic at first glance — you just need to add alt text to an image, right? But the topic is much more nuanced than some people think. In this article, we will review the different types of images, dive into some real-world examples of inaccessible public service announcements (PSAs), and discuss which elements matter most when critical messages need to reach everyone.

When it comes to informing the public about critical health issues, timing is everything. The information you consume today could save your life tomorrow. And with more than 65% of the population being visual learners — meaning they learn and remember best through visual communication — the job of creating and sharing accessible images has never been more important. This is especially true for public service announcements (PSAs) aimed at providing crucial and urgent information to the public.
But what happens when your users have visual impairments? Or dyslexia? Or cognitive disorders? How do they receive and understand this visual information? What elements make an image accessible or inaccessible?

Image Types And Alts

Before we dissect an image and examine each element that can make or break its accessibility, we first need to take a step back and think about the purpose of the image. Is it to inform a user? Elicit an emotion? Is the image acting as a link? Or is it purely eye-candy?
There are a number of questions that can help you determine how best to convey the image information to a person using an assistive technology (AT) device, like a screen reader.
“What type of message is the image trying to convey?”

“Is the message simple, complex, emotional, or actionable?”
Using a tool such as an online image decision tree or the simplified chart shown below can help you decide which category your image belongs to. Or just imagine your image has — poof! — vanished. Then ask yourself:
“Do I understand the content that remains?”
If the answer is yes, it is decorative. If not, the image is informative and contextually necessary. Once you determine what kind of image you are working with, there are some basic accessibility guidelines to consider.

Decorative Images

If you decide your image is decorative, then programmatically the image needs to be hidden. One way to do this is to use an empty/null alternative text attribute. This sends a signal to the AT devices to ignore this image as it is not needed to understand the content or action on the page. There are many ways to hide alternative text including using an empty/null alt (e.g. <img alt="">), using ARIA (e.g. <img role="presentation">, <img role="none">, or <img aria-hidden="true">), or by implementing the image as a CSS background.
Note: An empty/null alternative text attribute is not the same as a missing alternative text attribute. If the alternative text attribute is missing, the AT device might read out the file name or surrounding content in an attempt to give the user more information about the image. While aria-hidden="true" is an option to hide images, be cautious where you apply it as it will remove the entire element from the accessibility API.

<div class="drop-caps" aria-hidden="true">
    <img src=".../images/drop-caps/s.svg" alt="">
    <img src=".../images/drop-caps/character-12.svg" alt="">
In this drop cap example, both aria-hidden="true" and an empty/null alt <img alt=""> were used to hide the images from assistive technology devices. While this kind of redundancy is not necessary to make it accessible — it is also not harmful in this particular situation since the drop caps <div> does not contain any additional information we would need to expose to an AT user. Just remember: when it comes to accessible code, more is not always better.
Beyond programmatically hiding your image — there is not much more you need to consider when it comes to decorative images. If you are saying “But wait, what about X?” or “How about Y?” then you might need to go back to the image decision tree tools and re-evaluate your image — it might not be 100% decorative after all. One of the most difficult types of images to categorize tends to be the “emotional/mood” based images since this subtype is a bit subjective. What one person considers decorative another person might consider informative, so use your best judgment.

Informative Images

If you decide your image is informative, there are a lot more things to consider. For AT devices to understand the message or intent of an image, informative images must have programmatically-discernible alternative text. Typically, this is accomplished using the alt="[some description]" method, but there are many alternative ways to add image information depending on its subtype, type of image, and context (e.g. complex vs simple, SVG vs img). But having alternate text is not enough — it must also be meaningful. For example, if your image is about feeling safe at home, but your alternative information says “house” — does that convey the full message?
An example of an informative image is the following Smashing Magazine logo. If we ask the same question as before (does the context or content change if this image is missing?), then the answer is “yes.” In this example, the logo is both informative and actionable since it is both an image and a link. We can see from the code snippet that <a title="Back to the homepage"> is the link title and the image alternative text is <img alt="Smashing Magazine">. When we fire up an AT device — like a screen reader — we should hear both pieces of information conveyed.

<div class="logo">
    <a href="/" title="Back to the homepage">
        <source media="(min-width: 1350px)" srcset=".../images/logo-full.svg">
        <img src=".../images/logo/logo.svg" alt="Smashing Magazine">
Hearing both the phrase “back to the homepage” and “Smashing Magazine” in one feature is OK since each phrase is unique and connected to a different purpose.
For more complex alternative text phrases, conduct the telephone test. For example, if you called up a friend and said “purple slug” and hung up the phone your friend would probably be confused, but also might think of a purple slug — but in what context? If you called a friend and said “the purple slug is eating my hydrangeas,” that would paint a more vivid picture — without adding a lot of additional characters or effort.
Of course, an AT user will have to listen to your alternative text, so don’t go overboard. That is why it is suggested to cap your text at 150 characters. If you need to add more context to the image (e.g. complex image), there are other, more descriptive patterns or methods you can use to add more detail.

World Beyond Image Alts

Now that we covered image types and alternative text attribute basics, let’s look beyond and consider some additional image elements:
In each real-world PSA example, we will look at the image through the lens of a different type of disability — keeping in mind that simulators are tools and may not represent an individual’s true experience. Yet, by using such tools, we can begin to build empathy into our designs and really consider the different ways our images are being consumed.
Note: To be clear, the following examples are for illustrative and educational purposes only and not meant to call-out or otherwise pass judgment about the designs in question. Also, there may be multiple issues in one PSA, but we will just focus on one issue type per example. There will be a lot of opportunities for improvement in the area of digital communications when the dust settles on COVID-19 and accessibility is just one more area to consider reviewing.

Color And Contrast

The beating heart of design arguably is color, and if color is the heart of design, then contrast is the muscle. Without good color contrast levels in place elements like words, icons, and other graphical shapes are hard to discern and the design can quickly become inaccessible. But what happens when you perceive color and contrast differently than others — does the same message and intent come through? How can we reach people with color-sensing issues? Color blindness — is a real concern for accessibility-focused designers.
Who Color And Contrast Can Affect
  • It is estimated that 300 million people worldwide are color blind, and approximately 95% of those inflicted are male (1 in 12 men vs 1 in 200 women are color blind). There are many different variants of color blindness, with red/green color blindness being the most common, followed by blue/yellow, and total color blindness being the most rare.
  • Globally there are 246 million people with low vision. People with visual impairments such as glaucoma, cataracts, macular degeneration, diabetic retinopathy, corneal clouding, etc, may have issues with text contrast. People with partial sight and older adults also often experience limited color vision.
  • People using monochrome displays or in certain situations (e.g. low lighting in a room) might have trouble with contrast. People using text-only, limited-color stylesheets, or in certain situations (e.g. too much glare on a screen) might have trouble discerning colors, too.
PSA Color Review
In the first example, we are reviewing PSAs from the non-profit group called the Ad Council — one of the oldest and most prolific producers of such material in the US. The aim of these “higher risk assets” is to reach populations considered more susceptible to contracting and becoming seriously ill by the novel coronavirus (one of the groups that need this information the most).

Next, we can see two types of color blindness simulated using the ChromeLens extension. ChromeLens is a Google Chrome extension that provides a suite of tools to help with web accessibility development and includes the Lens Vision Simulator, which transforms the colors on a website simulating what a colorblind person might see.
Simulated PSA with Deuteranopia (red/green-blindness)

Below is a breakdown of some color contrast ratios found on the PSAs between the different color blindness simulators.
Original PSA — color contrast ratio of 1.26:1 with the text “Have” against the background:

Simulated PSAs with Protanomaly (red-weak)

Deuteranopia simulation filter applied — color contrast ratio of 1.07:1 with the text “Have” against the background

Protanomaly simulation filter applied — color contrast ratio of 1:15:1 with the text “Have” against the background

While these PSAs incorporate a variety of striking color choices and are visually appealing (when testing the text against the background in these images), many of the combinations do not pass the Web Content Accessibility Guidelines (WCAG) color contrast ratios. This is true even for the unedited versions of these designs, but when we apply the ChromeLens color blindness simulator for Deuteranopia (red/green-blindness) Protanomaly (red-weak), the color contrast ratios get even worse (1.26:1 vs 1.07:1 and 1:15:1). To make these PSAs more accessible, we would want to bump up the contrast so people with color-related vision disorders could read the text.
PSA Contrast Review
Going back to the “higher-risk assets” from the Ad Council, we can see how the PSAs look like to people in two different low vision situations.
First, we see the unedited version of the PSAs

Next, using the NoCoffee Vision Simulator tool, we can see how the PSAs might look to someone with low vision and cataracts.
PSAs with simulated low vision filter applied

Below is a breakdown of some color contrast ratios found on the PSAs between the different low vision simulators.
Original PSA — color contrast ratio of 1.33:1 with the word “Undergoing” against the background

PSA with low vision simulation filter applied — color contrast ratio of 1.25:1 with the word “Undergoing” against the background

PSA with cataract simulation filter applied — color contrast ratio of 1.06:1 with the word “Undergoing” against the background

A lot of people blame color for their design accessibility issues, but these examples show that contrast plays a key role as well. Without changing the colors on these PSAs, but by changing the user perspective and blurring or obfuscating the text, we can see that the text on the images is more difficult to read — even though the contrast ratios didn’t change by much (1.33:1 vs 1.25:1 and 1.06:1). Similar to the color examples (to make these PSAs more accessible), we need to increase the contrast on these images so people with low vision and eye disorders could read the text.
Next Steps For Accessible Color And Contrast
Review the WCAG color contrast ratio guidelines and use tools like the Colour Contrast Analyser to check your designs. Your images with copy need a color contrast ratio of at least 4.5:1 for regular-sized text, and at least 3:1 for large-sized text (18pt and larger). The color contrast ratio of 3:1 also applies to essential icons. Try a tool like the A11y Color Palette where you can quickly review all the possible accessible color combinations and create a palette with accessibility in mind. Or use the accessibility features built-in into the palette generator Coolors.
Next, utilize solid color backgrounds (reading text on busy backgrounds, overlays, textures, or gradients is difficult in general), but especially when the text does not have enough contrast. By picking colors on the opposite ends of the color spectrum and avoiding red/green and blue/yellow combinations, you will increase the likelihood that your color and contrast ratios are robust. Use a tool like the ChromeLens extension to double-check the color contrast with color blindness in mind. Also, be careful with light shades of color — especially grays — they are difficult to see for people with low vision. Use tools like NoCoffee Vision Simulator to simulate low vision issues and see how your design holds up in these situations.
Going beyond color contrast ratios, it is also important to not use color alone to convey information. For example, “contact information can be seen in red” or “click the blue button to learn more.” The same is true for sensory characteristics such as shape, color, size, visual location, orientation, or sound — they cannot be used on their own. For example, if you said "Please click the link to the left of the image for more information," an AT user could have difficulty finding the correct link.

Typography and Layout

In a perfect world, we would keep our text and images separated. This would allow users to manipulate the typography and layout in any way they would want: font size, letter spacing/kerning, justification, margins/padding, and more. But unfortunately, there are a lot of formats that this kind of separation is difficult or impossible, such as social media posts, emails, PDFs, and other fixed form media.
Who Typography And Layout Can Affect
  • Typography is especially important to the estimated 15–20% of the world’s population with dyslexia — a learning disorder in which certain letters, numbers, or combinations of letters can be confusing or seem to flip/move around.
  • People with low vision can have issues with tight letter spacing/kerning, morphing words like “barn” into “bam” or “modern” into “modem” while reading.
  • For people with attention-deficit disorders and reading or vision-based disabilities, a complex layout is a real barrier. These users have trouble keeping their place and following the flow of the content due to the lack of whitespace and clear linear pathways.
PSA Typography And Layout Review
Let’s first take a look at a PSA from California’s Long Beach Health and Human Services.
If we are looking at this PSA from an accessibility point of view, what typography and layout issues do you see? In what ways could we improve this image?

If we focus on the typography and layout the following elements stand out:
Red hand-drawn linesIllustrating the multiple “rivers of space” created by the justified alignment.
Blue dotted boxesOutlining six different layout changes.
Pink numbersHighlighting the 14 different typography treatments discovered (ignoring the logo). Some changes are more obvious like font family or color changes, some are more subtle like alignment, size, or weight changes in the typography.
Green question marksWhat does this equation even mean? Cognitively this is a difficult thing to ascertain given the odd layout.
Black lines and dotsExpected 12 points of visual interest in an UX eye-tracking test based on the order of the content blocks (top to bottom, left to right) and typical equation flow (X + Y = Z).
Let’s look at another PSA and again evaluate the typography and layout from an accessibility point of view.
The third PSA example is more consistent when it comes to typography and layout, and has more overall whitespace and a linear visual pathway compared to the first two examples.
Next Steps For Accessible Typography And Layout
Less is more when it comes to accessible typography, so limit the number of different font families and variations such as italic, bold, ALL CAPS, or other styling methods that may make the content difficult to read. The research is not conclusive about whether serif or sans-serif typefaces are easier to read, but if you choose font families that have clearly defined letter shapes it is more likely that the font will be accessible. Some common offenders to look out for when choosing an inclusive font include the “I” (ex. India), “l” (ex. lettuce), and “1” (ex. one). Likewise, characters like “b” and “d” and “q” and “p” can sometimes be mirrored (either left-right or up-down), and the letter “B” and the number “8” oftentimes look too similar.
In regards to layout, less is also more. Try and repeat patterns whenever possible and limit the width of any blocked section to 80 characters (or 40 characters for logograms). Likewise, avoid paragraph alignment which creates whitespace or “rivers of space” within the content (e.g. justified alignment). Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing. Incorporating all of these layout guidelines will help people with attention-deficit disorders, reading and vision-based disabilities focus more on the content.

Copy And Icons

Last but not least, let’s focus on the actual PSA message. Arguably, copy is the key element in informing the public on the latest COVID-19 updates and providing information about preventing the spread of the virus. But icons in this situation serve up more than just decoration; these elements visually repeat the same message as the copy. No pressure, but both copy and icons need to be spot-on to reach the widest array of people.
Who Copy and Icons Can Affect
  • People with attention-deficit disorders — estimated at 129 million people worldwide — can have issues focusing on copy that is too long, does not break items into lists, and lacks whitespace (think: line height, paragraph margins, etc).
  • For people with certain cognitive disabilities, it is difficult to understand figurative language or specialized usage like the phrases “it’s raining cats and dogs” or “that test was a piece of cake.”
  • People with cognitive, language, and learning disabilities may need visual icons, graphics, and symbols to understand the accompanying copy.
PSA Copy Review
For this example, let’s test the copy of two PSAs from the Centers for Disease Control and Prevention (CDC) for readability. Readability is the ease with which a reader can understand a written text. Readability of copy depends on both the content and presentation.
Blue dotted boxesOutlining three different layout changes.
Pink numbersHighlighting the four different typography treatments discovered (ignoring the logos). In this case, only one font family was used, with variations only on size, color, and weight.
Black lines and dotsExpected eight points of visual interest in an UX eye-tracking test based on the order of the content blocks (top to bottom).

If we focus on the typography and layout the following elements stand out:
Blue dotted boxesOutlining nine different layout changes.
Green numbersHighlighting the 11 different typography treatments discovered (ignoring the logos). Some changes are more obvious like font family or color changes, some are more subtle like alignment, size, or weight changes in the typography.
Black lines and dotsExpected 10 points of visual interest in an UX eye-tracking test based on the order of the content blocks (top to bottom, left to right) and numbering order (1 to 6) forming a zig-zag type eye movement.
So far we’ve seen some examples where there are a lot of typography changes and the layouts are complex. Now, let’s review a cleaner PSA. This one is from the Prevention Action Alliance out of Columbus, Ohio.

If we evaluate the main body copy using readability indicator tools like Readable and The Readability Test, we see that the “What you should know about COVID-19 to protect yourself and others” PSA has 388 words at an average reading grade level of 9 and a Flesch Kincaid Reading Ease1 of 64.6. In addition to those metrics (for accessible copy), we also want to look at the number of complex words and their frequency — in this case, 35 and 9.02% respectively.

 This PSA has a lot more imagery and a lot less text. If we again evaluate the main copy, we see that our copy now has a total of 90 words with an average grade of 6 and a Flesch Kincaid Reading Ease of 83.6. The number of complex words is now down to 4 with a frequency of 4.44%.

Compared to the first PSA, the “Stop the Spread of Germs” PSA one has 298 fewer words and is easier to read by 3rd-grade levels. It has a reading ease level increase of 19 points, and is less complex. Based on these numbers, we can extrapolate that the second PSA is more inclusive than the first when looking at copy alone.
PSA Icon Review
But testing the readability of copy isn’t the only way to measure the effectiveness of a PSA when it comes to message accessibility. Another element we need to look at are the icons accompanying the copy. If we are presented only the icons, will the same message be received?
Let’s now look at a couple of examples. Based on the icons alone, what is the message that the image is trying to convey about riding your bicycle safely during COVID-19?

This is the unedited PSA. Were you able to figure out the full message? While you might have been able to guess correctly for a couple of icons, were there parts of the message you missed not having the copy?
OK, let’s take a look at another example. This next PSA comes from the Pennsylvania Department of Health. Let’s do the same exercise as before: can you understand the message in this PSA (without the icon copy)?

Now we can see the PSA with copy. Were you able to figure out the full message? While there may have been an icon or two that tripped you up, was it easier to decipher the icons on the second PSA versus the first? Hopefully, this quick exercise helped you understand the critical role icons play in the message.
Next Steps for Accessible Copy and Icons
Be clear and concise. The unofficial rule of thumb is to write for a 9th-grade reading level. This level is based on the assumption that most people reach the 12th-grade reading level, but in times of peak stress, they might not be reading at their highest level. Try and use plain language and avoid technical jargon, fancy words, colloquialisms, and expressions. Likewise, make sure any acronyms, abbreviations, or unusual words are explained in more detail or linked out to additional resources. Tools like Readable and The Readability Test can help you determine the reading level of your copy, while tools like Hemingway Editor or Grammarly can suggest edits to make your copy more inclusive.
Use icons, graphics, and symbols to supplement copy whenever possible. Adding imagery allows you to break down some language and cognitive barriers and not rely on your typography to carry all the weight. Just be sure to choose icons that are common or don’t require a lot of thought.

Wrapping Up

Creating accessible images involves a lot more than just adding alt text. It is important to consider how all image elements — color, contrast, typography, layout, copy, and icons — affect your users as well. By taking a bit more time and building these accessibility principles into your images you will undoubtedly reach more people — on their terms. In uncertain times like these, we need to be sure we are addressing all the ways we can improve our images to be more inclusive in our messaging.

Can Data Visualization Improve The Mobile Web Experience?

Since more and more web traffic comes from mobile users, our websites need to be in the best position to serve them. The easiest thing to do would be to remove unnecessary content from the site. However, it may not always be the best solution. In this article,  proposes some ways to turn essential content into graphics to conserve space, create a more engaging UI and preserve the overall integrity of your content on mobile.

It can be tough to prioritize the mobile experience when it often feels like a compromise. Don’t include as much text. Remove some of your images. Stay away from features that get in the mobile visitor’s way. It’s kind of like a parent who tells you, “Go out and have a good time, but don’t do X, Y or Z!”
It’s not necessarily that a mobile visitor needs a shorter page, less text or fewer images to more easily consume content on a smartphone. They just need the content you give them to not feel like so much work.
If you look more closely at your pages, you may find that some of the written content can be converted into data visualizations. So, today we’re going to look at some things you can do to start converting more of your content into graphics and enhance mobile visitors’ experiences in the process.

Many UX designers are somewhat afraid of data, believing it requires deep knowledge of statistics and math. Although that may be true for advanced data science, it is not true for the basic research data analysis required by most UX designers. Since we live in an increasingly data-driven world, basic data literacy is useful for almost any professional — not just UX designers.
Aaron Gitlin, interaction designer at Google, argues that many designers are not yet data-driven:
“While many businesses promote themselves as being data-driven, most designers are driven by instinct, collaboration, and qualitative research methods.”

— Aaron Gitlin, “Becoming A Data-Aware Designer
With this article, I’d like to give UX designers the knowledge and tools to incorporate data into their daily routines.

But First, Some Data Concepts

In this article I will talk about structured data, meaning data that can be represented in a table, with rows and columns. Unstructured data, being a subject in itself, is more difficult to analyze, as Devin Pickell (content marketing specialist at G2 Crowd, writing about data and analytics) pointed out in his article “Structured vs Unstructured Data – What’s the Difference?.” If the structured data can be represented in a table form, the main concepts are:


The entire set of data we intend to analyze. This could be, for example, an Excel table. Another popular format for storing datasets is the comma-separated value file (CSV). CSV files are simple text files used to store table-like information. Each CSV row corresponds to a row in the table, and each CSV row has values separated (naturally) by commas, which correspond to table cells.

Data Point

A single row from a dataset table is a data point. In that way, a dataset is a collection of data points.

Data Variable

A single value from a data-point row represents a data variable — put simply, a table cell. We can have two types of data variables: qualitative variables, and quantitative variables. Qualitative variables (also known as categorical variables) have a discrete set of values, such as color = red/green/blue. Quantitative variables have numerical values, such as height = 167. A quantitative variable, unlike a qualitative one, can take any value.

Sunday, July 5, 2020

How To Make Performance Visible With GitLab CI And Hoodoo Of GitLab Artifacts

It’s not enough to optimize an application. You need to prevent performance from degradation, and the first step to do it is to make performance changes visible.

Performance degradation is a problem we face on a daily basis. We could put effort to make the application blazing fast, but we soon end up where we started. It’s happening because of new features being added and the fact that we sometimes don’t have a second thought on packages that we constantly add and update, or think about the complexity of our code. It’s generally a small thing, but it’s still all about the small things.
We can’t afford to have a slow app. Performance is a competitive advantage that can bring and retain customers. We can’t afford regularly spending time optimizing apps all over again. It’s costly, and complex. And that means that despite all of the benefits of performance from a business perspective, it’s hardly profitable. As a first step in coming up with a solution for any problem, we need to make the problem visible. This article will help you with exactly that.
Note: If you have a basic understanding of Node.js, a vague idea about how your CI/CD works, and care about the performance of the app or business advantages it can bring, then we are good to go.

How To Create A Performance Budget For A Project

The first questions we should ask ourselves are:
“What is the performant project?”

“Which metrics should I use?”

“Which values of these metrics are acceptable?”
The metrics selection is outside of the scope of this article and depends highly on the project context, but I recommend that you start by reading User-centric Performance Metrics by Philip Walton.
From my perspective, it’s a good idea to use the size of the library in kilobytes as a metric for the npm package. Why? Well, it’s because if other people are including your code in their projects, they would perhaps want to minimize the impact of your code on their application’s final size.
For the site, I would consider Time To First Byte (TTFB) as a metric. This metric shows how much time it takes for the server to respond with something. This metric is important, but quite vague because it can include anything — starting from server rendering time and ending up with latency problems. So it’s nice to use it in conjunction with Server Timing or OpenTracing to find out what it exactly consists of.
You should also consider such metrics as Time to Interactive (TTI) and First Meaningful Paint (the latter will soon be replaced with Largest Contentful Paint (LCP)). I think both of these are most important — from the perspective of perceived performance.
But bear in mind: metrics are always context-related, so please don’t just take this for granted. Think about what is important in your specific case.
The easiest way to define desired values for metrics is to use your competitors — or even yourself. Also, from time to time, tools such as Performance Budget Calculator may come handy — just play around with it a little.
Performance degradation is a problem we face daily. We could put effort to make the application blazing fast, but soon we end up where we started.

Use Competitors For Your Benefit

If you ever happened to run away from an ecstatically overexcited bear, then you already know, that you don’t need to be an Olympic champion in running to get out of this trouble. You just need to be a little bit faster than the other guy.
So make a competitors list. If these are projects of the same type, then they usually consist of page types similar to each other. For example, for an internet shop, it may be a page with a product list, product details page, shopping cart, checkout, and so on.
  1. Measure the values of your selected metrics on each type of page for your competitor’s projects;
  2. Measure the same metrics on your project;
  3. Find the closest better than your value for each metric in the competitor’s projects. Adding 20% to them and set as your next goals.
Why 20%? This is a magic number that supposedly means the difference will be noticeable to the bare eye. You can read more about this number in Denys Mishunov’s article “Why Perceived Performance Matters, Part 1: The Perception Of Time”.

A Fight With A Shadow

Do you have a unique project? Don’t have any competitors? Or you are already better than any of them in all possible senses? It’s not an issue. You can always compete with the only worthy opponent, i.e. yourself. Measure each performance metric of your project on each type of page and then make them better by the same 20%.

Synthetic Tests

There are two ways of measuring performance:
  • Synthetic (in a controlled environment)
  • RUM (Real User Measurements)
    Data is being collected from real users in production.
In this article, we will use synthetic tests and assume that our project uses GitLab with its built-in CI for project deployment.

Library And Its Size As A Metric

Let’s assume that you’ve decided to develop a library and publish it to NPM. You want to keep it light — much lighter than competitors — so it has less impact on the resulting project’s end size. This saves clients traffic — sometimes traffic which the client is paying for. It also allows the project to be loaded faster, which is pretty important in regards to the growing mobile share and new markets with slow connection speeds and fragmented internet coverage.

Package For Measuring Library Size

To keep the size of the library as small as possible, we need to carefully watch how it changes over development time. But how can you do it? Well, we could use package Size Limit created by Andrey Sitnik from Evil Martians.
Let’s install it.
npm i -D size-limit @size-limit/preset-small-lib
Then, add it to package.json.
"scripts": {
+ "size": "size-limit",
  "test": "jest && eslint ."
+ "size-limit": [
+   {
+     "path": "index.js"
+   }
+ ],
The "size-limit":[{},{},…] block contains a list of the size of the files of which we want to check. In our case, it’s just one single file: index.js.
NPM script size just runs the size-limit package, which reads the configuration block size-limit mentioned before and checks the size of the files listed there. Let’s run it and see what happens:
npm run size
We can see the size of the file, but this size is not actually under control. Let’s fix that by adding limit to package.json:
"size-limit": [
+   "limit": "2 KB",
    "path": "index.js"
Now if we run the script it will be validated against the limit we set.
A screenshot of the terminal; the size of the file is less than the limit and is shown as green. (Large preview)
In the case that new development changes the file size to the point of exceeding the defined limit, the script will complete with non-zero code. This, aside from other things, means that it will stop the pipeline in the GitLab CI.
Now we can use git hook to check the file size against the limit before every commit. We may even use the husky package to make it in a nice and simple way.
Let’s install it.
npm i -D husky
Then, modify our package.json.
"size-limit": [
    "limit": "2 KB",
    "path": "index.js"
+  "husky": {
+    "hooks": {
+      "pre-commit": "npm run size"
+    }
+  },
And now before each commit automatically would be executed npm run size command and if it will end with non-zero code then commit would never happen.
But there are many ways to skip hooks (intentionally or even by accident), so we shouldn’t rely on them too much.
Also, it’s important to note that we shouldn’t need to make this check blocking. Why? Because it’s okay that the size of the library grows while you are adding new features. We need to make the changes visible, that’s all. This will help to avoid an accidental size increase because of introducing a helper library that we don’t need. And, perhaps, give developers and product owners a reason to consider whether the feature being added is worth the size increase. Or, maybe, whether there are smaller alternative packages. Bundlephobia allows us to find an alternative for almost any NPM package.
So what should we do? Let’s show the change in the file size directly in the merge request! But you don’t push to master directly; you act like a grown-up developer, right?

Running Our Check On GitLab CI

Let’s add a GitLab artifact of the metrics type. An artifact is a file, which will «live» after the pipeline operation is finished. This specific type of artifact allows us to show an additional widget in the merge request, showing any change in the value of the metric between artifact in the master and the feature branch. The format of the metrics artifact is a text Prometheus format. For GitLab values inside the artifact, it’s just text. GitLab doesn’t understand what it is that has exactly changed in the value — it just knows that the value is different. So, what exactly should we do?
  1. Define artifacts in the pipeline.
  2. Change the script so that it creates an artifact on the pipeline.
To create an artifact we need to change .gitlab-ci.yml this way:
image: node:latest

  - performance

  stage: performance
    - npm ci
    - npm run size
+  artifacts:
+    expire_in: 7 days
+    paths:
+      - metric.txt
+    reports:
+      metrics: metric.txt

  1. The artifact will have the type reports:metrics
Now let’s make Size Limit generate a report. To do so we need to change package.json:
"scripts": {
-  "size": "size-limit",
+  "size": "size-limit --json > size-limit.json",
  "test": "jest && eslint ."
size-limit with key --json will output data in json format:

And redirection > size-limit.json will save JSON into file size-limit.json.
Now we need to create an artifact out of this. Format boils down to [metrics name][space][metrics value]. Let’s create the script generate-metric.js:
const report = require('./size-limit.json');
process.stdout.write(`size ${(report[0].size/1024).toFixed(1)}Kb`);
And add it to package.json:
"scripts": {
  "size": "size-limit --json > size-limit.json",
+  "postsize": "node generate-metric.js > metric.txt",
  "test": "jest && eslint ."
Because we have used the post prefix, the npm run size command will run the size script first, and then, automatically, execute the postsize script, which will result in the creation of the metric.txt file, our artifact.
As a result, when we merge this branch to master, change something and create a new merge request

In the widget that appears on the page we, first, see the name of the metric (size) followed by the value of the metric in the feature branch as well as the value in the master within the round brackets.
Now we can actually see how to change the size of the package and make a reasonable decision whether we should merge it or not..
OK! So, we’ve figured out how to handle the trivial case. If you have multiple files, just separate metrics with line breaks. As an alternative for Size Limit, you may consider bundlesize. If you are using WebPack, you may get all sizes you need by building with the --profile and --json flags:
webpack --profile --json > stats.json
If you are using next.js, you can use the @next/bundle-analyzer plugin. It’s up to you!
  • expire_in: 7 days — artifact will exist for 7 days.
  • paths:

  • It will be saved in the root catalog. If you skip this option then it wouldn’t be possible to download it.
  • reports:
      metrics: metric.txt