Subscribe: A List Apart
Added By: Feedage Forager Feedage Grade A rated
Language: English
animation  content  data  design  designers  it’s  list  make  new  page  people  task  time  web  website  window  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: A List Apart

A List Apart: The Full Feed

Articles for people who make web sites.

Published: 2016-10-25T14:00:00+00:00


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 [...]

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”). 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 favo[...]

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> document.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[...]

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? 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[...]

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 wid[...]

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). 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). 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 overal[...]

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 [...]

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 an[...]

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, 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 m[...]

This week's sponsor: HIRED


HIRED, the most efficient way to find a new job. Get exposed to 4,000+ companies with just 1 application.


Webfonts on the Prairie


I last wrote about the progress of webfonts for A List Apart six years ago. Very few sites used webfonts then, but there was a lot of pent-up frustration among designers to get moving after 15 years of confinement to so-called “web-safe” system fonts. And move they did. With the learn-as-you-go self-reliance that web creators have always been so good at—a slick change in syntax to grease this thing here, a polyfill to patch that thing there—we’ve come a long, long way with very little preparation. A success by anyone’s measure (mostly) As of May 2016, a majority of sites—60% of the Alexa Top 1 Million Sites—were using webfonts, up from only 2% in 2011. Image: HTTP Archive. In “Efficient Web Type, Circa 1556”, designer Kenneth Ormandy notes that “we are building sites that request more fonts, from an 8kb average transfer size at the beginning of 2012 to a 59kb average two years later.” Image: HTTP Archive. Data also shows that soon after a site adopts webfonts, it will likely add more: the number of requests go up and, so too, do the sizes of the files requested. An exodus away from system fonts is clearly underway. Webfonts have reached critical mass and will soon be the new normal in web typography. Now, whether webfonts, cloud computing, or animation, the adoption of new technologies means potential users have come to terms with their fears about them. These fears can be very irrational, and they can persist long after the conditions that gave rise to them are gone. For example, in 2009, web performance expert Steve Souders—then at Yahoo—warned web designers that they should, if at all possible, stay away from webfonts: “My first piece of advice is to avoid using @font-face unless it’s critical to the page.” Whoa. Okay, but that was back then. This is 2016. With usage at 60 percent, surely nobody would seriously argue for a return to system fonts, right? Wrong. In a post called “Webfonts”, web designer Adam Morse says we should all just say no to webfonts and insists that system fonts are a better choice. What? Just say no Morse writes: There are a lot of arguments around why you should use webfonts. In none of those arguments, have I heard about a single problem being solved for users. He goes on: Over the last three years I have participated in a number of testing sessions. In that time I never heard a user complain about: the use of system fonts in a design. a website having the same typeface as another site. a page using system fonts that loaded too quickly. a site NOT using web fonts. On the flip side I: observed users abandon a website because the page was loading slowly. heard people complain about the dreaded flash of unstyled text. In sum, Morse’s attitude is that web fonts aren’t worth the trouble they cause some users—especially in low-bandwidth conditions—and that sticking with tried-and-true system fonts is best for all concerned. Well. In less time than it takes to say “Holy holdout, Batman!” web designer Robin Rendle posted a rebuttal. A few days later came Frederic Marx’s “Webfonts Last”. And in between those volleys, both Jeffrey Zeldman and Jeremy Keith took note of the disturbance in the force and I, sucked into the vortex, offered to write this article. C’est le web. Morse’s criticisms obviously hit a sore spot with Robin Rendle and Frederic Marx and, frankly, me too. But why so touchy after all this time? Webfonts are a runaway train and anyone standing astride the tracks shouting stop is just asking to get plowed over. Didn’t everybody get the tweet about this? Well, maybe not—maybe some people genuinely aren’t aware that webfonts have become so popul[...]

This week's sponsor: ADOBE XD


ADOBE XD. Go from idea to prototype faster. Test drive the Adobe XD preview for Mac and tell us what you think.


Help! We (Think We) Need to Hire a Content Strategist


