A List Apart

Subscribe to A List Apart feed
Articles for people who make web sites.
Updated: 1 hour 11 min ago

How People Perceive Lossy Image Quality: A Study

Thu, 09/21/2017 - 06:30

The notion that lossy image quality is subjective is not an unreasonable hypothesis. There are many factors that play into how humans perceive quality: screen size, image scaling, and yes, even performance.

Many research projects have tackled this subject, but I’ve recently launched a survey that attempts to understand how people perceive image quality in a slightly different way: in the context of performance.

This image quality assessment serves up 25 different specimens, each of which is presented in a random lossy quality setting between 5 and 100, in both JPEG and WebP formats. As participants complete the survey, navigation, resource and paint timings are collected (when available) from the browser, as well as other client details such as a device’s resolution, pixel density, and many other pertinent details.

The real work of gathering data begins. This is where you can help out. If you have five to ten minutes to spare, please head over to https://imagesurvey.site and participate. When the survey is finished, I’ll post the raw data and write and article (or two) on the findings. If further experimentation is required, that will be pursued as well. I don’t know what we’ll find out, but we’ll find out together with your input. So please participate!

Thank you!

Note: If you have feedback for how to improve the survey, feel free to comment! Just be aware that your feedback can’t be implemented in this run of the survey, but it could be useful in constructing any follow-up surveys.

The Ten Essentials for Good API Documentation

Tue, 09/19/2017 - 07:00

API documentation is the number one reference for anyone implementing your API, and it can profoundly influence the developer experience. Because it describes what services an application programming interface offers and how to use those services, your documentation will inevitably create an impression about your product—for better or for worse.

In this two-part series I share what I’ve learned about API documentation. This part discusses the basics to help you create good API docs, while in part two, Ten Extras for Great API Documentation, I’ll show you additional ways to improve and fine-tune your documentation. 

Know your audience

Knowing who you address with your writing and how you can best support them will help you make decisions about the design, structure, and language of your docs. You will have to know who visits your API documentation and what they want to use it for. 

Your API documentation will probably be visited and used by the following audiences. 


Based on their skills, experience, and role in projects, developers will generally be the largest and most diverse group. They’ll be using your docs in different ways.

At Pronovix, we started conducting developer portal workshops with our clients to help them learn more about what developers need and how to best support their work—and what they’re really looking for in API documentation. This is also supported by solid research, such as the findings published in Stephanie Steinhardt’s article following a two-year research program at Merseburg University of Applied Sciences.

Newcomers: Developers lacking previous experience with your API tend to need the most support. They will take advantage of quickstart guides that encourage them to start using your API—clear, concise, step-by-step tutorials for the most important topics, and sample code and examples to help them understand how to use it in real projects. If you can make onboarding pleasant for newcomers, they will be more likely to devote themselves to learning every nuance of your API.

External developers: Developers already working with your API will come back repeatedly to your docs and use them as reference material. They will need quick information on all the functionality your API offers, structured in an easy to understand way to help them quickly find what they need.

Debuggers: Developers using your API will encounter errors from time to time and use your documentation to analyze the responses and errors that crop up.

Internal developers: API providers tend to focus so much on their external audience that they forget about their own developers; internal teams working on the API will use the API documentation, as well.

These are just the most common use cases.

Decision makers

Decision makers like CTOs and product managers will also check out your API documentation and evaluate your API. They need to determine whether your API will be a good fit for their project or not, so it’s crucial to your business that this group can easily and quickly find what they’re looking for.

Other audiences

Although not as common, journalists, technical writers, support staff, developer evangelists, and even your competition might read your API documentation. 

Remember the purpose of documentation

The foundation of your API documentation is a clear explanation of every call and parameter.

As a bare minimum, you should describe in detail:

  • what each call in your API does
  • each parameter and all of their possible values, including their types, formatting, rules, and whether or not they are required.
Context-based structure

People won’t read your API documentation in order, and you can’t predict which part they will land on. This means, you have to provide all the information they need in context. So following the best practices of topic-based authoring, you should include all necessary and related information in the explanation of each call.

Context.IO, for example, did a great job documenting each of their API calls separately with detailed information on parameters and their possible values, along with useful tips and links to related topics.


In order to be able to implement your API, developers need to understand it along with the domain it refers to (e.g., ecommerce). Real world examples reduce the time they need to get familiar with your product, and provide domain knowledge at the same time.

Add the following to the description of each call:

  • an example of how the call is made
  • an explanation of the request
  • sample responses

Studies have shown, that some developers immediately like to delve into coding, when getting to know a new API; they start working from an example. Analysis of eye-tracking records showed that visual elements, like example code, caught the attention of developers who were scanning the page, rather than reading it line by line.  Many looked at code samples before they started reading the descriptions.

Using the right examples is a surefire way to improving your API docs. I’ll explore ways to turn good API docs into great ones using examples in my upcoming post “Ten Extras for Great API Documentation”.

Error messages

When something goes wrong during development, fixing the problem without detailed documentation can become a frustrating and time-consuming process. To make this process as smooth as possible, error messages should help developers understand:

  • what the problem is;
  • whether the error stems from their code or from the use of the API;
  • and how to fix the problem.

All possible errors—including edge cases—should be documented with error-codes or brief, human-readable information in error messages. Error messages should not only contain information related to that specific call, but also address universal topics like authentication or HTTP requests and other conditions not controlled by the API (like request timeout or unknown server error).

This post from Box discusses best practices for server-side error handling and communication, such as returning an HTTP status code that closely matches the error condition, human-readable error messages, and machine-readable error codes.

Quickstart guide

Newcomers starting to implement your API face many obstacles:

  • They are at the beginning of a steep learning curve
  • They might not be familiar with the structure, domain, and ideas behind your API
  • It’s difficult for them to figure out where to start.

If you don’t make the learning process easier for them, they can feel overwhelmed and refrain from delving into your API. 

Many developers learn best by doing, so a quickstart guide is a great option. The guide should be short and simple, aimed at newcomers, and list the minimum number of steps required to complete a meaningful task (e.g., downloading the SDK and saving one object to the platform). Quickstart guides usually have to include information about the domain and introduce domain-related expressions and methods in more detail. It’s safest to assume that the developer has never before heard of your service.

Stripe’s and Braintree’s quickstart guides are great examples; both provide an overview of the most likely tasks you’ll want to perform with the API, as well as link you to the relevant information. They also contain links to contact someone if you need help.


Tutorials are step-by-step walkthroughs covering specific functionality developers can implement with your API, like SMS notifications, account verification, etc.

Tutorials for APIs should follow the best practices for writing any kind of step-by-step help. Each step should contain all the information needed at that point—and nothing more. This way users can focus on the task at hand and won’t be overloaded with information they don’t need.

The description of steps should be easy to follow and concise. Clarity and brevity support the learning process, and are a best practice for all kinds of documentation. Avoid jargon, if possible; users will be learning domain-related language and new technology, and jargon can instill confusion. Help them by making all descriptions as easy to understand as possible. 

The walkthrough should be the smallest possible chunk that lets the user finish a task. If a process is too complex, think about breaking it down into smaller chunks. This makes sure that users can get the help they need without going through steps they’re not interested in.

Twilio’s tutorials explain the most-likely use cases with sample apps in a wide variety of programming languages and frameworks. Universal topics

To implement your API, there are some larger topics that developers will need to know about, for example:

  • Authentication. Handled differently by each type of API, authentication (e.g., OAuth) is often a complicated and error-prone process. Explain how to get credentials, how they are passed on to the server, and show how API keys work with sample code.
  • Error handling. For now, error handling hasn’t been standardized, so you should help developers understand how your API passes back error information, why an error occurs, and how to fix it.
  • HTTP requests. You may have to document HTTP-related information as well, like content types, status codes, and caching.

Dedicate a separate section to explaining these topics, and link to this section from each related API call. This way you can make sure that developers clearly see how your API handles these topics and how API calls change behavior based on them. 

Layout and navigation

Layout and navigation are essential to user experience, and although there is no universal solution for all API docs, there are some best practices that help users interact with the material.

Dynamic layout

Most good examples of API documentation use a dynamic layout as it makes navigation easier for users than static layouts when looking for specific topics in extensive documentation. Starting with a scalable dynamic layout will also make sure you can easily expand your docs, as needed.

Single page design

If your API documentation isn’t huge, go with a single page design that lets users see the overall structure at first sight. Introduce the details from there. Long, single page docs also make it possible for readers to use the browser’s search functionality.

Stripe managed to present extensive documentation in an easy to navigate single page. Persistent navigation

Keep navigation visible at all times. Users don’t want to scroll looking for a navigation bar that disappeared.

Multi-column layout

2- or 3-column layouts have the navigation on the left and information and examples on the right. They make comprehension easier by showing endpoints and examples in context.

Clearbit’s three-column layout displays persistent navigation (table of contents) on the left, references in the middle, and code examples on the right. Syntax highlighter

Improving the readability of samples with syntax highlighting makes the code easier to understand.

The syntax highlighter in action on Plaid’s API documentation site.

If you’d like to start experimenting with a layout for your docs, you might want to check out some free and open source API documentation generators.

To learn about the pros and cons of different approaches to organizing your API docs in the context of developer portals, this is an excellent article by Nordic APIs.


All writing that you publish should go through an editing process. This is common sense for articles and other publications, but it’s just as essential for technical documentation.

The writers of your API docs should aim for clarity and brevity, confirm that all the necessary information is there, and that the structure is logical and topics aren’t diluted with unnecessary content. 

Editors should proofread your documentation to catch grammar mistakes, errors, and any parts that might be hard to read or difficult to understand. They should also check the docs against your style guide for technical documentation and suggest changes, if needed.

Once a section of documentation is ready to be published, it’s a good idea to show it to people in your target audience, especially any developers who haven’t worked on the documentation themselves. They can catch inconsistencies and provide insight into what’s missing.

Although the editing process can feel like a burden when you have to focus on so many other aspects of your API, a couple of iterations can make a huge difference in the final copy and the impression you make.

Keep it up-to-date

If your API documentation is out of date, users will get frustrated by bumping into features that aren’t there anymore and new ones that lack documentation. This can quickly diminish the trust you established by putting so much work into your documentation in the first place.

When maintaining your API docs, you should keep an eye on the following aspects:

  • Deprecated features. Remove documentation for deprecated features and explain why they were deprecated.
  • New features. Document new features before launch, and make sure there’s enough time planned for the new content to go through the editorial process.
  • Feedback. Useful feedback you get from support, or analytics should be reflected in your docs. Chances are you can’t make your docs perfect at the first try, but based on what users are saying, you can improve them continuously.

For all this to work, you will have to build a workflow for maintaining your documentation. Think about checkpoints and processes for the above mentioned aspects, editing, and publication. It also helps if you can set up a routine for reviewing your docs regularly (e.g. quarterly).

Following these best practices, you can build a solid foundation for your API documentation that can be continuously improved upon as you gain more insight into how users interact with them. Stay tuned for part two, where I give you some tips on how to turn good API docs into amazing ones.

Project Management for Humans

Thu, 09/14/2017 - 12:40

A note from the editors: We’re pleased to share an excerpt from Chapter 6 of Brett Harned's new book, Project Management for Humans, available now from Rosenfeld Media.

I loved the game Tetris as a kid. I played the Game Boy version for hours. It’s easy to get wrapped up in the concept of little shapes coming together in a logical way to clear a goal. The pieces complement one another, yet they all naturally work in different ways. The game has stuck with me since I was a kid (and, no, I’m not a gamer). I now have it on my phone and iPad and find myself playing it when I’m on a flight or bored, waiting for something to happen (which is never these days). Whether I’m playing the game a lot or not, the idea of making tiny boxes fit in neatly and clearing out rows of work is ingrained in my brain. It’s the project manager in me.

But here’s the thing: What project managers do on a daily basis when it comes to managing resources or staffing is similar to Tetris, and it’s a big project management challenge that we all face. The biggest difference between resourcing and Tetris? The team members we’re trying to assign tasks to aren’t blocks. They’re human beings, and they need to be treated as such.

Your Team Are People, Too!

Let’s move away from calling people “resources,” please. We’re really just staffing projects or assigning tasks. We’re not using people to just get things done. We’re asking them to solve challenges that are presented in our projects.

Set the Stage for Organized Resource Planning

The challenge of managing a team is making sure that they stay busy and working on tasks, yet are not completely overbooked. It’s a difficult balance to find, particularly when your projects require a variety of skills at different times, which seem to change all too often.

At the most basic level, you want to set up a system for tracking your projects and your team members’ time on those projects (see Figure 6.1). A simple goal is to ensure that you can confidently commit to deadlines on projects with the knowledge that your team is actually available to do the related work. It seems like a simple goal, but it’s often a difficult one to keep up with due to changes on projects, changes in personal schedules (hey, life happens), and an influx of new work and requests. But it’s not an insurmountable challenge. In fact, a simple spreadsheet could help you, particularly if you’re managing a smaller team. At the core, you want to track these items:

  • Projects (List them all, even the non-billable ones, or the other things that aren’t projects but end up taking a lot of time—like business development.)
  • People (List every person you work with.)
  • Estimated time (Track hours, days, weeks, etc. Make your best guess—based on your timeline or calendar—on how much each person will spend on a project or a task.)
Figure 6.1 Use a Google Spreadsheet, Numbers, or Excel to input your project and team data.

