Web Development Network  |  Sites:    Capital Tutorials    Internet Marketing Books    Arcade Games
Depiction- Webmaster Resources
Stock Image


Contributors: SSD VPS in Europe  |  SEO Las Vegas |  EsqRank |  Free SEO Report

Dental SEO Marketing  |  Best Las Vegas SEO Company  |  Currency Converter Live

Misc Links: Submit Tutorials (Earn $$) l Advertising l Privacy Policy | Site Map

RSS News Feeds



A List Apart: The Full Feed

Articles for people who make web sites.

This is the most recent feed available as of 12/07/2016 at 09:29 AM

Accessibility Whack-A-Mole

I don’t believe in perfection. Perfection is the opiate of the design community.

Designers sometimes like to say that design is about problem-solving. But defining design as problem-solving is of course itself problematic, which is perhaps nowhere more evident than in the realm of accessibility. After all, problems don’t come in neat black-and-white boxes—they’re inextricably tangled up with other problems and needs. That’s what makes design so fascinating: experimentation, compromise, and the thrill of chasing an elusive sweet spot.

Having said that, deep down I’m a closet idealist. I want everything to work well for everyone, and that’s what drives my obsession with accessibility.

Whose accessibility, though?

Accessibility doesn’t just involve improving access for people with visual, auditory, physical, speech, cognitive, language, learning, and neurological difficulties—it impacts us all. Remember that in addition to those permanently affected, many more people experience temporary difficulties because of injury or environmental effects. Accessibility isn’t a niche issue; it’s an everyone issue.

There are lots of helpful accessibility guidelines in Web Content Accessibility Guidelines (WCAG) 2.0, but although the W3C is working to better meet the complex needs of neurodiverse users, there are no easy solutions. How do we deal with accessibility needs for which there are no definitive answers? And what if a fix for one group of people breaks things for another group?

That’s a big question, and it’s close to my heart. I’m dyslexic, and one of the recommendations for reducing visual stress that I’ve found tremendously helpful is low contrast between text and background color. This, though, often means failing to meet accessibility requirements for people who are visually impaired. Once you start really looking, you notice accessibility conflicts large and small cropping up everywhere. Consider:

  • Designing for one-handed mobile use raises problems because right-handedness is the default—but 10 percent of the population is left handed.
  • Giving users a magnified detailed view on hover can create a mobile hover trap that obscures other content.
  • Links must use something other than color to denote their “linkyness.” Underlines are used most often and are easily understood, but they can interfere with descenders and make it harder for people to recognize word shapes.

You might assume that people experiencing temporary or long-term impairment would avail themselves of the same browser accessibility features—but you’d be wrong. Users with minor or infrequent difficulties may not have even discovered those workarounds.

With every change we make, we need to continually check that it doesn’t impair someone else’s experience. To drive this point home, let me tell you a story about fonts.

A new font for a new brand

At Wellcome, we were simultaneously developing a new brand and redesigning our website. The new brand needed to reflect the amazing stuff we do at Wellcome, a large charitable organization that supports scientists and researchers. We wanted to paint a picture of an energetic organization that seeks new talent and represents broad contemporary research. And, of course, we had to do all of this without compromising accessibility. How could we best approach a rebrand through the lens of inclusivity?

To that end, we decided to make our design process as transparent as possible. Design is not a dark art; it’s a series of decisions. Sharing early and often brings the benefit of feedback and allows us to see work from different perspectives. It also offers the opportunity to document and communicate design decisions.

When we started showing people the new website, some of them had very specific feedback about the typeface we had chosen. That’s when we learned that our new headline font, Progress Two, might be less than ideal for readers with dyslexia. My heart sank. As a fellow dyslexic, I felt like I was letting my side down.

My entire career had been geared toward fostering accessibility, legibility, and readability. I’d been working on the site redevelopment for over a year. With clarity and simplicity as our guiding principles, we were binning jargon, tiny unreadable text, and decorative molecules.

And now this. Were we really going to choose a typeface that undid all of our hard work and made it difficult for some people to read? After a brief panic, I got down to some research.

So what makes type legible?

The short answer is: there is no right answer. A baffling and often contradictory range of research papers exists, as do, I discovered, companies trying to sell “reasonably priced” (read: extortionate) solutions that don’t necessarily solve anything.

Thomas Bohm offers a helpful overview of characters that are easily misrecognized, and the British Dyslexia Association (BDA) has published a list of guidelines for dyslexia-friendly type. The BDA guidelines on letterforms pretty much ruled out all of the fonts on our short list. Even popular faces like Arial and Helvetica fail to tick all the boxes on the BDA list, although familiar sans serifs do tend to test well, according to some studies (PDF).

And it’s not just dyslexia that is sensitive to typography; we recently had a usability testing participant who explained that some people on the autism spectrum struggle with certain fonts, too. And therein lies the problem: there’s a great deal of diversity within neurodiversity. What works for me doesn’t work for everyone with dyslexia; not everyone on the autism spectrum gives a flip about fonts, but some really do.

At first my research discouraged and overwhelmed me. The nice thing about guidelines, though, is that they give you a place to start.

Progress

Some people find fonts specifically designed for dyslexia helpful, but there is no one-size-fits-all solution. Personally, I find a font like Open Dyslexic tricky to read; since our goal was to be as inclusive as possible, we ultimately decided that Open Dyslexic wasn’t the right choice for Wellcome. The most practical (and universal) approach would be to build a standards-compliant site that would allow users to override styles with their own preferred fonts and/or colors. And indeed, users should always be able to override styles. But although customization is great if you know what works for you, in my experience (as someone who was diagnosed with dyslexia quite late), I didn’t always know why something was hard, let alone what might help. I wanted to see if there was more we could do for our users.

Mariane Dear, our senior graphic designer, was already negotiating with the type designer (Gareth Hague of Alias) about modifying some aspects of Progress Two. What if we could incorporate some of the BDA’s recommendations? What if we could create something that felt unique and memorable, but was also more dyslexia friendly? That would be cool. So that’s what we set out to do.

Welcome, Wellcome Bold

When I first saw Progress Two, I wasn’t particularly keen on it—but I had to admit it met the confident, energetic aspirations of our rebranding project. And even though I didn’t initially love it, I think our new customized version, Wellcome Bold, has “grown up” without losing its unique personality. I’ve come to love what it has evolved into.

We used the BDA’s checklist as a starting point to analyze and address the legibility of the letterforms and how they might be improved.

Illusion number 1


If uppercase I, lowercase l, and numeral 1 look too similar, some readers might get confused. We found that the capital I and lowercase l of Progress Two weren’t distinct enough, so Hague added a little hook to the bottom of the l.

Illustration showing examples of capital ‘I’, lowercase ‘l’, and numeral ‘1’
Capital I, lowercase l, and numeral 1 show how Progress Two metamorphosed into Wellcome Bold. (All glyph illustrations by Eleanor Ratliff.)

Modern modem

In some typefaces, particularly if not set well, r and n can run together to appear to form an mmodern may be read as modem, for example. Breaking the flow between the two shapes differentiates them better.

Illustration showing how lowercase ‘r’ and ‘n’ were modified to prevent the two glyphs from running together when set next to each other
From Progress Two to Wellcome Bold: lowercase r and n were tweaked to prevent the two glyphs from running together when set next to each other.

Openings

Counters are the openings in the middle of letterforms. Generally speaking, the bigger the counters, the more distinct the letters.

Illustration showing counters in ‘b’, ‘a’, ‘e’, ‘o’, and ‘q’ in Wellcome Bold
Highlighted counters in Wellcome Bold’s lowercase b, a, e, o, and q.

Mirroring

Because some people with dyslexia perceive letters as flipped or mirrored, the BDA recommends that b and d, and p and q, be easily distinguishable.

Illustration showing how lowercase ‘d’ and ‘b’ were modified to make them more easily distinguishable in Wellcome Bold
Lowercase d and b were modified to make them more easily distinguishable in Wellcome Bold.

Word shapes

Most readers don’t read letter by letter, but by organizing letterforms into familiar word shapes. We modified Progress Two not just to make things easier for readers who are dyslexic; we did it as part of a wider inclusive design process. We wanted to make accessibility a central part of our design principles so that we could create an easier experience for everyone.

Test, test, and test again

In the course of our usability testing, we had the good fortune to be able to work with participants with accessibility needs in each round, including individuals with dyslexia, those on the autism spectrum, and users of screen readers.

Once we started introducing changes, we were anxious to make sure we were heading in the right direction. Nancy Willacy, our lead user experience practitioner, suggested that a good way to uncover any urgent issues would be to ask a large number of respondents to participate in a survey. The media team helped us out by tweeting our survey to a number of charities focused on dyslexia, dyspraxia, autism, and ADHD, and the charities were kind enough to retweet us to their followers.

Although we realize that our test was of the quick-and-dirty variety, we got no feedback indicating any critical issues, which reassured us that we were probably on the right track. Respondents to the survey had a slight preference for the adjusted version of Progress Two over Helvetica (we chose a familiar sans serif as a baseline); the unadjusted version came in last.

Anyone can do it

Even if you don’t have a friendly type designer you can collaborate with to tailor your chosen fonts, you can still do a lot to be typographically accessible.

Type

When selecting a typeface, look for letterforms that are clear and distinct.

  • Look closely and critically. Keeping the checklists we’ve mentioned in mind, watch for details that could potentially trip readers up, like shapes that aren’t well differentiated enough or counters that are too closed.
  • To serif or not to serif? Some research has shown that sans serifs are easier to read on screen, since, especially at lower resolutions, serifs can get muddy, make shapes less distinct, or even disappear altogether. If your existing brand includes a typeface with fine serifs or ornamental details, use it sparingly and make sure you test it with a range of users and devices.
  • Use bold for emphasis. Some research has shown that italics and all-caps text reduce reading speed. Try using bold for emphasis instead.
  • Underline with care. Underlines are great for links, but a standard text-decoration underline obscures descenders. In the future, the text-decoration-skip property may be able to help with that; in the meantime, consider alternatives to the default.

Space

Think carefully about spaces between, around, and within letterforms and clusters of words.

Words

The words you use are just as important as what you do with them.

  • Keep it short. Avoid long sentences. Keep headings clear and concise.
  • Avoid jargon. Write for your audience and cut the jargon unless it’s absolutely necessary. Acronyms and academic terms that might be appropriate for a team of specialists would be totally out of place in a more general article, for example.

So everything’s fixed, right?

Nope.

There is no perfect typeface. Although we worked hard to improve the experience of the Wellcome site, some people will still struggle with our customized headline font, and with the Helvetica, Arial, sans-serif font stack we’re using for body text. However hard we try, some people may need to override defaults and choose the fonts and colors that work best for them. We can respect that by building sites that allow modification without breaking.

Pragmatic perfection

The trouble with expecting perfection in one go is that it can be tempting to take the safe route, to go with the tried and tested. But giving ourselves room to test and refine also gives us the freedom to take risks and try original approaches.

Putting ourselves out there can feel uncomfortable, but Wellcome wants to fund researchers that have the big ideas and the chutzpah to take big risks. So shouldn’t those of us building the site be willing to do the same? Yes, maybe we’ll make mistakes, but we’ll learn from them. If we had chosen a safe typeface for our headline font, we wouldn’t be having these conversations; we wouldn’t have done the research that led us to make changes; we wouldn’t discover new issues that failed to come up in any of our research.

The process sparked much debate at Wellcome, which opened doors to some intriguing opportunities. In the future, I won’t be so reticent about daring to try new things.

Additional resources



This week's sponsor: ENVATO ELEMENTS

ENVATO ELEMENTS, the only subscription made with designers in mind. 9000+ quality fonts, graphics, templates and more. Get started today.



This week's sponsor: O’REILLY DESIGN CONFERENCE

O’REILLY DESIGN CONFERENCE - get the skills and insights you need to design the products of the future. Save 20% with code ALIST



Insisting on Core Development Principles

The web community talks a lot about best practices in design and development: methodologies that are key to reaching and retaining users, considerate design habits, and areas that we as a community should focus on.

But let’s be honest—there are a lot of areas to focus on. We need to put users first, content first, and mobile first. We need to design for accessibility, performance, and empathy. We need to tune and test our work across many devices and browsers. Our content needs to grab user attention, speak inclusively, and employ appropriate keywords for SEO optimization. We should write semantic markup and comment our code for the developers who come after us.

Along with the web landscape, the expectations for our work have matured significantly over the last couple of decades. It’s a lot to keep track of, whether you’ve been working on the web for 20 years or only 20 months.

If those expectations feel daunting to those of us who live and breathe web development every day, imagine how foreign all of these concepts are for the clients who hire us to build a site or an app. They rely on us to be the experts who prioritize these best practices. But time and again, we fail our clients.

I’ve been working closely with development vendor partners and other industry professionals for a number of years. As I speak with development shops and ask about their code standards, workflows, and methods for maintaining consistency and best practices across distributed development teams, I’m continually astonished to hear that often, most of the best practices I listed in the first paragraph are not part of any development project unless the client specifically asks for them.

Think about that.

Development shops are relying on the communications team at a finance agency to know that they should request their code be optimized for performance or accessibility. I’m going to go out on a limb here and say that shouldn’t be the client’s job. We’re the experts; we understand web strategy and best practices—and it’s time we act like it. It’s time for us to stop talking about each of these principles in a blue-sky way and start implementing them as our core practices. Every time. By default.

Whether you work in an internal dev shop or for outside clients, you likely have clients whose focus is on achieving business goals. Clients come to you, the technical expert, to help them achieve their business goals in the best possible way. They may know a bit of web jargon that they can use to get the conversation started, but often they will focus on the superficial elements of the project. Just about every client will worry more about their hero images and color palette than about any other piece of their project. That’s not going to change. That’s okay. It’s okay because they are not the web experts. That’s not their job. That’s your job.

If I want to build a house, I’m going to hire experts to design and build that house. I will have to rely on architects, builders, and contractors to know what material to use for the foundation, where to construct load-bearing walls, and where to put the plumbing and electricity. I don’t know the building codes and requirements to ensure that my house will withstand a storm. I don’t even know what questions I would need to ask to find out. I need to rely on experts to design and build a structure that won’t fall down—and then I’ll spend my time picking out paint colors and finding a rug to tie the room together.

This analogy applies perfectly to web professionals. When our clients hire us, they count on us to architect something stable that meets industry standards and best practices. Our business clients won’t know what questions to ask or how to look into the code to confirm that it adheres to best practices. It’s up to us as web professionals to uphold design and development principles that will have a strong impact on the final product, yet are invisible to our clients. It’s those elements that our clients expect us to prioritize, and they don’t even know it. Just as we rely on architects and builders to construct houses on a solid foundation with a firm structure, so should we design our sites on a solid foundation of code.

If our work doesn’t follow these principles by default, we fail our clients

So what do we prioritize, and how do we get there? If everything is critical, then nothing is. While our clients concentrate on colors and images (and, if we’re lucky, content), we need to concentrate on building a solid foundation that will deliver that content to end users beautifully, reliably, and efficiently. How should we go about developing that solid foundation? Our best bet is to prioritize a foundation of code that will help our message reach the broadest audience, across the majority of use cases. To get to the crux of a user-first development philosophy, we need to find the principles that have the most impact, but aren’t yet implicit in our process.

At a minimum, all code written for general audiences should be:

  • responsive
  • accessible
  • performant

More specifically, it’s not enough to pay lip service to those catch phrases to present yourself as a “serious” dev shop and stop there. Our responsive designs shouldn’t simply adjust the flow and size of elements depending on device width—they also need to consider loading different image sizes and background variants based on device needs. Accessible coding standards should be based on the more recent WCAG 2.0 (Level AA) standards, with the understanding that coding for universal access benefits all users, not just a small percentage (coupled with the understanding that companies whose sites don’t meet those standards are being sued for noncompliance). Performance optimization should think about how image sizes, scripts, and caching can improve page-load speed and decrease the total file size downloaded in every interaction.

Do each of these take time? Sure they do. Development teams may even need additional training, and large teams will need to be prescriptive about how that can be integrated into established workflows. But the more these principles are built into the core functions of all of our products, the less time they will take, and the better all of our services will be.

How do we get there?

In the long run, we need to adjust our workflows so that both front-end and backend developers build these best practices into their default coding processes and methodologies. They should be part of our company cultures, our interview screenings, our value statements, our QA testing scripts, and our code validations. Just like no one would think of building a website layout using tables and 1px spacer images anymore (shout out to all the old-school webmasters out there), we should reach a point where it’s laughable to think of designing a fixed-width website, or creating an image upload prompt without an alt text field.

If you’re a freelance developer or a small agency, this change in philosophy or focus should be easier to achieve than if you are part of a larger agency. As with any time you and your team expand and mature your skillsets, you will want to evaluate how many extra hours you need to build into the initial learning curves of new practices. But again, each of these principles becomes faster and easier to achieve once they’re built into the workflow.

There is a wealth of books, blogs, checklists, and how-tos you can turn to for reference on designing responsively, making sites accessible, and tuning for performance. Existing responsive frameworks can act as a starting point for responsive development. After developing the overarching layout and flow, the main speed bumps for responsive content arise in the treatment of tables, images, and multimedia elements. You will need to plan to review and think through how your layouts will be presented at different breakpoints. A tool like embedresponsively.com can speed the process for external content embeds.

Many accessibility gaps can be filled by using semantic markup instead of making every element a div or a span. None of the accessible code requirements should be time hogs once a developer becomes familiar with them. The a11y Project’s Web Accessibility Checklist provides an easy way for front-end developers to review their overall code style and learn how to adjust it to be more accessible by default. In fact, writing truly semantic markup should speed CSS design time when it’s easier to target the elements you’re truly focused on.

The more you focus on meeting each of these principles in the early stages of new projects, the faster they will become your default way of developing, and the time spent on them will become a default part of the process.

Maintaining focus

It’s one thing to tell your team that you want all the code they develop to be responsive, accessible, and performant. It’s another thing entirely to make sure it gets there. Whether you’re a solo developer or manage a team of developers, you will need systems in place to maintain focus. Make sure your developers have the knowledge required to implement the code and techniques that address these needs, and supplement with training when they don’t.

Write value statements. Post lists. Ask at every stage what can be added to the process to make sure these core principles are considered. When you hire new talent, you can add questions into the interview process to make sure your new team members are already up to speed and have the same values and commitment to quality from day one.

Include checkpoints within each stage of the design and development process to ensure your work continues to build toward a fully responsive, accessible, and performant end product. For example, you can adjust the design process to start with mobile wireframes to change team mindsets away from designing for desktop and then trying to backfill mobile and tablet layouts. Another checkpoint should be added when determining color palettes to test foreground and background color sets for accessible color contrast. Add in a step to run image files through a compressor before uploading any graphic assets. Ask designers to use webfonts responsibly, not reflexively. Set a performance budget, and build in steps for performance checks along the way. Soon, your team will simply “know” which features or practices tend to be performance hogs and which are lean. You will need to make sure testing and code reviews look for these things, too.

