Chris Ferdinandi turns the heat down low and lets the sauce reduce while we take a look at how to add spice to our source with a sprinkling of Array.reduce(). Just a little ingenuity with the humblest of functions.

Of all the modern array methods, the one I had the hardest time wrapping my head around was Array.reduce().

On the surface, it seems like a simple, boring method that doesn’t do much. But below its humble exterior, Array.reduce() is actually a powerful, flexible addition to your developer toolkit.

Today, we’re going to look at some cool things you can do with Array.reduce().

How Array.reduce() works

Most of the modern array methods return a new array. The Array.reduce() method is a bit more flexible. It can return anything. Its purpose is to take an array and condense its content into a single value.

That value can be a number, a string, or even an object or new array. That’s the part that’s always tripped me up – I didn’t realize just how flexible it is!

The syntax

The Array.reduce() accepts two arguments: a callback method to run against each item in the array, and a starting value.

The callback also accepts two arguments: the accumulator, which is the current combined value, and the current item in the loop. Whatever you return is used as the accumulator for the next item in the loop. On the very first loop, that starting value is used instead.

var myNewArray = [].reduce(function (accumulator, current) {
  return accumulator;
}, starting);

Let’s look at some examples to make this all tangible.

1. Adding numbers together

Let’s say you had an array of numbers that you wanted to add together. Using Array.forEach(), you might do something like this:

var total = 0;

[1, 2, 3].forEach(function (num) {
  total += num;
});

This is the cliche example for using Array.reduce(). I find the word accumulator confusing, so in this example, I’m calling it sum, because that’s what it is.

var total = [1, 2, 3].reduce(function (sum, current) {
  return sum + current;
}, 0);

Here, we pass in 0 as our starting value.

In the callback, we add the current value to the sum, which has our starting value of 0 on the first loop, then 1 (the starting value of 0 plus the item value of 1), then 3 (the sum value of 1 plus the item value of 2), and so on.

Here’s a demo.

2. Combining multiple array methods into Array.map() and Array.filter() into a single step

Imagine you had an array of wizards at Hogwarts.

var wizards = [
  {
    name: 'Harry Potter',
    house: 'Gryfindor'
  },
  {
    name: 'Cedric Diggory',
    house: 'Hufflepuff'
  },
  {
    name: 'Tonks',
    house: 'Hufflepuff'
  },
  {
    name: 'Ronald Weasley',
    house: 'Gryfindor'
  },
  {
    name: 'Hermione Granger',
    house: 'Gryfindor'
  }
];

You want to create a new array that contains just the names of wizards who are in Hufflepuff. One way you could do that is by using the Array.filter() method to get back just wizards whose house property is Hufflepuff. Then, you’d use the Array.map() method to create a new array containing just the name property for the remaining wizards.

// Get the names of the wizards in Hufflepuff
var hufflepuff = wizards.filter(function (wizard) {
  return wizard.house === 'Hufflepuff';
}).map(function (wizard) {
  return wizard.name;
});

With the Array.reduce() method, we can get the same array in a single pass, improving our performance. You pass in an empty array ([]) as the starting value. On each pass, you check to see if the wizard.house is Hufflepuff. If it is, you push it to the newArr (our accumulator in this example). If not, you do nothing.

Either way, you return the newArr to become the accumulator on the next pass.

// Get the names of the wizards in Hufflepuff
var hufflepuff = wizards.reduce(function (newArr, wizard) {
  if (wizard.house === 'Hufflepuff') {
    newArr.push(wizard.name);
  }
  return newArr;
}, []);

Here’s another demo.

3. Creating markup from an array

What if, instead of creating an array of names, we wanted to create an unordered list of wizards in Hufflepuff? Instead of passing an empty array into Array.reduce() as our starting value, we’ll pass in an empty string ('') and call it html.

If the wizard.house equals Hufflepuff, we’ll concatenate our html string with the wizard.name wrapped in an opening and closing list item (li). Then, we’ll return the html to become the accumulator on the next loop.

// Create a list of wizards in Hufflepuff
var hufflepuffList = wizards.reduce(function (html, wizard) {
  if (wizard.house === 'Hufflepuff') {
    html += '<li>' + wizard.name + '</li>';
  }
  return html;
}, '');

Add an opening and closing unordered list element before and after Array.reduce(), and you’re ready to inject your markup string into the DOM.

// Create a list of wizards in Hufflepuff
var hufflepuffList = '<ul>' + wizards.reduce(function (html, wizard) {
  if (wizard.house === 'Hufflepuff') {
    html += '<li>' + wizard.name + '</li>';
  }
  return html;
}, '') + '</ul>';

See it in action here.

4. Grouping similar items in an array together

The lodash library has a groupBy() method takes a collection of items as an array and groups them together into an object based on some criteria.

Let’s say you want an array of numbers.

If you wanted to group all of the items in numbers together based on their integer value, you would do this with lodash.

var numbers = [6.1, 4.2, 6.3];

// returns {'4': [4.2], '6': [6.1, 6.3]}
_.groupBy(numbers, Math.floor);

If you had an array of words, and you wanted to group the items in words by their length, you would do this.

var words = ['one', 'two', 'three'];

// returns {'3': ['one', 'two'], '5': ['three']}
_.groupBy(words, 'length');

Creating a groupBy() function with Array.reduce()

You can recreate that same functionality using the Array.reduce() method.

We’ll create a helper function, groupBy(), that accepts the array and criteria to sort by as arguments. Inside groupBy(), we’ll run Array.reduce() on our array, passing in an empty object ({}) as our starting point, and return the result.

var groupBy = function (arr, criteria) {
  return arr.reduce(function (obj, item) {
    // Some code will go here...
  }, {});
};

Inside the Array.reduce() callback function, we’ll check to see if the criteria is a function, or a property of the item. Then we’ll get its value from the current item.

If there’s no property in the obj with that value yet, we’ll create it and assign an empty array as its value. Finally, we’ll push the item to that key, and return the object as the accumulator for the next loop.