A couple of notes on how to use a spreadsheet to forecast team availability:

  • This should be set up on a week-by-week basis to minimize confusion (use tabs in your spreadsheet for each new week).
  • Always consider the “nonbillable” things that people must do (like stand-up meetings, internal tasks, sales, etc.).
  • The final cell contains a formula that tallies the hours for you; if the hours go over your typical limit (think of a 40-hour work week), it will turn red to notify you. You’ll want to have a good idea for just how “utilized” someone should be (32 hours/week is usually a good target).
  • You can input the actual hours logged in your time tracking system if you’d like. It could help with future estimating. (If you’re not tracking time, check in with your team on time percentages to get a gut check.)
  • Check your estimates with your team to make sure that the hours actually align with their assessment of the task (This might help with avoiding that red number!)
  • Communicate these hours to the entire team each week. Making sure that everyone “is in the know” will help on any project. Discussing it with individuals will help you understand effort, blockers, and possibly even different ways of working.

The landscape for project management tools is changing constantly. There are a number of tools in the marketplace for helping you manage and communicate this data. If you’ve working with a team of 10 or more, you might want to abandon the spreadsheet approach for something more official, organized and supported. Bonus: Many of these tools handle more than just resourcing!

Here’s the thing—it’s not just about numbers. The issue that makes estimating a team’s project hours difficult is that everyone works differently. There is no way to standardize the human factor here, and that’s what makes it tough. Forget the fact that no one on your team is a robot, and they all work at their own pace. Think about sick days, vacations, client delays, changes on projects, and so on. It’s a never-ending flow of shapes that must fit into the box that is a project. Be sure to have an ongoing dialogue about your staffing plans and challenges.

Match Resource Skills to Projects

Projects only slow down when decisions are not made. In that magical moment when things are actually going well, you want to make sure that your team can continue the pace. The only way to do that is by connecting with your team and understanding what motivates them. Here are some things to consider:

  • Interests: If you have a team member who loves beer, why not put that person on the beer design site? Maybe you have multiple people who want to be on the project, but they are all busy on other projects. These are the breaks. You’ve got to do what is right for the company and your budget. If you can put interests first, it’s awesome. It won’t always work out that way for everyone, but it’s a good first step to try.
  • Skill sets: It’s as simple as getting to know each and every team member’s work. Some people are meant to create specific types of designs or experiences. It not only has to do with interests, but it also has to do with strengths within those tasks. Sure, I may love beer, but that doesn’t mean that I am meant to design the site that caters to the audience the client is trying to reach.
  • Moving schedules: Projects will always change. One week you know you’re working against a firm deadline, and the next week that has changed due to the clients, the needs of the project, or some other reason someone conjured up. It’s tough to know when that change will happen, but when it does, how you’ll fill someone’s time with other work should be high on your mind.
  • Holidays: People always extend them. Plan for that!
  • Vacations: It’s great to know about these in advance. Be sure you know your company’s policies around vacations. You never ever want to be the PM who says “Well, you have a deadline on X date and that will conflict with your very expensive/exciting trip, so, um … no.” Ask people to request trips at least a month in advance so that you can plan ahead and make it work.
  • Illness: We’re all humans and that means we’re fine one day and bedridden the next. You’ve always got to be ready for a back-up plan. It shouldn’t fall on your client stakeholders to make up time, but sometimes it has to. Or sometimes you need to look for someone to pitch in on intermediate tasks to keep things of track while your “rock star” or “ninja” is getting better.
Align Plans with Staffing

When you’re working hard to keep up with staffing plans, you’ve got to have updated project plans. A small change in a plan could cause a change in staffing—even by a few hours—and throw everything else off.

Save Yourself and Your Team from Burnout

If you’re busy and not slowing down any time soon, you want to keep this spreadsheet (or tool) updated often. If you’re working at an agency, knowing what’s in your pipeline can also help you. Stay aligned with the person in charge of sales or assigning new projects so that you can anticipate upcoming needs and timelines. In some cases, you may even want to put some basic data in your spreadsheet or tool so that you can anticipate needs.

Good Resourcing Can Justify More Help

The value of tracking this data goes beyond your projects. It can help business owners make important decisions on growing a company.

No matter what you do, be sure to communicate about staffing as much as possible. If you’re in an organization that is constantly handling change, you’ll know that it’s a tough target to hit. In fact, your numbers will often be slightly off, but you’ll find comfort in knowing that you’re doing everything you can to stay ahead of the resource crunch. At the same time, your team will appreciate that you’re doing everything you can to protect their work-life balance.

Stakeholders Are Resources, Too

When you’re working on a team with a project, you have to consider the stakeholders as decision makers, too. Let’s face it—no one has ever been trained to be a good client, stakeholder, or project sponsor. In addition to that, they are likely to be working on several projects with several people at one time. Life as a client can be hectic! So do everything you can to help them plan their time appropriately. In general, you should let the stakeholders know they’ll have to plan for these things:

  • Meetings: You’ll conduct a kickoff meeting, weekly status updates, deliverable reviews, etc.
  • Scheduling: You’ll need stakeholders to wrangle calendars to get folks into said meetings.
  • Gathering feedback: This sounds easy, but it is not. You will need this person to spend time with all of the stakeholders to get their feedback and collate it for you to make sure there are no conflicting opinions.
  • Chasing down decisions: There are points on every project where one person will need to make sure there is agreement and decisions can be made to keep the project moving.
  • Daily ad hoc email, phone calls: Questions and requests will pop up, and you’ll need timely responses.
  • Operations: You might need invoices to be reviewed and approved or change requests to be reviewed and discussed. The stakeholders will need to make time to operate the project from their side of things.

This is a lot of work. And just like PM work, it is very hard to quantify or plan. If you’re in good hands, you’re working with someone who has good PM skills. If not, give them the list above along with a copy of this book. But seriously, if you can assist them with planning their time, it might be as simple as including action items or to-dos for them in a weekly email or in your status report. Just remember, they are busy and want the project to run smoothly as well. Help them make that happen.


Managing projects is hard enough, but being the person to manage who works on what and when can be even more difficult. However, if you don’t keep track of this basic information, you’ll likely find it hard to meet deadlines and wrap up projects without major issues. Here are some simple things you can do to make sure your that your team stays busy, yet not completely overbooked:

  • Set up a simple spreadsheet to forecast projects and hours per team member.
    • This data should be based on what’s included in your project scopes and timelines—be sure to double-check that.
    • You may want to check out one of the resourcing tools that are out there now.
  • Be sure to account for a number of factors that you can’t necessarily control in this process—for example, interests, skill sets, moving schedules, holidays, vacations, and so on.
  • Account for your sales process if you’re in an agency and stay ahead of new project requests.
  • Remember that you’re dealing with people here.
Want to read more?

This excerpt from Project Management for Humans will help you get started. Order the full copy today, as well as other excellent titles from Rosenfeld Media.

A List Apart volunteer update

Wed, 09/13/2017 - 07:08

A note from the editors: A few days ago, we announced a reimagined A List Apart, with you, our faithful readers of nearly 20 years, contributing your talents. The response from this community was humbling, thrilling, and, frankly, a bit overwhelming. If you volunteered to help A List Apart and haven’t heard back from us yet, here’s what’s up.

To the many wonderful souls who have so far volunteered to help A List Apart, thank you very, very much for your emails! And if you haven’t heard back from us yet, please excuse the delay. We’ve been inundated with messages from hundreds of potential volunteers across a wide spectrum of disciplines and potential task groups, and we are going through your messages slowly and carefully, responding personally to each one.

Some of you have written asking if we might be interested in having you write for us. Gosh, A List Apart has always welcomed articles from our community. Guidelines (plus how to submit your first draft, proposal, or outline) are available at alistapart.com/about/contribute. Please check them out—we’d love to look at any topically appropriate article you care to submit. 

But writing articles is far from the only way to support and make your mark at the new (19-year-old) ALA.

Meet the groups!

If you’ve expressed an interested in organizing or hosting an ALA-themed monthly meet-up, or have other ideas that can help grow community, we’ll invite you to join our newly forming COMMUNITY group. If EDUCATION AND OUTREACH is more your thing, we are starting a group for that, as well. There are other groups to come, as well—a list of our ideas appears in the original post on the topic, and there may be more groups to come.

How these groups will work, and what they will do, is largely going to be determined by the volunteers themselves. (That’s you folks.)

As we’re starting the work of supporting and organizing these groups on Basecamp, you can’t just add yourself to a group, as you could on, say, Slack. But that’s okay, because we want to approach this somewhat methodically, adding people a few at a time, and having little written conversations with you beforehand.

Our fear was that if we launched a bunch of Slack channels all at once, without speaking with each of you first, hundreds of people might add themselves the first day, but then nobody would have any direction as to what might be expected—and we might not have the resources ready to provide guidance and support.

By adding you to Basecamps a few at a time, and hopefully identifying leaders in each new group as it begins forming, we hope to provide a lightly structured environment where you can design your own adventures. It takes a little longer this way, but that’s by design. (A List Apart started in 1997 as a 16,000-member message board. Big open channels are great for letting everyone speak, but not necessarily the best way to organize fragile new projects.)

If you are interested in contributing to those projects, or curious about a particular area, and told us so in your initial email, we will eventually get to you and assign you to the right slot. If you haven’t yet volunteered, of course, you can still do so. (See the original post for details.)

Editors, developers, and designers

But wait, there’s more. Developers: if you have standards-oriented front-end development experience and would like to help out on day-to-day site maintenance, occasional minor upgrades, and an eventual redesign, just add yourself to A List Apart’s Github front-end repo: github.com/alistapart/AListApart.

Those with backend experience (particularly in ExpressionEngine and WordPress), you will hear from us as we work our way through your emails.

Editor-in-chief Aaron Gustafson and I have also been going slowly through your mails looking for additional editorial help. We’ve already found and added a few very promising people to our volunteer editorial staff, and will introduce them to you soon. If you’re an editor and we haven’t added you yet, not to worry! It likely means we haven’t gotten to your email yet. (So. Much. Email!)

As might be expected, a majority of those who volunteered offered their services as designers, developers, or both. The number of emails we’ve received from folks with these skills is humbling, touching, and a bit overwhelming. We have not yet begun to dig through this particular pile of mail. So if you haven’t heard from us, that’s why. (But, as I just mentioned, if you’re a developer, you can add yourself to our front-end repo. So do that, if you wish, and say hi!)

We love you

Hope this helps clarify what’s up. We are grateful for every single email we’ve gotten. We will eventually speak with you all. Thank you all again.



Patterns and Purpose, an Excerpt from Animation at Work

Tue, 09/12/2017 - 07:59

A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Rachel Nabors's new book, Animation at Work, available now from A Book Apart.

So we can use animations to tap into users’ visual systems and give them a cognitive speed boost, terrific! But before animating every element of our designs, we must learn when and how to use this new tool: with great power comes great responsibility, and so forth. And as animation must vie with many other concerns for development and design time, it makes sense to spend our resources where they’ll go the farthest.

This chapter sets you up with some core animation patterns and shows you how animation applies to a greater system. Then you’ll learn how to spot cognitive bottlenecks and low-hanging fruit, maximizing the impact of the animations you do invest in.

Common Animation Patterns

If you’ve looked at as many examples of animation on the web and in app interfaces as I have, certain patterns start to emerge. These patterns are helpful for identifying and succinctly verbalizing the purpose of an animation to others. Here are the categories I’ve found myself using the most:

Transitions take users from place to place in the information space, or transition them out of one task into another. These tend to have massive impacts on the content on the page, replacing large portions of information.

Supplements bring information on or off the page, but don’t change the user’s “location” or task. They generally add or update bits of additional content on the page.

Feedback indicates causation between two or more events, often used to connect a user’s interaction with the interface’s reaction.

Demonstrations explain how something works or expose its details by showing instead of telling.

Decorations do not convey new information and are purely aesthetic.

Let’s have a look at each of them and see how they impact the user’s experience.


The web was originally designed as a series of linked documents. Clicking on a link caused the browser to wipe the screen, often causing a telltale flash of white, before painting the next page from scratch. While this made sense in the context of linked text-based documents, it makes less sense in an era where pages share many rich design elements and belong to the same domain. Not only is it wasteful of the browser’s resources to be recreating the same page layout over and over, but it also increases users’ cognitive load when they have to reorient and reevaluate the page’s content.

Animation, specifically motion, can facilitate the user’s orientation in an information space by offloading that effort to the brain’s visual cortex. Using a transition between changes in task flow or locations in information architecture ideally reinforces where the user has been, where they are going, and where they are now in one fell swoop.

For example, on Nike’s SB Dunk page, when a user clicks a navigation arrow, the current sneaker moves out of the way while the next sneaker moves in from the opposite direction (Fig 2.1). These transitions clearly show the user how they are navigating along a linear continuum of sneakers, helping them keep track of their place and reinforcing the spatial model of perusing a real-world row of sneakers.

Fig 2.1: On this Nike page, transitions are used to navigate forwards and backwards along a linear continuum of sneakers. (Watch the accompanying video.)

On another shoes site, fluevog.com, transitions move the user from task to task (Fig 2.2). After a user starts typing in the search field, the results are animated on top of a darker backdrop. This transitions the user from the browsing context to refining their search results, streamlining their focus while also reassuring them that they can get back to browsing without much effort.

Fig 2.2: On Fluevog’s website, transitions move users from the browsing context to the searching context. (Watch the accompanying video.) Supplements

While transitions move the user from state to state, supplemental animations bring ancillary information to the user. Think of times when information complementary to the main content of the page appears or disappears in view: alerts, dropdowns, and tooltips are all good candidates for a supplemental animation on entry and exit.

Remember that these animations need to respect the user’s Cone of Vision: will they be looking directly at a tooltip appearing next to their cursor, or will their attention need to be directed to an alert on the side of their tablet?