Nothing worth doing happens by accident. Every time we overlook our responsibilities as designers and developers because it’s faster to cut corners, our products suffer and our industry as a whole suffers. As web professionals, how we work and what we prioritize when no one’s looking make a difference in thousands of little ways to thousands of people we will never meet. Remember that. Our clients and our users are counting on us.

 



The Coming Revolution in Email Design

Email, the web’s much maligned little cousin, is in the midst of a revolution—one that will change not only how designers and developers build HTML email campaigns, but also the way in which subscribers interact with those campaigns.

Despite the slowness of email client vendors to update their rendering engines, email designers are developing new ways of bringing commonplace techniques on the web to the inbox. Effects like animation and interactivity are increasingly used by developers to pull off campaigns once thought impossible. And, for anyone coming from the world of the web, there are more tools, templates, and frameworks than ever to make that transition as smooth as possible. For seasoned email developers, these tools can decrease email production times and increase the reliability and efficacy of email campaigns.

Perhaps more importantly, the email industry itself is in a state of reinvention. For the first time, email client vendors—traditionally hesitant to update or change their rendering engines—are listening to the concerns of email professionals. While progress is likely to be slow, there is finally hope for improved support for HTML and CSS in the inbox.

Although some problems still need to be addressed, there has never been a better time to take email seriously. For a channel that nearly every business uses, and that most consumers can’t live without, these changes signal an important shift in a thriving industry—one that designers, developers, and strategists for the web should start paying attention to.

Let’s look at how these changes are manifesting themselves.

The web comes to email

It’s an old saw that email design is stuck in the past. For the longest time, developers have been forced to revisit coding techniques that were dated even back in the early 2000s if they wanted to build an HTML email campaign. Locked into table-based layouts and reliant on inline styles, most developers refused to believe that email could do anything more than look serviceable and deliver some basic content to subscribers.

For a few email developers, though, frustrating constraints became inspiring challenges and the catalyst for a variety of paradigm-shifting techniques.

When I last wrote about email for A List Apart, most people were just discovering responsive email design. Practices that were common on the web—the use of fluid grids, fluid images, and media queries—were still brand new to the world of email marketing. However, the limitations of some email clients forced developers to completely rethink responsive email.

Until recently, Gmail refused to support media queries (and most embedded styles), leaving well-designed, responsive campaigns looking disastrous in mobile Gmail apps. While their recently announced update to support responsive emails is a huge step forward for the community, the pioneering efforts of frustrated email developers shouldn’t go unnoticed.

Building on the work first introduced by MailChimp’s Fabio Carneiro, people like Mike Ragan and Nicole Merlin developed a set of techniques typically called hybrid coding. Instead of relying on media queries to trigger states, hybrid emails are fluid by default, leaving behind fixed pixels for percentage-based tables. These fluid tables are then constrained to appropriate sizes on desktop with the CSS max-width property and conditional ghost tables for Microsoft Outlook, which doesn’t support max-width. Combined with Julie Ng’s responsive-by-default images, hybrid coding is an effective way for email developers to build campaigns that work well across nearly every popular email client.

<img alt="" src="" width="600" style="display: block; width: 100%; max-width: 100%; min-width: 100px; font-family: sans-serif; color: #000000; font-size: 24px; border="0";" />

Responsive-by-default images with HTML attributes and inline CSS.

More recently, two other methods have emerged that address the issues with mobile email using more advanced techniques. Both Rémi Parmentier’s Fab Four technique and Stig Morten Myre’s mobile-first approach take the concept of mobile-first development so common on the web and apply it to email. Instead of relying on percentage-based fluid tables, both techniques take advantage of the CSS calc function to determine table and table cell widths, allowing for more adaptable emails across a wide range of clients. And, in both cases, developers can largely drop the use of tables in their markup (save for Microsoft ghost tables), creating emails that hew closer to modern web markup.

Moving beyond responsive layouts, email designers are increasingly adding animation and interactivity to their campaigns, creating more engaging experiences for subscribers. Animated GIFs have long been a staple of email design, but CSS animations are becoming more prevalent. Basic transitions and stylistic flourishes like Email Weekly’s heart animation (scroll down) or Nest’s color-shifting background colors are relatively easy to implement, fall back gracefully when not supported, and give email designers more options to surprise and delight their audiences.

Image showing Nest’s keyframe-animation-driven shifting background colors.
Nest’s keyframe-animation-driven shifting background colors. Image courtesy of Nest.

Combined with the checkbox hack and Mark Robbins’s punched card coding, CSS animations allow email developers to create highly interactive experiences for the inbox. While earlier examples of interactivity were reserved for elements like product carousels, people like Robbins and the Rebelmail team have started creating full-blown checkout experiences right in an email.

Image showing the different stages of Rebelmail’s interactive checkout email.
The different stages of Rebelmail’s interactive checkout email. Image courtesy of Rebelmail.

Interactivity doesn’t have to be reserved for viewing retail products, though. At Litmus, animations and interactivity were used to provide a full product tour inside of an email.

Screenshot showing Litmus Buildeer—a code editor built for email design and development.
An interactive product tour in an email. Image courtesy of Litmus.

In this case, interactivity was used to provide product education, allowing users to experience a product before they even got their hands on it. While similar educational effects have been achieved in the past with animated GIFs, the addition of truly interactive elements created an experience that elevated it above similar campaigns.

Finally, the web’s focus on accessibility is cropping up in email, too. Both table-based layouts and inconsistencies in support for semantic elements across email clients have contributed to a near-complete lack of accessibility for email campaigns. Advocates are now speaking out and helping to change the way developers build emails with accessibility in mind.

The use of role=presentation on tables in email is becoming more widespread. By including role=presentation on table elements, screen readers recognize that those tables are used for layout instead of presenting tabular data and skip right to the content of the campaign.

Developers are also embracing semantic elements like proper headings and paragraphs to provide added value for people with visual impairments. So long as you are careful to override default margins on semantic, block-level elements, designers can safely use those elements without worrying about broken layouts. It is now something that every email developer should be doing.

Combined with email’s focus on alternative text—widely used to combat email clients that disable images for security reasons—accessible tables and semantic elements are laying the foundation for more usable, accessible email campaigns. There’s still a huge amount of research and education needed around accessibility in email, but the email world is slowly catching up to that of the web.

All of these techniques, mostly commonplace on the web, are relatively new to the world of HTML email. Somes have been used on a limited scale, but they are on the verge of becoming mainstream. And, while animation and interactivity aren’t appropriate for every email campaign, they are valuable additions to the email toolbox. Taken together, they represent a massive shift in how developers and marketers approach HTML email and are changing the way subscribers think about the humble inbox.

Better tooling

If anything can be considered a constant on the web, it’s that web designers and developers love building tools and frameworks to (in theory) improve their workflows and the reliability of their code. Just like accessibility and interactivity, this focus on tooling and frameworks has been making its way into the email industry over the past few years.

Instead of relying on individual, locally saved, static HTML files, many email developers are now embracing not only GitHub to host and share code, but complete build systems to compile that code, as well. Tools like Grunt and Gulp are now in wider use, as are static site generators like Middleman.

Being able to focus on discrete components means developers no longer have to update multiple HTML files when managing large email programs. For teams in charge of dozens, if not hundreds, of different email templates, this is a godsend. Updating a logo in one place and having it propagate across different campaigns, for example, saves tons of time.

The use of build tools also opens up the possibility of hyperpersonalized campaigns: emails with custom content and custom layouts on a per-subscriber basis. Allowing build systems to handle the compilation of individual modules means that those modules can be pieced together in a virtually unlimited number of ways based on conditions set at the beginning of the build process. This moves personalization in email beyond basic name substitutions and gives email marketers an unbelievably powerful way to connect with subscribers and provide way more value than your typical “batch and blast” campaign.

Likewise, more email developers are relying on preprocessors like Sass and Less to speed up the development workflow. Controlling styles through variables, mixins, and logic can be extremely powerful. While CSS post processors aren’t in wide use, a few savvy email developers are now starting to take advantage of upcoming CSS features in their campaigns.

Email developers and designers working with smaller teams, or those less familiar with advanced tools like preprocessors and build tools, now have a plethora of HTML email templates and frameworks at their disposal. They range in complexity from simple, static HTML files that make customization easy to completely abstracted coding frameworks like MJML and Zurb’s Foundation for Emails 2. Both MJML and Foundation for Emails 2 introduce their own templating languages, allowing email developers to use markup closer to that found on the web, which is then compiled into more complex, table-based HTML.

<mjml>
  <mj-body>
    <mj-container>
      <mj-section>
        <mj-column>
          <mj-text>Hello World!</mj-text>
        </mj-column>
      </mj-section>
    </mj-container>
  </mj-body>
</mjml>

An example of MJML’s templating language, which compiles to table-based markup.

One area that still needs improvement is testing. While tools like Litmus have vastly improved the experience of testing static emails across clients, interactive emails present new challenges. Since testing services currently return static screenshots taken from the inbox, access to devices is crucial for teams working on interactive campaigns. Although a few people are coming up with novel approaches to testing interactive emails (most notably Cyrill Gross’s use of WebKit browsers and clever JavaScript), tooling around interactive email testing will need to improve for more email developers to adopt some of the techniques I describe here.

A seat at the table

Two of the most exciting developments in the email world are the recent Microsoft and Litmus partnership and Gmail’s announcement of support for media queries.

Due to their typically abysmal support for HTML and CSS (especially the box model and floats), the many variations of Outlook have long been the biggest thorn in email developers’ sides. Outlook is the primary reason that emails use tables for layout.

Now, though, for the first time, Microsoft is reaching out to the email community to document bugs and rendering problems in order to guide future development efforts and improve the rendering engines underpinning their email clients. While we’ll still have to rely on tables for the foreseeable future, this is a good indicator that the email community is moving closer to some form of standards, similar to the web in the early 2000s. I don’t think we’ll ever see standards as widely propagated across email clients as they are on the web, but this is the first step toward better HTML and CSS support for email developers.

One likely result of the Microsoft/Litmus partnership is that more email client vendors will open up lines of communication with the email design industry. With any luck, and a lot of work, Microsoft will be the first of many vendors to sit down at the table with email designers, developers, and marketers in order to improve things not only for email professionals, but also for the subscribers we serve. There are already signs that things are getting better beyond Microsoft’s promise to improve.

Gmail, one of the more problematic email clients, recently updated their rendering engine to support display: none;—an unprecedented move from a team that is historically unsympathetic to the concerns of the email community. Email developers were in for an even bigger surprise from the Gmail team when they announced that they will be supporting media queries and embedded styles, too. While the hybrid coding approach mentioned earlier is still useful for addressing some email clients, this change means that it is now easier than ever to apply the principles of responsive web design—fluid grids, fluid images, and media queries—to HTML email campaigns.

Perhaps more interesting is Gmail’s added support for embedded CSS and element, class, and ID selectors. With this one change, embedded styles will be nearly universally supported—meaning that email designers will no longer be bound to inline styles and all the headaches they bring. Emails will now be easier to design, develop, and maintain. The lighter code base and more familiar style of writing CSS means that many of the blockers for web developers taking email seriously will be removed.

Beyond rallying around improved support for HTML and CSS, the email community itself is thriving. I remember the dark days—really only a few years ago—of email design, when it was extraordinarily difficult to find reliable information about how to build email campaigns, let alone connect with others doing the same. Today, people interested in email have a large and growing community to turn to for help. More marketers, designers, and developers are sharing their work and opinions, contributing to a discourse that is helping to shape the industry in new and interesting ways.

Perhaps more importantly, designers and developers are beginning to understand that working with email is a viable career option. Instead of relegating email to one more task as a web dev, many are now taking up the mantle of the full-time email developer.

Now’s the time

Where once there was just darkness and Dreamweaver, the email world is brightening with the light of a growing community, better tools, and amazing techniques to animate a traditionally static medium. And, with the increasing support of email client vendors, we can finally see the flicker of email standards way off on the horizon.

While some folks have expressed emotions ranging from amusement to scorn when discussing email marketing, no one can take it for granted anymore. Subscribers love email, even if you don’t. Email is routinely the most effective digital marketing channel. Companies and teams need to embrace that fact and take email seriously. Fortunately, now’s the perfect time to do that. Never have there been more tools, resources, and people dedicated to making email better.

The revolution in email is bound to be a slow one, but make no mistake: it’s coming. The web is leaking into the inbox. If you can’t keep up, your campaigns (and you) will be left behind.



This week's sponsor: ADOBE XD

ADOBE XD BETA, the only all-in-one solution for designing, prototyping, and sharing experiences for websites and mobile apps.



Awaken the Champion A/B Tester Within

Athletes in every sport monitor and capture data to help them win. They use cameras, sensors, and wearables to optimize their caloric intake, training regimens, and athletic performance, using data and exploratory thinking to refine every advantage possible. It may not be an Olympic event (yet!), but A/B testing can be dominated the same way.

I talked to a website owner recently who loves the “always be testing” philosophy. He explained that he instructs his teams to always test something—the message, the design, the layout, the offer, the CTA.

I asked, “But how do they know what to pick?” He thought about it and responded, “They don’t.”

Relying on intuition, experienced as your team may be, will only get you so far. To “always test something” can be a great philosophy, but testing for the sake of testing is often a massive waste of resources—as is A/B testing without significant thought and preparation. 

Where standard A/B testing can answer questions like “Which version converts better?” A/B testing combined with advanced analyses gives you something more important—a framework to answer questions like “Why did the winning version convert better?”

Changing athletes, or a waste of resources?

Typical A/B testing is based on algorithms that are powered by data during the test, but we started trying a different model on our projects here at Clicktale, putting heavy emphasis on data before, during, and after the test. The results have been more interesting and strategic, not just tactical.

Let’s imagine that Wheaties.org wants to reduce bounce rate and increase Buy Now clicks. Time for an A/B test, right?

The site’s UX lead gets an idea to split test their current site, comparing versions with current athletes to versions featuring former Olympians.

Wheaties Page Design
Wheaties page design.

But what if your team monitored in-page visitor behavior and saw that an overwhelming majority of site visitors do not scroll below the fold to even notice the athletes featured there?

Now the idea of testing the different athlete variants sounds like a waste of time and resources, right?

But something happens when you take a different vantage point. What if your team watched session replays and noticed that those who do visit the athlete profiles tend to stay on the site longer and increase the rate of “Buy Now” clicks exponentially? That may be a subset of site visitors, but it’s a subset that’s working how you want.

If the desired outcome is to leverage the great experiences built into the pages, perhaps it would be wise to bring the athlete profiles higher. Or to A/B test elements that should encourage users to scroll down.

In our experience, both with A/B testing our own web properties and in aggregating the data of the 100 billion in-screen behaviors we’ve tracked, we know this to be true: testing should be powerful, focused, and actionable. In making business decisions, it helps when you’re able to see visual and conclusive evidence.

Imagine a marathon runner who doesn’t pay attention to other competitors once the race begins. Now, think about one who paces herself, watches the other racers, and modifies her cadence accordingly.

By doing something similar, your team can be agile in making changes and fixing bugs. Each time your team makes an adjustment, you can start another A/B test ... which lets you improve the customer experience faster than if you had to wait days for the first A/B test to be completed.

The race is on

Once an A/B test is underway, the machines use data-based algorithms to determine a winner. Based on traffic, conversion rate, number of variations, and the minimum improvement you want to detect, the finish line may be days or weeks away. What is an ambitious A/B tester to do?

Watch session replay of each variation immediately, once you’ve received a representative number of visitors. Use them to validate funnels and quickly be alert to any customer experience issues that may cause your funnels to leak.

Focus on the experience. Understanding which user behavior dominates each page is powerful, internalizing why users are behaving as they are enables you to take corrective actions mid-course and position yourself properly.

The next test

In your post-test assessments, again use data to understand why the winning variation succeeded with its target audience. Understanding the reason can help you prioritize future elements to test.

For example, when testing a control with a promotional banner (that should increase conversions) against a variation without a promotion, a PM may conclude that the promotion is ineffective when that variation loses.

Studying a heatmap of the test can reveal new insights. In this example, conversions were reduced because the banner pushed the “buy now” CTA out of sight.

Example of A/B testing on mobile devices
Example of A/B testing on mobile devices.

In this case, as a next test, the PM may decide not to remove the banner, but rather to test it in a way that keeps the more important “buy now” CTA visible. There is a good chance such a combination will yield even better results.

There are plenty of other examples of this, too. For instance, the web insights manager at a credit card company told me that having the aggregate data, in the form of heatmaps, helps him continually make more informed decisions about this A/B testing. In their case, they were able to rely on data that indicated they could remove a content panel without hurting their KPIs.

Another one of our customers, GoDaddy, was able to increase conversions on its checkout page by four percent after running an A/B test. “With our volume, that was a huge, huge increase…. We also tripled our donations to Round Up for Charity,” said Ana Grace, GoDaddy’s director of ecommerce, global product management. But the optimization doesn’t stop once a test is complete; GoDaddy continues to monitor new pages after changes, and sometimes finds additional hypotheses that require testing.

What it takes to go for the gold

I was not blessed with the natural athletic ability of an Olympian, but when it comes to A/B testing web assets and mobile apps, I have what I need to determine which version will be the winner. The powerful combination of behavioral analytics and big data gives athletes the knowledge they need to make the most of their assets, and it can do the same for you.



Let Emotion Be Your Guide

We were sitting in a market research room in the midst of a long day of customer interviews. Across from us, a young mother was telling us about her experience bringing her daughter into the ER during a severe asthma attack. We had been interviewing people about their healthcare journeys for a large hospital group, but we’d been running into a few problems.

First, the end-goal of the interviews was to develop a strategy for the hospital group’s website. But what we’d discovered, within the first morning of interviews aimed at creating a customer journey map, was that hospital websites were part of no one’s journey. This wasn’t wildly surprising to us—in fact it was part of the reason we’d recommended doing customer journey mapping in the first place. The hospital had a lot of disease content on their site, and we wanted to see whether people ever thought to access that content in the course of researching a condition. The answer had been a resounding no. Some people said things like, “Hmm, I’d never think to go to a hospital website. That’s an interesting idea.” Others didn’t even know that hospitals had websites. And even though we’d anticipated this response, the overwhelming consistency on this point was starting to freak out our client a little—in particular it started to freak out the person whose job it was to redesign the site.

The second issue was that our interviews were falling a little flat. People were answering our questions but there was no passion behind their responses, which made it difficult to determine where their interactions with the hospital fell short of expectations. Some of this was to be expected. Not every customer journey is a thrill ride, after all. Some people’s stories were about mundane conditions. I had this weird thing on my hand, and my wife was bugging me to get it checked out, so I did. The doctor gave me cream, and it went away, was one story. Another was from someone with strep throat. We didn’t expect much excitement from a story about strep throat, and we didn’t get it. But mixed in with the mundane experiences were people who had chronic conditions, or were caregivers for children, spouses, or parents with debilitating diseases, or people who had been diagnosed with cancer. And these people had been fairly flat as well.