var groupBy = function (arr, criteria) {
  return arr.reduce(function (obj, item) {

    // Check if the criteria is a function to run on the item or a property of it
    var key = typeof criteria === 'function' ? criteria(item) : item[criteria];

    // If the key doesn't exist yet, create it
    if (!obj.hasOwnProperty(key)) {
      obj[key] = [];
    }

    // Push the value to the object
    obj[key].push(item);

    // Return the object to the next item in the loop
    return obj;

  }, {});
};

Here’s a demo of the completed helper function.

Special thanks to Tom Bremer for helping me make some improvements to this one. You can find this helper function and more like it on the Vanilla JS Toolkit.

5. Combining data from two sources into an array

Remember our array of wizards?

var wizards = [
  {
    name: 'Harry Potter',
    house: 'Gryfindor'
  },
  {
    name: 'Cedric Diggory',
    house: 'Hufflepuff'
  },
  {
    name: 'Tonks',
    house: 'Hufflepuff'
  },
  {
    name: 'Ronald Weasley',
    house: 'Gryfindor'
  },
  {
    name: 'Hermione Granger',
    house: 'Gryfindor'
  }
];

What if you had another data set, an object of house points each wizard has earned.

var points = {
  HarryPotter: 500,
  CedricDiggory: 750,
  RonaldWeasley: 100,
  HermioneGranger: 1270
};

Imagine you wanted to combine both sets of data into a single array, with the number of points added to each wizard’s data in the wizards array. How would you do it?

The Array.reduce() method is perfect for this!

var wizardsWithPoints = wizards.reduce(function (arr, wizard) {

  // Get the key for the points object by removing spaces from the wizard's name
  var key = wizard.name.replace(' ', '');

  // If the wizard has points, add them
  // Otherwise, set them to 0
  if (points[key]) {
    wizard.points = points[key];
  } else {
    wizard.points = 0;
  }

  // Push the wizard object to the new array
  arr.push(wizard);

  // Return the array
  return arr;

}, []);

Here’s a demo combining data from two sources into an array.

6. Combining data from two sources into an object

What if you instead wanted to combine the two data sources into an object, where each wizard’s name was the key, and their house and points were properties? Again, the Array.reduce() method is perfect for this.

var wizardsAsAnObject = wizards.reduce(function (obj, wizard) {

  // Get the key for the points object by removing spaces from the wizard's name
  var key = wizard.name.replace(' ', '');

  // If the wizard has points, add them
  // Otherwise, set them to 0
  if (points[key]) {
    wizard.points = points[key];
  } else {
    wizard.points = 0;
  }

  // Remove the name property
  delete wizard.name;

  // Add wizard data to the new object
  obj[key] = wizard;

  // Return the array
  return obj;

}, {});

Here’s a demo combining two data sets into an object.

Should you use Array.reduce() more?

The Array.reduce() method has gone from being something I thought was pointless to my favorite JavaScript method. So, should you use it? And when?

The Array.reduce() method has fantastic browser support. It works in all modern browsers, and IE9 and above. It’s been supported in mobile browsers for a long time, too. If you need to go back even further than that, you can add a polyfill to push support back to IE6.

The biggest complaint you can make about Array.reduce() is that it’s confusing for people who have never encountered it before. Combining Array.filter() with Array.map() is slower to run and involves extra steps, but it’s easier to read. It’s obvious from the names of the methods what they’re supposed to be doing.

That said, there are times where Array.reduce() makes things that would be complicated more simple rather than more complicated. The groupBy() helper function is a good example.

Ultimately, this is another tool to add to your toolkit. A tool that, if used right, can give you super powers.

About the author

Chris Ferdinandi helps people learn vanilla JavaScript. He believes there’s a simpler, more resilient way to make things for the web.

Chris is the author of the Vanilla JS Pocket Guide series, creator of the Vanilla JS Academy training program, and host of the Vanilla JS Podcast. His developer tips newsletter is read by thousands of developers each weekday.

He’s taught developers at organizations like Chobani and the Boston Globe, and his JavaScript plugins have been used used by Apple and Harvard Business School. Chris Coyier, the founder of CSS-Tricks and CodePen, has described his writing as “infinitely quote-worthy.”

Chris loves pirates, puppies, and Pixar movies, and lives near horse farms in rural Massachusetts. He runs Go Make Things with Bailey Puppy, a lab-mix from Tennessee.

More articles by Chris

Rob Weychert reaches for the top notes to sing us a song of typographic scale. A little attention to scale and to the mathematics will help you to hit a high note with your designs this Christmas and beyond.

I’ve been studying music theory this year. While some of its core concepts were already familiar to me, much of their specifics were not. Or so I thought. A funny thing happened when I was learning the major scales.

While playing through a song I had written some years before, I started picking it apart to see how it correlated with the theory I was learning. I had composed the melody without any thought to what the specific notes were, but as I started to transcribe them, a pattern quickly emerged: all the B’s and E’s were flat and the rest of the notes were natural. Lo and behold, long before my music theory studies began, I had written a song in B♭ major. My ears already knew how the major scales worked even if my brain didn’t. (If you know how “do re mi fa so la ti do” is supposed to sound tonally, then your ears know, too.)

When music is composed to a scale, it sounds “right” to us. And just as our ears appreciate harmony and melody with a rational basis, our eyes can appreciate the same concepts applied to spatial relationships.

Have you ever struggled with sizing type in a design project, especially when you need more than just one or two sizes? Have you ever despaired at the number of ad-hoc type sizes on your site spiraling out of control over time? It could be that you’ve been composing the typographic equivalent of a cacophonous symphony. And the first thing any composer will tell you to do is to get that thing on a scale.

Meet the typographic scale

You don’t need to know music theory to work with a typographic scale. You only need to know that a scale is a range of values with an established mathematic relationship. For a typographic scale, that relationship is frequently a steady interval between type sizes. Depending on what you need your type to do, the interval might be fixed (e.g. each size is two pixels bigger than the size before it) or it might be proportional (e.g. each size is twice as big as the size before it). I personally rarely find fixed intervals useful, so I’ll be focusing on proportional intervals.

The most important thing to understand about proportional intervals is thankfully not complicated: The bigger the intervals are, the more drastic the size differences will be in your scale. If your layout calls for contrast, a bigger interval might be the way to go. If you’re aiming for something more nuanced, go smaller. But keep these things in mind:

• There is such a thing as too much nuance: if a size on your scale is virtually indistinguishable from the sizes adjacent to it, it defeats the purpose of using a scale.
• On the flip side, too much contrast renders the sizes’ proportional relationship moot. At a certain point, massive display type is arguably more graphic than textual.
• More is less. The more sizes you use, the less they’ll mean.

Setting up the scale variables

The quickest way to get a scale up and running when working on the web is to drop its values into some CSS variables. The naming convention I typically use begins with --scale0, which is the body text size. The size below it is --scale-1 (as in “scale minus one”), the size above it is --scale1, and so on. Keeping the names relative to each other like this helps me move around the scale intuitively as I use it. If, say, --scale4 isn’t big enough for my h1, I can move up to --scale5 or --scale6, and I always know exactly how many steps away from the body text I am. Here’s a first pass at a simple set of scale variables using an interval of 1.5:

:root {
  --scale-2: 7.1px;  /* 10.7 ÷ 1.5 */
  --scale-1: 10.7px; /* 16 ÷ 1.5   */
  --scale0: 16px;    /* body text  */
  --scale1: 24px;    /* 16 × 1.5   */
  --scale2: 36px;    /* 24 × 1.5   */
}

I can use these variables with any CSS property that accepts a numeric value, like so:

p { font-size: var(--scale0); }

Rooting around in rems

I’m off to a good start. However, those px values are a little too absolute for my liking. If I convert them to rems, it’ll give my scale more flexibility. rem stands for “root em.” 1rem is equivalent to the html element’s text size, which in most browsers defaults to 16px. Crucially, though, users can adjust that size in their browser settings, and using rems in my CSS will respect those preferences.

:root {
  --scale-2: 0.4rem;  /* 0.7rem ÷ 1.5 */
  --scale-1: 0.7rem;  /* 1rem ÷ 1.5   */
  --scale0: 1rem;     /* body text    */
  --scale1: 1.5rem;   /* 1rem × 1.5   */
  --scale2: 2.25rem;  /* 1.5rem × 1.5 */
}

Another benefit of the relative nature of rems: I tend to use larger text sizes on large viewports and smaller text sizes on small viewports. Rather than adjusting dozens or hundreds of typographic CSS declarations per breakpoint, I can shift the whole scale up or down merely by adjusting the font-size on the html element:

html { font-size: 100%; }     /* 1rem = 16px */

@media screen and (min-width: 25em) {
  html { font-size: 112.5%; } /* 1rem = 18px */
}

Calculating with calc()

My scale is coming along. Its variables’ intuitive names make it easy for me to use, and its rem values respect the user’s browser preferences and allow me to easily shift the size of the entire scale at different viewport sizes. But my setup still isn’t optimized for one very important adjustment: the interval, which is currently 1.5. If 1.5 isn’t quite working for me and I want to see how an increase or decrease will affect the scale, I need to do the math all over again for every step in the scale every time I adjust the interval. The bigger the scale, the more time that will take. It’s time to put down the abacus and get calc() involved.

:root {
  --int: 1.5;
  --scale0: 1rem;
  --scale-1: calc(var(--scale0) / var(--int));
  --scale-2: calc(var(--scale-1) / var(--int));
  --scale1: calc(var(--scale0) * var(--int));
  --scale2: calc(var(--scale1) * var(--int));
}

My interval now has its very own variable, called --int. calc() determines each scale size by multiplying the preceding size by --int. Now that every size is ultimately dependent on --scale0’s value, --scale0 must appear first in the list. Since the sizes smaller than --scale0 are going down rather than up, their values require division rather than multiplication.

Scaling the scale

I can now quickly and easily tweak my scale’s interval by adjusting --int until the proportions are just right, but if I want to add more sizes to the scale, I need to add more variables and calc() values. This isn’t too big of a deal, but if I want to double or triple the number of sizes, it’s kind of a headache. Luckily, this is the sort of thing Sass is really good at. In the following code, adjusting the first four Sass variables at the top of :root will quickly spin up a set of CSS variables like the scale above, with any interval (proportional or fixed) and any number of scale sizes:

:root {
  $interval: 1.5;    // Unitless for proportional, unit for fixed
  $body-text: 1rem;  // Must have a unit
  $scale-min: -2;    // Unitless negative integer
  $scale-max: 2;     // Unitless positive integer

  --int: #{$interval};
  --scale0: #{$body-text};

  @if $scale-min < 0 {
  // Generate scale variables smaller than the base text size
    @for $i from -1 through $scale-min {
      @if type-of($interval) == number {
        @if unitless($interval) {
          --scale#{$i}: calc(var(--scale#{$i + 1}) / var(--int));
        } @else {
          --scale#{$i}: calc(var(--scale#{$i + 1}) - var(--int));
        }
      }
    }
  }
  @if $scale-max > 0 {
    // Generate scale variables larger than the base text size
    @for $i from 1 through $scale-max {
      @if type-of($interval) == number {
        @if unitless($interval) {
          --scale#{$i}: calc(var(--scale#{$i - 1}) * var(--int));
        } @else {
          --scale#{$i}: calc(var(--scale#{$i - 1}) + var(--int));
        }
      }
    }
  }
}

Go forth and scale

Typographic scales have been an indispensable part of my work for many years, and CSS variables and calc() make setup, adjustments, and experimentation easier than ever. I hope you find these techniques as useful as I do!

About the author

Rob Weychert is a Brooklyn-based designer. He helps shape the reading experience at ProPublica and has previously helped make books at A Book Apart, games at Harmonix, and websites at Happy Cog. In his free time, he obsesses over music and film. Despite all this, he is probably best known as a competitive air guitarist.

More articles by Rob

Jina Anne silences the night to talk about how we talk about Design Systems. Can the language we use impact the effectiveness of the solution? Fear not, if mighty dread has seized your troubled mind. Design systems of great joy we bring to you and all mankind.

Ooh, clickbaity title. Why on earth would I, a self-proclaimed “design systems advocate”, say there is no design system? Yes, I’m being a little tongue-in-cheek. Maybe I just wanted an excuse to use the “there is no spoon” gif. But I do have an actual point, so bear with me.

Design systems as a “thing” vs design systems as a methodology