When a user adds a product to their shopping cart on glossier.com, rather than taking them to a whole new shopping cart page, the site merely updates the user as to their cart’s contents by popping it out as a sidebar (Fig 2.3c). While a transition would snap the user out of browsing mode, this supplemental animation lets the user dismiss the shopping cart and continue shopping.

The shopping cart sidebar uses an additional supplemental animation to quickly and subtly attract the user’s eye: a progress meter gradually fills to show how much the user needs to spend to get free shipping (Fig 2.3d).

Fig 2.3: Glossier.com uses supplemental animation to show and hide the user’s shopping cart, keeping them in the shopping context longer without forcing them into the purchasing context. (Watch the accompanying video.)

This shopping cart process has a third animation pattern going on: the Add to Bag button gains a spinning icon when clicked, which gives the user feedback as to its loading state (Fig 2.3b). Speaking of feedback…


Animation can give users direct feedback about their interactions. A depressed button, a swiping gesture—both link a human action to an interface’s reaction. Or the flip side: a loading spinner on a page indicates that we’re waiting on the computer. Without visual feedback, people are left wondering if they actually clicked that “pay now” button, or if the page is really loading after all.

On the Monterey Bay Aquarium’s site, hovering over a button causes its color to fade from red to blue, indicating that the element is interactive and ready to react to user input (Fig 2.4). Button hovers are classic examples for this kind of animation, partly because the gain of giving users visual feedback on buttons is so measurable and important to business.

Fig 2.4: On the Monterey Bay Aquarium’s site, hovering on a button triggers an animation that gives the user feedback that the element is interactive. (Watch the accompanying video.)

Design studio Animal’s site uses a bar of color across the top of the page as well as an animated version of their logo to indicate the page’s loading and loaded states while providing interest and reinforcing their “wild” branding (Fig 2.5).

Fig 2.5: Design studio Animal uses a progress to let users know how much of the page has loaded, and an animated logo to indicate when it’s fully loaded. (Watch the accompanying video.) Demonstrations

Demonstrations are my personal favorite use of animation. They can be both entertaining and insightful. These animations put information into perspective, show what’s happening, or how something works. This makes demonstrative animations perfect partners for infographics. One thing all demonstrative animations do is tell a story, as you’ll see.

“Processing…” pages are an opportunity to explain what’s happening to users while they wait. TurboTax makes good use of these processing pages (Fig 2.6). After users submit their US tax forms, it banishes any remaining anxiety by showing them where their information is headed and what they can expect—all while reinforcing their brand’s friendliness and accessibility. (It also helps that the animation distracts users from a rather lengthy page load with something visually engaging!)

Fig 2.6: TurboTax both informs their users and masks long page loads by demonstrating what’s going on after the user submits their US tax forms. (Watch the accompanying video.)

Coin famously uses demonstrative animations to explain their consolidation card’s value proposition to curious visitors as they scroll through the site (Fig 2.7)—no need to press play and sit through a video ad or wade through paragraphs of expository content. This page is the very essence of “show, don’t tell.”

Fig 2.7: As visitors scroll through Coin’s site, the company’s value proposition plays out in front of them. (Watch the accompanying video.) Decorations

It’s not hard to mistake decorative animations for demonstrative animations. But there is a key difference: where demonstrations bring new information into the system, decorative animations do not. They are the fats and sugars of the animation food pyramid: they make great flavor enhancers, but moderation is key.

The best way to spot a purely decorative animation is to ask, “What can a user learn from this animation? Does this guide them or show them something they wouldn’t know otherwise?” If the answer is no, you might have a decorative animation on your hands.

Even though they get a bad rap, decorative animations can help turn the ordinary into the extraordinary. Revisionist History’s site uses decorative animations judiciously to bring flat illustrations to life. The animations add just enough interest to allow for the visual content on the page to be more austere, letting users focus on the podcast (Fig 2.8).

Fig 2.8: Revisionist History’s site uses decorative animations to add visual interest to non-visual media. (Watch the accompanying video.)

Polygon.com epically used animated illustrations to create centerpieces for a series of console reviews. These decorative animations may not have added new information, but they crucially reinforced the Polygon brand. They also helped each console review stand out from the competition, which at the time sported indistinguishable photographs of the same devices.

Fig 2.9: Polygon uses decorative animations as a showstopping feature to stand out from the competition. (Watch the accompanying video.) Want to read more?

This excerpt from Animation at Work will help you get started. Order the full copy today, as well as other excellent titles from A Book Apart.

New A List Apart wants you!

Thu, 09/07/2017 - 08:00

As A List Apart approaches its 20th anniversary—a milestone in independent, web-based publishing—we’re once again reimagining the magazine. We want your feedback. And most of all, we want you.

We’re getting rid of advertisers and digging back to our roots: community-based, community-built, and determinedly non-commercial. If you want to highlight local events or innovations, expand your skills, give back, or explore any other goal or idea, we’re here to support you with networking and backing from the community.

In recent years, we’ve seen our rich universe of diverse, creative blogs and sites implode—leaving fewer and fewer channels available to new voices. As more content centralizes into a handful of all-powerful networks, there’s a dreary sameness in perspective and presentation.

This creeping monopolization is a sad echo of how media worked in the 20th century. It doesn’t reflect 21st century diversity and empowerment. It’s not the web’s promise. It’s not how it’s supposed to be.

We have no beef with networks like Twitter or Facebook, or with companies like Apple and Google that currently dominate our communal digital space. We just think diversity is about expanding and speaking up—not consolidating and homogenizing.

Define the next decade with us

A List Apart has always been more than a publisher; we’re an ecosystem of practitioners who are passionate about our craft. We’ll keep finding and sharing great articles—we’re just taking it to the next level.

Two ways to pitch in

If you want to put your favorite skills to use, expand your professional experience, or have a goal or idea for A List Apart, we’re here to listen. And if you’d like to support us in some other way, we’ve made that easy, too. Currently there are two ways to pitch in:


Use the email address at the bottom of this message to let us know if you want to create or join a team that “owns” some area you’re interested in, such as:

  • Design & development
  • Community service and local meetups/events
  • Education and entry level/advanced resources
  • Book/resource coverage and reviews
  • Editorial: Editing, acquisitions, and email
  • Social media, SEO, or marketing
  • Project management
  • Your suggestions!

If you don’t have time to volunteer but still want to support us, you’ll be able to offer other forms of help—for instance, making a small, monthly donation via Patreon to help cover our expenses. This will also grant you membership benefits. (Details at Patreon.)

Sharing is caring

More about all of this will soon be revealed. Meantime, if you have feedback or questions about what we’ve shared so far, kindly fire away in the comments. (Hey, how’s that for an idea? A comments section that’s positive and not divisive.)

As we imagine the next 20 years of web design, there’s a lot we don’t know—other than a strong hunch that accessible, semantic HTML will continue to be the bedrock of it all. But one thing we do know: the web, in its reach and its potential, is too important to be left to the mercies of a few powerful companies, however well-intended they may be.

If you’ve a mind to do so, please help us keep our little corner of the indie web alive and well. Help the open web stay open. Help us build the future. To get involved, email us at contact@alistapart.com—or share your thoughts in the Comments section below.

The independent content producer refuses to die!


Jeffrey Zeldman, Publisher
Aaron Gustafson, Editor-in-chief
& the gang



Conducting the Technical Interview

Tue, 09/05/2017 - 11:41

I vividly remember my first interview as a manager. My hands were shaking as I led the candidate up the stairs to the conference room I had booked. When we got there, I went into a panic. What if I don’t ask a vital question? How do I even know what the vital questions are? What if I hire him and he’s completely unprofessional? How can I tell if he really knows JavaScript? Wait a second—does he have a prosthetic leg? Did I just take a candidate with a prosthetic leg up the stairs? Oh no, I’m failing this interview already!

Even if you’re familiar with the basics of interviewing, technical interviews can be nerve-wracking. Whether you’re a new team lead or you’ve been in leadership for years, concerns and insecurities like the ones I had in my first interview can haunt you, and even well-established interview processes can fail to adequately screen candidates.

Interviewing for technical positions is, in many ways, a balancing act. You look at past, present, and future; you look at soft skills and hard skills; you have to think as both a buyer and a seller; you even have to worry about company image and reputation management. There are some basic things you can do to keep that balance and best represent your company.

Define the ideal role

I’ll admit, for my first round of interviews, all I was looking for was someone who could tick off all the technical skills on a checklist. As I progressed in my management career, I started to learn that I never looked for the same person twice—each time I had an opening, the team had different needs, and I had to take those into account when hiring someone. Even though the job description for a front-end developer didn’t change much each time, my expectations for the ideal candidate did. That gap between the job description and the ideal role tripped me up for a long time.

Before you start interviewing, you’ll need a solid written description of what you’re looking for in an ideal candidate, beyond what job postings typically go into. The job posting may say Senior Front End Developer, but if you need someone to be your CSS animation specialist and help define standards and best practices—whether now or in eight months—you’ll need to take that into account when hiring.

Be future-oriented with your description: ask yourself what happens when the employee outgrows his or her role. Could this person be a supervisor, or would they even want to be? Is there an opportunity to be a technical leader or architect at your company, if that’s the route this person chooses? Could this person one day replace you? (Remember, you’re probably not getting promoted until there’s someone to take your place.) If you have no answer to the question of what happens when an employee outgrows the role, the answer is usually found at another company.

Also ask what happens if the team continues to grow. Does this person have the aptitude to pick up new skills and responsibilities as needed? How will this person respond to change? What if you have to put this person in front of a client? At a healthy company, growth is inevitable, both in size and scope. Your definition should describe someone who can grow with you and not get left behind.

Define not only the technical skills, but also the soft skills needed for the role you have in mind. If you need someone to take the lead on collaborating with the Creative team, you’ll need to define what would make an employee successful in that role and hire for that. This can actually be more important than the technical skill requirements. Technical skills can be easily trained—soft skills cannot.

When you do all of this, you’ll have a list of expectations for a role that probably won’t fit in a job posting. When appropriate (don’t make promises of growth), test those waters with the people you’re interviewing. Even if you determine a person would be good as a trainer, they may not want to do that, which can be a nasty surprise if you hired the person with the intent of them growing into the role a year down the road.

Once you know what you’re looking for, the next step is getting them to want to work for you.

Sell the job

The saddest interviews for me are the ones where I find that ideal candidate I envisioned and they get away. Sometimes, they just get a higher salary somewhere else; but sometimes, they decide that they don’t like the company and want to keep looking. Both are sad, but either way, getting candidates to like your company is always in your best interest.

Remember, when you’re interviewing someone, they’re also interviewing you. Don’t ever assume that your company is the only place a candidate is interviewing. It’s true that some people walk in the door with their minds made up, but many are still deciding whether they want to work for your company—and the better the candidate, the more options they’re going to have, so the more you’re going to have to sell to win them over.

So how do you sell a job? A salesman will tell you it starts with knowing three things really well: the product, the competition, and the customer. The product is your company: benefits, compensation, culture, type of work, amount of work, and even location. The competition is any local business that hires similar types of people, and you’ll need to know the same things about them that you do about your own company. The customer is the job applicant. Knowing each of these things well and being able to compare them is key to winning the best candidates.

Do your research not only into your own company, but your local competitors. What are your competitive advantages? What are theirs? (If you think a ping pong table is a competitive advantage, you’ll probably need to dig a little deeper.) Sometimes it’s not about what you have so much as what the competition doesn’t. If you’re seeing a lot of interviewees from a competitor, find out why and see if you can use that factor to sell your company.

Learn what prospective employees are looking for in a job. There will likely be some commonalities. If you’re losing top talent because you don’t offer a benefit or they don’t like your processes, you’d be wise to revisit those. Just like the technology in our industry is constantly changing, the expectations and needs of our employees are also changing. Don’t fall behind with what you offer to your employees.

Almost every candidate will have questions about what the work environment is like. You should have a little elevator speech to sum up your answer and sell your company in a minute or less. You may actually want to lead the interview with that speech to get those questions out of the way and get the candidate excited for the position before you start finding out about them.

Lastly, be authentic with your interviewees. Don’t try to spin a weakness as a strength, because most people will see right through that. If you don’t believe in your company enough to be totally honest about it, why should they believe in it enough to work for you? You don’t need to hand them a comprehensive list of everything that’s wrong with your company, but don’t shy away from questions along those lines, and don’t try to reframe a shortcoming as a strength. As an example, if your company has a reputation for burning some people out, that’s important, but you can talk about the type of people who do well there rather than the people who don’t. It’s better that people find that out in the interview than after three months of training.

Hire a person, not a code machine

In my five years as a supervisor, I only had to fire two people. Want to guess how many of those were because they lacked technical skills? Zero. In both cases, the employees didn’t work out for non-technical reasons.

There are a number of non-technical factors to look for in a candidate: personality, fit with the team, communication skills, openness to change, leadership potential, and a host of others. (That’s the real reason you’re conducting an interview and not just asking for test results.) These details don’t magically reveal themselves in the technical portion of the interview—you need to ask about them.

Create a list of standard questions for candidates. Questions should be open-ended and answered with a story. Examples include:

  • Tell us about a time when your good communication helped to solve a problem.
  • Tell us about a time when you disagreed with your supervisor and what you did about it.
  • Tell us about a time you successfully described a technical concept to a non-technical person.
  • How would you explain inheritance to a junior developer?
  • Tell us about a recent time you learned from a mistake.

Order is important: ask the non-technical questions first. The technical portion of the interview can make some people nervous, and you won’t get a good gauge of who the candidate is if their thoughts are fixated on the technical questions they missed.

Putting thought into screening for soft skills is vital. But remember that this is a technical interview—you have to put just as much thought into screening for technical talent.

Stick to the standards

