Subscribe: A List Apart
Added By: Feedage Forager Feedage Grade B rated
Language: English
animation  content  data  design  designers  fig  it’s  make  new  page  svg  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-18T14:00:00+00:00


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 out a string of property keys—we use a helper method built into document that g[...]

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) and the :first-child selector. The following query selects everything if the li[...]

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

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 overall customer experience. Repeatable. Create task questions that you can test again [...]

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

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

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 motion audit will focus your animation efforts and the design reasoning behind them[...]

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 popular. As Rob Larsen observes in his book The Uncertain Web: Most of the time, [...]

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, depending on the organization and the kind of content strategy work you do, your role c[...]

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. Instead ask them what their users will think of the design.” It is also possible[...]

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 developer, giving animation a reputation for “taking too long to prioritize.”[...]

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.


Practical SVG


A note from the editors: We’re pleased to share an excerpt from Chapter 6 of Chris Coyiers’s new book, Practical SVG, available now from A Book Apart.You’ll probably want to exert some sizing control over any graphic you put on a website. Hey! You! Logo! You should be this size: (image) .logo { width: 220px; height: 80px; } And so shall it be. But if the element you are resizing happens to be svg, the result might not be exactly what you expect. Sizing svg is a little more complicated than sizing an img. I’m not saying this to scare you. It’s almost complicated in a good way, because it gives you more control and opens up some interesting possibilities. Keep these two concepts in mind when you’re working with the size of SVG images: The viewport is simply the height and width of the element: the visible area of the SVG image. It’s often set as width and height attributes right on the SVG itself, or through CSS. The viewBox is an attribute of svg that determines the coordinate system and aspect ratio. The four values are x, y, width, and height. Say we’re working with some SVG like this: In this case, the viewport and viewBox are in perfect harmony (Fig 6.1). The SVG will be drawn in the exact area it visually occupies. See the Pen adqEmQ by Chris Coyier (@chriscoyier) on CodePen. Fig 6.7: Example of preserveAspectRatio="none". Poor little buggers. Amelia Bellamy-Royds wrote a comprehensive article on scaling SVG, in which she covers things like the fact that svg can essentially contain other svg with different aspect ratios and behavior, so you can make some parts of an image scale and others not, which is pretty cool and unique to SVG. Approaches to artboard sizing When you draw SVG in editing software, that software likely gives you some kind of artboard to draw on. That’s not a technical SVG term; it’s essentially a visual metaphor for viewBox. Let’s say you’re working with a whole set of icons for a site. One approach is to make all artboards hug each edge of the icon (Fig 6.8). Fig 6.8: Example of graphics in Adobe Illustrator cropped to their edges. Here’s a quick trick to get that artboard cropping in Illustrator: select the Artboard tool and then “Fit to Artwork Bounds” from the Presets menu (Fig 6.9). Fig 6.9: The menu option in Adobe Illustrator for resizing an artboard to the edges of a graphic. The big advantage to this technique is alignment (Fig 6.10). If you want to align any edge of any of these icons to anything else, that’s easy to do. There is no mysterious space you need to contend with, or tweaky positional CSS. .icon.nudge { position: relative; right: -2px; /* UGHCKKADKDKJ */ } Fig 6.10: Icons aligning to edges without little bits of extra space you have to account for. The big disadvantage to the cropping technique is relative sizing. Imagine you take the practical step of sizing your icon’s width and height, like this: .icon { width: 1em; height: 1em; } A tall, skinny icon will shrink to fit in that space and potentially appear awkwardly small. Or perhaps you’re trying to have an intentionally small star shape as an icon, except the star has a squarish aspect ratio and thus grows to fill the space, appearing bigger than you want it to. Here’s an example where two icons are sized identically as a square (Fig 6.11). The “expand” icon looks right at home, since it has a square aspect ratio to match. But the[...]

This week's sponsor: HIRED


​HIRED, where companies apply to you. Get your profile in front of 4,000+ companies with one application.

Finding Opportunities in the Mistakes We Make


Roughly six years into my software development career, I had worked on interesting projects, met amazing people, and had the opportunity to travel to exotic cities. Yet I was frustrated. I was burning the candle at both ends to get things done. I didn’t look back to see if I could improve on how things were being done; I had no time. Deep down I knew it wasn’t feasible. I was working hard, not smart; I felt like I wasn’t working toward anything; I was falling behind with technology. I was burning out. I started searching for an opportunity to facilitate my technical growth. Two years later I was based at an enterprise client who adopted agile software development methodologies, and everything changed for me. This new world exposed me to a diverse working environment and new perspectives, and encouraged me to ask even more questions than before. This is when I discovered the power of the words “reflect, inspect, and adapt.” It wasn’t a walk in the park with unicorns and rainbows, but the experience has aided me in officially branding my career as one exciting journey of professional and self-discovery. Now ten years into my career, I realize that for most of that time I have been in survival mode. After looking back, I’d like to share how I found opportunities in the mistakes I made. Define clear career and personal goals Computers weren’t a household name when I was growing up in South Africa, but I was lucky to have access to my dad’s Pentium 386. I was amazed at this technology. When we got internet access, I was immediately hooked on the online world. I taught myself HTML and later built my own machine with the money I made from designing a website for the local newspaper. When I chose my higher education path I had one goal—I wanted to make websites. I didn’t want a degree; I wanted experience. I studied at a college for two years, then excitedly entered the workforce to follow my passion. As I entered the workforce, I wasn’t prepared for the politics: managers expecting things to be done almost immediately; clients who don’t engage and are unsure of what they want; clients who express urgency, yet wait for the last minute to provide you with everything you need; an increased workload due to colleagues who stay well inside their comfort zone. These are just some examples of the politics that initiated my frustrations. I wondered if this is where I’d still be in five or ten years and if I would be able to sustain it. I didn’t know the answer to the former, but to the latter it was definitely no. Coupled with turning thirty, the new perspectives I developed in the agile environment made me really evaluate my future. I realized that I didn’t have goals; I was only chasing my passion. Granted, it is fun and I gained a lot of experience in many different areas in IT, but I don’t have anything tangible to show for it now. After much reflection, I discovered these goals for myself: Increase productivity. I minimize distractions like email, social media, and uninvited guests to improve my productivity. To make sure I am working on the right tasks, I need to have a clear understanding about what I am working on and why. Develop software that has a positive impact on people. It is important to understand business thinking and impact on users. I need to ask appropriate questions, and I need to guide and negotiate with product stakeholders. Share my knowledge. I can create an online identity (publish articles, blog), possibly speak at events, and contribute to open-source s[...]