We were struggling with two problems that we needed to solve simultaneously. First: what to do with the three remaining days of interviews we had lined up, when we’d already discovered on the morning of day one that no one went to hospital websites. And second: how to get information that our client could really use. We thought that if we could just dig a little deeper underneath people’s individual stories, we could produce something truly meaningful for not only our client, but the people sitting with us in the interview rooms.

We’d been following the standard protocol for journey mapping: prompting users to tell us about a specific healthcare experience they’d had recently, and then asking them at each step what they did, how they were feeling and what they were thinking. But the young mother telling us about her daughter’s chronic asthma made us change our approach.

“How were you feeling when you got to the ER?” we asked.

“I was terrified,” she said. “I thought my daughter was going to die.” And then, she began to cry. As user experience professionals we’re constantly reminding ourselves that we are not our users; but we are both parents and in that moment, we knew exactly what the woman in front of us meant. The entire chemistry of the room shifted. The interview subject in front of us was no longer an interview subject. She was a mother telling us about the worst day of her entire life. We all grabbed for the tissue box, and the three of us dabbed at our eyes together.

And from that point on, she didn’t just tell us her story as though we were three people sitting in front of a two-way mirror.  She told us her story the way she might tell her best friend.

We realized, in that interview, that this was not just another project. We’ve both had long careers in user research and user experience, but we’d never worked on a project that involved the worst day of people’s lives. There might be emotion involved in using a frustrating tool at work or shopping for the perfect gift, but nothing compares to the day you find yourself rushing to the emergency room with your child.

So we decided to throw out the focus on the hospital website, concentrate on where emotion was taking us, and trust that we would be able to reconcile our findings with our client’s needs. We, as human beings, wanted to hear other human beings tell us about the difficulties of caring for a mother with Alzheimer’s disease. We wanted to know what it felt like to receive a cancer diagnosis after a long journey to many doctors across a spectrum of specialties. We wanted to understand what we could do, in any small way, to help make these Worst Days minutely less horrible, less terrifying, and less out-of-control. We knew that the client was behind the two-way mirror, concerned about the website navigation, but we also knew that we were going to get to someplace much more important and meaningful by following wherever these stories took us.

We also realized that not all customer journeys are equal. We still wanted to understand what people’s journeys with strep throat and weird hand rashes looked like, because those were important too. Those journeys told us about the routine issues that we all experience whenever we come into contact with the medical establishment—the frustration of waiting endlessly at urgent care, the annoyance of finding someone who can see you at a time when you can take off from work, the importance of a doctor who listens. But we also wanted to get to the impassioned stories where the stakes and emotions were much higher, so we adjusted our questioning style accordingly. We stuck to our standard protocol for the routine medical stories. And for the high-stakes journeys, the ones that could leave us near tears or taking deep breaths at the end of the interview, we proceeded more slowly. We gave our interview subjects room to pause, sigh, and cry. We let there be silence in the room. We tried to make it not feel weird for people to share their most painful moments with two strangers.

When we completed our interviews at the end of the week, we had an incredibly rich number of stories to draw from—so many, in fact, that we were able to craft a digital strategy that went far beyond what the hospital website would do. (Website? We kept saying to ourselves. Who cares about the website?) We realized that in many ways, we were limiting ourselves by thinking about a website strategy, or even a digital strategy. By connecting with the emotional content of the conversations, we started to think about a customer strategy—one that would be medium-agnostic.

In Designing for Emotion, Aarron Walter encourages us to “think of our designs not as a façade for interaction, but as people with whom our audience can have an inspired conversation.” As we moved into making strategic recommendations, we thought a lot about how the hospital (like most hospitals) interacted with their patients as a bureaucratic, depersonalized entity. It was as though patients were spilling over with a hundred different needs, and the hospital group was simply silent. We also thought about what a helpful human would do at various stages of the journey, and found that there were multiple points where pushing information out to customers could make a world of difference.

We heard from people diagnosed with cancer who said, “After I heard the word ‘cancer’ I didn’t hear anything else, so then I went home and Googled it and completely panicked.” So we recommended that the day after someone gets a devastating diagnosis like that, there is a follow-up email with more information, reliable information resources, and videos of other people who experienced the same thing and what it was like for them.

We heard from people who spent the entire day waiting for their loved ones to get out of surgery, not knowing how much longer it would take, and worried that if they stepped out for a coffee, they would miss the crucial announcement over the loudspeaker. As a result, we proposed that relatives receive text message updates such as, “Your daughter is just starting her surgery. We expect that it will take about an hour and a half. We will text you again when she is moved to the recovery room.”

The stories were so strong that we believed they would help our client refocus their attention away from the website and toward the million other touchpoints and opportunities we saw to help make the worst day of people’s lives a little less horrible.

And for the most part, that is what happened. We picked a few journeys that we thought provided a window on the range of stories we’d been hearing. As we talked through some of the more heart-rending journeys there were audible gasps in the room: the story of a doctor who had refused to see a patient after she’d brought in her own research on her daughter’s condition; a woman with a worsening disease who had visited multiple doctors to try to get a diagnosis; a man who was caring for his mother-in-law, who was so debilitated by Alzheimer’s that she routinely tried to climb out the second floor bedroom window.

In Design for Real Life, Sarah Wachter-Boettcher and Eric Meyer note that “the more users have opened up to you in the research phase” the more realistic your personas can be. More realistic personas, in turn, make it easier to imagine crisis points. And this was exactly what began to unfold as we shared our user journeys. As we told these stories, we felt a shift in the room. The clients started to share their own unforgettable healthcare experiences. One woman pulled out her phone and showed us pictures of her tiny premature infant, wearing her husband’s wedding ring around her wrist as she lay there in an incubator, surrounded by tubes and wires. When we took a break we overheard a number of people on the client side talking over the details of these stories and coming up with ideas for how they could help that went so beyond the hospital website it was hard to believe that had been our starting point. One person pointed out that a number of journeys started in Urgent Care and suggested that perhaps the company should look at expanding into urgent care facilities.

In the end, the research changed the company’s approach to the site.

“We talked about the stories throughout the course of the project,” one of our client contacts told me. “There was so much raw humanity to them.” A year after the project wrapped up (even though due to organizational changes at the hospital group our strategy recommendations have yet to be implemented), our client quickly rattled off the names of a few of our customer types. It is worth noting, too, that while our recommendations went much farther than the original scope of the project, the client appreciated being able to make informed strategic decisions about the path forward. Their immediate need was a revamped website, but once they understood that this need paled in comparison to all of the other places they could have an impact on their customers’ lives, they began talking excitedly about how to make this vision a reality down the road.

For us, this project changed the way we conceptualize projects, and illustrated that the framework of a website strategy or even “digital” strategy isn’t always meaningful. Because as the digital world increasingly melds with the IRL world, as customers spend their days shifting between websites, apps, texting, and face-to-face interactions, it becomes increasingly important for designers and researchers to drop the distinctions we’ve drawn around where an interaction happens, or where emotion spikes.

Before jumping in however, it is important to prep the team about how, and most importantly, why your interview questions probe into how customers are feeling. When you get into the interview room, coaxing out these emotional stories requires establishing emotional rapport quickly, and making it a safe place for participants to express themselves.

Being able to establish this rapport has changed our approach to other projects as well—we’ve seen that emotion can play into customer journeys in the unlikeliest of places. On a recent project for a client who sells enterprise software, we interviewed a customer who had recently gone through a system upgrade experience which affected tens of thousands of users. It did not go well and he was shaken by the experience. “The pressure on our team was incredible. I am never doing that ever again,” he said. Even for this highly technical product, fear, frustration, anger, and trust were significant elements of the customer journey. This is a journey where a customer has ten thousand people angry at him if the product he bought does not perform well, and he could even be out of a job if it gets bad enough. So while the enterprise software industry doesn’t exactly scream “worst day of my life” in the same way that hospitals do, emotion can run high there as well.

We sometimes forget that customers are human beings and human beings are driven by emotion, especially during critical life events. Prior to walking into the interview room we’d thought we might unearth some hidden problems around parking at the ER, navigating the hospital, and, of course, issues with the website content. But those issues were so eclipsed by all of the emotions surrounding a hospital visit that they came to seem irrelevant. Not being able to find parking at the ER is annoying, but more important was not knowing what you were supposed to do next because you’d just been told you have cancer, or because you feared for your child’s life. By digging deeper into this core insight, we were able to provide recommendations that went beyond websites, and instead took the entire human experience into account.

For researchers and designers tasked with improving experiences, it is essential to have an understanding of the customer journey in its full, messy, emotional agglomeration. Regardless of the touchpoint your customer is interacting with, the emotional ride is often what ties it all together, particularly in high-stakes subject matter. Are your client’s customers likely to be frustrated, or are they likely to be having the worst day of their lives? In the latter types of situations, recognize that you will get much more impactful insights when you address the emotions head-on.

And when appropriate, don’t be afraid to cry.



Liminal Thinking

A note from the editors: We’re pleased to share an excerpt from Practice 4 of Dave Gray's new book, Liminal Thinking, available now from Two Waves Books. Use code ALA-LT for 20% off!

A theory that explains everything, explains nothing
Karl Popper

Here’s a story I heard from a friend of mine named Adrian Howard. His team was working on a software project, and they were working so hard that they were burning themselves out. They were working late nights, and they agreed as a team to slow down their pace. “We’re going to work 9 to 5, and we’re going to get as much done as we can, but we’re not going to stay late. We’re not going to work late at night. We’re going to pace ourselves. Slow and steady wins the race.”

Well, there was one guy on the team who just didn’t do that. He was staying late at night, and Adrian was getting quite frustrated by that. Adrian had a theory about what was going on. What seemed obvious to him was that this guy was being macho, trying to prove himself, trying to outdo all the other coders, and showing them that he was a tough guy. Everything that Adrian could observe about this guy confirmed that belief.

Late one night, Adrian was so frustrated that he went over and confronted the guy about the issue. He expected a confrontation, but to his surprise, the guy broke down in tears. Adrian discovered that this guy was not working late because he was trying to prove something, but because home wasn’t a safe place for him. They were able to achieve a breakthrough, but it was only possible because Adrian went up and talked to him. Without that conversation, there wouldn’t have been a breakthrough.

It’s easy to make up theories about why people do what they do, but those theories are often wrong, even when they can consistently and reliably predict what someone will do.

For example, think about your horoscope. Horoscopes make predictions all the time:

  • “Prepare yourself for a learning experience about leaping to conclusions.”
  • “You may find the atmosphere today a bit oppressive.”
  • “Today, what seems like an innocent conversation will hold an entirely different connotation for one of the other people involved.”
  • “Stand up to the people who usually intimidate you. Today, they will be no match for you.”

These predictions are so vague that you can read anything you want into them. They are practically self-fulfilling prophecies: if you believe them, they are almost guaranteed to come true, because you will set your expectations and act in ways that make them come true. And in any case, they can never be disproven.

So what makes a good theory, anyway?

A scientist and philosopher named Karl Popper spent a lot of time thinking about this. Here’s the test he came up with, and I think it’s a good one: Does the theory make a prediction that might not come true? That is, can it be proven false?

What makes this a good test? Popper noted that it’s relatively easy to develop a theory that offers predictions—like a horoscope—that can never be disproven.

The test of a good theory, he said, is not that it can’t be disproven, but that it can be disproven.

For example, if I have a theory that you are now surrounded by invisible, undetectable, flying elephants, well, there’s no way you can prove me wrong. But if my theory can be subjected to some kind of test—if it is possible that it could be disproved, then the theory can be tested.

He called this trait falsifiability: the possibility that a theory could be proven false.

Many theories people have about other people are like horoscopes. They are not falsifiable theories, but self-fulfilling prophecies that can never be disproven.

Just because you can predict someone’s behavior does not validate your theories about them, any more than a horoscope prediction “coming true” means it was a valid prediction. If you want to understand what’s going on inside someone else’s head, sometimes you need to have a conversation with them.

Many years after the Vietnam War, former U.S. Secretary of State Robert McNamara met with Nguyen Co Thach, former Foreign Minister of Vietnam, who had fought for the Viet Cong in the war. McNamara had formed the hypothesis that the war could have been avoided, that Vietnam and the United States could have both achieved their objectives without the terrible loss of life. When he presented his thinking to Thach, Thach said, “You’re totally wrong. We were fighting for our independence. You were fighting to enslave us.”

“But what did you accomplish?” asked McNamara. “You didn’t get any more than we were willing to give you at the beginning of the war. You could have had the whole damn thing: independence, unification.”

“Mr. McNamara,” answered Thach. “You must have never read a history book. If you had, you’d know that we weren’t pawns of the Chinese or the Russians. Don’t you understand that we have been fighting the Chinese for a thousand years? We were fighting for our independence. And we would fight to the last man. And we were determined to do so. And no amount of bombing, no amount of U.S. pressure would ever have stopped us.”

McNamara then realized that the entire war had been based on a complete misunderstanding. He said: “In the case of Vietnam, we didn’t know them well enough to empathize. And there was total misunderstanding as a result. They believed that we had simply replaced the French as a colonial power, and we were seeking to subject South and North Vietnam to our colonial interests, which was absolutely absurd. And we saw Vietnam as an element of the Cold War. Not what they saw it as: a civil war.”

Sometimes people come into conflict not because they disagree, but because they fundamentally misunderstand each other. This can happen when people are viewing a situation from completely different points of view.

Have you ever had someone that you worked with, where you thought, this person is insane; they make no sense; they are crazy; they’re just nuts?

Everyone knows someone like that, right?

Sometimes people really do have mental disorders, including problems that can create danger for themselves and others. If that’s the case, it might make sense to stay away from them, or to seek help from a mental health professional.

But far more often, saying another person is crazy is just a way to create internal coherence within your belief bubble. Your “obvious” is stopping you from seeing clearly. The “crazy person” may be acting based on beliefs that are inconceivable to you because they are outside your bubble.

If you think to yourself, this person is just nuts, and nothing can be done about it, it can’t be changed, then it’s possible that your theory about that person is constrained by a limiting belief.

Most people don’t test their theories about other people, because it’s a potential bubble-buster: if you give your self-sealing logic bubble a true test, then it just might collapse on you.

People do fake tests all the time, of course.

Here’s an easy way to do a fake test of your beliefs. Just search the Internet. No matter what your belief is, you’ll find plenty of articles that support and reinforce your bubble. The Internet is like a grocery store for facts. It’s easier than ever to find “facts” that support pretty much any belief.

Fake tests will help if your goal is to feel better about yourself and reinforce your bubble. But if you want to figure out what is really going on, a fake test will not help.

What will help is triangulation: the practice of developing multiple viewpoints and theories that you can compare, contrast, combine, and validate, to get a better understanding of what’s going on.

U.S. military strategist Roy Adams told me this story about an “aha” moment he had in Iraq.

He was having a beer with a friend who was in the Special Forces. Usually, they didn’t talk about work, but he happened to have a map with him. At the time, Adams and his team were designing their plans based on the political boundaries of the map, so on the map were districts, as well as the people who were in charge of the districts.

His friend said, “You know, this is really interesting.” And he picked up a pen and said, “Let me draw the tribal boundaries on this map for you.” The boundaries were completely different but overlapping. Suddenly, Adams had two different versions of reality on his map.

The political map was primarily a Shia map, and the tribal map had both Sunni and Shia. Only by overlaying the two maps did Adams start to understand the situation. Neither map would have made sense by itself.

By laying these maps over each other, suddenly things started to click. Now he understood why they were having success in some places and meeting resistance in others. Everything started to make more sense.

The insights in this case came not from one map or another, but through overlaying them. This is the practice of triangulation. Each map represented one theory of the world, one version of reality. It was only by viewing the situation through multiple perspectives—multiple theories—that he was able to gain insight and see the situation differently. (Fig. 1)

Illustration of two people holding rectangles and identifying where they overlap
Fig 1: Look for alternatives.

My friend Adrian Howard told me about a similar experience he had when working at a large Telecom company that had grown by acquiring other companies over many years. His team found itself running up against resistance and pushback that seemed odd and inexplicable. Then someone on the team took some markers and color-coded the boxes on the org chart based on which companies the people in each box had originally come from—many of whom used to be fierce competitors—and suddenly the reasons for the resistance became clear and understandable.

For any one observation there may be a vast number of possible explanations. Many of them may be based on beliefs that are outside of your current belief bubble, in which case, they may seem strange, absurd, crazy, or just plain wrong.

Most of the time we are all walking around with our heads so full of “obvious” that we can’t see what’s really going on. If you think something is obvious, that’s an idea that bears closer examination. Why do you think it’s obvious? What personal experiences have you had that led to that belief? Can you imagine a different set of experiences that might lead to a different belief?

Cultivate as many theories as you can—including some that seem odd, counter-intuitive, or even mutually contradictory—and hold onto them loosely. Don’t get too attached to any one of them. (Fig. 2)

An illustration of a person holding the strings of three large balloons
Fig 2: Hold your theories loosely.

Then you can start asking questions and seeking valid information to help you understand what’s really going on. The way to seek understanding is to empty your cup, step up and give people your full attention, suspend your beliefs and judgments, and listen carefully.

The thing to remember is that people act in ways that make sense to them. If something doesn’t make sense to you, then you’re missing something.

What are you missing? If someone says something that seems odd or unbelievable, ask yourself, “What would I need to believe for that to be true?”

In many cases, the only way you’re ever going to understand what’s inside someone else’s head is by talking to them. Sometimes that idea might seem scary. It may be that you will hear something that threatens your bubble of belief. But if you can get over your fear, go and talk to the dragon, or take the ogre out for coffee. You just may learn something that will change your life.

Practice exercises

Triangulate and validate. Look at situations from as many points of view as possible. Consider the possibility that seemingly different or contradictory beliefs may be valid. If something doesn’t make sense to you, then you’re missing something.

Exercise #1

Think about a co-worker or family member, someone you care about, or can’t walk away from for whatever reason, that you have trouble getting along with. Consider their beliefs and behavior, and come up with as many theories as you can to explain why they act the way they do. Then see if you can have a conversation with that person to explore what’s really going on.

Exercise #2

Think of a situation at home or work that you find problematic. Try to come up with as many perspectives as you can that might give you a different way to look at the situation. What is your current theory? What is its opposite? How many perspectives or points of view can you think of that might help you see that situation through different eyes?

Want to read more?

Get 20% off your copy of Liminal Thinking and other titles from Two Waves Books—an imprint of Rosenfeld Media—with code ALA-LT.

Cover of Liminal Thinking


Network Access: Finding and Working with Creative Communities

A curious complaint seems to ripple across the internet every so often: people state that “design” is stale. The criticism is that no original ideas are being generated; anything new is quickly co-opted and copied en-masse, leading to even more sterility, conceptually. And that leads to lots of articles lamenting the state of the communities they work in.