And I’m not talking about web standards. If you’re not asking all developers the same questions, there’s a good chance you won’t get a fair comparison, which means a greater likelihood that you’ll fall back on biases like similarity or likeability.

Develop a standard set of technical questions, and a written test. The questions should allow for some discussion, but have a clearly-defined right answer. Examples of these questions are everywhere. You’ll probably want to customize your list so that people can’t just look up the answers online before the interview, but lists like those will get you most of the way there.

(And don’t feel like you need to come up with this list on your own. If you have technical experts at your disposal, utilize them. You’ll probably want one in the interview, too.)

The written test can make or break an interview. It should not be easy, nor should it be mandatory to get every question right. When an applicant is writing out code by hand from memory, leniencies must be given for syntax—give points for partial answers and ideas. Remember what Stephen Wolfram, creator of the Wolfram Alpha answer engine, said on the subject: “One thing I’ve noticed is that in almost every area, the people who go furthest are not the ones with the best technical skills, but the ones who have the best strategy for figuring out what to do.” You’re trying to get a feel for the candidate’s problem-solving strategy, not their ability to memorize every minutia of coding syntax.

There should be at least a few “fix this code” sections to see how sharp their debugging skills are. Again, you shouldn’t focus on trick questions or ridiculously obscure syntax problems—you just want to measure the candidate’s ability to think through and solve a technical problem.

Questions should be relevant to what the job entails—if they’ll be expected to create custom CSS animations, make sure to ask about that—but they should avoid niche- or process-specific knowledge unless it’s vital to the position. Rule of thumb: if your company does something differently than the rest of the industry, don’t quiz them on it.

Once you have the questions and test prepared, run the questions by some of your existing team members to see how they fare. If your entry-level developers get all of the questions right—probably a bad sign; if your senior developers all bomb the test—also a bad sign.

In the questions, there should be some clear delineation between roles. What are the must-answer questions for mid-level developers? For seniors? There can be some flexibility here, but you should have a pretty good idea what a senior test looks like and what a mid-level test looks like.

If a candidate aces your standard interview questions, you can hire them with confidence. But when the technical portion of the interview doesn’t go well, you need to know how to handle that too.

Know when to move on

The most awkward interview I ever conducted was with a PHP developer who freelanced and was looking for his first agency job. When we began the technical questions, I quickly realized he didn’t know as much as he thought he did. Of the 22 technical questions, he got about 2 correct. He got more and more distressed with every tough question—especially when I corrected his wrong answers—and by the end of the technical portion, he looked like he’d been punched in the stomach.

That guy was not qualified for the job, and both of us knew it from question 3. This was pretty early on in my management career, so I just plowed through the entire list of questions, knowing he would fail them. Learn from my mistake: don’t do that.

Let interviewees fail gracefully. Don’t interrupt them with the right answer to the question they’re struggling with, and don’t correct them if they get the answer partially right. If they get the question wrong, just move on without showing judgment. If they really can’t get a question, just tell them you’re moving on.

If a person bombs the verbal questions, don’t make them sit through the written test (which will probably be much harder). Feel free to tell them right then and there that they’re not a good fit for your particular position and wish them well in their quest for work. If you think they could be a good fit for another position in your company, or if you’d like to see them back once they get a better grasp on the fundamentals, go ahead and let them know. But there’s no point in leading them on with a vague non-answer if the answer is definitely no.


Screening for technical talent can be tricky. Having a holistic view of both the role and the candidate is key to making the right hiring decision. Remember to take careful notes, even if you don’t think you’ll need them. And good luck!

Yes, That Web Project Should Be a PWA

Wed, 08/30/2017 - 12:30

It seems like ever since Frances Berriman  coined the term “Progressive Web App” in an effort to describe a new class of website, there’s been a great deal of confusion over exactly what a Progressive Web App (PWA) is. Sure, her husband, Alex Russell, put together a handy guide to the characteristics of a PWA, and they have been the subject of reams of documentation, dozens of blog posts, and equally as many conference talks.

Even with so much well-written, accessible content about PWAs freely available, misinformation abounds. Maybe you’ve run into one or more of these:

  • If you’re building a PWA, you need to use a JavaScript framework.
  • To build a PWA, start with a single page app.
  • PWAs only make sense for “apps” your users want to install.
  • PWAs only make sense in mobile.
  • PWAs are an Android thing.

None of these are true, but like so much misinformation these days, each contains a shred of truth that has been contorted into a falsehood. If you’re considering building a PWA, you might use a JavaScript framework or build it as a single page app, but it’s by no means necessary. They’re an option for building a PWA just like they’re an option for any other web project. After all, every PWA is (or at least should be) a website. PWAs just have some features that empower them to do more than websites have traditionally been able to… like install. But, similarly, installation is not the raison d’être of every PWA. And, while many of the first PWAs were focused on mobile and only worked on Android, PWAs are not limited to small screen devices anymore. They’re also more than a Google thing too; Microsoft, Mozilla, Opera, and Samsung are all on board. Apple has yet to declare their intent with regard to Service Workers (one of the technical underpinnings of PWAs), but Progressive Web Apps work really well in Safari anyway!

Sadly, misinformation like this has convinced many designers and developers (and their management teams) that PWAs aren’t appropriate for their projects. They are! Your site—every site—should be a PWA. This approach offers benefits for every project on the web, but I’ll get to that in a minute. Before I do, I want to level-set on what, exactly, makes a PWA a PWA. If you’ve been tracking PWAs closely or have already built one, you can skim or skip the next section. If you aren’t all that familiar or don’t feel like you have a good grasp on what they are, no worries, the next section is a very brief primer that will get you up to speed quickly.

So what is a PWA?

As I mentioned, a PWA is a website with special powers. The term “app” in the “Progressive Web App” is not indicative of the sort of content or experience users should expect with a PWA. You shouldn’t get hung up on it; “Progressive Web App” is a marketing term. PWAs have the ability to connect with the operating system (and, thereby, its users) on a deeper level through installation and APIs offering capabilities like notifications, access to the address book, and more. Not all of these APIs require installation for access, but some do. It may help to think about a PWA as being a website++.

What makes a PWA a PWA? Not much, actually; there are only three requirements:

  1. You need to be running under HTTPS. PWAs can be granted a whole host of extra privileges in an operating system, so it’s critical that the connection to your web server be secure. If you need help with this, you should check out the free SSL service Let’s Encrypt.
  2. You need a Web App Manifest. This is a lot less scary than it sounds. It’s a JSON file with information about your site. You may even have a bare-bones one already if you’ve used a favicon generator. Make sure you reference it using a link in the head of your web pages so browsers and search spiders can find it.
  3. You need a Service Worker. This is probably the most complicated step, but there are a ton of recipe guides out there for creating Service Workers tailored to the kind of jobs you want them to do. This one, from Mozilla, is especially good.

That’s it. Once you have those in place, your website is a Progressive Web App. At least technically. Why the qualification? Well, this is where things get a little more nuanced.

Back in 2015, when he debuted the PWA concept, Alex Russell outlined ten characteristics PWAs shared (or at least were capable of). Most of those characteristics are, without a doubt, how we should be building for the web. Others are not as universal and would not make sense in every kind of project. I suspect that might be one of the sources of confusion for folks considering adopting the PWA approach and it’s the reason I decided to write this article.

Quality experiences and the universal benefits of PWAs

In the next few sections, I will discuss several web project archetypes and how adopting some of these PWA characteristics can benefit their users. After all, that’s who we’re doing this for. But before I get to that, I want to discuss the seven characteristics of PWAs that are useful in any web project.

As I mentioned, there are some characteristics of PWAs that will absolutely provide value to your users and are well worth your time and consideration. In fact, all of them are considered best practices in web design and development.

First off, PWAs must be safe. As I mentioned in my discussion of their technical requirements, PWAs must be running under HTTPS. Period. Thankfully, the cost of running your site under HTTPS has dropped to zero. Sure, there are legitimate challenges to converting large existing websites over, but it’s worth it for so many reasons. The primary one is that it protects your users from malicious man-in-the-middle attacks being made by ISPs, in hotels and airports, infected routers, or others with network access. HTTPS ensures that both the code and content you send to your users actually arrives intact. It’s not fool-proof, but it’s an important step in protecting your users and your data. Running HTTPS is also a prerequisite for access to many of the newer (and more sensitive) APIs including Geolocation and Service Workers and for performance-boosting technologies like HTTP/2 and Brotli compression. It’s also worth noting that many browsers are beginning to mark non-HTTPS sites “unsafe” and SSL also affects search ranking.

I mentioned earlier that PWAs were never intended to be a mobile-only approach. PWAs are for everyone. Making your project available to more people on more devices with wildly varying operating systems, browser capabilities, system APIs, and screen sizes is only going to increase your reach and create more opportunities to be successful. This is where progressive enhancement and responsive design come in. By building responsive layouts, your designs will adapt to provide the most appropriate layout given the screen real estate you have to work with, whether dependent on the dimensions of the device or on the window size set by your user. Progressive enhancement enables your projects to adapt to an even wider array of variance, in both the execution environment (device, OS, etc.) and, more importantly, your users.

Progressive enhancement also helps you avoid situations where users can’t access your project because they happen to use a device or browser you’re unfamiliar with or haven’t tested on. It ensures your site works on any device that can access the web, regardless of its capabilities, allowing you to use your valuable time optimizing that experience for more modern browsers and devices. It’s also a more economical approach in the long-run.

Another quality Alex identified was that many PWAs are “app-like”. Note the like. They are not apps, but rather, provide app-like experiences that users that—dare I say it?—enjoy using. The more you can do to provide a consistent, seamless, effortless user experience (which is really what “app-like” is implying here), the more likely you are to see repeat visits, increased sales, etc.. It’s worth noting that this doesn’t mean you have to use JavaScript; it simply means you should think about the flow your users take through your site and take every opportunity to remove the friction from the process of them accomplishing their goals.

If you’ve built something, you probably want folks to find it. PWAs, by definition, are easy to discover. Your site’s content should be written in such a way that it pops up organically when people search for related topics. Don’t get all spammy, but take care to author content in a thoughtful, appropriate, and straightforward way.

Related to discoverability is that PWAs are linkable. If your users can reach a certain point in your site via natural navigation, you should do your best to ensure they can save their place by bookmarking it or when they re-launch their web browser and your site’s tab is re-launched. This also plays into how shareable your project is. You may also want to do yourself a favor and spend some time putting together some Open Graph meta tags and some JSON-LD to make your content even more shareable.

Last, but certainly not least, there’s network independence. This is the big one that gets developers so excited. Offline capabilities and persistent storage has, to some extent, been possible for a while now; heck, Microsoft debuted client-side data storage back in 1999! Alas, while client side data stores—IndexedDB, localStorage, etc.—have definitely come of age in the last few years, true control over resource caching has been pretty abysmal. Then came Service Workers and the Cache API. These two technologies work in concert with the Fetch API to make, intercept, augment, and store resource requests made from within your site, meaning your users may still access your content, even if their network connection is interrupted.

There are a ton of fantastic resources covering the ins and outs of Service Workers, so I’m going to skip the technical stuff and just talk about some of the neat things you can do with them:

  • Prefetch and cache resources you know your users are going to need. This can improve performance dramatically.
  • Cache every page and asset requested by your site so they don’t need to be retrieved from the server each time a new page is loaded. This improves performance on navigation as well as on return visits.
  • Define a custom “offline” page. This prevents users from seeing the browser’s generic “You’re not connected” message.
  • Look for a network connection first and provide the “live” copy of a given resource if it’s available, falling back to a previously cached “stale” version if it’s not. This can also prevent users from seeing “You’re not connected” messages.
  • Respond to requests for JPEG images with WebP (which tend to be considerably smaller) versions of those images if the browser supports them. This strategy allows you to provide alternate image sources that improve performance without having to modify your markup.

Service Workers are capable of a whole lot more—some of which I will get into shortly—and are on track to be granted many more incredibly useful features in the not too distant future. They have already proven their worth and bring value to any project on the web. For a useful list of recipes, check out this cookbook from Mozilla or this one from the Chrome team.

Other PWA benefits by project type

Now that we’ve looked at the universally-beneficial qualities of PWAs, let’s shift gears. Every project is different, but there are a handful of archetypes that most web projects tend to fall into. And each of those archetypes can derive real benefits from running as a PWA.


When I think about informational sites, I’m talking about the kinds of sites many of us in the industry refer to as “brochureware.” Vanity sites are a good example of this. Small business sites whose interactivity tops out at a contact for or a phone number link are another. Portfolios would also fall into this category as would many restaurant sites.

In most cases, projects like these are there to serve folks wanting to know more about you, your business, a project, or something similar. In most cases, you’re not going to see a ton of repeat visits. Folks come to the site looking to find out a specific piece of information—which hopefully they can access quickly and easily—and they’re off again. They might return, but they might not, meaning the performance gains provided by a Service Worker’s offline caching could be useful, but likely won’t have quite the level of impact it would have on a site that gets frequent repeat visits. It’s also highly unlikely—though not impossible—that someone will actually install a project like this.

Depending on the type of site you’re building, you might consider integrating some device APIs. If the site is for a brick-and-mortar business, add Geolocation support. If you have sales or specials you’d like to inform your visitors about, you might consider integrating Notifications (either Web or Push).

Even though two of the oft-touted “major” benefits of being a PWA—install-ability and offline capability—are less applicable for informational sites, making projects like these a PWA is still beneficial. Those are just two aspects of being a PWA. Your users will thank you for building a site that works on every one of their devices, is easy to use, comes up in search, and is easily shared with their friends.