Those of us working in content strategy know that it is a rich and complicated discipline. We understand, of course, that there are different types of content strategists. But we need to remember that outside of our content strategy bubble, the discipline is still pretty new to colleagues and clients. As the discipline matures and more companies are looking to hire for content strategy, how can companies educate themselves on how to use our specific skills? I’ve recently been on the job market. And so I’ve spent a lot of time wading through content strategy job listings and meeting with hiring managers. My experience suggests that people beginning to actively hire content specialists frequently have little understanding of what their companies need beyond a title. I would even estimate that about half of my interviews over the past few months have consisted of talking through and refining job descriptions with those sitting across the table from me. Hiring managers at agencies, brands, and startups would do well to hire based on the type of work they want to focus on—not on a price tag or a title. Like experience design (which content strategy is sometimes folded into), content strategy has subspecialties. Some strategists veer more toward the UX side: user research, content maps, content modeling. Others specialize in PR and native advertising (social media, influencer outreach, and content discovery); still others focus more on content management systems and governance. Some content strategists even overlap with digital strategists (considering the audience, conversion, and the larger digital ecosystem), but then also do some of the more tactical, executional work to bring these digital ecosystems to life. Others may specialize in search and organic growth. Increasingly, former journalists have started to position themselves as content strategists, using their expertise with long-form and mid-length content to cash in on the boom in native advertising work and branded content creation. And let’s not forget how industry and categories figure into the equation. For example, if you are an ecommerce brand hiring a content strategist for a website relaunch, you may want a content strategist with past experience in ecommerce working on your site, given your specific conversion challenges. Similarly, for highly regulated spaces like financial services, healthcare, or alcohol, a content strategist with past experience navigating these categories makes sense. If you don’t practice content strategy, talk to someone who does For any company trying to make their first content-strategy hire, the most logical place to start is talking with a real live content strategist. I don’t mean that you should reach out to a content strategist on the pretense that this is a position for them and then use an interview to pick their brain (and waste their time). For starters, that’s not very nice; furthermore, you don’t want anyone spreading the word that your company doesn’t know what it’s doing and may not be the best place to work. No, I mean that you should formally engage a content strategist as a consultant. Have them talk to your team, take a look at your business, help write up an accurate job description, and even start recruiting through their network for the specific position you seek to fill. Chances are they know a lot of good people in their community who would be a perfect fit for the role. Too often, I’ve seen job descriptions written by someone who is obviously not a content strategist and interviews conducted by people who don’t really understand the discipline. This is likely because, depen[...]

Why Aren’t You Asking Questions?


It’s the kickoff meeting. You are the lead designer on the project, and this is the first meeting with everyone in the room. Your client is reciting her wish list, and you’re taking diligent notes—probably with cute, relatable doodles. An hour passes, and you’ve barely said a sentence. You’re nodding your head, scarcely making eye contact. You have some thoughts, but you aren’t speaking up. Why aren’t you speaking up? You’ve likely been burned in the past. Perhaps you’ve shared some ideas and they were turned down. You have felt embarrassed in meetings. Projects that you put your heart and soul into were changed at the last minute without your consultation or discarded, apparently without a second thought. Now, while it’s admirable to be an agreeable, easy-to-work-with colleague, being quiet and keeping your head down isn’t the answer because this is not a production line. You are a designer, and part of your job is contributing to the conversation. It’s a designer’s job to ask good questions You want to do your best work and meet your client’s needs, so playing an active role in the conversation is vital. To extract the most information you can from your client, you must ask questions. Lots of questions. Think of it like playing detective, gathering clues and working to understand the players in the game. Laura Kalbag writes, “As designers, we can’t expect other people to know the right language to describe exactly why they think something doesn’t work. We need to know the right questions that prompt a client to give constructive criticism and valuable feedback.” They are looking to you as the professional to not only listen to their needs, but to also be able to identify and understand their unexpressed needs. It is not the client’s job to know exactly what their logo should be or how their website should function. That’s your job. They are coming to you to share ideas, to express concerns, likes, and dislikes. They are looking to you to help guide them to a solution. Clients will always ask you to make their logo bigger, prescribe solutions, and ask you to do things that will make you smack your forehead. You can roll your eyes at how much they don’t understand about design or you can roll up your sleeves and begin practicing your craft by helping them clarify what they need. Mike Monteiro from his brilliant and on point book Design is a Job First, understand the end users’ needs It’s pretty likely that your client isn’t the main user of the website or product you are designing. Even if they are amazing at articulating exactly their tastes and preferences, it’s beside the point because they are not the target audience. If you are fortunate enough to be on a project that dedicates resources to user research, familiarize yourself with its findings. If you do not have access to this information, ask a few questions about who the end user is and what their needs are to better understand the target audience you are actually designing for: Who exactly do you anticipate will be using this website? What problem is this website solving for them? Or What will they accomplish by using this website? What are their pain points? Once you establish who the end user is, try to phrase your upcoming questions in a way that encourages the client to see through the eyes of the end user, not their own. User experience consultant and writer Paul Boag simplifies this on “A client’s natural inclination will be to give you his personal opinion on the design. This is reinforced because you ask them what they think of the design. I[...]