What people see is an endless recycling within their group, with very little bleed-over into other disciplines or networks. Too often, we speak about our design communities and networks as resources to be used, not as groups of people.

Anthony McCann describes the two main ways we view creative networks and the digital commons:

We have these two ways of speaking: commons as a pool of resources to be managed, and commons as an alternative to treating the world as made up of resources.

One view is that communities are essentially pools of user-generated content. That freely available content is there to be mined—the best ideas extracted and repackaged for profit or future projects. This is idea as commodity, and it very conveniently strips out the people doing the creating, instead looking at their conceptual and design work as a resource.

Another way is to view creative networks as interdependent networks of people. By nature, they cannot be resources, and any work put into the community is to sustain and nourish those human connections, not create assets. The focus is on contributing.

A wider view

By looking at your design communities as resources to be mined, you limit yourself to preset, habitual methods of sharing and usage. The more that network content is packaged for sale and distribution, the less “fresh” it will be. In Dougland Hine’s essay Friendship is a Commons, he says when we talk enthusiastically about the digital commons these days, we too often use the language of resource management, not the language of social relations.

Perhaps we should take a wider, more global view.

There are numerous digital design communities across the world; they are fluid and fresh, and operate according to distinct and complex social rules and mores. These designers are actively addressing problems in their own communities in original ways, and the result is unique, culturally relevant work. By joining and interacting with them—by accessing these networks—we can rethink what the design community is today.

Exploring larger communities

There are a number of creative communities I’ve become a part of, to varying degrees of attention. I’ve been a member of Behance for almost 10 years (Fig. 1), back when it was something very different (“We are pleased to invite you to join the Behance Network, in partnership with MTV”).

Screenshot of an old Behance Network page
Fig. 1: Screenshot of the Behance creative community website in 2009. Source: belladonna

While I lived in Japan, Behance was a way for me to learn new digital design techniques and participate in a Western-focused, largely English speaking design network. As time has gone on, it’s strange that I now use it almost exclusively to see what is happening outside the West.

Instagram, Twitter, and Ello are three mobile platforms with a number of features that are great for collecting visual ideas without the necessity of always participating. The algorithms are focused on showing more of what I have seen—the more often I view work from Asian and African designers and illustrators, the more often I discover new work from those communities. While interesting for me, it does create filter bubbles, and I need to be careful of falling into the trap of seeing more of the same.

There is, of course, a counter-reaction to the public, extractive nature of these platforms—the rise of “Slack as community.” The joke about belonging to 5-10 different Slack groups is getting old, but illustrates a trend in the industry during the past year or so. I see this especially with designers of color, where the firehoses of racist/sexist abuse on open digital networks means that creativity is shelved in favor of simple preservation. Instead, we move, quietly and deliberately, to Slack, a platform that is explicit in its embrace of a diverse usership, where the access is much more tightly controlled, and where the empathy in design/dev networks is more readily shared and nurtured.

Right now, these are the creative platforms where I contribute my visual thinking, work, and conversations toward addressing messy visual questions—interactive ideas that assume a radically different way of viewing the world. There are, of course, others.

Exploring visual design alternatives

In Volume II of Mawahib (a series of books that showcase Arab illustrators, photographers, and graphic designers), we see one of these design communities compiled and printed, an offline record of a thriving visual network (Fig. 2).

Photograph of printed book interior and cover
Fig. 2: Page spreads from the Mawahib book, showcasing Arab illustration and design work

And perhaps it is in the banding together that real creative change can happen. I was fascinated to read this article about an illustration collective in Singapore. At 7 years old, it’s reportedly the longest running drawing event in Singapore. Michael Ng says, “Many people don’t know illustrators like us exist in Singapore and they’re amazed. Companies have also come up to hire us for work because of the event. We also network amongst ourselves, passing on opportunities and collaborations.” Comments like this show that there are thriving visual design scenes worldwide, ones that collaborate internally, and work for exposure and monetary gain externally.

Illustrated poster promoting an event
Fig. 3: Poster from the Organisation of Illustrators Council in Singapore, advertising one of their collaborative sketching nights

UX research that builds community

Earlier in this article, we started by looking at the different ways people view existing creative communities. But what about people who create new ones? Here, once again, we have designers and strategists who use careful cultural research to create and develop sustainable digital networks, not simply resource libraries.

First, let’s look at the pilot of My Voice, an open source medical tool developed at Reboot. The residents of Wamba, a rural area in Nasarawa State, Nigeria, struggled to find a way to communicate with their healthcare providers. Reboot saw an opportunity to develop an empowering, responsive platform for the community, a way for people to share feedback with clinics and doctors in the area.

After a nine-week trial of the platform and software, the residents of Wamba saw the clinics begin making small changes to how they communicated—things like better payment info and hours of operation. The health department officials in the area also saw a chance to better monitor their clinics and appear more responsive to their constituents. What began as a way to report on clinic status and quality became a way for the community and local government to improve together.

Photo of two people facing one another; one is a woman wearing a black headwrap and a red sweater
Fig. 4: Interviews with community residents for the MyVoice medical app

In another project, a group of researchers worked with a community in South Africa’s Eastern Cape to design and test mobile digital storytelling. Their experience creating a storytelling platform that did not follow European narrative tradition is enlightening, and hits on a key framing in line with how the people in Ndungunyeni view creative networks (Fig. 4).

Contrary to their initial ideas, the UX researchers found that storytelling ”...as an individual activity is discordant with villagers’ proximity, shared use of phones and communication norms. They devote significant time exchanging views in meetings and these protocols of speaking and listening contribute to cohesion, shared identity and security.”

Image of two planning documents presenting an arrangement of photos and digital media viewing device controls, with lines pointing to various photos and device control icons on one end, and to paragraphs of text on the other
Fig 5: Mobile digital storytelling prototype (left) and story recording UI (right)

In both of these examples, we see new creative networks relying on linked social systems and cues in order to thrive. Most importantly, they rely on reciprocation—the trade of ideas, whether there is immediate personal benefit or not. Each of the participants—the community members, the UX designers, the clinics, and the local government— was able to collaborate on a common goal. Simply-crafted technology and UX made this possible, even in rural areas with little cellular connectivity. They all contributed, not looking to extract value, but to add it; they used these networking tools to deepen their interactions with others.

Building alternatives to current networks

Almost every project we work on as designers would certainly benefit from alternative viewpoints. That can be hard to set up, however, and collaborating with designers and developers outside your immediate circle may seem scary at first. Keep in mind that the goal is to add value to others’ networks and build interpersonal connections. This is the only way that we keep the creative ideas fresh.

Starting with freelance and project work

Sometimes the simplest way to access different creative circles is simply to pay for project work.  A great example is Karabo Moletsane’s project for Quartz Africa. An accomplished illustrator from South Africa, Moletsane recently did a set of 32 wonderful portraits for the Quartz Africa Innovators 2016 Series (Fig. 6). When I asked Moletsane about how she got the illustration job, she said it came via her work on AfricanDigitalArt.com. Moletsane also said she regularly posts work on her Instagram and Behance, making Quartz’s choice to work with this talented South African for a global series on African innovators a no-brainer.

A combined graphic. On the left is a piece of contemporary artwork depicting the portrait of a woman. On the right is a piece displaying 32 portraits in a similar style, arranged in rows and columns.
Fig. 6: Karabo Moletsane’s full series of 32 African Innovators, for Quartz Magazine

Hiring and team-building from different networks

Sometimes, shorter freelance projects won’t give you long-term quality access to new design communities and ideas. Sometimes you need to bring people onto your team, full-time. Again, I point out what Dougland Hine says regarding the ways digital communities can work:

...people have had powerful experiences of what it means to come together, work and build communities [but] the new forms of collaboration easily turn into new forms of exploitation…

Instead of looking for short-term access, hiring and developing team members from other networks can be a powerful alternative. Tyler Kessler, the CEO of Lumogram in St. Louis, recently wrote about hiring a new head of development based in Nigeria, and what it has meant to his company. He used Andela, a startup that is training and hiring out a new generation of developers from Nigeria.

Collaboration around specific Ideas

Your contributions to networks also need not be permanent or rigid. There are numerous opportunities to join collectives, or working groups, that build more ephemeral networks around specific issues. One such project, by the DESIS Cluster Collective (pdf), was set up “to investigate which new services, tools, and solutions we can design together with the elderly, when thinking about our future society.” The breadth of ideas is astounding, from systems for healthier eating, to mini-parks within urban areas for seniors to hang out in. Each team involved contributed deep user research, information design, and cultural cues to propose new ways for our elderly to coexist (Fig. 7).

Combined image depicting a young woman and an elderly woman sitting at a table, several arms leaning on top of a large map, and a series of four stick-figure illustrations featuring people addressing environmental and situational challenges.
Fig. 7: Cultural interface research with the elderly, conducted by the Royal College of Art, England in 2013

The form and utility of design communities in the 21st century is fluid, and goes from groups of like-minded designers and illustrators to communities working digitally to solve specific problems. Even short-term collectives are addressing social issues.

All are intricate groups of creative humans. They shouldn’t be viewed, in any way, as “resources” for extraction and inspiration. Too often in the Western design world, we hear that ideas have largely plateaued and become homogenous, but that ignores the amazing work flourishing in other nations and pockets of the internet. How you build connections among other creative people makes you part of the network. See them, however ephemeral and globally distributed, as a powerful way to expand your design horizons and be part of something different.

 



This week's sponsor: INDEED PRIME

INDEED PRIME, the job search platform for top tech talent. Apply to 100 top tech companies with 1 simple application.



JavaScript for Web Designers: DOM Scripting

A note from the editors: We’re pleased to share an excerpt from Chapter 5 of Mat Marquis' new book, JavaScript for Web Designers, available now from A Book Apart.

Before we do anything with a page, you and I need to have a talk about something very important: the Document Object Model. There are two purposes to the DOM: providing JavaScript with a map of all the elements on our page, and providing us with a set of methods for accessing those elements, their attributes, and their contents.

The “object” part of Document Object Model should make a lot more sense now than it did the first time the DOM came up, though: the DOM is a representation of a web page in the form of an object, made up of properties that represent each of the document’s child elements and subproperties representing each of those elements’ child elements, and so on. It’s objects all the way down.

window: The Global Context

Everything we do with JavaScript falls within the scope of a single object: window. The window object represents, predictably enough, the entire browser window. It contains the entire DOM, as well as—and this is the tricky part—the whole of JavaScript.

When we first talked about variable scope, we touched on the concept of there being “global” and “local” scopes, meaning that a variable could be made available either to every part of our scripts or to their enclosing function alone.

The window object is that global scope. All of the functions and methods built into JavaScript are built off of the window object. We don’t have to reference window constantly, of course, or you would’ve seen a lot of it before now—since window is the global scope, JavaScript checks window for any variables we haven’t defined ourselves. In fact, the console object that you’ve hopefully come to know and love is a method of the window object:

window.console.log
function log() { [native code] }

It’s hard to visualize globally vs. locally scoped variables before knowing about window, but much easier after: when we introduce a variable to the global scope, we’re making it a property of window—and since we don’t explicitly have to reference window whenever we’re accessing one of its properties or methods, we can call that variable anywhere in our scripts by just using its identifier. When we access an identifier, what we’re really doing is this:

function ourFunction() {
    var localVar = "I’m local.";
    globalVar = "I’m global.";

    return "I’m global too!";
};
undefined

window.ourFunction();
I’m global too!

window.localVar;
undefined

window.globalVar;
I’m global.

The DOM’s entire representation of the page is a property of window: specifically, window.document. Just entering window.document in your developer console will return all of the markup on the current page in one enormous string, which isn’t particularly useful—but everything on the page can be accessed as subproperties of window.document the exact same way. Remember that we don’t need to specify window in order to access its document property—window is the only game in town, after all.

document.head
<head>...</head>

document.body
<body>...</body>

Those two properties are themselves objects that contain properties that are objects, and so on down the chain. (“Everything is an object, kinda.”)

Using the DOM

The objects in window.document make up JavaScript’s map of the document, but it isn’t terribly useful for us—at least, not when we’re trying to access DOM nodes the way we’d access any other object. Winding our way through the document object manually would be a huge headache for us, and that means our scripts would completely fall apart as soon as any markup changed.

But window.document isn’t just a representation of the page; it also provides us with a smarter API for accessing that information. For instance, if we want to find every p element on a page, we don’t have to write out a string of property keys—we use a helper method built into document that gathers them all into an array-like list for us. Open up any site you want—so long as it likely has a paragraph element or two in it—and try this out in your console:

document.getElementsByTagName( "p" );
[<p>...</p>, <p>...</p>, <p>...</p>, <p>...</p>]

Since we’re dealing with such familiar data types, we already have some idea how to work with them:

var paragraphs = document.getElementsByTagName( "p" );
undefined

paragraphs.length
4

paragraphs[ 0 ];
<p>...</p>

But DOM methods don’t give us arrays, strictly speaking. Methods like getElementsByTagName return “node lists,” which behave a lot like arrays. Each item in a nodeList refers to an individual node in the DOM—like a p or a div—and will come with a number of DOM-specific methods built in. For example, the innerHTML method will return any markup a node contains—elements, text, and so on—as a string:

var paragraphs = document.getElementsByTagName( "p" ),
    lastIndex = paragraphs.length – 1, /* Use the length of the `paragraphs` node list minus 1 (because of zero-indexing) to get the last paragraph on the page */
    lastParagraph = paragraphs[ lastIndex ]; 

lastParagraph.innerHTML;
And that’s how I spent my summer vacation.
Fig 5.1: First drafts are always tough.

Fig 5.1: First drafts are always tough.

The same way these methods give us access to information on the rendered page, they allow us to alter that information, as well. For example, the innerHTML method does this the same way we’d change the value of any other object: a single equals sign, followed by the new value.

var paragraphs = document.getElementsByTagName( "p" ),
    firstParagraph = paragraphs[ 0 ];

firstParagraph.innerHTML = "Listen up, chumps:";
"Listen up, chumps:"

JavaScript’s map of the DOM works both ways: document is updated whenever any markup changes, and our markup is updated whenever anything within document changes (Fig 5.1).

Likewise, the DOM API gives us a number of methods for creating, adding, and removing elements. They’re all more or less spelled out in plain English, so even though things can seem a little verbose, it isn’t too hard to break down.

DOM Scripting

Before we get started, let’s abandon our developer console for a bit. Ages ago now, we walked through setting up a bare-bones HTML template that pulls in a remote script, and we’re going to revisit that setup now. Between the knowledge you’ve gained about JavaScript so far and an introduction to the DOM, we’re done with just telling our console to parrot things back to us—it’s time to build something.

We’re going to add a “cut” to an index page full of text—a teaser paragraph followed by a link to reveal the full text. We’re not going to make the user navigate to another page, though. Instead, we’ll use JavaScript to show the full text on the same page.

Let’s start by setting up an HTML document that links out to an external stylesheet and external script file—nothing fancy. Both our stylesheet and script files are empty with .css and .js extensions, for now—I like to keep my CSS in a /css subdirectory and my JavaScript in a /js subdirectory, but do whatever makes you most comfortable.

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <link rel="stylesheet" type="text/css" href="css/style.css">
    </head>
    <body>

        <script src="js/script.js"></script>
    </body>
</html>

We’re going to populate that page with several paragraphs of text. Any ol’ text you can find laying around will do, including—with apologies to the content strategists in the audience—a little old-fashioned lorem ipsum. We’re just mocking up a quick article page, like a blog post.

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <link rel="stylesheet" type="text/css" href="css/style.css">
    </head>
    <body>
        <h1>JavaScript for Web Designers</h1>

        <p>In all fairness, I should start this book with an apology—not to you, reader, though I don’t doubt that I’ll owe you at least one by the time we get to the end. I owe JavaScript a number of apologies for the things I’ve said to it during the early years of my career, some of which were strong enough to etch glass.</p>

        <p>This is my not-so-subtle way of saying that JavaScript can be a tricky thing to learn.</p>

        [ … ]

        <script src="js/script.js"></script>
    </body>
</html>

Feel free to open up the stylesheet and play with the typography, but don’t get too distracted. We’ll need to write a little CSS later, but for now: we’ve got scripting to do.

We can break this script down into a few discrete tasks: we need to add a Read More link to the first paragraph, we need to hide all the p elements apart from the first one, and we need to reveal those hidden elements when the user interacts with the Read More link.

We’ll start by adding that Read More link to the end of the first paragraph. Open up your still-empty script.js file and enter the following:

var newLink = document.createElement( "a" );

First, we’re intializing the variable newLink, which uses document.createElement( "a" ) to—just like it says on the tin—create a new a element. This element doesn’t really exist anywhere yet—to get it to appear on the page we’ll need to add it manually. First, though, <a></a> without any attributes or contents isn’t very useful. Before adding it to the page, let’s populate it with whatever information it needs.

We could do this after adding the link to the DOM, of course, but there’s no sense in making multiple updates to the element on the page instead of one update that adds the final result—doing all the work on that element before dropping it into the page helps keep our code predictable.

Making a single trip to the DOM whenever possible is also better for performance—but performance micro-optimization is easy to obsess over. As you’ve seen, JavaScript frequently offers us multiple ways to do the same thing, and one of those methods may technically outperform the other. This invariably leads to “excessively clever” code—convoluted loops that require in-person explanations to make any sense at all, just for the sake of shaving off precious picoseconds of load time. I’ve done it; I still catch myself doing it; but you should try not to. So while making as few round-trips to the DOM as possible is a good habit to be in for the sake of performance, the main reason is that it keeps our code readable and predictable. By only making trips to the DOM when we really need to, we avoid repeating ourselves and we make our interaction points with the DOM more obvious for future maintainers of our scripts.

So. Back to our empty, attribute-less <a></a> floating in the JavaScript ether, totally independent of our document.

Now we can use two other DOM interfaces to make that link more useful: setAttribute to give it attributes, and innerHTML to populate it with text. These have a slightly different syntax. We can just assign a string using innerHTML, the way we’d assign a value to any other object. setAttribute, on the other hand, expects two arguments: the attribute and the value we want for that attribute, in that order. Since we don’t actually plan to have this link go anywhere, we’ll just set a hash as the href—a link to the page you’re already on.

var newLink = document.createElement( "a" );

newLink.setAttribute( "href", "#" );
newLink.innerHTML = "Read more";

You’ll notice we’re using these interfaces on our stored reference to the element instead of on document itself. All the DOM’s nodes have access to methods like the ones we’re using here—we only use document.getElementsByTagName( "p" ) because we want to get all the paragraph elements in the document. If we only wanted to get all the paragraph elements inside a certain div, we could do the same thing with a reference to that div—something like ourSpecificDiv.getElementsByTagName( "p" );. And since we’ll want to set the href attribute and the inner HTML of the link we’ve created, we reference these properties using newLink.setAttribute and newLink.innerHTML.