Periodical sites encompass everything from a blog or newsletter or podcast to online comics, magazines, newspapers, and video programs. These sorts of projects are like informational projects, but are updated regularly (or semi-regularly). They also have an audience that is likely to return (ahem) periodically to read a new article, watch a new video, or listen to a new podcast episode. Since they share much of their DNA with informational sites—heck, a periodical may even be part of an informational site—all of the qualities that benefit informational sites benefit periodicals as well. There are, however, some capabilities that PWAs offer that periodicals are perfectly suited to take advantage of.

In discussing promotions or specials, I mentioned that Push Notifications could be an option for informational sites. They should be a given for a periodical site. Push Notifications provide a mechanism for your server to send an update to any instances of your Service Worker that are installed on your users’ machines. And, assuming they’ve granted you permission, those updates can be displayed to your users even if they don’t have your PWA installed or a browser tab open to your site.

Don’t take this as an opportunity to spam your users, as you’ll likely lose their eyeballs and business. Instead, choose appropriate times to ping them. If your site only gets updates once or twice a week, notifying them of individual posts is probably good and can provide a nice alternative for folks who don’t use a feed reader. If you have frequent updates, consider a daily or weekly roll-up. This might even be a good candidate for some A-B testing.

You could also up your game by offering an easy in-page tool for saving an article for offline reading. Why would you want to do that rather than caching everything the user ever sees using the Service Worker? Well, given the nature of a periodical, the reuse of individual content items is likely pretty low. If you cache everything the use ever sees—especially if your content contains a lot of high resolution images—you’re gonna be filling their cache up with stuff they may never want to see again. In order to be a good web citizen, you could either clean that up regularly by keeping track of the last time a resource was accessed (which, frankly, seems like a lot of work) or you could cache just the necessary long-lived resources like your CSS and JavaScript files. Then you can put your users in control by providing a button that enables them to save an entry for later.

Continuing our journey through Service Worker land, you could start exploring Background Sync to pull in new resources periodically. If you’re a newspaper, maybe you want to prime your users’ caches every morning with the front page and the top feature stories. If you’re a podcast, maybe you want to load in the newest episode on a regular cadence. Again, to play nicely in the sandbox, you’ll probably want to trash older articles, episodes, and so on, but this could be a great way to provide an incredibly fast experience for your users. Think about it… they launch your site and the browser already has everything it needs to render today’s issue. Magic!

Finally, periodicals are one of those archetypes where the option to install your site begins to make sense. Some people like being able to hit an icon on their home screen or in the Start Menu to access their local newspaper. It’s not for everyone and may not be right for every periodical, but it’s an option. And offering your users the ability to install your PWA comes for free, so you may as well embrace it and make sure your Web App Manifest has been thoughtfully authored to provide a good user experience when your PWA is installed.


Any site that facilitates the exchange of information could be considered transactional. The most common examples include online shops, banking and stock trading tools, travel booking systems, and payment portals. PWAs have, to a large extent, already proven their value in this area. A quick peek on PWA Stats revealed the following “wins”:

  • The Raphael Hotels increased website conversions by 20%, pageviews by 66%, sessions by 59%, and reduced bounce rate 51%.
  • MakeMyTrip saw a 3× increase in conversion and 160% increase in shopper sessions and first-time shoppers are 3× more likely to convert on the PWA than in native app.
  • Lancôme saw a 17% increase in conversions, a 51% increase in mobile sessions overall and a 53% increase on iOS alone.

The kicker on that last one? iOS doesn’t even support Service Workers!

It’s well-known that improving page performance increases conversions, so the speed improvements granted by a smart caching and offline strategy with Service Workers are incredibly important here. But there are numerous other ways PWAs can benefit transactional sites as well.

Since I mentioned offline, I’ll add that your offline strategy should not begin and end with Service Workers. For a while now, we’ve used cookies to track transactional data shopping cart contents, but cookies have always been severely limited in terms of the amount of data they can store because they get sent along with every network request. With IndexedDB, localStorage, and sessionStorage, we have the ability to store more (and richer) data about the transaction taking place on the client side. Storing this information on the client makes it easier to recover from problems like a network loss. If a transaction fails, you will still have access to the data (which might have otherwise been lost in a failed POST) and you can either periodically try the transaction again or wait until you see the network is back before submitting it. Either way, adding real-time messaging about what’s going on and how you are working to resolve it will go a long way toward assuring your users that their data is not lost.

If your project is highly transactional, you will definitely want to look at Background Sync as a means of keeping your users’ local data in sync with server data. For example, if you are building a banking system, synchronizing information like recent transactions and current balances will be incredibly useful to your customers. Same goes with current stock prices and balances if you’re working on a trading platform.

In most transactional scenarios, notifications can be quite helpful. Borrowing on the scenario I mentioned earlier, notifications can be used to let someone know when their transaction has completed (after all, in a PWA you could complete the transaction during a Background Sync when your site isn’t running). Notifications come in a two flavors: Web Notifications are triggered via JavaScript in an active page, Push Notifications are sent from the server and can be delivered even when the site isn’t open. Depending on the scenario, one or the other will probably make more sense. Just be aware that Push Notifications are not as well supported as Web Notifications… yet.

For transactional sites that are frequently accessed (and I realize “frequently” is a very relative term) the install-ability of a PWA is a huge win. Isolating your site within its own app container allows users to focus on the task at hand, without the distraction of other tabs. It also insulates the processes running your code from the process running all of the sites they have open in their browser. Additionally, it has less overhead since there’s no browser chrome running alongside it. All of these benefits work together to create a streamlined, frictionless experience for your users.

Once installed, many operating systems will grant your project access to internal APIs. Perhaps you want to let them choose an address to ship a gift to, from their contacts. Or maybe you want to enable them to add the flights they just booked directly to their calendar. Or perhaps you want to voice-enable your app by integrating with their virtual assistant. All of those scenarios become possible in the context of a PWA, which is a huge boon for transactional websites.


Social websites—think Twitter, Facebook, etc.—are excellent candidates for PWA-ification. In fact, Twitter has already gone that route. Social sites combine aspects of periodical and transactional websites, so they naturally inherit many of the benefits of those archetypes. Push Notifications, in particular, are incredibly important for sites like this, as re-engagement is crucial for the long-term success of your platform. Install-ability is also important in that regard.

Performance, especially initialization speed, is going to be an important benchmark for social projects, as users will not sit around waiting for all of their feed items (and their associated imagery, videos, etc.) to load. Caching your site’s assets will help a bit, but—depending on your project goals and situation—you might consider using Background Sync to update your users’ news feeds so they are ready to go (or close to it) the next time they open it up.

As transactional projects, social websites will also benefit from access to device and system APIs when installed. Most social networks, for example, request permission to peruse your Contacts to look for friends and colleagues that are also using the service. If you go that route, it’s imperative that you don’t abuse the privilege by trying to trick your users into spamming their friends with info about your service. If we don’t respect our users and their private information, we run the risk of losing access to it (and them) altogether.


When we talk about “web apps,” often online software is what naturally comes to mind. Some examples include email clients, accounting tools, project management suites, version control systems, and photo editors. In many ways, these are software in the traditional sense, they just exist on the web instead of being installed locally… until now.

Through the magic of PWAs, these software-as-a-service projects can become full-fledged desktop (and mobile) applications. This enables teams that have gone all-in on web technologies to continue (or even increase) their investment in that area without sacrificing the convenience of install-ability on native platforms. Sure, there are absolutely some solid reasons why you might want to customize a native experience for your software, but for the vast majority of cases the web offers everything necessary to run your application… that’s why its on the web in the first place.

Offline data stores, background synchronization, and file system access help to elevate the experience for your users, making this archetype the most obvious beneficiary from Progressive Web Apps.


Some projects are, frankly, too sprawling to fall neatly into one archetype or another. I’m thinking of schools, large corporations, mammoth financial institutions. These projects are often an amalgam of many or all of the archetypes I’ve covered here. As such, all of the benefits accrued to those archetypes apply, in context of course.

When looking at a large institutional project, it can be difficult to figure out how to assemble an overarching strategy for turning it into a PWA. The good news is that you don’t necessarily have to. You can carve up your project into many individual PWAs that can exist independently.

Take, for example, an online learning system. You could create a PWA for the learning system itself, but you could also carve off each individual course as its own, installable PWA, with its own cache, notifications, etc. The reason you can do this is that Service Workers and Web App Manifests can be scoped. You can scope them to a specific hostname or you could even scope them to a specific path within your URL structure. While obviously more complicated, if you think of each of those courses as having a course template and you think of a Web App Manifest and Service Worker being part of that template, it becomes easier to wrap your head around.

It’s your turn

Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives. If you hadn’t considered building a PWA before, I hope this article has changed your mind. And if you’re already neck-deep in Service Workers, perhaps it’s given you some ideas for new ways to approach the projects you’re working on.

User Interfaces for Variable Fonts

Fri, 08/25/2017 - 08:00

The tools we design with have a unique effect on the way we work, constraining and empowering us while we explore, examine and create. Variable fonts give us a new, wide open typographic space with which to work. Instead of prescribing value to individual UI elements in a vacuum, we should take a hybrid and calculated approach to variable font interfaces. How do we structure our design tools to adapt to the new advantages variable fonts provide us with?

Despite being ahead of their time, variable font precursors—Multiple Master and GX—didn’t see widespread adoption for several reasons—one key reason being the lack of effective user interfaces that could communicate their creative utility to designers.

Since their introduction, variable fonts have moved forward quickly, landing with various degrees of experimental support across major browsers. With this comes the exciting ability for fonts to responsively adapt to different layouts and context. While responsive design has become more standard, effective variable font user interfaces have yet to be adopted.

A number of approaches can make variable fonts (which can house effectively any number of variations) easier to understand and use. Through design exploration and looking at prexisting examples we can see how each UI element has different benefits and drawbacks. We find that few patterns should be applied to every case.

Enabling Variable Fonts

Within our design tools, variable fonts present a unique challenge, allowing users to select and change different properties of the typeface that are exposed by the typeface designer. These changes occur along an interpolation axis—or a line that reflects variation values of a font:

Previewing Dunbar, a variable font with two axes by CJ Dunn within Fontview. AxisPraxis and Typeshift (my own design tool) are some other great places to check out variable fonts!

A variable font can have any number of axes, but these can generally be reduced down to a few commonly used axes mostly likely to be used for Responsive Design. These default axes are called registered axes in the spec. Each one has a different set of use cases:

  • Font Weight – (wght): For adapting font weight to the container size, the weight of other elements, changes to hierarchy and screen resolution
  • Font Width – (wdth): For fitting the width of the typeface to the width of a container
  • Font Italicization – (ital): For changing how italicised the type is
  • Font Slant – (slnt): For changing how oblique the type is
  • Font Optical size – (opsz): For adapting to container size, font size and adjusting hierarchy and typographic color

These axes take advantage of much of the layout-based adaption variable fonts provide. Some of these concepts are best illustrated in Erik Van Blokland’s responsive lettering project:

Along with some of the amazingly beautiful Type and Media work to date:

In these examples, the glyphs’ optical size, weight and width shift at the same time as you resize the window. While a large portion of variable font axes directly correlate to layout, any number of arbitrary, non registered axes can also be created by the type designer. These can be for any type of change to the typeface in addition to interacting with the layout. David Berlow’s Decovar ornamental typeface is an example of this at one extreme.

Decovar sports a wide number of settings for adjusting the font’s decorative terminals and skeleton of the font. The limit here is the type designer’s imagination.

New Spaces

Variable fonts carry with them a broad range of possibilities and can open up entire designspaces of creative options to type, graphic and web designers. These aren’t human readable at first—they exist as mathematical representations. However, there are proposed approaches to help us visualize and manipulate variable fonts. By exploring user interface patterns, we can better understand how to illuminate the exciting spaces within a variable font. At its foundation, this involves making variable fonts aware of their context.

Mapping UI: Context

Before looking at UI, it’s worth noting that variable font axes can be directly linked to a wide range of inputs. These can be any combination of sensor readings to controller inputs and environmental signals. Certain registered axes however, make the most sense for responsive design and HTML/CSS/JS. A font’s width and weight axes are directly related to the container a set line of type can fit into. Variable fonts are able to adapt to the size of their containers—either filling them completely or at a specific set proportion.

A progression of work over the years has led to fonts adapting to fit their container. Paravel’s FitText and Zach Leatherman’s BigText were early examples of scaling text to fit a responsive container. Nick Sherman and Chris Lewis’s Font To Width swapped the width and weight version of the actual font to adapt to the container. Much of Eric Van Blokland’s previous work and responsive lettering project crystalized the idea of interpolation for adjusting type to width, height and optical variations within responsive design. Laurence Penny’s AxisPraxis demonstration links weight and width to the size of the container itself, allowing people manipulate the textbox instead of the type directly. All these strategies point to type set in relation to its container.

Optical size variations can also be linked to font size, allowing important characteristics to shine at display sizes while minimizing details to ensure the font remains robust at small sizes. In 2013, Nick (with David Jonathan Ross, Frank Grießhammer, and Florian Hardwig) showcased this feature in Adobe InDesign.

Automatic Optical Sizing in InDesign

This functionality outlined in inDesign is now available for variable fonts, allowing optical sizes to adapt in tandem with a user’s font size. Through techniques like these variable fonts can to adhere to layout / container dimensions, font size, and user context.

Often times however, a font itself needs to drive design and layout (in the case of most design tools like Sketch and Illustrator). In this case, we need UI to directly control the variable font. Interfaces rely on affordances to communicate to people how they work. UI and UX patterns carry a variety of assumptions people have built up over the years by interacting with similar controls—both physical and digital. We can break down some of these patterns and look at their advantages and disadvantages.

Mapping UI: Single Axis Controls