Recently I tweeted my thoughts on why I have been tending to use design systems in plural form (rather than using an article like “a” or “the” in front of it). During my time at Salesforce when our team was called “Design Systems” and my role was “Lead Designer, Design Systems”, I would get asked “Why is it plural? We only have one.”.

My thoughts:

I liked my title at Salesforce as “Lead Designer, Design Systems”.

People asked, but it’s just one. Why plural?

“A design system” or “The design system” makes people think of a deliverable artifact/library.

But it’s ongoing design systems work. Process improvement & workflows.

— design systems jina (@jina) December 12, 2019

Lately, I’ve been thinking a lot about the way we talk about design systems, including the confusion and negativity that can come along with it. Amélie Lamont gave a talk in 2018 called “The Language of Design”, and in it, she talked about the way we talk about design systems and design itself from a “jargony point of view”. She argues that design is technically problem-solving.

I definitely agree. People get caught up in “design” as the actual role or action of designing and have even taken issue with the term “design systems” for this very reason (and have suggested it be more focused on code). I don’t think it really does us a good service to just swap out one role for the other. And… is it even about the role?

For other folks, which I include myself, we see design as a larger effort that involves the end-user experience (which includes usability, accessibility, performance, etc) as well as having a huge impact on the business. This includes code.

But really, it should all be focused on people. I like Mina Markham’s definition of what makes for good art direction in design systems:

Art direction is progressive. Localized. Cross-functional. Inclusive. Systematic.

Mina Markham

You’ll notice that the emphasis of what she speaks about is on people.

So in the design systems work we do, you often think of a style guide. Or a component library. Or a Sketch UI Kit. And there are arguments on whether either of those things can be called a design system if it doesn’t include this other thing or that other thing. We even talk about whether design systems are products or are more of a service. My take? The word “design” and “system” used in combination together literally just means to systemize your design (and in my world view that is more about the overall experience). And so if for you that means a Sketch UI Library, then you do you! My point is I think there is too much focus on the deliverables in the first place.

I touched on this briefly very recently:

Something I’ve been thinking a lot about is how much time we spend on making beautiful design system websites. I love looking at them. They’re great. But as our design and engineering tools get closer and closer together, will we come to a point where we don’t need the website? Can our tools surface suggestions for better accessibility, localization, performance, and usability, because our design system is baked into the tools? Just a thought.

Quote from post in Smarter Design Systems Tools

Invisible Design Systems?

So this is something I am striving for in 2020 — in what ways can we improve our collaboration, remove any proverbial gaps between design and engineering (not just bridge them), and have more meaningful conversations around the work we do? I don’t have any wrong or right answers here, but I am looking forward to seeing this progress in our field.

Design tools are bringing in smarter, automated ways to check for color contrast and other accessibility issues that can be detected early on. Sketch just announced their Assistant feature planned for 2020, which will check for your visual design discrepancies. And some design tools are using real code to be used in your product.