Next: we want this link to come at the end of our first paragraph, so our script will need a way to reference that first paragraph. We already know that document.getElementsByTagName( "p" ) gives us a node list of all the paragraphs in the page. Since node lists behave like arrays, we can reference the first item in the node list one by using the index 0.

var newLink = document.createElement( "a" );
var allParagraphs = document.getElementsByTagName( "p" );
var firstParagraph = allParagraphs[ 0 ];

newLink.setAttribute( "href", "#" );
newLink.innerHTML = "Read more";

For the sake of keeping our code readable, it’s a good idea to initialize our variables up at the top of a script—even if only by initializing them as undefined (by giving them an identifier but no value)—if we plan to assign them a value later on. This way we know all the identifiers in play.

So now we have everything we need in order to append a link to the end of the first paragraph: the element that we want to append (newLink) and the element we want to append it to (firstParagraph).

One of the built-in methods on all DOM nodes is appendChild, which—as the name implies—allows us to append a child element to that DOM node. We’ll call that appendChild method on our saved reference to the first paragraph in the document, passing it newLink as an argument.

var newLink = document.createElement( "a" );
var allParagraphs = document.getElementsByTagName( "p" );
var firstParagraph = allParagraphs[ 0 ];

newLink.setAttribute( "href", "#" );
newLink.innerHTML = "Read more";

firstParagraph.appendChild( newLink );

Now—finally—we have something we can point at when we reload the page. If everything has gone according to plan, you’ll now have a Read More link at the end of the first paragraph on the page. If everything hasn’t gone according to plan—because of a misplaced semicolon or mismatched parentheses, for example—your developer console will give you a heads-up that something has gone wrong, so be sure to keep it open.

Pretty close, but a little janky-looking—our link is crashing into the paragraph above it, since that link is display: inline by default (Fig 5.2).

Well, it’s a start.

Fig 5.2: Well, it’s a start.

We have a couple of options for dealing with this: I won’t get into all the various syntaxes here, but the DOM also gives us access to styling information about elements—though, in its most basic form, it will only allow us to read and change styling information associated with a style attribute. Just to get a feel for how that works, let’s change the link to display: inline-block and add a few pixels of margin to the left side, so it isn’t colliding with our text. Just like setting attributes, we’ll do this before we add the link to the page:

var newLink = document.createElement( "a" );
var allParagraphs = document.getElementsByTagName( "p" );
var firstParagraph = allParagraphs[ 0 ];

newLink.setAttribute( "href", "#" );
newLink.innerHTML = "Read more";
newLink.style.display = "inline-block";
newLink.style.marginLeft = "10px";

firstParagraph.appendChild( newLink );

Well, adding those lines worked, but not without a couple of catches. First, let’s talk about that syntax (Fig 5.3).

Now we’re talking.

Fig 5.3: Now we’re talking.

Remember that identifiers can’t contain hyphens, and since everything is an object (sort of), the DOM references styles in object format as well. Any CSS property that contains a hyphen instead gets camel-cased: margin-left becomes marginLeft, border-radius-top-left becomes borderRadiusTopLeft, and so on. Since the value we set for those properties is a string, however, hyphens are just fine. A little awkward and one more thing to remember, but this is manageable enough—certainly no reason to avoid styling in JavaScript, if the situation makes it absolutely necessary.

A better reason to avoid styling in JavaScript is to maintain a separation of behavior and presentation. JavaScript is our “behavioral” layer the way CSS is our “presentational” layer, and seldom the twain should meet. Changing styles on a page shouldn’t mean rooting through line after line of functions and variables, the same way we wouldn’t want to bury styles in our markup. The people who might end up maintaining the styles for the site may not be completely comfortable editing JavaScript—and since changing styles in JavaScript means we’re indirectly adding styles via style attributes, whatever we write in a script is going to override the contents of a stylesheet by default.

We can maintain that separation of concerns by instead using setAttribute again to give our link a class. So, let’s scratch out those two styling lines and add one setting a class in their place.

var newLink = document.createElement( "a" );
var allParagraphs = document.getElementsByTagName( "p" );
var firstParagraph = allParagraphs[ 0 ];

newLink.setAttribute( "href", "#" );
newLink.setAttribute( "class", "more-link" );
newLink.innerHTML = "Read more";

firstParagraph.appendChild( newLink );

Now we can style .more-link in our stylesheets as usual:

.more-link {
    display: inline-block;
    margin-left: 10px;
}

Much better (Fig 5.4). It’s worth keeping in mind for the future that using setAttribute this way on a node in the DOM would mean overwriting any classes already on the element, but that’s not a concern where we’re putting this element together from scratch.

No visible changes, but this change keeps our styling decisions in our CSS and our behavioral decisions in JavaScript.

Fig 5.4: No visible changes, but this change keeps our styling decisions in our CSS and our behavioral decisions in JavaScript.

Now we’re ready to move on to the second item on our to-do list: hiding all the other paragraphs.

Since we’ve made changes to code we know already worked, be sure to reload the page to make sure everything is still working as expected. We don’t want to introduce a bug here and continue on writing code, or we’ll eventually get stuck digging back through all the changes we made. If everything has gone according to plan, the page should look the same when we reload it now.

Now we have a list of all the paragraphs on the page, and we need to act on each of them. We need a loop—and since we’re iterating over an array-like node list, we need a for loop. Just to make sure we have our loop in order, we’ll log each paragraph to the console before we go any further:

var newLink = document.createElement( "a" );
var allParagraphs = document.getElementsByTagName( "p" );
var firstParagraph = allParagraphs[ 0 ];

newLink.setAttribute( "href", "#" );
newLink.setAttribute( "class", "more-link" );
newLink.innerHTML = "Read more";

for( var i = 0; i < allParagraphs.length; i++ ) {
    console.log( allParagraphs[ i ] );
}

firstParagraph.appendChild( newLink );

Your Read More link should still be kicking around in the first paragraph as usual, and your console should be rich with filler text (Fig 5.5).

Fig 5.5: Looks like our loop is doing what we expect.

Fig 5.5: Looks like our loop is doing what we expect.

Now we have to hide those paragraphs with display: none, and we have a couple of options: we could use a class the way we did before, but it wouldn’t be a terrible idea to use styles in JavaScript for this. We’re controlling all the hiding and showing from our script, and there’s no chance we’ll want that behavior to be overridden by something in a stylesheet. In this case, it makes sense to use the DOM’s built-in methods for applying styles:

var newLink = document.createElement( "a" );
var allParagraphs = document.getElementsByTagName( "p" );
var firstParagraph = allParagraphs[ 0 ];

newLink.setAttribute( "href", "#" );
newLink.setAttribute( "class", "more-link" );
newLink.innerHTML = "Read more";

for( var i = 0; i < allParagraphs.length; i++ ) {
    allParagraphs[ i ].style.display = "none";
}

firstParagraph.appendChild( newLink );

If we reload the page now, everything is gone: our JavaScript loops through the entire list of paragraphs and hides them all. We need to make an exception for the first paragraph, and that means conditional logic—an if statement, and the i variable gives us an easy value to check against:

var newLink = document.createElement( "a" );
var allParagraphs = document.getElementsByTagName( "p" );
var firstParagraph = allParagraphs[ 0 ];

newLink.setAttribute( "href", "#" );
newLink.setAttribute( "class", "more-link" );
newLink.innerHTML = "Read more";

for( var i = 0; i < allParagraphs.length; i++ ) {

    if( i === 0 ) {
            continue;
    }
    allParagraphs[ i ].style.display = "none";
}

firstParagraph.appendChild( newLink );

If this is the first time through of the loop, the continue keyword skips the rest of the current iteration and then—unlike if we’d used break—the loop continues on to the next iteration.

If you reload the page now, we’ll have a single paragraph with a Read More link at the end, but all the others will be hidden. Things are looking good so far—and if things aren’t looking quite so good for you, double-check your console to make sure nothing is amiss.

Now that you’ve got a solid grounding in the DOM, let’s really dig in and see where to take it from here.

Want to read more?

The rest of this chapter (even more than you just read!) goes even deeper—and that’s only one chapter out of Mat’s hands-on, help-you-with-your-current-project guide. Check out the rest of JavaScript for Web Designers at A Book Apart.



Using CSS Mod Queries with Range Selectors

Recently, I was asked to build a simple list that would display in a grid—one that could start with a single element and grow throughout the day, yet alway be tidy regardless of the length. So, as you do sometimes when you’re busy with one thing and asked if you can do something completely different, I tried to think of any reason why it couldn’t be done, came up blank, and distractedly said, “Yes.”

At the time, I was working on a London-based news organization’s website. We’d spent the previous year migrating their CMS to the Adobe AEM platform while simultaneously implementing a responsive UI—both big improvements. Since that phase was complete, we were starting to focus on finessing the UI and building new features. The development project was divided into a number of small semiautonomous teams. My team was focusing on hub pages, and I was leading the UI effort.

Each hub page is essentially a list of lists, simply there to help readers find content that interests them. As you can imagine, a news website is almost exclusively made of content lists! A page full of generic vertical lists would be unhelpful and unappealing; we wanted readers to enjoy browsing the content related to their sphere of interest. Sections needed to be distinct and the lists had to be both individually distinguishable and sit harmoniously together. In short, the visual display was critical to the usability and effectiveness of the entire page.

That “simple list” I said I’d build would be high profile, sitting in its own panel near the top of a hub page and serving to highlight a specific point of interest. Starting with one item and growing throughout the day as related articles were published, the list needed to be a rectangular grid rather than a single column, and never have “leftover” items in the last row. And no matter how many child elements it contained at any given moment, it had to stay tidy and neat because it would display above the fold. Each item would be more or less square, with the first item set at 100% width, the second two at 50%, and all subsequent items 33% and arranged in rows of three. My simple list suddenly wasn’t so simple.

Not everyone wants a generic grid or stack of identical items—there’s something nice about selective prominence, grouped elements, and graceful line endings. These styles can be hardcoded if you know the list will always be an exact length, but it becomes more of a challenge when the length can change. How could I keep that last row tidy when there were fewer than three items?

Various arrangements of list items that do and do not break the planned layout in the bottom row.
Our intended layout would break visually as more items were added to the list.

When it came to actually building the thing, I realized that knowing the length of the list wasn’t very helpful. Having loved Heydon Pickering’s excellent article on quantity queries for CSS, I assumed I could find out the length of the list using QQs, then style it accordingly and all would be fine.

But since my list could be any length, I’d need an infinite number of QQs to meet the requirements! I couldn’t have a QQ for every eventuality. Plus, there were rumors a “Load More” button might be added down the road, letting users dynamically inject another 10 or so items. I needed a different solution.

After a minor meltdown, I asked myself, What would Lea Verou do? Well, not panicking would be a good start. Also, it would help to simplify and identify the underlying requirements. Since the list would fundamentally comprise rows of three, I needed to know the remainder from mod 3.

The “mod” query

Being able to select and style elements by the number of siblings is great, but there’s more to this than mere length. In this case, it would be much better to know if my list is divisible by a certain number rather than how long it is.

Unfortunately, there isn’t a native mod query in CSS, but we can create one by combining two selectors: :nth-child(3n) (aka the “modulo” selector) and the :first-child selector.

The following query selects everything if the list is divisible by three:

li:nth-last-child(3n):first-child,
li:nth-last-child(3n):first-child ~ li { 
 … selects everything in a list divisible by three … 
}
Four rows of list items (cats in boxes). The top and bottom rows are selected (full color, not grayed out) because each is divisible by 3.
Only those rows divisible by three are selected. See the Pen Using CSS Mod Queries with Range Selectors: Fig 2 by Patrick (@clanceyp) on CodePen. Cat image via Paper Bird Publishing.

Let’s talk through that code. (I use li for “list item” in the examples.)

The css selector:

li:nth-last-child(3n):first-child ~ li

Select all following siblings:

... ~ li

The first child (first li in the list, in this case):

...:first-child ...

Every third item starting from the end of the list:

...:nth-last-child(3n):...

That combination basically means if the first child is 3n from the end, select all of its siblings.

The query selects all siblings of the first item, but doesn’t include the first item itself, so we need to add a selector for it separately.

li:nth-last-child(3n):first-child,
li:nth-last-child(3n):first-child ~ li { 
… styles for list items in a list divisible by 3 …  
}

Check out the demo and give it a try!

What about remainders?

With my mod query, I can select all the items in a list if the list is divisible by three, but I’ll need to apply different styles if there are remainders. (In the case of remainder 1, I’ll just need to count back in the CSS from the second-to-last element, instead of the last. This can be achieved by simply adding +1 to the query.)

li:nth-last-child(3n+1):first-child,
li:nth-last-child(3n+1):first-child ~ li { 
… styles for elements in list length, mod 3 remainder = 1 …  
}

Ditto for remainder 2—I just add +2 to the query.

li:nth-last-child(3n+2):first-child,
li:nth-last-child(3n+2):first-child ~ li { 
… styles for elements in list length, mod 3 remainder = 2 …  
} 

Creating a range selector

Now I have a way to determine if the list length is divisible by any given number, with or without remainders, but I still need to select a range. As with mod query, there isn’t a native CSS range selector, but we can create one by combining two selectors: :nth-child(n) (i.e., “everything above”) and :nth-child(-n) (i.e., “everything below”).

This allows us to select items 3 to 5, inclusive:

li:nth-child(n+3):nth-child(-n+5){ 
... styles for items 3 to 5 inclusive ...
}
A row of six list items (graphics of cats in boxes). The two on the left are grayed out, followed by three “selected” cats in full color, and the one on the right is grayed out.
We’ve selected a range: cats 3, 4, and 5.

True, that could just as easily be achieved with simple :nth-child(n) syntax and targeting the item positions directly—li:nth-child(3), li:nth-child(4), li:nth-child(5){ ... }—but defining a start and end to a range is obviously much more versatile. Let’s quickly unpack the selector to see what it’s doing.

Selects all the items up to and including the fifth item:

li:nth-child(n+3):nth-child(-n+5){ … }

Selects all the items from the third item onwards:

li:nth-child(n+3):nth-child(-n+5){ … }

Combining the two—li:nth-child(n+3):nth-child(-n+5)—creates a range selector.

If we look at an example, we might have a product grid where the list items contain an image, title, and description. Let’s say the product image speaks for itself, so in the first row we promote the image and hide all the text. With the second and third row, we display the title and image as a thumbnail, while in subsequent rows we hide the image and show the title and description on a single line.

A grid of three cat graphics in a top row, then two rows of  blocks each comprising a cat graphic and a product title, then four rows each listing text for product title and  product details.
A product grid of our cats. We have standalone graphics in the top row, small graphics plus product titles in the second and third rows, and then we lose the graphics and only show text for all rows after that. See the Pen Using CSS Mod Queries with Range Selectors: Fig 4 by Patrick (@clanceyp) on CodePen.

By using the range selector, we can select the first three, the fourth through ninth, and the 10th onwards. This allows us to change the ranges at different breakpoints in the CSS so we can keep our product grid nice and responsive.

Notes on SCSS mixins

Since I was using a CSS preprocessor, I simplified my code by using preprocessor functions; these are SCSS mixins for creating range selectors and mod queries.