Single axis variable fonts are the most straightforward and only require one control. Toggles, sliders and knobs are all well suited for handling single axes. The most elemental of these—toggles, can be used to limit options for the sake of clarity.


Toggles denote “on” or “off” or a single selection:

A toggle UI for jumping between two points on an axis

A toggle’s simplicity can reduce choices to options people care about—like toggling serifs on or off (where intermediate values are less important). Single toggle based selection menus have existed since the earliest desktop publishing interfaces.

Aldus Pagemaker (released in July 1985) with a font selection menu option for Bold and Italic fonts Knobs

Typically knobs communicate an amount of something added to a whole.

Knobs are less common in digital interfaces but can be found in software plugins for Digital Audio Workstations. Knobs have the advantage of being compact while having a longer control surface to house values in a given square area. Another interesting property of knobs is that they can be periodic—allowing values to wrap entirely around the knob control. Underware’s Zeitung Flex introduced knobs as a method for controlling variable fonts.

Because the visible control surface isn’t straight, digital knobs have more of a learning curve (pun intended). Most knob controls alleviate this by allowing people to brush up and down to rotate the knob after it’s active or has been selected. Unless they’re large enough, knobs can also be hard to use with touch interactions.


Typically horizontal sliders communicate a balance or equilibrium between a range of two values.

Horizontal sliders are a common UI pattern across the web and native applications. iOS makes frequent use of this interface element:

Digital sliders have the advantage of working similarly to the way physical sliders do and are easy to learn. Sliders map well to a range of two different values on opposite ends of a spectrum—users just pick a middle value. Because of this, sliders are intuitive for both touch and mouse controls—actions happen in a single, linear motion.

Typically vertical sliders communicate the amount of a specific value, sometimes in context with other values.

Vertical sliders are typically seen in audio applications where it’s most important to horizontally scan and compare the levels of neighboring controls. Most digital audio workstations use them for volume levels.

The Ableton Live DAW. Note how the row of volume sliders can provide context for each other. Equalizers and other effects often use a similar UI pattern

Overall, sliders take up more space, but provide a clear and precise method for picking a specific value.

Any UI element can be overused (sliders and knobs alike) and misapplied. Ultimately, application of single axis controls should be considerate of the design tool and variable font itself. One key consideration is how the interface scales to account for additional font axes. Slider interfaces have an advantage in this category by being able to unfold naturally to support a two-axis control pattern.

Mapping UI: 2-Axis Controls

It’s common for variable fonts to have two or more axes. In these cases, a two-axis pattern can work best to avoid an overload of UI elements and give a designer better visibility.


Pads typically communicate a field of options.

Control pads  allow people to adjust two variable font axes at the same time. This pattern has been used in both audio hardware and software to control parameters along an X and Y axis.

Some audio hardware and software tools have pads with an X and Y axis for changing two parameters simultaneously

Control pads are less common in digital interfaces but hold familiarity through analogous design tool patterns like color pickers, which also provide people with a field of options.

X/Y control pads help reveal a larger portion of a font’s design space. They lack the directness of sliders and knobs, but provide a way for people to easily traverse through combinations of font variations.

The utility of having each axis map to a single control or direction quickly diminishes as the number of axes increases. At this point, we find effectiveness shift from manipulation to visualization.

Mapping UI: Multi Axis Controls and Visualizations

Fonts with three or more axes (variable fonts can have virtually any number of axes) are best served with different control and visualization approaches. Each axis can be represented mathematically as a feature or dimension. Fonts with a single axis map to a slider or knob while two axis fonts can take advantage of a pad UI. Three axis variable fonts can have their axes mapped to a cube.

Reverse Noordzij Cube Demo by DJR

At three axes, things shift away from UI towards more of a visualization approach, as effective digital omnidirectional controls are rare. Three and up, or N-dimensional font designspaces aren’t intuitive when mapped to physical space, so the best way think of them is as the amount of ingredients in a recipe. Take a cake recipe for example:

  • 1 cup white sugar
  • 1/2 cup butter
  • 2 eggs
  • 2 teaspoons vanilla extract
  • 1 1/2 cups all-purpose flour
  • 1 3/4 teaspoons baking powder
  • 1/2 cup milk

Each one of these ingredients represents a different feature of the cake. When combined with heat, they work together to create the final cake. Variable font axes or features work the same way:

  • 100% Font Width
  • 25% Font Weight
  • 5% Font Optical Size
  • 10% Font Serifs
  • 75% Font X-Height

People can adjust the axis postion (or amount of each ingredient) of a variable font, all of which have an effect on the final appearance of the typeface. Certain axes, like font width and stroke contrast may work together in parallel, while others, like x-height and font width may be more independent from each other.

Designing type with +3 Variations

At a certain level of complexity—a design tool’s focus should shift to serve more technical users. Type designers have their own category of challenges as they design, proof and test their fonts with intricate design spaces. Some variable fonts may have axes that are not exposed to users. There are other strategies for visualizing complex variable fonts like these.

For this, we can look at the visualization of multivariate data—a topic that has already been widely studied. There’s a broad range of existing strategies, some of which can be applied to variable fonts. The following deck divides these strategies into several categories:

  • Geometric projection techniques
  • Icon-based techniques
  • Pixel-oriented techniques
  • Hierarchical techniques
  • Hybrid techniques

By flattening axes, designers can see many aspects of a variable font at once. Star plots—an icon based technique—allow for the combination of multiple axes into a single chart.

Each axis extends from the center, with the sum total of a given variable font’s current settings making up the polygon shape. Other font instances can also be layered on top of the visualization with the abstraction of color.

Instances (likely masters) of a hypothetical variable font mapped on a star plot. Note the difference in the axis positions between the wide font vs. the narrow font.

Layers allow us to view the relationships between variable font instances. We can see how certain variable properties might be correlated with each other in a design space and between masters. Similar approaches, like parallel coordinates, are better structured to show relationships between axes.

Instances (likely masters) of a hypothetical variable font mapped to parallel coordinates. Note how the visualization reveals that there are only two possible values for optical size (distinct display and text variations). It also shows a possible correlation to a shorter x-height (as a display master may have smaller counters than a legibility minded text variation).

Kai Chang’s talk on visualizing multiple dimensions with parallel coordinates provides a great primer on assigning data’s dimensions to visual properties and charts. Other approaches like Fontmap group things based off arbitrary features.

These methods help us make sense of large sets of information with lots of related variables. Ultimately, they work by limiting our field of view and changing the angle through which we look at a set of variations. Instead of trying to see everything at once, we can break things down into manageable slices. Good interface controls allow us to quickly change our viewing perspective and organize axes. This UI is just as important as the visualizations themselves.

Mapping Controls

Variable font UI is most effective when it adapts along with the font. Thus, the more information a variable font can provide to the design program the better. Axes that are similar can be grouped together and collapsed under categories in the UI (for example, grouping axes that deal with serifs vs. font weight). Currently, there are discussions around allowing certain axes to be flagged (and ideally ordered and grouped) in order to intelligently reveal and hide advanced functionality through progressive disclosure within a design app.

What axes are revealed and how they’re categorized come down to a combination of the type designer’s intent and the user’s personal preferences. Both of these are relative but important. Web designers / developers may want certain types of axes for adapting the font to their responsive design. Type designers may want to limit the number of available axes to ensure consistency or simplify licensing. In other cases, graphic designers may want access to powerful, creative variable fonts with a large number of axes (for example matching stroke weight and serifs to the thickness of other graphic elements). Because of this, variable font UI needs smart defaults that responsibly translate the type designer’s intention while retaining ability for designers to make modifications.

In this line of thinking, every axis does not need to map 1:1 to a corresponding control. Multiple variable font axes can be assigned to a single macro control. On the font/type designer’s side, this would take the form as meta axes. On the interface size, this would take the form of assignable macro controls.

Macro controls are a common UI pattern in software synthesizer interfaces—they allow multiple parameters to be mapped to any combination of controls.

A standard feature in software synthesizers, macros let people assign any number of parameters to a single control. Note how the Macro 1 knob can adjust settings for both Oscillators A and B. Turning the macro knob also gives us peripheral information around change over time.

Mappable controls allow people to break up and organize a design space to fit their needs. In addition to giving users the ability to sort and power multiple controls, this method can help people discover relationships between axes. In this example, changing the font weight and optical size at the same time allow you to see and select the right balance of the two.

Typeshift’s dropdowns allow a reshuffling of axis controls for Voto Serif. Note how switching the optical axis to the pad control helps reveal how the font weight and optical size relate with each other.

While the axes themselves are independent of each other, the visual outcomes they produce are intertwined. Font weight and optical size are both related to each other and should be considered simultaneously when designing. This swapping of axes is comparable to reordering dimensions (see the reordering section) in the parallel coordinate charts mentioned earlier. In both cases, the interface can provide a smart, opinionated organization and flexibly surface new combinations.

Dynamic interfaces for dynamic fonts

Interfaces for variable fonts should adapt along with the fonts themselves.  There’s no single static UI pattern that will work as the best solution for all variable fonts. Instead of debating sliders and knobs, we should be exploring hybrid interfaces that take advantage of what each UI element has to offer. Likewise, UI should be considered in the context of our design tools with the acknowledgement that it will change how we design, influencing our choices. This gives us a unique opportunity to further typographic creativity and utility.

Integrating Animation into a Design System

Thu, 08/17/2017 - 11:09

Keeping animation choreography cohesive from the outset of a project can be challenging, especially for small companies. Without a dedicated motion specialist on the team, it can be difficult to prioritize guidelines and patterns early in the design process. What’s more likely to happen is that animations will be added as the product develops.

Unsurprisingly, the ad-hoc approach can lead to inconsistencies, duplications, and rework in the long run. But it also provides space for creative explorations and discoveries of what works and what doesn’t. As useful as it is to be able to establish system foundations early, it is also ok to let the patterns emerge organically as your team experiments and finds their own voice in motion.

Once there are enough animations, you might start thinking about how to ensure some consistency, and how to reuse existing patterns rather than recreate them from scratch every time. How do you transition a few odd animations to a cohesive system? I find it helpful to start by thinking about the purpose of animations and the feel they’re designed to evoke.

Start with purpose and feel Purpose

Like any other element in a design system, animations must have a purpose. To integrate animation, start by looking through your interface and noting how and why you use animations in your particular product and brand.

For example, at FutureLearn we noticed that we primarily use animation in three ways: to indicate a state change, to add an emphasis, or to reveal extra information.

A state change shows that an object has changed state due to user interaction. For example, a state can change on hover or on click. Animation here is used to soften the transition between states. Emphasis animations are used to draw attention to specific information or an action, for example a nudge to encourage users to progress to the next step in the course. Reveal animations are used to hide and reveal extra information, such as a menu being hidden to the side, a drop down, or a popover.

There are no “standard” categories for the purposes of animations. Some products use a lot of standalone animations, such as animated tutorials. Some use screen transitions, others don’t. For example, in Salesforce Lightning Design System personality and branding animations are grouped into a separate category.

Animation types in Salesforce Lightning Design System are categorized in a different way to FutureLearn.

The categories are specific to your interface and brand, and to how you use animation. They shouldn’t be prescriptive. Their main value is to articulate why your team should use animation, in your specific project.


As well as having a purpose in helping the user understand how the product works, animation also helps to express brand personality. So another aspect to consider is how animation should feel. In “Designing Interface Animation,” Val Head explains how adjectives describing brand qualities can be used for defining motion. For example, a quick soft bouncy motion can be perceived as lively and energetic, whereas steady ease-in-outs feel certain and decisive.

Brand qualities translated to motion Brand feel Animation feel Effect examples Lively and energetic Quick and soft Soft bounce
Soft overshoot Playful and friendly Elastic or springy Squash and stretch
Bouncy easing
Wiggle Decisive and certain Balanced and stable Ease-in, Ease-out Ease-in-out Calm and soft Small soft movements or no movement at all Opacity, color or blur changes, scale changes

As you look through the animation examples in your interface, list how the animation should feel, and note particularly effective examples. For example, take a look at the two animations below. While they’re both animating the entrance and exit of a popover, the animations feel different. The Marvel example on the left feels brisk through the use of bouncy easing, whereas the small movement combined with opacity and blur changes in the FutureLearn example on the right make it feel calm and subtle.

Popover animation on Marvel (top) and FutureLearn (bottom).

There’s probably no right and wrong way to animate a popover. As far as I know it all depends on your brand and how you choose to communicate through motion. In your interface you might begin to notice animations that have the same purpose but have entirely different feels. Take note of the ones that feel right for your brand, so that you can align the other animations to them later on.

Audit existing animations

Once you have a rough idea of the role animation plays in your interface and how it should feel, the next step is to standardize existing animations. Like an interface inventory, you can conduct an inventory focused specifically on animations. Start by collecting all the existing animations. They can be captured with QuickTime or another screen recording application. At the same time, keep a record of them in a Google Doc, Keynote, or an Excel file—whatever suits you.

Based on the purpose you defined earlier, enter categories, and then add the animations to the categories as you go. As you go through the audit, you might adjust those categories or add new ones, but it can be helpful not having to start with a blank page.

Example of initial categories for collecting animations in Google Doc.

For each animation add:

  • Effect: The effect might be difficult to describe at first (Should it be “grow” or “scale,” “wiggle” or “jiggle”?). Don’t worry about the right words yet, just describe what you see–you can refine that later.
  • Example: This could be a screenshot of the animated element with a link to a video clip, or an embedded gif.
  • Timing and easing: Write down the values for each example, such as 2 seconds ease.
  • Properties: Write down the exact values that change, such as color or size.
  • Feel: Finally, add the feel of the animation—is it calm or energetic, sophisticated and balanced, or surprising and playful?