This week's sponsor: CONTENTFUL


CONTENTFUL, an API-first, developer-friendly CMS. Build custom content-rich front-end with the tools of your choice.


Communicating Animation


Consistent animation is crucial to both branding and UX. Interfaces obey laws of “design physics”; keeping animation consistent throughout an experience envelops users in an illusion of life, of reality. Animations that step out of line disrupt that flow and feel sloppy or jarring. But because animation sits squarely at the intersection of design, development, and UX, achieving consistency presents unique challenges: Communication issues make it hard for siloed teams to understand and tackle animations together. Inadequate deliverables prevent developers from moving forward quickly. Lack of respect for and deference to fellow team members leads to lopsided implementations that privilege some voices at the expense of others. When it comes to animation, it’s important for everyone to be heard. Including animations in our style guides and design systems is a great place to start. However, this is relatively new territory, and most animation documentation initiatives seem to be driven by either development or design. In an ideal world, developers and designers would live in harmony and collaboration, but all too often the two houses exist in isolation from each other. Most examples of animation in documentation reflect this rift by falling into one of two categories: thematic and educational, as seen in Google’s Material Design guidelines; or granular and explicit, as displayed in Salesforce’s Lightning Design System. Designers want to provide guidance and overarching themes, as well as educational materials, in an effort to raise the profile of animation both within a company and within the larger web design and development communities. Meanwhile, developers aspire to define and dictate animation for maintainability and consistency. This contrast reflects the needs of each group. Designers want to know the underlying principles of motion design driving their application; developers want to know how to build that design to spec. These interests are not at odds with each other—rather, they form incomplete halves of a greater whole: Documentation details what’s there and why. Defaults offer building blocks and rules for spinning up new projects. Unity provides a common language and choreography. Guidance empowers future designers to make smart decisions. As of this writing, there is no Ultimate Animation Style Guide/Pattern/Tile/Whatever example that combines all of these elements perfectly. There may never be an animation-style-guide pattern that satisfies everyone. Some organizations may need more of some of the above components than others, depending on the project and the animation or development literacy of the team. But all approaches share features that we can combine to create the Ultimate Animation Documentation for our own teams. Let’s have a look. Deliverables Deliverables are supposed to round off the design process, but I often find it helpful to start with what developers want and need. Some companies have designers who build prototypes in code. Developers then find it easy to go into the code and grab the variables needed to reproduce the UI animations. But not all workflows look like this, and many motion designers will rightly argue that the very act of animating code-first limits the ideation process. That’s why, at many companies, designers create animations in After Effects or Photoshop and then hand them off to developers. The developers must then pick apart these videos and gifs to determine what is changing at what rate. This makes the burden of implementation especially heavy for the[...]

Another 10k Apart: Create a Website in 10 KB, Win Prizes!


It gives us great pleasure to announce the 2016 10k Apart competition. Create a fully functioning website in 10 KB or less! Amaze your friends! Astound the world! Compete for fabulous prizes!

Why 10k? Why now? It’s simple, really. In the 16 years since we told you about the first contest to create a functioning website in 5 KB or less, countless aspects of web design and development have changed. And, year after year, A List Apart has marked those changes, even instigating more than a few of them ourselves. But in all those years, one thing has remained constant: the need to keep our websites lean. Indeed, in the age of mobile slash responsive slash multidevice design, keeping sites lean and mean is more important than ever.

In 2000, Stewart Butterfield launched the original 5k competition to celebrate the skill, ingenuity, and innovation of designers and developers who wring every byte of performance out of the websites and applications they fashion. Ten years later, Microsoft and An Event Apart launched the first 10k Apart—adding progressive enhancement, accessibility, and responsive web design to the competition’s requirements.

And now, An Event Apart and Microsoft Edge have teamed up once more to entice you, the makers of websites, to improve your performance game yet again by competing in a new 10k Apart that’s even tougher than the last one. Golly!

Ah, but there’s gain for your pain. Besides fame and glory, you could win $10,000 in cash, tickets to An Event Apart, the complete A Book Apart series, and a copy of Aaron Gustafson’s Adaptive Web Design, 2nd Edition, which I consider the unofficial successor to Designing With Web Standards. So what are you waiting for? Hop on over to the 10k Apart website for complete rules and details.