Engineering tools are advancing every day as well. I was just attending Flutter Interact recently, which was an event held by Google about their Flutter UI toolkit. It previously enabled you to get apps built for native platforms like Android and iOS, from one code base, and now has also announced their support for desktop and web. The push at this year’s event was focused on making this approachable for creatives (with their integrations into tools like Adobe XD. It really does feel like design and engineering tools are coming closer and closer together. And that’s all really cool and exciting.

However, I have to tell you: a lot of the time that I’m working in design systems, I’m not even touching a design tool. Or coding. Rather, it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting. That’s a lot of invisible systems work right there. (I use “invisible” here to mean there is not a direct tangible object in some of this work, though it all does serve the end-user through the product outcomes).

Designed objects are the fruit of invisible systems.

Amélie Lamont

This definitely is not me saying “don’t build a style guide” or “don’t make a Sketch UI Kit”. Use whatever works best for your organization. But this essentially is a plea to always put the focus on the people using your products. And, think about design systems as more of a methodology. A shining example of this way of designing systems is the newly released Encore from Spotify. I had the opportunity to see this revealed at Design Systems London, and they just published a post on it recently.

What’s different about Encore is that it isn’t a single monolithic thing. It’s a framework that brings Spotify’s existing design systems under one brand—a “system of systems.”

Source: Reimagining Design Systems at Spotify

This design systems work is not about one style guide website and instead focuses on the needs across several systems that are connected. Design Tokens help this to be a reality. Needless to say, I’m a big fan.

Love for your community

Design system principle #4: Favor community over control.

— Nathan Curtis (@nathanacurtis) March 23, 2017

When you’re doing design systems work in your organization, you are actually building a community. This can involve shared language and nomenclature, an aligned purpose, and better, closer collaboration. It doesn’t have to be a “style police” situation (I actually very much dislike the term “governance”). This can be a joint effort – working together to share the ownership of design systems together.

I was a big fan of the pairing model that we had at Salesforce when I was there. The work we did in design systems informed the work our product designers did. But then the work that the product designers did, in turn, informed the work we did in design systems. It was a very cyclical model and combined Nathan Curtis’s observed models of the Centralized Team and the Federated Contributors.

From my experience, I have found that great design systems teams have hybrid skillsets. Whether that is having actual hybrid designer/engineers on the team, or just ensuring that those skillsets are represented across the team, it’s important to have the perspectives of design, engineering, product, content, accessibility, and more.

I think that part of a designer’s role – and not even a designer. Anybody who uses the design system by nature of what a design system is – it’s the conglomeration of all the disciplines. Some code, some design, some product knowledge, some writing. And what that means is I think everybody on the team has to approach it with some humility.

Dan Mall

Kim Williams spoke recently in her talk, Start with your Brand Purpose, on Design Systems Love:

Love is patient. With design systems, …it’s a marathon and not a sprint. …this is a long game and it is a labor of love. And love is kind. We support everyone through change. Internally change is so hard. How do you help engineers work in a different way, how do you help PMs think strategically and embrace a new definition of analytical, how do you make in-roads with marketing so that they’re comfortable with you talking about brand and that you’re comfortable with marketing talking about user experience? How do you really, really build those relationships up through empathy. …the onus is on us to educate, to facilitate, to help others understand, to speak the language, to be that bridge, to be that connector, to be that catalyst for our companies. It always trusts, always hopes, always perseveres. Never fails. I love this because there’s a resiliency that we need to have, a resilience when we go through this.

Kim Williams

I love, love, love that.

And so while I still think it’s fun to explore new tools and get really excited about certain processes, at the end of the day, (in my most humble opinion), the best design systems teams are not just hybrid teams — they are also teams that work and supports each other really well, thus producing amazing user-centered work.

So, my suggestion for the coming year is to perhaps move away from thinking of design systems as an actual thing (especially when it comes to the negative perception of spending time on them) and more as a way of working better, more efficiently, and more creatively so that we can build great experiences for our users. I like to repeat in my work, Design Systems are for people, because it is a call to cherish, support, and empower the people you serve (both internally and externally).

Happy holidays!

About the author

Jina is a design systems advocate and coach. At Amazon, Jina was Senior Design Systems Lead. At Salesforce, she was Lead Designer on the Lightning Design System. She led the CSS architecture and style guide for the Apple Online Store. She’s also worked at GitHub, Engine Yard, Crush + Lovely, and Memphis Brooks Museum of Art, and more. She developed projects with W3C, Mass.gov, FedEx, etc.

Jina coauthored Design Systems Handbook, Fancy Form Design, and The Art & Science of CSS. She’s published several articles. She’s spoken at conferences including Adobe MAX. Print Magazine featured Jina as a leading San Francisco creative.

More articles by Jina

Divya Sasidharan calls into question the trade-offs often made between security and usability. Does a secure interface by necessity need to be hard to use? Or is it the choice we make based on years of habit? Snow has fallen, snow on snow.

Security is often synonymous with poor usability. We assume that in order for something to be secure, it needs to by default appear impenetrable to disincentivize potential bad actors. While this premise is true in many instances like in the security of a bank, it relies on a fundamental assumption: that there is no room for choice.

With the option to choose, a user almost inevitably picks a more usable system or adapts how they interact with it regardless of how insecure it may be. In the context of the web, passwords are a prime example of such behavior. Though passwords were implemented as a way to drastically reduce the risk of attack, they proved to be marginally effective. In the name of convenience, complex, more secure passwords were shirked in favor of easy to remember ones, and passwords were liberally reused across accounts. This example clearly illustrates that usability and security are not mutually exclusive. Rather, security depends on usability, and it is imperative to get user buy-in in order to properly secure our applications.

Security and Usability; a tale of broken trust

At its core, security is about fostering trust. In addition to protecting user accounts from malicious attacks, security protocols provide users with the peace of mind that their accounts and personal information is safe. Ironically, that peace of mind is incumbent on users using the security protocols in the first place, which further relies on them accepting that security is needed. With the increased frequency of cyber security threats and data breaches over the last couple of years, users have grown to be less trusting of security experts and their measures. Security experts have equally become less trusting of users, and see them as the “the weakest link in the chain”. This has led to more cumbersome security practices such as mandatory 2FA and constant re-login flows which bottlenecks users from accomplishing essential tasks. Because of this break down in trust, there is a natural inclination to shortcut security altogether.

Build a culture of trust not fear

Building trust among users requires empowering them to believe that their individual actions have a larger impact on the security of the overall organization. If a user understands that their behavior can put critical resources of an organization at risk, they will more likely behave with security in mind. For this to work, nuance is key. Deeming that every resource needs a similarly high number of checks and balances diminishes how users perceive security and adds unnecessary bottlenecks to user workflows.

In order to lay the foundation for good security, it’s worth noting that risk analysis is the bedrock of security design. Instead of blindly implementing standard security measures recommended by the experts, a better approach is to tailor security protocols to meet specific use cases and adapt as much as possible to user workflows. Here are some examples of how to do just that:

Risk based authentication

Risk based authentication is a powerful way to perform a holistic assessment of the threats facing an organization. Risks occur at the intersection of vulnerability and threat. A high risk account is vulnerable and faces the very real threat of a potential breach. Generally, risk based authentication is about calculating a risk score associated with accounts and determining the proper approach to securing it. It takes into account a combination of the likelihood that that risk will materialize and the impact on the organization should the risk come to pass. With this system, an organization can easily adapt access to resources depending on how critical they are to the business; for instance, internal documentation may not warrant 2FA, while accessing business and financial records may.

Dynamically adaptive auth

Similar to risk based auth, dynamically adaptive auth adjusts to the current situation. Security can be strengthened and slackened as warranted, depending on how risky the access point is. A user accessing an account from a trusted device in a known location may be deemed low risk and therefore not in need of extra security layers. Likewise, a user exhibiting predictive patterns of use should be granted quick and easy access to resources. The ability to adapt authentication based on the most recent security profile of a user significantly improves the experience by reducing unnecessary friction.

Conclusion

Historically, security failed to take the user experience into account, putting the onus of securing accounts solely on users. Considering the fate of password security, we can neither rely on users nor stringent security mechanisms to keep our accounts safe. Instead, we should aim for security measures that give users the freedom to bypass them as needed while still protecting our accounts from attack. The fate of secure systems lies in the understanding that security is a process that must constantly adapt to face the shifting landscape of user behavior and potential threats.

About the author

Divya is a web developer who is passionate about open source and the web. She is currently a developer experience engineer at Netlify, and believes that there is a better workflow for building and deploying sites that doesn’t require a server—ask her about the JAMstack. You will most likely find her in the sunniest spot in the room with a cup of tea in hand.

More articles by Divya

Amy Hupe prepares a four bird roast of tasty treats so we can learn how the needs of many different types of users can be served through careful implementation of components within a design system.

Design systems help us to make our products consistent, and to make sure we’re creating them in the most efficient way possible. They also help us to ensure our products are designed and built to a high quality; that they’re not only consistent in appearance, and efficiently-built, but that they are good. And good design means accessible design.

1 in 5 people in the UK have a long term illness, impairment or disability – and many more have a temporary disability. Designing accessible services is incredibly important from an ethical, reputational and commercial standpoint. For EU government websites and apps, accessibility is also a legal requirement.

With that in mind, I’ll explain the four main ways I think we can use design systems to promote accessible design within an organisation, and what design systems can’t do.

1. Bake it in

Design systems typically provide guidance and examples to aid the design process, showing what best practice looks like. Many design systems also encompass code that teams can use to take these elements into production. This gives us an opportunity to build good design into the foundations of our products, not just in terms of how they look, but also how they work. For everyone.

Let me give an example.

The GOV.UK Design System contains a component called the Summary list. It’s used in a few different contexts on GOV.UK, to summarise information. It’s often used at the end of a long or complex form, to let users check their answers before they send them, like this:

Users can review the information and, if they’ve entered something incorrectly, they can go back and edit their answer by clicking the “Change” link on the right-hand side. This works well if you can see the change link, because you can see which information it corresponds to.

In the top row, for example, I can see that the link is giving me the option to change the name I’ve entered because I can see the name label, and the name I put in is next to it.

However, if you’re using a screen reader, this link – and all the others – will just say “change”, and it becomes harder to tell what you’re selecting. So to help with this, the GOV.UK Design System team added some visually-hidden text to the code in the example, to make the link more descriptive.

Sighted users won’t see this text, but when a screen reader reads out the link, it’ll say “change name”. This makes the component more accessible, and helps it to satisfy a Web Content Accessibility Guidelines (WCAG 2.1) success criterion for links which says we must “provide link text that identifies the purpose of the link without needing additional context”.

By building our components with inclusion in mind, we can make it easier to make products accessible, before anyone’s even had to think about it. And that’s a great starting point. But that doesn’t mean we don’t have to think about it – we definitely do. And a design system can help with that too.

2. Explain it

Having worked as the GOV.UK Design System’s content designer for the best part of 3 years, I’m somewhat biased about this, but I think that the most valuable aspect of a design system is its documentation.

(Here’s a shameless plug for my patterns Day talk on design system documentation earlier this year, if you want to know more about that.)

When it comes to accessibility, written documentation lets us guide good practice in a way that code and examples alone can’t.

By carefully documenting implementation rules for each component, we have an opportunity to distribute accessible design principles throughout a design system. This means design system users encounter them not just once, but repeatedly and frequently, in various contexts, which helps to build awareness over time.

For instance, WCAG 2.1 warns against using colour as “the only visual means of conveying information, calling an action, prompting a response or distinguishing a visual element”. This is a general principle to follow, but design system documentation lets us explain how this relates to specific components.

Take the GOV.UK Design System’s warning buttons. These are used for actions with serious, often destructive consequences that can’t easily be undone – like permanently deleting an account.

The example doesn’t tell you this, but the guidance explains that you shouldn’t rely on the red colour of warning buttons to communicate that the button performs a serious action, since not all users will be able to see the colour or understand what it signifies.

Instead, it says, “make sure the context and button text makes clear what will happen if the user selects it”. In this way, the colour is used as an enhancement for people who can interpret it, but it’s not necessary in order to understand it.

Making the code in our examples and component packages as accessible as possible by default is really important, but written documentation like this lets us be much more explicit about how to design accessible services.

3. Lead by example

In our design systems’ documentation, we’re telling people what good design looks like, so it’s really important that we practice what we preach.

Design systems are usually for members of staff, rather than members of the public. But if we want to build an inclusive workplace, we need to hold them to the same standards and ensure they’re accessible to everyone who might need to use them – today and in the future.

One of the ways we did this in my team, was by making sure the GOV.UK Design System supports users who need to customise the colours they use to browse the web. There are a range of different user needs for changing colours on the web. People who are sensitive to light, for instance, might find a white background too bright. And some users with dyslexia find certain colours easier to read than others.

My colleague, Nick Colley, wrote about the work we did to ensure GOV.UK Design System’s components will work when users change colours on GOV.UK. To ensure we weren’t introducing barriers to our colleagues, we also made it possible to customise colours in the GOV.UK Design System website itself.

Building this flexibility into our design system helps to support our colleagues who need it, but it also shows others that we’re committed to inclusion and removing barriers.

4. Teach it

The examples I’ve drawn on here have mostly focused on design system documentation and tooling, but design systems are much bigger than that. In the fortuitously-timed “There is No Design System”, Jina reminds us that tooling is just one of the ways we systematise design:

…it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting.”

To make a design system successful, we can’t just build a set of components and hope they work. We have to actively help people find it, use it and contribute to it. That means we have to go out and talk about it. We have to support people in learning to use it and help new teams adopt it. These engagement activities and collaborative processes that sit around it can help to promote awareness of the why, not just the what.

At GDS, we ran workshops on accessibility in the design system, getting people to browse various web pages using visual impairment simulation glasses to understand how visually impaired users might experience our content. By working closely with our systems’ users and contributors like this, we have an opportunity to bring them along on the journey of making something accessible.

We can help them to test out their code and content and understand how they’ll work on different platforms, and how they might need to be adjusted to make sure they’re accessible. We can teach them what accessibility means in practice.

These kinds of activities are invaluable in helping to promote accessible design thinking. And these kinds of lessons – when taught well – are disseminated as colleagues share knowledge with their teams, departments and the wider industry.

What design systems can’t do

Our industry’s excitement about design systems shows no signs of abating, and I’m excited about the opportunities it affords us to make accessible design the default, not an edge case. But I want to finish on a word about their limitations.

While a design system can help to promote awareness of the need to be accessible, and how to design products and services that are, a design system can’t make an organisation fundamentally care about accessibility.

Even with the help of a thoughtfully created design system, it’s still possible to make really inaccessible products if you’re not actively working to remove barriers. I feel lucky to have worked somewhere that prioritises accessibility. Thanks to the work of some really brilliant people, it’s just part of the fabric at GDS. (For more on that work and those brilliant people, I can’t think of a better place to start than my colleague Ollie Byford’s talk on inclusive forms.)

I’m far from being an accessibility expert, but I can write about this because I’ve worked in an organisation where it’s always a central consideration. This shouldn’t be something to feel lucky about. It should be the default, but sadly we’re not there yet. Not even close.

Earlier this year, Domino’s pizza was successfully sued by a blind customer after he was unable to order food on their website or mobile app, despite using screen-reading software. And in a recent study carried out by disability equality charity, Scope, 50% of respondents said that they had given up on buying a product because the website, app or in-store machine had accessibility issues.

Legally, reputationally and most importantly, morally, we all have a duty to do better. To make sure our products and services are accessible to everyone. We can use design systems to help us on that journey, but they’re just one part of our toolkit.

In the end, it’s about committing to the cause – doing the work to make things accessible. Because accessible design is good design.

About the author

Amy is a content specialist and design systems advocate who’s spent the last 3 years working as a Senior Content Designer at the Government Digital Service.

In that time, she’s led the content strategy for the GOV.UK Design System, including a straightforward and inclusive approach to documentation.

In January, Amy will continue her work in this space, in her new role as Product Manager for Babylon Health’s design system, DNA.

More articles by Amy

Drew McLellan puts the chairs up on the tables, sweeps the floor, and closes off our season, and indeed the entire 24 ways project with a look back at what it’s meant to run this site as a site project, and what impact side projects can have on the work we do. Will the last one out turn off Christmas the lights?

Brought to you by The CSS Layout Workshop. Does developing layouts with CSS seem like hard work? How much time could you save without all the trial and error? Are you ready to really learn CSS layout?

Fifteen years ago, on a bit of a whim, I decided it would be fun to have a Web Standards version of something like the Perl Advent calendar. A simple website with a new tip or trick each day leading the readers through December up until Christmas.

I emailed a bunch of friends that kept web design and development themed blogs (remember those?) suggesting the idea and asking if they’d like to contribute. My vision had been that each post would be a couple of paragraphs of information. A small nugget of an idea, or a tip, or a suggestion. What happened was something really amazing. I began to receive really insightful blog posts containing some of the most valuable writing I’d seen online all year.

Look at this piece from Ethan Marcotte on Centered Tabs with CSS, or this detailed piece on scripting block quotes from Jeremy Keith. I was blown away, and the scene was set.

Collaboration

What I hadn’t anticipated in 2005 was that this little side project would turn into a fixture of the industry calendar, would introduce me to a raft of field experts, and would have me working with an eclectic team of collaborators for fifteen long seasons.

And that last point is crucial. I’ve by no means produced this alone. Rachel Andrew has been a constant supporter in helping each year to see the light of day and producing our ebooks. After a couple of years, Brian Suda stepped in to help me plan and select authors. In 2008, I managed to persuade Tim Van Damme to replace my very basic site design with something altogether more fitting. In 2010, Anna Debenham came on board initially to help with the production of articles, but rapidly became a co-producer working with me on all aspects of the content. Owen Gregory joined up that same year to help with the proofing and editing of articles, and for many years did a fantastic job writing the home page article teasers, which are now but a shadow of their former selves.

Also in 2010, we produced a book in collaboration with Five Simple Steps and raising funds in the memory of Remy and Julie’s daughter, Tia Sharp.

In 2013, Paul Robert Lloyd stepped up to the plate to provide us with the design you see today, which not only subtly shifts colours between each day, but across the years as well. Compare the reds of 2005 to the purples of 2019, and the warm tones of a Day 1 to its correspondingly cool Day 24. It’s a terrific piece of work.

In 2014 we won a Net Award for Best Collaborative Project at a fancy ceremony in London. Many past authors were there, and as it was an aware for our collaborative efforts, we all posed with the glassware for photos.

Looking back, looking forward

But even I, Sea Captain Belly Button am not enough of a navel gazer to just be writing an article just about this website. As we draw our fifteenth and final year to a close, it’s important to reflect on what can be learned. Not from the articles (so much!) or from the folly of committing to a nightly publishing schedule for a month every year for fifteen years (don’t do it!) but from the value in starting something not because you have to, but just because you want to. From scratching an itch. From working with a friend just because you love spending time with them. Or for doing something because you see the opportunity for good.

As web designers and developers, we have the opportunity to turn the skills we use in our profession to so many different purposes. In doing so you never know what good might come from it.

Seeing the good

This week I asked around to find out what good others have seen from their side projects. Long time 24 ways contributor Simon Willison had this to say:

Basically every job I’ve ever had relates back to a side-project in some way

— Simon Willison (@simonw) December 17, 2019

Simon went onto explain how it was a website side project that got him his first job in tech. After that, his personal blog lead him to getting a job at Lawrence Journal-World where he created Django. On his honeymoon, Simon and his new wife (and 24 ways contributor) Natalie Downe created Lanyrd, and Simon’s more recent Datasette project landed him a JSK Fellowship at Stanford. That’s an impressive record of side projects, for sure.

Others had similar stories. My good friend Meri Williams is currently CTO of challenger bank Monzo, as well as being a trustee at Stonewall and Chair of The Lead Developer conference.

I got asked to write the book you tech reviewed off the back of a Meetup talk.

Chairing @TheLeadDev has led to me getting to hire & work with so many new brilliant people, as well as getting me multiple CTO gigs (both perm & interim)

Got the gig chairing Lead Dev after meeting @RuthYarnit at a dev meet-up in the basement of a pub in Reading (which I think @drewm you also spoke at / introduced me to!)

Leading LGBTQ employee network at P&G eventually led to my applying for board role at Stonewall

— Meri Williams ???????????? (@Geek_Manager) December 18, 2019

Again, an impressive list of achievements, and I’m sure both Simon and Meri would have eventally found other routes to their individual success, but the reality is they did it through side projects. Through being present and active, contributing a little to their communities, and receiving so much more back in return.

Of course, not all projects have to be directly related to the web or software to be fulfilling. Of course they don’t. Mark Small and Jack Shoulder embraced their love of a good rear end and created MuseumBums, informally cataloging perfect posteriors for your perusing pleasure. On its success, Mark says:

Ok! We’ve been profiled in the Cambridge Independent, the Sun and the Metro; raised money for Prostate Cancer UK; created a little community of museum fans who aren’t afraid to be a bit silly online; and we’ve got a list of big ideas for developing our ????????️???? offer further! ????

— Marky Smallstice ???????????? (@thehistoryb0y) December 17, 2019

Jack adds:

We’ve also got a shout out on @BBCRadio4 and helped a beloved museum achieve record numbers of visitors.

Wow. It’s been a *year*

— Jack Frost (@jackshoulder) December 17, 2019

I had so many heartwarming responses to my request for stories, I really recommend you go over to the thread on Twitter and read it. It’s been one of my favourite set of replies in a long time.

Focussing on what’s important

As the years progressed, more and more publications sprang up both at Christmas and throughout the year with how-to articles explaining techniques. As a natural response, 24 ways started mixing up solution-based articles with bigger picture takes on a wider range of topics, but always with a practical takeaway to impress your friends.

After the embarrassment of white dudes that dominated the early years, we actively sought to open the opportunity to write to a wider and more diverse range of experts. While I don’t think we ever got as much racial diversity in our lineup as I would have liked to have achieved, I’m very proud that each season has been closely gender-balanced since 2012. This is something that was never forced or remotely hard to achieve, all it took was an awareness of the potential for bias.

Calling time

With all the benefits that side projects can bring, it’s also important to be mindful of downsides. Not every project will take flight, and those that do can also start to consume valuable time. That’s fine while it’s fun and you’re seeing the benefits, but it’s neither fun or healthy long-term to have no time away from something that might otherwise be your job.

Spending time with family, friends, and loved ones is equally important especially at this time of year. Just as anyone who does a lot of sport or fitness will tell you about the value of rest days between your activities to let the body recover, time away from ‘work’ is important to do the same for your brain.

Having run this site every Christmas for 15 seasons, it’s time to take a breather and give it a rest. Who knows if we might return in the future, but no promises. It’s been a good run, and an absolute privilege to provide this small tradition to the community I love.

So from me and the whole 24 ways family, Happy Christmas to all, and to all a good night.

About the author

Drew McLellan is a developer and content management consultant from Bristol, England. He’s the lead developer for the popular Perch and Perch Runway content management systems, and public speaking portfolio site Notist. Drew was formerly Group Lead at the Web Standards Project, and a Search Innovation engineer at Yahoo!. When not publishing 24 ways, he keeps a personal site about web development, takes photos, tweets a lot and tries to stay upright on his bicycle.

More articles by Drew

Education, awareness and bringing dignity back to weaving... only these will help put handloom back where it once belonged, designers tell SUBHA J RAO

Four women who work closely with traditional weavers talk about why the #IWearHandloom initiative is a start in recognising the importance of handlooms

Flaunting an enviable collection of exclusive editions of denims, L. Murali Krishnan is a true-blue denim lover and a die hard fashionista

Designers must create new templates that suit their creativity instead of allowing the market to set the pace for them, says Sabyasachi Mukherjee, who will present his collection at the finale of Lakme Fashion Week.

Poonam Bhagat’s penchant for intricate detailing is visible in her latest collection, writes PRIYADARSHINI PAITANDY

The second season of Madras Bridal Fashion Show has something for every kind of bride

Designers play with a wide colour palette for the festive season

Don’t let the grey skies dampen your style. Add a dose of colour to your outfits, slip into those jelly shoes, open that kitschy umbrella and you’re good to go, writes RANJANI RAJENDRA

Designers Gaurav Gupta and Purvi Doshi explain how innovation and sustainability can go hand in hand

Anjalee and Arjun Kapoor on their latest collection ‘Persian Flora’ and the importance of connecting with people and places

Saif Siddiqui on designing the ISHU scarf that’s got celebs going gaga over it

The ongoing Olympics at Rio is creating a buzz not just for its sports but also for the fashion flaunted by the sportsmen, says NEETI SARKAR

The ongoing Olympics at Rio is creating a buzz not just for its sports but also for the fashion flaunted by the sports stars, says NEETI SARKAR

Bina Rao’s collection for Lakme Fashion Week Winter/Festive 2016 draws inspiration from Rembrandt’s paintings

A mushrooming of beauty facilities in the city, offering a plethora of choices, is redefining the conventional idea of beauty

Designer Sonal Verma tells us how leather craftsmanship is giving her a push into the world of fashion

SRIYA NARAYANAN embraces the minimalism trend and tells you how to master it

Who modelled for whom during this year's edition of Lakme Fashion Week's Winter collection?

Fashion designer Ritu Beri wonders if privatisation is the key to India performing better at global sporting events

Skirts are back in news in more ways than one

Manish Malhotra, the designer behind the country’s first virtual reality fashion show, tells us what made his show special

Pop-up stores might offer the perfect retail therapy, fusing style and surprise, but we still have a lot of catching up to do with the West, curators tell us.

“It is a Festival of Fantasy; Beauty and majesty shining magically. Dreams that grow wondrous; Dazzling brilliantly”

Sumona Parekh tells us how she is reviving Baluchori weaves and bringing them into the mainstream fashion

Malabar Gold and Diamonds brings to town a wide range of exquisite handcrafted jewellery

NEETI SARKAR gets fashion experts to reveal how you can dress smart this season in spite of the finicky weather

Testing time it was for models from India and abroad during auditions of the Amazon India Fashion Week Spring-Summer 2017.

Indonesian designer Anniesa Hasibuan made history at the New York Fashion Week on September 12. Find out how.

Rang Mahal brings to the city the creations of 250 weavers from Nadia

Aneeth Arora tells MADHUR TANKHA how she has given the fabric a new meaning for her latest collection

This festive season, give the staid old gift box a miss and opt for curated ones instead, writes PRIYADARSHINI PAITANDY

Kavita Bhartia’s latest collection is inspired by Turkish pottery

Whip out the deep grape lipstick. Here are favourite make-up trends this coming winter

A conversation and an exhibition that offer glimpses of the city of Nizams

Vidhya Maghanath Sunder designed jewellery as a hobby, but the response she got for her creations convinced her to look at it as a serious business venture

An affinity for art and certain turns her life took that drew R. Vaishnavi to tattooing

Shantanu and Nikhil speak of their 16-year-journey and why they like to keep their style subtle

Do you have treggings in your closet yet? A. SHRIKUMAR tells you why you should own a pair or more of these comfortably trendy pants

Swedish brand H&M launches its first store in the city today. We list the top picks from the collection.

Sagar Tenali, whose demise has left the city’s fashion fraternity in shock, had dreamt of showcasing his work at Lakme Fashion Week