After the inventory of animations at FutureLearn, we ended up with a document with about 22 animations, grouped into four categories. Here’s the state change category.

The “State Change” page from FutureLearn’s animation audit, conducted in a Google Doc. Define patterns of usage

Once you’ve collected all the animations, you can define patterns of usage, based on the purpose and feel. For example, you might notice that your emphasis animations typically feel energetic and playful, and that your state change transitions are more subtle and calm.

If these are the tones you want to strike throughout the system, try aligning all the animations to them. To do that, take the examples that work well (i.e. achieve the purpose effectively and have the right feel) and try out their properties with other animations from the same category. You’ll end with a handful of patterns.

Animation patterns on FutureLearn, grouped by purpose and feel Purpose Animation effects Feel Interactive state change Color, 2s ease
Opacity, in – 0.3s, out – 1.1s ease
Scale, 0.4 ease Calm, soft Emphasis Energetic pulse, 0.3s ease-in
Subtle pulse
Wiggle, 0.5s ease-in-out Energetic, playful Info reveal Slide down, 0.4 swing
Slide up, 0.7s ease
FadeInUp, 0.3 ease
Rotate, 0.3 ease Certain, decisive, balanced Develop vocabulary to describe effects

Animation effects can be hard to capture in words. As Rachel Nabors noted in “Communicating Animations,” sometimes people would start with “friendly onomatopoeias: swoosh, zoom, plonk, boom,” which can be used as a starting point to construct shared animation vocabularies.

Some effects are common and can be named after the classic animation principles (squash and stretch, anticipation, follow through, slow in and out1) or can even be borrowed from Keynote (fade in, flip, slide down, etc.), others will be specific to your product.

Vocabulary of animations in Salesforce Lightning Design System. Movement types in IBM Design Language.

There might also be animation effects unique to your brand that would require a distinctive name. For example, TED’s “ripple” animation in the play button is named after the ripple effect of their intro videos.

The ripple effect in the intro video on TED (left) mirrored in the play button interaction (right). Specify building blocks

For designers and developers, it is useful to specify the precise building blocks that they can mix and match to create the new animations. Once you have the patterns and effects, you can extract precise values—timing, easing, and properties—and turn them into palettes. The animation palettes are similar to color swatches or a typographic scale.


Timing is crucial in animation. Getting the timing right is not so much about perfect technical consistency as making sure that the timing feels consistent. Two elements animated with the same speed can feel completely different if they are different sizes or travel different distances.

The idea of “dynamic duration” in Material Design focuses on how fast something needs to move versus how long it should take to get there:

Rather than using a single duration for all animations, adjust each duration to accommodate the distance travelled, an element’s velocity, and surface changes.

Sarah Drasner, the author of SVG Animations, suggested that we should deal with timing in animation like we deal with headings in typography. Instead of having a single value, you’d start with a “base” and provide several incremental steps. So instead of h1, h2 and h3, you’d have t1, t2, t3.

Depending on the scale of the project, the timing palette might be simple, or it might be more elaborate. Most of the animations on FutureLearn use a base timing of 0.4. If this timing doesn’t feel right, most likely your object is traveling a shorter distance (in which case use “Shorter time”) or a longer distance (in which case use “Longer time”).

  • Shorter time: 0.3s: Shorter travel distance
  • Base: 0.4s: Base timing
  • Longer time: 0.6s: Longer distance traveled

Similar ideas used in the duration guidelines for the Carbon Design System are related to the “magnitude of change”:

Duration guidelines in Carbon Design System. Easing

Different easing values can give an animation a distinctive feel. It’s important to specify when to use each value. The easing palettes in the Marvel Styleguide provide a handy guide for when to use each value, e.g. “Springy feel. Good for drawing focus.”

Easing palette in the Marvel Styleguide.

An easing palette can also be more generic and be written as a set of guidelines, as done in the Salesforce Lightning Design System, for example:

For FutureLearn, we kept it even more simple and just limited it to two types of easing: Ease out “for things that move” (such as scale changes and slide up/down) and Linear “for things that don’t move” (such as color or opacity change).


In addition to timing and easing values, it is useful to specify the properties that typically change in your animations, such as:

  • Opacity
  • Color
  • Scale
  • Distance
  • Rotation
  • Blur
  • Elevation

Again, you can specify those properties as palettes with a base number, and the incremental steps to support various use cases. For example, when specifying scaling animations at FutureLearn, we noticed that the smaller an object is, the more it needs to scale in proportion to its size, for the change to be visible. A palette for scaling objects reflects that:

Small: ×0.025
Large objects
e.g. an image thumbnail

Base: ×0.1
Medium objects
e.g. button

Large: ×0.25
Small objects
e.g. icon

Although there’s no perfect precision to how these properties are set up, they provide a starting point for the team and help us reduce inconsistencies in our motion language.

Agree on the guiding principles

If you have guiding principles, it’s easier to point to them when something doesn’t fit. Some of the principles may be specific to how your team approaches animation. For example,

Guiding principles for motion in Salesforce Lightning Design System are kept short and simple.

If your team is not yet confident with animation, it may be worth including some of the more general principles, such as “reserve it for the most important moments of the interaction” and “don’t let it get in the way of completing a task.”

The guiding principles section can also include rationale for using animation in your product, and the general feel of your animation and how it connects with your brand. For example, IBM Design Language uses the physical movement of machines to extract the qualities they want to convey through animations, such as precision and accuracy.

From the powerful strike of a printing arm to the smooth slide of a typewriter carriage, each machine movement serves a purpose and every function responded to a need. IBM Design Language

In IBM’s Design Language, the rhythmic oscillation of tape reels in motion is used in a metaphorical way to support user’s waiting experience.

Guiding principles can also include spatial metaphors, which can provide a helpful mental model to people trying to create animations. Google’s Material Design is a great example of how thinking of interface as physical “materials” can provide a common reference for designers and developers when thinking about motion in their applications.

In Material Design, “Material can push other material out of the way.” To sum up

When integrating animation in design systems, try viewing it in relation to three things: guiding principles, patterns of usage, and building blocks. Guiding principles provide general direction, patterns of usage specify when and how to apply the effects, and building blocks aid the creation of new animations. Even if your animations were initially created without a plan, bringing them together in a cohesive, documented system can help you update and build on what you have in an intentional and brand-supporting way.

Further reading:
Creating Usability with Motion: The UX in Motion Manifesto
Web Animation Past, Present, and Future
Designing Interface Animation
Animation in Responsive Design


Practical User Research: Creating a Culture of Learning in Large Organizations

Thu, 07/27/2017 - 09:00

Enterprise companies are realizing that understanding customer needs and motivations is critical in today’s marketplace. Building and sustaining new user research programs to collect these insights can be a major struggle, however. Digital teams often feel thwarted by large organizations that are slow to change and have many competing priorities for financial investments.

As a design consultant at Cantina, I’ve seen companies at wildly different stages of maturity related to how customer research impacts their digital work. Sometimes executives struggle to understand the value without quantifiable numbers. Other times engineering teams see customer research and usability testing as a threat to delivery dates.

While you can’t always tackle these issues directly, the great thing about large organizations is that they’re brimming with people, tools, and work practices forming an overall culture. By understanding and utilizing each of these organizational resources, digital teams can create an environment focused on learning from customers.

I did some work recently for a client I’ll call WorkTech, who had this same struggle aligning their digital projects with the needs of their customers. WorkTech was attempting to redesign their entire ecommerce experience with a lean budget and team. In a roughly six month engagement, two of us from Cantina were tasked with getting the project back on track with a user-centered design approach. We had to work fast and start bringing customer insights to bear while moving the project forward. Employing a pragmatic approach that looked at people, tools, and work practices with a fresh set of eyes helped us create an environment of user research that better aligned the redesign with the needs of WorkTech’s customers.

Get comfortable talking to People in different roles

Effective user research programs start and end with people. Recognizing relationships and the motivations held by everyone interacting with a product or service encourages goodwill and can unearth key connections and other, less tangible benefits. To create and sustain a culture of learning in your company, find a group of users to interview—get creative, if you have to—and enlist the support of teammates and stakeholders.

Begin by taking stock of anyone connected to your product. You won’t always find a true set of end users internally, but everyone can help raise awareness of the value of user research—and they can help your team sustain forward progress. Ask yourself the following questions to find allies and research resources:

  • What departments use your product indirectly, but have connections to people in the user roles you’re targeting?
  • Is there a project sponsor who can help sell the value of research and connect you to additional staff that can assist in some capacity?
  • Are there employees in other departments whose individual goals align with getting better feedback from users?
  • Are there departments within the organization (sales, customer service) who can offer connections to customers wanting to provide candid feedback?

Our WorkTech project didn’t have a formal research budget for recruiting users (or any other research task). What we did have going for us was a group of internal users who gave our team immediate access to an initial pool of research participants. The primary platform we were hired to help redesign was used by two groups: WorkTech employees and the customers they interacted with. Over time, our internal users were able to connect us with their external counterparts, amplifying the number of people offering feedback significantly.

Maximize the value of every interview

While interviewing external customers, we kept an eye on the long term success of our research program and concluded each session by asking participants:

  • If they’d be willing to join another session in the future (most were willing)
  • If they could share names of anyone else in their network (internal or external) they thought would have feedback to offer

During each conversation, we also identified distinct areas of expertise for each user. This allowed us to better target future usability testing sessions on specific pieces of functionality.

Using this approach, our pool of potential participants grew exponentially and we gained insight into the shared motivations of different user personas. Taking stock of such different groups of people using the platform also revealed opportunities that helped us prioritize different aspects of the overall redesign effort.

Find helpful Tools that are already available or free

Tools can’t create an effective user research program on their own, but they are hugely helpful during the actual execution of research. While some organizations have an appetite for purchasing dedicated “user research” platforms able to handle recruitment, scheduling, and session recordings, many others already have tools in place that bring value to the organization in different areas. If your budget is tiny (or nonexistent), you may be able to repurpose or extend the software and applications your company already uses in a way that can support talking to customers.

Consider the following:

  • Are there current tools available in the organization (perhaps in other groups) that could be adapted for research purposes?
  • Are users already familiar with any tools or workflows you can utilize during research activities?
  • If new tools for automating specific tasks are out of budget, can your team build up repeatable templates and processes manually?

We discovered early on at WorkTech that our internal user base had very similar toolsets because of company-wide technology purchases. Virtually all employees already had Cisco Webex installed and were familiar with remote conferencing and sharing their screen.

WorkTech offices and customers were spread across the continental United States, so it made sense for our sessions to be remote, moderated conversations via phone and teleconference. Using Webex allowed the internal users to focus on the actual interview, avoiding the friction they might have felt attempting to use new technology.

Leveraging pre-existing tools also meant we could expand our capabilities without incurring significant new costs. (The only other tool we introduced was a free InVision account, which allowed us to create simple prototypes of new UI concepts, conduct weekly usability tests, and document and share our findings quickly and easily.)

Document and define templates as you go

Many digital research tools are simply well-defined starting points—templates for the various types of communication and idea capture needed. If purchasing access to these automated tools is out of the question, using a little elbow grease can be equally effective over time.

At WorkTech, maintaining good documentation trails minimized the time spent creating new materials for each round of research and testing. For repeatable tasks like creating scripts and writing recruitment emails, we simply saved and organized each document as we created it. This allowed us to build a library of reusable templates over time. Even though it was a bit of a manual effort, this payoff increased with every additional round of usability testing.

Utilizing available tools eliminates another significant hurdle to getting started—time delays. In large organizations with tight purchase protocols, using repurposed and free tools can enable teams to get moving quickly. Filling in the remaining gaps with good documentation and repeatable templates covers a wide range of scenarios and doesn’t let finances act as a blocker when collecting insights from users. 

Take a fresh look at your company’s Work Practices

A culture of learning won’t be sustainable over the long term if the lessons learned from user research aren’t informing what is being built. Bringing research insights to bear on your product or site is where everything pays off, ensuring digital teams can focus on what delivers the highest value to customers.

Being successful here requires a keen understanding of the common processes your organization uses to get things accomplished. By being aware of an organization’s current work practices (not some utopian version), digital teams can align what they’ve learned with practices that help ensure solutions get shipped.

Dig into the work practices in your organization and identify ways to meet people where they are:

  • Are there centrally-located workspaces that can be used for posting insights and keeping research outcomes in front of the team?
  • Are there any regularly-scheduled meetings with diverse teams that would be an opportunity to present research findings?
  • Are there established sprint cycles or product management reviews you can align with research efforts?

The WorkTech team collaborating with us on the project already had weekly meetings on the calendar, with an open agenda for high priority items. Knowing it would be important to get buy-in from this group, we set up our research and usability sessions each week on Tuesdays. This allowed us to establish a cadence where every Tuesday we tested prototypes, and every Wednesday we presented findings at the WorkTech team meeting. As new questions or design concepts to validate came up, the team was able to document them, pause any further debates, and move on to other topics of discussion. Everyone knew testing was a weekly occurrence, and within a few weeks even the most skeptical developer started asking us to get customer feedback on specific features they were struggling with.

Schedule regular customer sessions even before you are “ready”

Committing to a cadence of regular weekly sessions also allowed us to separate scheduling from test prep tasks. We didn’t wait to schedule sessions only when we desperately needed feedback. Because the time was already set aside each Tuesday, we simply had to develop questions and tests for the highest priority topic at that point in time. If something wasn’t quite ready, the next set of sessions was only a week away.