// range selector mixin
@mixin select-range($start, $end){
  &:nth-child(n+#{$start}):nth-child(-n+#{$end}){
   @content;
   }
}
// mod query mixin
@mixin mod-list($mod, $remainder){
  &:nth-last-child(#{$mod}n+#{$remainder}):first-child,
  &:nth-last-child(#{$mod}n+#{$remainder}):first-child ~ li {
    @content;
    }
}

Then in my code I could nest the mixins.

li {
@include mod-list(3, 0){
  @include select-range(3, 5){
    // styles for items 3 to 5 in a list mod 3 remainder = 0
    }
  }
}

Which is, if nothing else, much easier to read!

Putting it all together

So now that I have a little arsenal of tools to help me deal with mods, ranges, and ranges within mods, I can break away from standard-implementation fixed length or fixed-layout lists. Creative use of mod queries and range selectors lets me apply styles to change the layout of elements.

Getting back to the original requirement—getting my list to behave—it became clear that if I styled the list assuming it was a multiple of three, then there would only be two other use cases to support:

  • Mod 3, remainder 1
  • Mod 3, remainder 2

If there was one remaining item, I’d make the second row take three items (instead of the default two), but if the remainder was 2, I could make the third row take two items (with the fourth and fifth items at 50%).

In the end, I didn’t need numerous queries at all, and the ones I did need were actually quite simple.

There was one special case: What if the list only contained two elements?

That was solved with a query to select the second item when it’s also the last child.

li:nth-child(2):last-child { 
... styles for the last item if it’s also the second item ...
}

The queries ultimately weren’t as hard as I’d expected; I just needed to combine the mod and range selectors.

li:nth-last-child(3n):first-child /* mod query */ 
~ li:nth-child(n+3):nth-child(-n+5){ /* range selector */
... styles for 3rd to 5th elements, in a list divisible by 3 ...
}

Altogether, my CSS looked something like this in the end:

/* 
  default settings for list (when its mod 3 remainder 0)
  list items are 33% wide
  except; the first item is 100% 
          the second and third are 50%
*/
li {
  width: 33.33%;
}
li:first-child {
  width: 100%;
}
/* range selector for 2nd and 3rd */
li:nth-child(n+2):nth-child(-n+3){
  width: 50%;
}
/* overrides */
/* mod query override, check for mod 3 remainder = 1 */  
li:nth-last-child(3n+1):first-child ~ li:nth-child(n+2):nth-child(-n+3) {
  width: 33.33%; /* override default 50% width for 2nd and 3rd items */
}
/* mod query override, check for mod 3 remainder = 2 */ 
li:nth-last-child(3n+2):first-child ~ li:nth-child(n+4):nth-child(-n+5) {
  width: 50%; /* override default 33% width for 4th and 5th items */
}
/* special case, list contains only two items */
li:nth-child(2):last-child {
  margin-left: 25%;
}

Experience for yourself (and a note on browser support)

The mod queries and range selectors used in this article rely on the CSS3 selectors, so they will work in all modern browsers that support CSS3, including Internet Explorer 9 and above (but remember, IE will expect a valid doctype).

I created a small mod query generator that you can use to experiment with mod queries.

When I first came across QQs, I thought they were great and interesting but largely theoretical, without many practical real-world use cases. However, with mobile usage outstripping desktop, and responsive design now the norm, the need to display lists, target parts of lists depending on the length/mod, and display lists differently at different breakpoints has become much more common. This really brings the practical application of QQs into focus, and I’m finding more than ever that they are an essential part of the UI developer’s toolkit.

Additional resources



A Redesign with CSS Shapes

Here at An Event Apart (an A List Apart sibling) we recently refreshed the design of our “Why Should You Attend?” page, which had retained an older version of our site design and needed to be brought into alignment with the rest of the site. Along the way, we decided to enhance the page with some cutting-edge design techniques: non-rectangular float shapes and feature queries.

To be clear, we didn’t set out to create a Cutting Edge Technical Example™; rather, our designer (Mike Pick of Monkey Do) gave us a design, and we realized that his vision happened to align nicely with new CSS features that are coming into mainstream support. We were pleased enough with the results and the techniques that we decided to share them with the community.

Styling bubbles

Here are some excerpts from an earlier stage of the designs (Fig. 1). (The end-stage designs weren’t created as comps, so I can’t show their final form, but these are pretty close.)

Fig 1: Late-stage design comps showing “desktop” and “mobile” views.

What interested me was the use of the circular images, which at one point we called “portholes,” but I came to think of as “bubbles.” As I prepared to implement the design in code, I thought back to the talk Jen Simmons has been giving throughout the year at An Event Apart. Specifically, I thought about CSS Shapes and how I might be able to use them to let text flow along the circles’ edges—something like Fig. 2.

Fig 2: Flowing around a circular shape.

This layout technique used to be sort of possible by using crude float hacks like Ragged Float and Sliced Sandbags, but now we have float shapes! We can define a circle—or even a polygon—that describes how text should flow past a floated element.

“Wait a minute,” you may be saying, “I haven’t heard about widespread support for Shapes!” Indeed, you have not. They’re currently supported only in the WebKit/Blink family—Chrome, Safari, and Opera. But that’s no problem: in other browsers, the text will flow past the boxy floats the same way it always has. The same way it does in the design comps, in fact.

The basic CSS looks something like this:

img.bubble.left {
    float: left; margin: 0 40px 0 0 ;
    shape-outside: circle(150px at 130px 130px);
    }
img.bubble.right {
    float: right; margin: 0 0 0 40px;
    shape-outside: circle(150px at 170px 130px);
    }

Each of those bubble images, by the way, is intrinsically 260px wide by 260px tall. In wide views like desktops, they’re left to that size; at smaller widths, they’re scaled to 30% of the viewport’s width.

Shape placement

To understand the shape setup, look at the left-side bubbles. They’re 260×260, with an extra 40 pixels of right margin. That means the margin box (that is, the box described by the outer edge of the margins) is 300 pixels wide by 260 pixels tall, with the actual image filling the left side of that box.

This is why the circular shape is centered at the point 130px 130px—it’s the midpoint of the image in question. So the circle is now centered on the image, and has a radius of 150px. That means it extends 20 pixels beyond the visible outer edge of the circle, as shown here (Fig. 3).

Fig 3: The 150px radius of the shape covers the entire visible part of the image, plus an extra 20px

In order to center the circles on the right-side bubbles, the center point has to be shifted to 170px 130px—traversing the 40-pixel left margin, and half the width of the image, to once again land on the center. The result is illustrated here, with annotations to show how each of the circles’ centerpoints are placed (Fig. 4).

Fig 4: Two of the circular shapes, as highlighted by Chrome’s Inspector and annotated in Keynote (!)

It’s worth examining that screenshot closely. For each image, the light blue box shows the element itself—the img element. The light orange is the basic margin area, 40 pixels wide in each case. The purple circle shows the shape-outside circle. Notice how the text flows into the orange area to come right up against the purple circle. That’s the effect of shape-outside. Areas of the margin outside that shape, and even areas of the element’s content outside the shape, are available for normal-flow content to flow into.

The other thing to notice is the purple circle extending outside the margin area.  This is misleading: any shape defined by shape-outside is clipped at the edge of the element’s margin box. So if I were to increase the circle’s radius to, say, 400 pixels, it would cover half the page in Chrome’s inspector view, but the actual layout of text would be around the margin edges of the floated image—as if there were no shape at all. I’d really like to see Chrome show this by fading the parts of the shape that extend past the margin box. (Firefox and Edge should of course follow suit!)

Being responsive

At this point, things seem great; the text flows past circular float shapes in Chrome/Safari/Opera, and past the standard boxy margin boxes in Firefox/Edge/etc. That’s fine as long as the page never gets so narrow as to let text wrap between bubbles—but, of course, it will, as we see in this screenshot (Fig. 5).

Fig 5: The perils of floats on smaller displays

For the right-floating images, it’s not so bad—but for the left floaters, things aren’t as nice. This particular situation is passably tolerable, but in a situation where just one or two words wrap under the bubble, it will look awful.

An obvious first step is to set some margins on the paragraphs so that they don’t wrap under the accompanying bubbles. For example:

.complex-content div:nth-child(even):not(:last-child) p {
    margin-right: 20%;
}
.complex-content div:nth-child(odd):not(:last-child) p {
    margin-left: 20%;
}

The point here being, for all even-numbered child divs (that aren’t the last child) in a complex-content context, add a 20% right margin; for the odd-numbered divs, a similar left margin.

That’s pretty good in Chrome (Fig. 6) (with the circular float shapes) because the text wraps along the bubble and then pushes off at a sensible point. But in Firefox, which still has the boxy floats, it creates a displeasing stairstep effect (Fig. 7).

Fig 6: Chrome (with float shapes)
Fig 7: Firefox (without float shapes)

On the flip side, increasing the margin to the point that the text all lines up in Firefox (33% margins) would mean that the float shape in Chrome would be mostly pointless, since the text would never flow down along the bottom half of the circles.

Querying feature support

This is where @supports came into play. By using @supports to run a feature query, I could set the margins for all browsers to the 33% needed when shapes aren’t supported, and then reduce it for browsers that do understand shapes. It goes something like this:

.complex-content div:nth-child(even):not(:last-child) p {
    margin-right: 33%;
}
.complex-content div:nth-child(odd):not(:last-child) p {
    margin-left: 33%;
}

@supports (shape-outside: circle()) {
    .complex-content div:nth-child(even):not(:last-child) p {
        margin-right: 20%;
    }
    .complex-content div:nth-child(odd):not(:last-child) p {
        margin-left: 20%;
    }
}

With that, everything is fine in the two worlds (Fig. 8 and Fig. 9). There are still a few things that could be tweaked, but overall, the effect is pleasing in browsers that support float shapes, and also those that don’t. The two experiences are shown in the following videos. (They don’t autoplay, so click at your leisure.)

Captured in Chrome; higher resolution available (mp4, 3.3MB)
Captured in Firefox; higher resolution available (mp4, 2.9MB)

Thanks to feature queries, as browsers like Firefox and MS Edge add support for float shapes, they’ll seamlessly get the experience that currently belongs only to Chrome and its bretheren.  There’s no browser detection to adjust later, no hacks to clear out. There’s only silent progressive enhancement baked right into the CSS itself.  It’s pretty much “style and forget.”

While an arguably minor enhancement, I really enjoyed the process of working with shapes and making them progressively and responsively enhanced. It’s a nice little illustration of how we can use advanced features of CSS right now, without the usual wait for widespread support. This is a general pattern that will see a lot more use as we start to make use of shapes, flexbox, grid, and more cutting-edge layout tools, and I’m glad to be able to offer this case study.

Further reading

If you’d like to know more about float shapes and feature queries, I can do little better than to recommend the following articles.



This week's sponsor: Adobe XD

ADOBE XD. Go from idea to prototype faster. Download XD to create and share your design ideas, and download the mobile companion apps to preview your prototypes on actual devices.



Task Performance Indicator: A Management Metric for Customer Experience

It’s hard to quantify the customer experience. “Simpler and faster for users” is a tough sell when the value of our work doesn’t make sense to management. We have to prove we’re delivering real value—increased the success rate, or reduced time-on-task, for example—to get their attention. Management understands metrics that link with other organizational metrics, such as lost revenue, support calls, or repeat visits. So, we need to describe our environment with metrics of our own.

For the team I work with, that meant developing a remote testing method that would measure the impact of changes on customer experience—assessing alterations to an app or website in relation to a defined set of customer “top tasks.” The resulting metric is stable, reliable, and repeatable over time. We call it the Task Performance Indicator (TPI).

For example, if a task has a TPI score of 40 (out of 100), it has major issues. If you measure again in 6 months’ time but nothing has been done to address the issues, the testing score will again result in a TPI of 40.

In traditional usability testing, it has long been established that if you test with between three and eight people, you’ll find out if significant problems exist. Unfortunately, that’s not enough to reveal precise success rates or time-on-task measurements. What we’ve discovered from hundreds of tests over many years is that reliable and stable patterns aren’t apparent until you’re testing with between 13 and 18 people. Why is that?

When the number of participants ranges anywhere from 13–18 people, testing results begin to stabilize and you’re left with a reliable baseline TPI metric.

The following chart shows why we can do this (Fig. 1).

A graph showing how TPI scores essentially leveled out upon as more participants were included.
Fig 1: TPI scores start to level out and stabilize as more participants are tested.

How TPI scores are calculated

We’ve spent years developing a single score that we believe is a true reflection of the customer experience when completing a task.

For each task, we present the user with a “task question” via live chat. Once they understand what they have to do, the user indicates that they are starting the task. At the end of the task, they must provide an answer to the question. We then ask people how confident they are in their answer.

A number of factors affect the resulting TPI score.

Time: We establish what we call the “Target Time”—how long it should take to complete the task under best practice conditions. The more they exceed the target time, the more it affects the TPI.

Time out: The person takes longer than the maximum time allocated. We set it at 5 minutes.

Confidence: At the end of each task, people are asked how confident they are. For example, low confidence in a correct answer would have a slight negative impact on the TPI score.

Minor wrong: The person is unsure; their answer is almost correct.

Disaster: The person has high confidence, but the wrong result; acting on this wrong answer could have serious consequences.

Gives up: The person gives up on the task.

A TPI of 100 means that the user has successfully completed the task within the agreed target times.

In the following chart, the TPI score is 61 (Fig. 2).

A pie chart illustrating sample results for Overall Task Performance, and a vertical bar showing Mean Completion Times in comparison with Mean Target Times.
Fig 2: A visual breakdown of sample results for Overall Task Performance, Mean Completion Times, and Mean Target Times.

Developing task questions

Questions are the greatest source of potential noise in TPI testing. If a question is not worded correctly, it will invalidate the results. To get an overall TPI for a particular website or app, we typically test 10-12 task questions. In choosing a question, keep in mind the following:

Based on customer top tasks. You must choose task questions that are examples of top tasks. If you measure and then seek to improve the performance of tiny tasks (low demand tasks) you may be contributing to a decline in the overall customer experience.

Repeatable. Create task questions that you can test again in 6 to 12 months.

Representative and typical. Don’t make the task questions particularly difficult. Start off with reasonably basic, typical questions.

Universal, everyone can do it. Every one of your test participants must be able to do each task. If you’re going to be testing a mixture of technical, marketing, and sales people, don’t choose a task question that only a salesperson can do.

One task, one unique answer. Limit each task question to only one actual thing you want people to do, and one unique answer.

Does not contain clues. The participant will examine the task question like Sherlock Holmes would hunt for a clue. Make sure it doesn’t contain any obvious keywords that could be answered by conducting a search.

Short—30 words or less. Remember, the participant is seeing each task question for the first time, so aim to keep its length at less than 20 words (and definitely less than 30).

No change within testing period. Choose questions where the website or app is not likely to change during the testing period. Otherwise, you’re not going to be testing like with like.

Case Study: Task questions for OECD

Let’s look at some top tasks for the customers of Organisation for Economic Co-operation and Development (OECD), an economic and policy advice organization.

  1. Access and submit country surveys, reviews, and reports.
  2. Compare country statistical data.
  3. Retrieve statistics on a particular topic.
  4. Browse a publication online for free.
  5. Access, submit, and review working papers.

Based on that list, these task questions were developed:

  1. What are OECD’s latest recommendations regarding Japan’s healthcare system?
  2. In 2008, was Vietnam on the list of countries that received official development assistance?
  3. Did more males per capita die of heart attacks in Canada than in France in 2004?
  4. What is the latest average starting salary, in US dollars, of a primary school teacher across OECD countries?
  5. What is the title of Box 1.2 on page 73 of OECD Employment Outlook 2009?
  6. Find the title of the latest working paper about improvements to New Zealand’s tax system.

Running the test

To test 10-12 task questions usually takes about one hour, and you’ll need between 13 and 18 participants (we average 15). Make sure that they’re representative of your typical customers. 

We’ve found that remote testing is better, faster, and cheaper than traditional lab-based measurement for TPI testing. With remote testing, people are more likely to behave in a natural way because they are in their normal environment—at home or in the office—and using their own computer. That makes it much easier for someone to give you an hour of their time, rather than spend the morning at your lab. And since the cost is much lower than lab-based tests, we can set them up more quickly and more often. It’s even convenient to schedule them using Webex, GoToMeeting, Skype, etc.

The key to a successful test is that you are confident, calm, and quiet. You’re there to facilitate the test—not to guide it or give opinions. Aim to become as invisible as possible.

Prior to beginning the test, introduce yourself and make sure the participant gives you permission to record the session. Next, ask that they share their screen. Remember to stress that you are only testing the website or app—not them. Ask them to go to an agreed start point where all the tasks will originate. (We typically choose the homepage for the site/app, or a blank tab in the browser.)

Explain that for each task, you will paste a question into the chat box found on their screen. Test the chat box to confirm that the participant can read it, and tell them that you will also read the task aloud a couple of times. Once they understand what they have to do, ask them to indicate when they start the task, and that they must give an answer once they’ve finished. After they’ve completed the task, ask the participant how confident they are in their answer.

Analyzing the results

As you observe the tests, you’re looking for patterns. In particular, look for the major reasons people give for selecting the wrong answer or exceeding the target time.

Video recordings of your customers as they try—and often fail—to complete their tasks have powerful potential. They are the raw material of empathy. When we identify a major problem area during a particular test, we compile a video containing three to six participants who were affected. For each participant, we select less than a minute’s worth of video showing them while affected by this problem. We then edit these participant snippets into a combined video (that we try to keep under three minutes). We then get as many stakeholders as possible to watch it. You should seek to distribute these videos as widely, and as often as possible.

How Cisco uses the Task Performance Indicator

Every six months or so, we measure several tasks for Cisco, including the following:

Task: Download the latest firmware for the RV042 router.

The top task of Cisco customers is downloading software. When we started the Task Performance Indicator for software downloads in 2010, a typical customer might take 15 steps and more than 300 seconds to download a piece of software. It was a very frustrating and annoying experience. The Cisco team implemented a continuous improvement process based on the TPI results. Every six months, the Task Performance Indicator was carried out again to see what had been improved and what still needed fixing. By 2012—for a significant percentage of software—the number of steps to download software had been reduced from 15 to 4, and the time on task had dropped from 300 seconds to 40 seconds. Customers were getting a much faster and better experience.

According to Bill Skeet, Senior Manager of Customer Experience for Cisco Digital Support, implementing the TPI has had a dramatic impact on how people think about their jobs:

We now track the score of each task and set goals for each task. We have assigned tasks and goals to product managers to make sure we have a person responsible for managing the quality of the experience ... Decisions in the past were driven primarily by what customers said and not what they did. Of course, that sometimes didn’t yield great results because what users say and what they do can be quite different.

Troubleshooting and bug fixing are also top tasks for Cisco customers. Since 2012, we’ve tested the following.

Task: Ports 2 and 3 on your ASR 9001 router, running v4.3.0 software, intermittently stop functioning for no apparent reason. Find the Cisco recommended fix or workaround for this issue.

Combination of pie charts and browser screenshots, depicting progression of change to the Bug Task Success Rate from February 2012 through December 2014.
Fig 3: Bug Task Success Rate Comparisons, February 2012 through December 2014.

For a variety of reasons, it was difficult to solve the underlying problems connected with finding the right bug fix information on the Cisco website. Thus, the scores from February 2012 to February 2013 did not improve in any significant way.

For the May 2013 measurement, the team ran a pilot to show how (with the proper investment) it could be much easier to find bug fix information. As we can see in the preceding image, the success rate jumped. However, it was only a pilot and by the next measurement it had been removed and the score dropped again. The evidence was there, though, and the team soon obtained resources to work on a permanent fix. The initial implementation was for the July 2014 measurement, where we see a significant improvement. More refinements were made, then we see a major turnaround by December 2014.

Task: Create a new guest account to access the Cisco.com website and log in with this new account.

Graph depicting Success/Failure rates from March 2015 through June 2015
Fig 4: Success/Failure rates from March 2015 through June 2015

This task was initially measured in 2014; the results were not good.

In fact, nobody succeeded in completing the task during the March 2014 measurements, resulting in three specific design improvements to the sign-up form. These involved:

  1. Clearly labelling mandatory fields
  2. Improving password guidance
  3. Eliminating address mismatch errors.

A shorter pilot form was also launched as a proof of concept. Success jumped by 50% in the July 2014 measurements, but dropped 21% by December 2014 because the pilot form was no longer there. By June 2015, a shorter, simpler form was fully implemented, and the success again reached 50%.

The team was able to show that because of their work:

  • The three design improvements improved the success rate by 29%.
  • The shorter form improved the success rate by 21%.

That’s very powerful. You can isolate a piece of work and link it to a specific increase in the TPI. You can start predicting that if a company invests X it will get a Y TPI increase. This is control and the route to power and respect within your organization, or to trust and credibility with your client.

If you can link it with other key performance indicators, that’s even more powerful.

The following table shows that improvements to the registration form halved the support requests connected with guest account registration (Fig. 5).

Bar chart illustrating registration support request numbers for Q1 2014 (1,500), Q2 2015 (679), and Q3 2015 (689).
Fig 5: Registration Support Requests, Q1 2014, Q2 2015, and Q3 2015.

A more simplified guest registration process resulted in:

  • A reduction in support requests—from 1,500 a quarter, to less than 700
  • Three fewer people were required to support customer registration
  • 80% productivity improvement
  • Registration time down to 2 minutes from 3:25.

Task: Pretend you have forgotten the password for the Cisco account and take whatever actions are required to log in.

When we measured the change passwords task, we found that there was a 37% failure rate.

A process of improvement was undertaken, as can be seen by the following chart, and by December 2013, we had a 100% success rate (Fig. 6).

Four pie charts illustration the progression of improvement in success rate from November 2012 (63%), May 2013 (77%), August 2013 (88%), and December 2013 (100%).
Fig 6: Progression of success rate improvement from November 2012 to December 2013.

100% success rate is a fantastic result. Job done, right? Wrong. In digital, the job is never done. It is always an evolving environment. You must keep measuring the top tasks because the digital environment that they exist within is constantly changing. Stuff is getting added, stuff is getting removed, and stuff just breaks (Fig. 7).

Two pie charts, one reporting a success rate of 41% for March 2014 and the other a 100% success rate for July 2014.
Fig 7: Comparison of success rates, March 2014 and July 2014.

When we measured again in March 2014, the success rate had dropped to 59% because of a technical glitch. It was quickly dealt with, so the rate shot back up to 100% by July.

At every step of the way, the TPI gave us evidence about how well we were doing our job. It’s really helped us fight against some of the “bright shiny object” disease and the tendency for everyone to have an opinion on what we put on our webpages ... because we have data to back it up. It gave us more insight into how content organization played a role in our work for Cisco, something that Jeanne Quinn (senior manager responsible for the Cisco Partner) told us kept things clear and simple while working with the client.

The TPI allows you to express the value of your work in ways that makes sense to management. If it makes sense to management—and if you can prove you’re delivering value—then you get more resources and more respect.



Why We Should All Be Data Literate

Recently, I was lucky enough to see the great Jared Spool talk (spoiler: all Spool talks are great Spool talks). In this instance, the user interface icon warned of the perils of blindly letting data drive design.

I am in total agreement with 90 percent of his premise. Collecting and analyzing quantitative data can indeed inform your design decisions, and smart use of metrics can fix critical issues or simply improve the user experience. However, this doesn’t preclude a serious problem with data, or more specifically, with data users. Spool makes this clear: When you don’t understand what data can and can’t tell you and your work is being dictated by decisions based on that lack of understanding—well, your work and product might end up being rubbish. (Who hasn’t heard a manager fixate on some arbitrary metric, such as, “Jane, increase time on page” or “Get the bounce rate down, whatever it takes”?) Designing to blindly satisfy a number almost always leads to a poorer experience, a poorer product, and ultimately the company getting poorer.

Where Spool and I disagree is in his conclusion that all design teams need to include a data scientist. Or, better yet, that all designers should become data scientists. In a perfect world, that would be terrific. In the less-perfect world that most of us inhabit, I feel there’s a more viable way. Simply put: all designers can and should learn to be data literate. Come to think of it, it’d be nice if all citizens learned to be data literate, but that’s a different think piece.

For now, let’s walk through what data literacy is, how to go about getting it for less effort and cost than a certificate from Trump University, and how we can all build some healthy data habits that will serve our designs for the better.

What Data Literacy Is and Isn’t

Okay, data literacy is a broad term—unlike, say, “design.” In the education field, researchers juggle the terms “quantitative literacy,” “mathematical literacy,” and “quantitative reasoning,” but parsing out fine differences is beyond the scope of this article and, probably, your patience. To keep it simple, let’s think about data literacy as healthy skepticism or even bullshit detection. It’s the kind of skepticism you might adopt when faced with statements from politicians or advertisers. If a cookie box is splashed with a “20% more tasty!” banner, your rightful reaction might be “tastier than what, exactly, and who says?” Yes. Remember that response.

Data literacy does require—sorry, phobics—some math. But it’s not so bad. As a designer, you already use math: figuring pixels, or calculating the square footage of a space, or converting ems to percent and back. The basics of what you already do should give you a good handle on concepts like percentages, probability, scale, and change over time, all of which sometimes can hide the real meaning of a statistic or data set. But if you keep asking questions and know how multiplication and division work, you’ll be 92 percent of the way there. (If you’re wondering where I got that percentage from, well—I made it up. Congratulations, you’re already on the road to data literacy.)

Neil Lutsky writes about data literacy in terms of the “construction, communication, and evaluation of arguments.” Why is this relevant to you as a designer? As Spool notes, many design decisions are increasingly driven by data. Data literacy enables you to evaluate the arguments presented by managers, clients, and even analytics packages, as well as craft your own arguments. (After all, a key part of design is being able to explain why you made specific design decisions.) If someone emails you a spreadsheet and says, “These numbers say why this design has to be 5 percent more blue,” you need to be able to check the data and evaluate whether this is a good decision or just plain bonkers.

Yes, this is part of the job.

It’s So Easy

Look, journalists can get pretty good at being data literate. Not all journalists, of course, but there’s a high correlation between the ability to question data and the quality of the journalism—and it’s not high-level or arcane learning. One Poynter Institute data course was even taught (in slightly modified form) to grade schoolers. You’re a smart cookie, so you can do this. Not to mention the fact that data courses are often self-directed, online, and free (see “Resources” listed below).

Unlike data scientists who face complex questions, large data sets, and need to master concepts like regressions and Fourier transforms, you’re probably going to deal with less complex data. If you regularly need to map out complex edge-node relationships in a huge social graph or tackle big data, then yes, get that master’s degree in the subject or consult a pro. But if you’re up against Google Analytics? You can easily learn how to ask questions and look for answers. Seriously, ask questions and look for answers.

Designers need to be better at data literacy for many of the same reasons we need to work on technical literacy, as Sarah Doody explains. We need to understand what developers can and can’t do, and we need to understand what the data can and can’t do. For example, an A/B test of two different designs can tell you one thing about one thing, but if you don’t understand how data works, you probably didn’t set up the experiment conditions in a way that leads to informative results. (Pro tip: if you want to see how a change affects click-through, don’t test two designs where multiple items differ, and don’t expect the numbers to tell you why that happened.) Again: We need to question the data.

So we’ve defined a need, researched our users, and identified and defined a feature called data literacy. What remains is prototyping. Let’s get into it, shall we?

How to Build Data Literacy by Building Habits

Teaching data literacy is an ongoing topic of academic research and debate, so I’ll leave comprehensive course-building to more capable hands than mine. But together, we can cheaply and easily outline simple habits of critical thought and mathematical practice, and this will get us to, let’s say, 89 percent data literacy. At the least, you’ll be better able to evaluate which data could make your work better, which data should be questioned more thoroughly, and how to talk to metric-happy stakeholders or bosses. (Optional homework: this week, take one metric you track or have been told to track at work, walk through the habits below, and report back.)

Habit one: Check source and context

This is the least you should do when presented with a metric as a fait accompli, whether that metric is from a single study, a politician, or an analytics package.

First, ask about the source of the data (in journalism, this is reflex—“Did the study about the health benefits of smoking come from the National Tobacco Profiteering Association?”). Knowing the source, you can then investigate the second question.

The second question concerns how the data was collected, and what that can tell you—and what it can’t.  Let’s say your boss comes in with some numbers about time-on-page, saying “Some pages are more sticky than others. Let’s redesign the others to keep customers on all the other pages longer.” Should you jump to redesign the less-sticky pages, or is there a different problem at play?

It’s simple, and not undermining, to ask how time-on-page was measured and what it means. It could mean a number of things, things that that single metric will never reveal. Things that could be real problems, real advantages, or a combination of the two. Maybe the pages with higher time-on-page numbers simply took a lot longer to load, so potential customers were sitting there as a complex script or crappy CDN was slooooowly drawing things on the not-a-customer-any-more’s screen. Or it could mean some pages had more content. Or it could mean some were designed poorly and users had to figure out what to do next.

How can you find this out? How can you communicate that it’s important to find out? A quick talk with the dev team or running a few observations with real users could lead you to discover what the real problem is and how you can redesign to improve your product.

What you find out could be the difference between good and bad design. And that comes from knowing how a metric is measured, and what it doesn’t measure. The metric itself won’t tell you.

For your third question, ask the size of the sample. See how many users were hitting that site, whether the time-on-page stat was measured for all or some of these users, and whether that’s representative of the usual load. Your design fix could go in different directions depending on the answer. Maybe the metric was from just one user! This is a thing that sometimes happens.

Fourth, think and talk about context. Does this metric depend on something else? For example, might this metric change over time? Then you have to ask over what time period the metric was measured, if that period is sufficient, and whether the time of year when measured might make a difference.

Remember when I said change over time can be a red flag? Let’s say your boss is in a panic, perusing a chart that shows sales from one product page dropping precipitously last month. Design mandates flood your inbox: “We’ve got to promote this item more! Add some eye-catching design, promote it on our home page!”

What can you do to make the right design decisions? Pick a brighter blue for a starburst graphic on that product page?

Maybe it would be more useful to look at a calendar. Could the drop relate to something seasonal that should be expected? Jack o’lantern sales do tend to drop after November 1. Was there relevant news? Apple’s sales always drop before their annual events, as people expect new products to be announced. A plethora of common-sense questions could be asked.

The other key point about data literacy and change is that being data literate can immunize against common errors when looking at change over time. This gets to numeracy.

Habit two: Be numerate

I first learned about numeracy through John Allen Paulos’ book Innumeracy: Mathematical Illiteracy and its Consequences, though the term “innumeracy” was originated by Pulitzer Prize-winning scientist Douglas Hofstadter. Innumeracy is a parallel to illiteracy; it means the inability to reason with numbers. That is, the innumerate can do math but are more likely to trip up when mathematical reasoning is critical. This often happens when dealing with probability and coincidence, with statistics, and with things like percentages, averages, and changes. It’s not just you—these can be hard to sort out sort out! We’re presented with these metrics a lot, but usually given little time to think about them, so brushing up on that bit of math can really help put out (or avoid) a trash fire of bad design decisions.

Consider this:  A founder comes in with the news that an app has doubled its market base in the two weeks it’s been available. It’s literally gone up 100 percent in that time. That’s pretty awesome, right? Time to break out the bubbly, right? But what if you asked a few questions and found that this really meant the founder was the first user, then eventually her mom got onto it. That is literally doubling the user base exactly 100 percent.

Of course that’s obvious and simple. You see right off why this startup probably shouldn’t make the capital outlay to acquire a bottle or two juuuust yet. But exactly this kind of error gets overlooked easily and often when the math gets a bit more complex.

Any time you see a percentage, such as “23% more” or “we lost 17%,” don’t act until you’ve put on your math hat. You don’t even need to assume malice; this stuff simply gets confusing fast, and it’s part of your job not to misread the data and then make design decisions based on an erroneous understanding.

Here’s an example from Nicolas Kayser-Bril, who looks into the headline, “Risk of Multiple Sclerosis Doubles When Working at Night”:

“Take 1,000 Germans. A single one will develop MS over his lifetime. Now, if every one of these 1,000 Germans worked night shifts, the number of MS sufferers would jump to two. The additional risk of developing MS when working in shifts is one in 1,000, not 100%. Surely this information is more useful when pondering whether to take the job.”

This is a known issue in science journalism that isn’t discussed enough, and often leads to misleading headlines. Whenever there’s a number suggesting something that affects people, or a number suggesting change, look not just at the percentage but at what this would mean in the real world; do the math and see if the result matches the headline’s intimation. Also ask how the percentage was calculated. How was the sausage made? Lynn Arthur Steen explains how percentages presented to you may not just be the difference of two numbers divided by a number. Base lesson: always learn what your analytics application measures and how it calculates things. Four out of five dentists agree...so that’s, what, 80 percent true?

Averages are another potentially deceptive metric that simple math can help; sometimes it’s barely relevant, if at all. “The average length of a book purchased on Amazon is 234.23 pages” may not actually tell you anything. Sometimes you need to look into what’s being averaged. Given the example “One in every 15 Europeans is illiterate,” Kayser-Bril points out that maybe close to one in 15 Europeans is under the age of seven. It’s good advice to learn the terms “mode,” “median,” and “standard deviation.” (It doesn’t hurt (much), and can make you a more interesting conversationalist at dinner parties!)

Habit three: Check your biases

I know, that sounds horrible. But in this context, we’re talking about cognitive biases, which everyone has (this is why I encourage designers to study psychology, cognition studies, and sociology as much as they can). Though we have biases, it’s how aware we are of these issues and how we deal with them that counts.

It’s out of scope to list and describe them all (just thinking I know them all is probably an example of Dunning-Kruger). We’ll focus on two that are most immediately relevant when you’re handed supposedly-objective metrics and told to design to them. At least, these are two that I most often see, but that may be selection bias.

Selection bias

Any metric or statistical analysis is only as good as (in part) what you choose to measure. Selection bias is when your choice of what to measure isn’t really random or representative. This can come from a conscious attempt to skew the result, from carelessly overlooking context, or due to some hidden process.

One example might be if you’re trying to determine the average height of the adult male in the United States and find it to be 6'4"—oops, we only collected the heights of basketball players. Online opinion polls are basically embodied examples of selection bias, as the readers of a partisan site are there because they already share the site operator’s opinion. Or you may be given a survey that shows 95 percent of users of your startup’s app say they love it, but when you dig in to the numbers, the people surveyed were all grandmothers of the startup team employees (“Oh, you made this, dear? I love it!”). This holds in usability testing, too: if you only select, say, high-level programmers, you may be convinced that a “to install this app, recompile your OS kernel” is a totally usable feature. Or end up with Pied Piper’s UI.

Now, these all seem like “sure, obvs” examples. But selection bias can show up in much more subtle forms, and in things like clinical studies. Dr. Madhukar Pai’s slides here give some great examples — especially check out Slide 47, which shows how telephone surveys have almost built-in selection biases.

So, what’s a designer to do? As you can see from Dr. Pai’s lecture slides, you can quickly get into some pretty “mathy” work, but the main point is that when you’re faced with a metric, after you’ve checked out the context, look at the sample. You can think about the claim on the cookie box in this way. It’s “20% more tasty”?  What was the sample, 19 servings of chopped liver and one cookie?

Confirmation bias

Storytelling is a powerful tool. Again, it’s how our brains are wired. But as with all tools, it can be used for good or for evil, and can be intentional or accidental. As designers, we’re told we have to be storytellers: how do people act, how do they meet-cute our product, how do they feel, what’s the character arc? This is how we build our knowledge of the world, by building stories about it. But, as Alberto Cairo explains in The Truthful Art this is closely linked to confirmation bias, where we unconsciously (or consciously) search for, select, shape, remember, interpret, or otherwise torture basic information so that it matches what we already think we know, the stories we have. We want to believe.

Confirmation bias can drive selection bias, certainly. If you only test your design with users who already know how your product works (say, power users, stakeholders, and the people who built the product), you will get distorted numbers and a distorted sense of how usable your product is. Don’t laugh: I know of a very large and popular internet company that only does user re-search with power users and stakeholders.

But even if the discovery process is clean, confirmation bias can screw up the interpretation. As Cairo writes, “Even if we are presented with information that renders our beliefs worthless, we’ll try to avoid looking at it, or we’ll twist it in a way that confirms them. We humans try to reduce dissonance no matter what.” What could this mean for your design practice? What could this mean for your designs when stakeholders want you to design to specific data?

Reading (Numbers) is Fundamental

So, yes. If you can work with a data scientist in your design team, definitely do so. Try to work with her and learn alongside her. But if you don’t have this luxury, or the luxury of studying statistics in depth, think of data literacy as a vital part of your design practice. Mike Monteiro is passionate that designers need to know math, and he’s of course correct, but we don’t need to know math just to calculate visual design. We need to know math enough to know how to question and analyze any metric we’re given.

This is something you can practice in everyday life, especially in an election season. When you see someone citing a study, or quoting a number, ask: What was measured? How was it measured? What was the context? What wasn’t measured? Does that work out in real life? Keep looking up terms like selection bias, confirmation bias, Dunning-Kruger, sample size effect, until you remember them and their application. That is how you build habits, and how you’ll build your data literacy muscles.

I’ve long loved the Richard Feynman quote (that Cairo cites in The Truthful Art): “The first principle is that you must not fool yourself — and you are the easiest person to fool.” Consider always that you might be fooling yourself by blindly accepting any metric handed to you. And remember, the second-easiest person to fool is the person who likely handed you the metric, and is motivated to believe a particular outcome. Data literacy requires honesty, mastering numeracy, and stepping through the habits we’ve discussed. Practice every day with news from politics: does a statistic in the news give you that “of course, that’s how things are” feeling? Take a deep breath, and dig in; do you agree with a policy or action because it’s your political party proposing it? What’s the context, the sample size, the bias?

It’s tough to query yourself this way. But that’s the job. It’s tougher to query someone else this way, whether it’s your boss or your significant other. I can’t help you figure out the politics and social minefield of those. But do try. The quality of your work (and life) may depend on it.

Resources



This week's sponsor: OPTIMAL WORKSHOP

OPTIMAL WORKSHOP — test your website‘s performance with fast and powerful UX research tools.​



Designing Interface Animation: an Interview with Val Head

A note from the editors: To mark the publication of Designing Interface Animation, ALA managing editor Mica McPheeters and editor Caren Litherland reached out to Val Head via Google Hangouts and email for a freewheeling conversation about web animation. The following interview has been edited for clarity and brevity.

Animation is not new, of course, but its journey on the web has been rocky. For years, technological limitations compelled us to take sides: Should we design rich, captivating sites in Flash? Or should we build static, standards-compliant sites with HTML and CSS (and maybe a little JavaScript)?

Author Val Head describes herself as a “weirdo” who never wanted to choose between those two extremes—and, thanks to the tools at our disposal today, we no longer have to. Without compromising standards, we can now create complex animations natively in the browser: from subtle transitions using CSS to immersive, 3-D worlds with WebGL. Animation today is not just on the web, but of the web. And that, says Val, is a very big deal.

Caren Litherland: Are people intimidated by animation?

Val Head: There are definitely some web folks out there who are intimidated by the idea of using web animation in their work. For some, it’s such a new thing—very few of us have a formal background in motion design or animation—and it can be tough to know where to start or how to use it. I’ve noticed there’s some hesitation to embrace web animation due to the “skip intro” era of Flash sites. There seems to be a fear of recreating past mistakes. But it doesn’t have to be that way at all.

We’re in a new era of web animation right now. The fact that we can create animation with the same technologies we’ve always used to make websites—things like CSS and JavaScript—completely changes the landscape. Now that we can make animation that is properly “of the web” (to borrow a phrase from Jeremy Keith), not just tacked on top with a plug-in, we get to define what the new definition of web animation is with our work.

Right now, on the web, we can create beautiful, purposeful animation that is also accessible, progressively enhanced, and performant. No other medium can do that. Which is really exciting!

CL: I’ve always felt that there was something kind of ahistorical and ahistoricizing about the early web. As the web has matured, it seems to have taken a greater interest in the history and traditions that inform it. Web typography is a good example of this increased self-awareness. Can the same be said for animation?

VH: I think so! In the early days of the web, designers often looked down on it as a less capable medium. Before web type was a thing, a number of my designer friends would say that they could never design for the web because it wasn’t expressive enough as a medium. That the web couldn’t really do design. Then the web matured, web type came along, and that drastically changed how we designed for the web. Web animation is doing much the same thing. It’s another way we have now to be expressive with our design choices, to tell stories, to affect the experience in meaningful ways, and to make our sites unique.

With type, we turned to the long-standing craft of print typography for some direction and ideas, but the more we work with type on the web, the more web typography becomes its own thing. The same is true of web animation. We can look to things like the 12 classic principles of animation for reference, but we’re still defining exactly what web animation will be and the tools and technologies we use for it. Web animation adds another dimension to how we can design on the web and another avenue for reflecting on what the rich histories of design, animation, and film can teach us.

Mica McPheeters: Do you find that animation often gets tacked on at the end of projects? Why is that? Shouldn’t it be incorporated from the outset?

VH: Yes, it often does get left to the end of projects and almost treated as just the icing on top. That’s a big part of what can make animation seem like it’s too hard or ineffective. If you leave any thought of animation until the very end of a project, it’s pretty much doomed to fail or just be meaningless decoration.

Web animation can be so much more than just decoration, but only if we make it part of our design process. It can’t be a meaningful addition to the user experience if you don’t include it in the early conversations that define that experience.

Good web animation takes a whole team. You need input from all disciplines touching the design to make it work well. It can’t just be designed in a vacuum and tossed over the fence. That approach fails spectacularly well when it comes to animation.

Communicating animation ideas and making animation truly part of the process can be the biggest hurdle for teams to embrace animation. Change is hard! That’s why I dedicated two entire chapters of the book to how to get animation done in the real world. I focus on how to communicate animation ideas to teammates and stakeholders, as well as how to prototype those ideas efficiently so you can get to solutions without wasting time. I also cover how to represent animation in your design systems or documentation to empower everyone (no matter what their background is) to make good motion design decisions.

CL: Can you say more about the importance of a motion audit? Can it be carried out in tandem with a content audit? And how do content and animation tie in with each other?

VH: I find motion audits to be incredibly useful before creating a motion style guide or before embarking on new design efforts. It’s so helpful to know where animation is already being used, and to take an objective look at how effective it is both from a UX angle and a branding angle. If you have a team of any significant size, chances are you’ve probably got a lot of redundant, and maybe even conflicting, styles and uses of animation in your site. Motion audits give you a chance to see what you’re already doing, identify things that are working, as well as things that might be broken or just need a little work. They’re also a great way to identify places where animation could provide value but isn’t being used yet.

Looking at all your animation efforts at a high level gives you a chance to consolidate the design decisions behind them, and establish a cohesive approach to animation that will help tie the experience together across mediums and viewport sizes. You really need that high-level view of animation when creating a motion style guide or animation guidelines.

You could definitely collect the data for a motion audit in tandem with a content audit. You’ll likely be looking in all the same places, just collecting up more data as you go through your whole site.

There is a strong tie between content and animation. I’ve been finding this more and more as I work with my consulting clients. Both can be focused around having a strong message and communicating meaningfully. When you have a clear vision of what you want to say, you can say it with the motion you use just like you can say it with the words you choose.

Voice and tone documents can be a great place to start for deciding how your brand expresses itself in motion. I’ve leaned on these more than once in my consulting work. Those same words you use to describe how you’d like your content to feel can be a basis of how you aim to make the animation feel as well. When all your design choices—everything from content, color, type, animation—come from the same place, they create a powerful and cohesive message.

CL: One thing in your book that I found fascinating was your statement that animation “doesn’t have to include large movements or even include motion at all.” Can you talk more about that? And is there any sort of relationship between animation and so called calm technology?

VH: It’s true, animation doesn’t always mean movement. Motion and animation are really two different things, even though we tend to use the words interchangeably. Animation is a change in some property over time, and that property doesn’t have to be a change in position. It can be a change in opacity, or color, or blur. Those kinds of non-movement animation convey a different feel and message than animation with a lot of motion.

If you stick to animating only non-movement properties like opacity, color, and blur, your interface will likely have a more calm and stable feel than if it included a lot of movement. So if your goal is to design something that feels calm, animation can definitely be a part of how you convey that feeling.

Any time you use animation, it says something, there’s no getting around that. When you’re intentional with what you want it to say and how it fits in with the rest of your design effort, you can create animation that feels like it’s so much a part of the design that it’s almost invisible. That’s a magical place to be for design.

MM: Do we also need to be mindful of the potential of animation to cause harm?

VH: We do. Animation can help make interfaces more accessible by reducing cognitive load, helping to focus attention in the right place, or other ways. But it also has potential to cause harm, depending on how you use it. Being aware of how animation can potentially harm or help users leads us to make better decisions when designing it. I included a whole chapter in the book on animating responsibly because it’s an important consideration. I also wrote about how animation can affect people with vestibular disorders a little while back on A List Apart.

MM: Who today, in your opinion, is doing animation right/well/interestingly?

VH: I’m always on the lookout for great uses of animation on the web—in fact, I highlight noteworthy uses of web animation every week in the UI Animation Newsletter.

Stripe Checkout has been one of my favorites for how well it melds UI animation seamlessly into the design. It really achieves that invisible animation that is so well integrated that you don’t necessarily notice it at first. The smooth 3D, microinteraction animation, and sound design on the Sirin Labs product page are also really well done, but take a completely different approach to UI animation than Checkout.

Publications have been using animation in wonderful ways for dataviz and storytelling lately, too. The Wall Street Journal’s Hamilton algorithm piece was a recent data-based favorite of mine and the New York Times did some wonderful storytelling work with animation around the Olympics with their piece on Simone Biles. Also, I really love seeing editorial animation, like the Verge had on a story about Skype’s sound design. The animations they used really brought the story and the sounds they were discussing come to life.

I really love seeing web animation used in such a variety of ways. It makes me extra excited for the future of web animation!

MM: Any parting thoughts, Val?

VH: My best advice for folks who want to use more animation in their work is to start small and don’t be afraid to take risks as you get more comfortable working with animation. The more you animate, the better you’ll get at developing a sense for how to design it well. I wrote Designing Interface Animation to give web folks a solid foundation on animation to build from and I’m really excited to see how web animation will evolve in the near future.

For even more web animation tips and resources, join me and a great bunch of designers and developers on the UI Animation Newsletter for a weekly dose of animation knowledge.



Designing Interface Animation

A note from the editors: We’re pleased to share Chapter 9 of Val Head’s new book, Designing Interface Animation: Meaningful Motion for User Experience, available now from Rosenfeld. For 20% off all books purchased through rosenfeldmedia.com, use the discount code ALADIA.

Each animation in an interface tells a micro story, and as a user encounters more and more animations throughout your site or product, these micro stories add up to reveal the personality and story of the brand or product behind them. The animations create an impression; they give your brand a certain personality. It’s up to us as designers to take control of the combined story that animations are telling about the brand we’re working on. Your animations will be much more effective if you intentionally design the additional messages they’re sending.

Brand animation design guidelines aren’t something entirely new, of course. Brands have been expressing themselves in motion in commercials, TV bumpers, video titles, and similar places for years, and they’ve had guidelines for those mediums. What’s new is the idea of needing animation design guidelines for the web or interfaces. Even if your brand will never be in a traditional commercial or video, having a website is enough of a reason to need a motion style guide these days.

How Your Brand Moves Tells Its Story

Deciding what you use animation for, and how you implement it, for a particular project defines how you express your brand or tell your brand’s story with animation. Often, the decisions of which properties to animate or what easing to use on which elements is done at the component or page level without considering the bigger picture. Assembling a global set of rules about motion and animation for your entire project will help you make more cohesive animation decisions moving forward. These choices lead to more consistent design decisions surrounding animation and make your design stronger overall. It requires you to go back and forth between the big picture of the overall project and the more detailed components, but your entire design will benefit from looking at the project from both perspectives as you work.

There are two approaches to begin defining how your brand expresses itself in motion. The first is to go from the bottom up: start by evaluating what you already have and build from there. The second is to go from the top down: first, determine what it is your brand should be saying about itself on a high level, and then determine how individual animations will express that concept.

The first approach works best for existing projects that already use animation. There could be hidden gems of communication to build upon in the animations you’ve already designed—ones that will inform the bigger picture you’re working to define. The second approach is generally your only option when starting a brand new project, as there won’t be any existing animation to start from. Whichever approach you choose (or even if you use both), you’ll arrive at the same end result, a common set of guidelines for putting your brand in motion, so they are equally good places to begin.

Defining Your Brand in Motion from the Bottom Up

Before you start documenting for the future, you need to get a good picture of what you’re currently using animation for. It’s hard to move forward before knowing where you currently stand. (That is, unless you’re planning to throw it all out and start over.) For existing projects that already use animation, you can start with a motion audit to find all the instances and ways you’re currently using animation. Collecting these in one place will identify the common threads and even help you eliminate unnecessary duplicated or overly similar animations. A motion audit will focus your animation efforts and the design reasoning behind them.

A motion audit gathers up all the interface animations you’re currently using to identify patterns and evaluate their effectiveness as a group.

The Motion Audit

To collect all your animations in one place, you’ll need some screen recording software that will output video. QuickTime is a handy built-in option for Macs, but a more specialized tool like ScreenFlow can save you some time with its more robust cropping and editing tools. Use whichever tool is easiest and fastest for you. The exact software used is less important than the end collection and what it will tell you.

How to do a motion audit (Fig. 9.1):

  • Collect screen recordings of every animation currently on your site. (Be sure to get a recording of all the different states for interactive animations.)
  • Crop and edit the video clips as needed to focus in on the animations.
  • Assemble all the video clips into one document and group them in categories according to content type (for example, one slide for all the button animations, one slide for navigation animations, etc.).
  • Review the document with your team to evaluate your brand’s existing animation style.

When you have all of those in one place, you can look for global trends, find potential redundancies, and most importantly, evaluate if the way you’re currently using animation accurately reflects the personality of your brand or product.

A screenshot of a page/slide of a motion audit document created for Shopify.
Fig 9.1: A screenshot of a page/slide of a motion audit document created for Shopify.

Software for Motion Audits

Recording Animations

For the screen recording part of motion audits, I like to use ScreenFlow. It’s Mac only, but Camtasia offers similar functionality for both Windows and Mac. The QuickTime player that comes installed with OS X is also an option. It’s especially good for recording animations from an iPhone. Just plug it into the computer and select it as a camera in QuickTime.

The Motion Audit Document

My preferred software for the end document is Keynote. (PowerPoint would do just fine here as well.) I prefer it because it makes it easy to set each animation’s video clip to play when clicked and because it lends itself well to be projected and discussed as a group.

When Keynote isn’t an option, creating a web-based motion audit is a good alternative. It’s easy to share, and the video clips can be played directly from within the web pages. I find that having the videos playable from the document is really useful. Often, you’ll discover animations that some of your teammates weren’t aware of or maybe haven’t encountered in a while.

The key is having an end result that can be shared and discussed easily. So if there’s another format that your team has a strong preference for, you can make that work, too.

Evaluate Your Existing Animation’s Design

The first question you’ll want to investigate is: Does the personality expressed by the existing animations fit your brand? Look at the qualities of the animations you’re using to answer this one. What kind of personality traits do the easing and timing used convey? If it’s snappy and bouncy, does that match your brand’s personality and energy? If it’s all stable ease-in-outs, is your brand personality also stable and decided? If you find the mood of the animations doesn’t fit your brand’s personality, small changes to the easing and timing could make a huge difference to bring the animation in line with your brand.

If the personality conveyed from your animations is all over the place and not cohesive at all, starting over and taking the top-down approach described might be the next best step. It’s often easier to work from the top down with a clear vision, as opposed to trying to fix a huge group of existing animations that are all a little bit off.

If the personality conveyed by your animations does fit your brand perfectly, great! Take a detailed look at what all these animations have in common. List the easing, timing, and other design choices they have in common. This will be the basis of your brand’s animation style guide.

Evaluate Your Existing Animation’s Purpose

Next, look at the purpose of the animations you’ve collected. How are they aiding your users in their tasks? Are they bringing something positive to the experience? Their purpose can be anything from something tactical like providing feedback to something more branding related like expressing your brand’s personality. Challenge yourself to articulate a purpose for each one to help you evaluate how useful they are. If there’s no definable purpose for an animation to be there, consider eliminating or redesigning it to have a solid purpose and goal. (Good UX purposes for animation are covered in Chapters 4 through 8.)

It’s also helpful to group the animations in your motion audit by their purpose—gathering up all the animations that are there to give feedback into one section, for example. This can reveal some helpful insights, similarities, and patterns among animations that share a similar purpose.

Define Your Brand in Motion from the Top Down

If your brand doesn’t currently use any animation or if you’re starting a new project, you can develop your brand’s animation design guidelines from the top down instead. That is, start from your brand’s design philosophy or the traits your brand aims to embody and decide how to translate those into animation. It’s starting from a different place, but it gets you to the same end goal of having specific and defined ways that your brand will exist in motion.

The Words You Use to Describe Your Brand

Start with the adjectives that you use to describe your brand or product. The description of the personality or feelings it aims to create. Is your brand energetic? Friendly? Strong? Playful? Stable? All this descriptive language can be translated into motion just like it can for other design tools like typography and color. Animation speaks in similar ways.

A great place to look for these descriptive words is in your copywriting guidelines or voice and tone guidelines. Many of the same words used to describe how to write for your brand can be directly applied to motion as well. Brand style guides or brand books can also be a good source for descriptive language.

If none of the above exists for your brand, you’ll need to do a little work to define your brand’s voice. “5 Easy Steps to Define and Use Your Brand Voice” by Erika Heald could be helpful for a quick start. Or to get even deeper into defining your brand, I recommend reading Designing Brand Identity by Alina Wheeler.

Energetic

If your brand is energetic, friendly, or bold, animation that relies on a lot of overshoots or follow-through and anticipation can help convey a sense of energy. Softly overshooting the target position can make animations feel both friendly and energetic. Drastic overshoots and quick speed changes read as bold and outgoing. Taken even further, adding a bit of bounce to overshoots or follow-through can convey a sense of even more energy in a movement—so much energy that an object has to bounce off its destination once or twice before it settles (Fig. 9.2).

Placement of square shapes in relation to a target finish line
Placement of square shapes in relation to a target finish line
Placement of square shapes in relation to a target finish line
Fig 9.2: Follow-through and overshoots in motion come across as energetic. The more exaggerated the movement, the more energy is implied. See it in action in this video.

Quick, soft movements—like overshoots—tend to read as energetic in a friendly way. On the other hand, quick movement with sharp changes in direction can suggest impatience, curtness, or urgency. That kind of movement is difficult to show in print, but you can see a video version here to see what I mean.

Playful and Friendly

Playful brands can take advantage of squash and stretch to convey that playfulness (Fig. 9.3). Squash and stretch also makes movements read as energetic. However, beware, because it can also make motion look childish or sloppy if it’s done with too much of a heavy hand. But, on the other hand, when it’s done well, it can really set you apart.

Bouncy easing can also evoke friendliness or playfulness. Wobbly bounces can seem playful and elastic, while springy bounces can seem friendly.

Rounded and elliptical shapes suggesting changes in dimension
Rounded and elliptical shapes suggesting changes in dimension
Rounded and elliptical shapes suggesting changes in dimension
Fig 9.3: Squash and stretch tends to create a sense of playfulness and a little goes a long way. See it in action in this video.

Decisive and Sure

Ease-in-outs—that is any easing that gradually speeds up into the action, is fastest in the middle, and then slows at the end of the action—are balanced and stable. They produce animation that accelerates into the action and then slows down to hit its end target exactly and with precision and decisiveness. Sticking with variations of ease-in-outs can communicate a sense of stability and balance for your brand. A variation of ease-in-out easing applied to a simple horizontal movement would look like this video example in Fig. 9.4.

A graphic illustration the curves of an ease-in-out progression
Fig 9.4: Motion with ease-in-out easing like the graph above, and similar easing curve variations, tends to read as calm and decisive action because elements move fastest in the middle of the action and decelerate into their final position. You can see the resulting motion in this video.

Calm

The amount of movement you employ can also say something about your brand. Animation doesn’t necessarily have to include large movements or even include motion at all. Smaller movements read as more calm and subtle than larger more drastic movements. Using smaller movements can contribute to the stable and calm personality of your brand.

You can still imply the same kinds of movements, just in a less drastic way. For example, when you aim to create small movements, you might have a modal animate into place from 50% of the way down the screen instead of 100% off-screen past the bottom of the visible area (Fig. 9.5).

Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Fig 9.5: Both squares in the frames above arrive at the same destination, but the first one gets there by moving a shorter distance. This smaller movement often reads as feeling calmer and more subdued than larger movements. See both in action in video: small movements vs. large movements.

Stable

Animating properties like opacity and blur instead of creating movement is another way of conveying a sense of calm and stability (Fig. 9.6). (Animating these properties will change the appearance of the object—making it more transparent or blurred, for example—but because the position of the element isn’t being animated, no movement will occur.) It can also convey a sense of softness or even feel dreamy, depending on how softly you use the opacity and blurs. Sticking to these nonmovement properties can still say so much about your brand in small spaces where motion may not be possible or desirable.

A square shape progressively becoming transparent
A square shape progressively becoming transparent
A square shape progressively becoming transparent
Fig 9.6: Animating non-motion properties, like blur and opacity, can read as more stable and subtle. See it in action in this video.

These are just the start of adjectives to consider when trying to convey a specific type of energy in the design of your animation. Like most other design tools, it’s more of an art than a science. Experiment with the guidelines to find what expresses your brand best for you.

Referencing Motion from Real Life

Looking to the physical world can be a great option for finding your brand’s style for motion by finding a physical object or creature to emulate with your on-screen animation. Technically, you could choose anything at all to base your motion on, but this works best when the thing you choose is relevant—either literally or metaphorically—to your product or brand.

IBM has done a wonderful job of this with its Machines in Motion design guidelines. IBM used to make those giant, room-sized computers, typewriters, and other hardware before becoming the IBM they are today. They decided to reach back to their rich history as a company when defining how they would express their brand in motion (Fig. 9.7).

Screenshot of IBM’s Machines in Motion design guidelines
Fig 9.7: IBM’s Machines in Motion design guidelines pair movements from the physical products IBM used to make with matching motion for their animation interactions. See it in action.
 

They used these past machines to inform their motion design efforts on two levels. On a high level, they chose four machine traits that all their interface motions should embody: agility, efficiency, precision, and order. From there, they got more specific and paired motion from the actual machines with screen-based equivalent animations. On-screen menu drawers are animated to have the same motion as the carriage return motion of a 1970s IBM typewriter. Loading spinners are animated to have the same acceleration patterns as reel-to-reel tapes of an old mainframe’s tape drives.

These one-to-one translations of motion from the historical real-world objects to the screen-based motion inform all of their motion design decisions. If you have physical objects, either historical or not, that are significant to your brand or product, you could develop your own guidelines using this same approach.

A more metaphorical approach to emulating real-world objects can work well, too. Finding a particular dance piece or animal movement that speaks to the same personality values as your brand can be a great place to start. Music can be a source of motion inspiration, even if you’re not including any sound in your interface. Choosing a specific rhythm or phrasing from music to apply to your animation’s movement brings a whole new dimension to the idea of UX choreography. There are so many possibilities out there. Find something that feels inspiring for your brand and explore how it can establish a cohesive thread through all your animations.

Staying on Point

  • Animation design guidelines or values can help keep your brand’s motion efforts consistent and cohesive.
  • Collecting and evaluating existing animations as a group with a motion audit can give you valuable insight into how you’re currently using animation.
  • The same words you use to describe your brand and its values can be translated into motion to define your brand’s motion style.
  • Looking to real-world objects or animals to emulate can also help define what your brand looks like in motion.




 
 
 
 
 

Affiliates

New Tutorials Photoshop Tutorials
Tutorial Man Wallpaper Stock  More

Resources