Using these principles, we conducted 40+ sessions over the course of 12 weeks, gathering valuable insights from the two primary user groups. We were able to gather quantifiable data pointing to one design pattern over another, which minimized design debates and instilled confidence in the research program and the design. In addition to building relationships with users across the spectrum, the sessions helped us uncover several key interface issues that we were then able to design around.

Even more valuable than the interface issues were general uses cases that came to light, where the website experience was only one component in a large ecosystem of internal processes at customers’ organizations. These insights proved valuable for our redesign project, but also provided a deeper understanding of WorkTech’s customer base, helping to prove the value of research efforts to key stakeholders.

Knowing the schedules and team norms in your organization is critical for creating a user research program whose insights get integrated into the design and development process. The insights of a single set of sessions are important, but creating a culture surrounding user research is more valuable to the long term success of your product or site, as is a mindset of ongoing empathy toward users.

To help grow and sustain a culture of research, though, teams have to be able to prove the value in financial terms. Paul Boag said it elegantly in the third Smashing Magazine book: “Because cost is (often a) primary reason for not testing, money has to be part of your justification for testing.”

The long term success of your program will likely be tied to how well you can prove its ROI in business terms, even though the methods described here minimize the need to ask for money. In other words, translate the value of user research to terms any business person can understand. Find ways to quantify the work hours currently lost to feature debates and building un-validated features, and you’ll uncover business costs that can be eliminated.

User research doesn’t have to be a big dollar, corporate initiative. By paying attention to the people, tools, and work practices within an organization, your team can demonstrate the value of user research on the ground, which will open doors to additional resources in the future.

This week's sponsor: ​Jamf Now

Sun, 07/09/2017 - 22:01

JAMF NOW is an on-demand mobile device management solution for your Apple devices at work. Get started for free today!

Team Conflict: Four Ways to Deflate the Discord that’s Killing Your Team

Tue, 06/27/2017 - 08:00

It was supposed to be a simple web project. Our client needed a site that would allow users to create, deploy and review survey results. Aside from some APIs that weren’t done, I wasn’t very worried about the project. I was surprised that my product manager was spending so much time at the client’s office.

Then, she explained the problem. It seemed that the leaders of product, UX and engineering didn’t speak to each other and, as a result, she had to walk from office to office getting information and decisions.

When two people have a bad interaction, they can work it out or let the conflict grow, spreading it to other team members and their leaders.

The conflicts probably started small. One bad interaction, then another, then people don’t like each other, then teams don’t work together well. The small scrape becomes a festering wound that slows things down, limits creativity and lowers morale.

Somehow as a kid working my way through school I discovered I had a knack for getting around individuals or groups that were fighting with each other. I simply figured out who I needed to help me accomplish a task, and I learned how to convince, cajole or charm them into doing it. I went on to teach these skills to my teams.

That sufficed for a while. But as I became a department head and an adviser to my clients, I realized it’s not enough to make it work. I needed to learn how to make it better. I needed to find a way to stop the infighting I’ve seen plague organizations my entire career. I needed to put aside my tendency to make the quick fix and have hard conversations.

It’s messy, awkward and hard for team leaders to resolve conflict but the results are absolutely worth it. You don’t need a big training program, a touchy-feely retreat or an expensive consultant. Team members or team leads don’t have to like each other. What they have to do is find common ground, a measure of respect for one another, and a willingness to work together to benefit the project.

Here are four ways to approach the problem.

Start talking

No matter how it looks at first, it’s always a people problem. Gerald M. Weinberg, The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

Resist the urge to wait for the perfect time to address team conflict. There’s no such thing. There will always be another deadline, another rollout, another challenge to be met.

In our office, a UX designer and product manager were having trouble getting along. Rather than take responsibility, they each blamed our “process” and said we needed to clarify roles and procedures. In other words, they each wanted to be deemed “in charge” of the project. Certainly I could have taken that bullet and begun a full-on assessment of our processes and structure. By taking the blame for a bad company framework, I could have dodged some difficult conversations.  But I knew our process wasn’t the problem.

First, I coached the product manager to be vulnerable, not an easy thing for him to do. I asked him to share his concerns and his desire to have a more productive relationship with the UX designer. The PM’s willingness to be uncomfortable and open about his concerns lifted the tension. Once he acknowledged the elephant in the room—namely that the UX designer was not happy working with him—the designer became more willing to risk being honest. Eventually, they were able to find a solution to their disagreements on the project, largely because they were willing to give each other a measure of respect.

The worst thing I’ve seen is when leaders move people from team to team hoping that they will magically find a group of people that work well together, and work well with them. Sometimes the relocated team members have no idea that their behavior or performance isn’t acceptable. Instead of solving the problem, this just spreads the dissatisfaction.

Instead, be clear right from the beginning that you want teams that will be open about challenges, feel safe discussing conflicts, and be accountable for solving them.

Have a clear purpose

Although many aspects of our collective endeavor are open for discussion, choice of mountain is not among them. J. Richard Hackman, Leading Teams: Setting the Stage for Great Performances

I was working on an enterprise CMS re-design and re-platform. Our weekly review and estimation sessions were some of the most painful meetings of my career. There was no trust or shared purpose—even estimating a simple task was a big fight.

When purpose and priorities are murky you are likely to find conflict. When the team doesn’t know what mountain they are trying to climb, they tend to focus on the parts of the project that are most relevant to them. With each team member jealously guarding his or her little ledge, it’s almost impossible to have cooperation.

This assault on productivity is likely because the project objective is non-existent, or muddled nonsense, or so broad the team doesn’t see how it can have an impact. Or, maybe the objective is a moving target, constantly shifting.

Size can be a factor.  I’ve seen enterprise teams with clear missions and startups with such world-changing objectives they can’t figure out how to ship something that costs less than a million dollars.

When I’m meeting with prospects or new clients I look at three areas to see if they are having this problem:

  • What language do they use to describe each other? Disconnected teams say “UX thinks,” “The dev team” or “product wants.” Unified teams say “we.”
  • How easy or hard is task estimation? Disconnected teams fight about the level of difficulty. United teams talk about tradeoffs and argue about what’s best for the product or customers.
  • Can they easily and consistently describe their purpose? Disconnected teams don’t have a crisp and consistent answer. Unified teams nod their heads when one of their members shares a concise answer.

If a team is disconnected, it’s likely because you haven’t given them a common goal. A single email or a fancy deck isn’t enough. Make your objectives simple and repeat them so much that the team groans every time you start.

Plan conversations

Words do not sit in our brains in isolation. Each word is surrounded by its own connotations, memories and associations Simon Lancaster, Winning Minds: Secrets From the Language of Leadership

Years ago I was frustrated to tears by a manager who, I felt, took from me the product I spent two years building. I knew I needed to talk with him but I struggled to find a productive way to tell him why I was upset.  (Telling someone he is being a jackass is not productive.)

A good friend in HR helped me script the conversation. It had three parts:

  • I really work well when…
  • This situation is bothering me because…
  • What I’d like to see happen is…

Leaders have an important role to play in resolving issues. When a leader decides that their person is right and another person is wrong it turns a team problem into an organization problem. Instead we should should provide perspective, context and show how actions could be misunderstood.

Leaders also need to quickly, clearly and strongly call about bad behavior. When I found out one of my people raised their voice at a colleague, I made it clear that wasn’t acceptable and shouldn’t happen again. He admitted that he lost his cool, apologized and then we started working on the resolving the situation.

Require accountability Being responsible sometimes means pissing people off. General Colin Powell,former U.S. Secretary of State

If you have a problem and you go to Holly Paul, an inspiring HR leader, you can expect that she will listen. You can also expect that she’ll work with you on a plan to resolve it. Most importantly you can expect she will make sure you are doing what you said you’d do when you said you would do it.

Before I met Holly I would listen to problems then try to go solve them. Now I work with the person and tell them that I will be checking back with them, often putting the reminder in my calendar during the conversation so I don’t forget.

Since I started focusing on fixing conflict, I’ve seen great changes on my team. Many of them have started for the first time dealing with the people, fixing their issues and forging much stronger relationships. Our team is stronger and having a greater influence on the organization.

It’s messy, awkward and hard. I’ve been working on this for a long time and I still make mistakes. I still don’t always want to push when I meet resistance. This will never be easy, but it will be worth it and it’s your responsibility as a leader. For however long these people are with you, you need to make them better as individuals and a unit.

You don’t need a big training, a touchy-feely retreat or an expensive consultant. You just need to start doing the work every day. The rest will come.

Color Accessibility Workflows

Tue, 06/06/2017 - 08:00

A note from the editors: We’re pleased to share an excerpt from Chapter 3 of Geri Coady's new book, Color Accessibility Workflows, available now from A Book Apart.

The Web Content Accessibility Guidelines (WCAG) 2.0 contain recommendations from the World Wide Web Consortium (W3C) for making the web more accessible to users with disabilities, including color blindness and other vision deficiencies.

There are three levels of conformance defined in WCAG 2.0, from lowest to highest: A, AA, and AAA. For text and images of text, AA is the minimum level that must be met.

AA compliance requires text and images of text to have a minimum color contrast ratio of 4.5:1. In other words, the lighter color in a pair must have four-and-a-half times as much luminance (an indicator of how bright a color will appear) as the darker color. This contrast ratio is calculated to include people with moderately low vision who don’t need to rely on contrast-enhancing assistive technology, as well as people with color deficiencies. It’s meant to compensate for the loss in contrast sensitivity often experienced by users with 20/40 vision, which is half of normal 20/20 vision.

Level AAA compliance requires a contrast ratio of 7:1, which provides compensation for users with 20/80 vision, or a quarter of normal 20/20 vision. People who have a degree of vision loss more than 20/80 generally require assistive technologies with contrast enhancement and magnification capabilities.

Text that acts as pure decoration, nonessential text that appears in part of a photograph, and images of company logos do not strictly need to adhere to these rules. Nonessential or decorative text is, by definition, not essential to understanding a page’s content. Logos and wordmarks may contain textual elements that are essential to broadcasting the company’s visual identity, but not to conveying important information. If necessary, the logo may be described by using an alt attribute for the benefit of a person using screen-reader software. To learn more, check out accessibility specialist Julie Grundy’s blog post on Simply Accessible, where she goes into the best practices around describing alt attributes.

Text size plays a big role in determining how much contrast is required. Gray text with an RGB value of (150,150,150) on a pure white background passes the AA level of compliance, as long as it’s used in headlines above 18 points. Gray text with an RGB value of (110,110,110) passes the AA level at any text size, and will be AAA compliant if used as a headline above 18 points (Fig 3.1). A font displayed at 14 points may have a different level of legibility compared to another font at 14 points due to the wide diversity of type styles, so keep this in mind, especially when using very thin weights.

Fig 3.1: Text size also plays a role when calculating compliance ratios.

Personally, I recommend that all body text be AAA compliant, with larger headlines and less important copy meeting AA compliance as a bare minimum. Keep in mind that these ratios refer to solid-colored text over solid-colored backgrounds, where a single color value can be measured. Overlaying text on a gradient, pattern, or photograph may require a higher contrast value or alternative placement, such as over a solid-colored strip, to provide sufficient legibility.

These compliance ratios are often what folks mean when they claim that achieving accessible design by “ticking off boxes” can only come at the cost of stifled creativity or restricted color choices. But that simply isn’t true. Experimentation with a color-contrast checker proves that many compliance ratios are quite reasonable and easy to achieve—especially if you are aware of the rules from the beginning. It would be much more frustrating to try to shift poor color choices into something compliant later in the design process, after branding colors have already been chosen. If you fight your battles up front, you’ll find you won’t feel restricted at all.

If all this talk of numbers seems confusing, I promise there’ll be no real math involved on your side. You can easily find out if your color pairs pass the test by using a color-contrast checker.

Contrast checkers

One of my favorite tools is Lea Verou’s Contrast Ratio (Fig 3.2). It gives you the option of entering a color code for a background and a color code for text, and it calculates the ratio for you.

Fig 3.2: Lea Verou’s Contrast Ratio checker.

Contrast Ratio supports color names, hex color codes, RGBA values, HSLA values, and even combinations of each. Supporting RGBA and HSLA values means that Verou’s tool supports transparent colors, a handy feature. You can easily share the results of a check by copying and pasting the URL. Additionally, you can modify colors by changing the values in the URL string instead of using the page’s input fields.

Another great tool that has the benefit of simultaneously showing whether a color combination passes both AA and AAA compliance levels is Jonathan Snook’s Colour Contrast Check (Fig 3.3).

Fig 3.3: Jonathan Snook’s Colour Contrast Check.

At the time of writing, Colour Contrast Check doesn’t support HSL alpha values, but it does display the calculated brightness difference and color difference values, which might interest you if you want a little more information.

Color pickers

If you need help choosing accessible colors from the start, try Color Safe. This web-based tool helps designers experiment with and choose color combinations that are immediately contrast-compliant. Enter a background color as a starting point; then choose a standard font family, font size, font weight, and target WCAG compliance level. Color Safe will return a comprehensive list of suggestions that can be used as accessible text colors (Fig 3.4).

Fig 3.4: Color Safe searches for compliant text colors based on an existing background color.

Adjustment tools

When faced with color choices that fail the minimum contrast ratios, consider using something like Tanaguru Contrast Finder to help find appropriate alternatives (Fig 3.5). This incredibly useful tool takes a foreground and background color pair and then presents a range of compliant options comparable to the original colors. It’s important to note that this tool works best when the colors are already close to being compliant but just need a little push—color pairs with drastically low contrast ratios may not return any suggestions at all (Fig 3.6).

Fig 3.5: This color pair is not AA compliant.

Fig 3.6: A selection of Tanaguru’s suggested AA-compliant alternatives.

There’s more where that came from!

Check out the rest of Color Accessibility Workflows at A Book Apart.