Subscribe: A List Apart
http://www.alistapart.com/feed/rss.xml
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
animation  data  design  email  it’s  new  page  people  task  test  testing  time  web  we’re  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-11-22T15:00:00+00:00

 



This week's sponsor: O’REILLY DESIGN CONFERENCE

2016-11-28T05:01:00+00:00

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

(image)



Insisting on Core Development Principles

2016-11-22T15:00:00+00:00

The web community talks a lot about best practices in design and development: methodologies that are key to reaching and retaining users, considerate design habits, and areas that we as a community should focus on. But let’s be honest—there are a lot of areas to focus on. We need to put users first, content first, and mobile first. We need to design for accessibility, performance, and empathy. We need to tune and test our work across many devices and browsers. Our content needs to grab user attention, speak inclusively, and employ appropriate keywords for SEO optimization. We should write semantic markup and comment our code for the developers who come after us. Along with the web landscape, the expectations for our work have matured significantly over the last couple of decades. It’s a lot to keep track of, whether you’ve been working on the web for 20 years or only 20 months. If those expectations feel daunting to those of us who live and breathe web development every day, imagine how foreign all of these concepts are for the clients who hire us to build a site or an app. They rely on us to be the experts who prioritize these best practices. But time and again, we fail our clients. I’ve been working closely with development vendor partners and other industry professionals for a number of years. As I speak with development shops and ask about their code standards, workflows, and methods for maintaining consistency and best practices across distributed development teams, I’m continually astonished to hear that often, most of the best practices I listed in the first paragraph are not part of any development project unless the client specifically asks for them. Think about that. Development shops are relying on the communications team at a finance agency to know that they should request their code be optimized for performance or accessibility. I’m going to go out on a limb here and say that shouldn’t be the client’s job. We’re the experts; we understand web strategy and best practices—and it’s time we act like it. It’s time for us to stop talking about each of these principles in a blue-sky way and start implementing them as our core practices. Every time. By default. Whether you work in an internal dev shop or for outside clients, you likely have clients whose focus is on achieving business goals. Clients come to you, the technical expert, to help them achieve their business goals in the best possible way. They may know a bit of web jargon that they can use to get the conversation started, but often they will focus on the superficial elements of the project. Just about every client will worry more about their hero images and color palette than about any other piece of their project. That’s not going to change. That’s okay. It’s okay because they are not the web experts. That’s not their job. That’s your job. If I want to build a house, I’m going to hire experts to design and build that house. I will have to rely on architects, builders, and contractors to know what material to use for the foundation, where to construct load-bearing walls, and where to put the plumbing and electricity. I don’t know the building codes and requirements to ensure that my house will withstand a storm. I don’t even know what questions I would need to ask to find out. I need to rely on experts to design and build a structure that won’t fall down—and then I’ll spend my time picking out paint colors and finding a rug to tie the room together. This analogy applies perfectly to web professionals. When our clients hire us, they count on us to architect something stable that meets industry standards and best practices. Our business clients won’t know what questions to ask or how to look into the code to confirm that it adheres to best practices. It’s up to us as web professionals to uphold design and development principles that will have a strong impact on the final product, yet are invisible to our clients. It’s those elements that our clients expect [...]



The Coming Revolution in Email Design

2016-11-15T15:00:00+00:00

Email, the web’s much maligned little cousin, is in the midst of a revolution—one that will change not only how designers and developers build HTML email campaigns, but also the way in which subscribers interact with those campaigns. Despite the slowness of email client vendors to update their rendering engines, email designers are developing new ways of bringing commonplace techniques on the web to the inbox. Effects like animation and interactivity are increasingly used by developers to pull off campaigns once thought impossible. And, for anyone coming from the world of the web, there are more tools, templates, and frameworks than ever to make that transition as smooth as possible. For seasoned email developers, these tools can decrease email production times and increase the reliability and efficacy of email campaigns. Perhaps more importantly, the email industry itself is in a state of reinvention. For the first time, email client vendors—traditionally hesitant to update or change their rendering engines—are listening to the concerns of email professionals. While progress is likely to be slow, there is finally hope for improved support for HTML and CSS in the inbox. Although some problems still need to be addressed, there has never been a better time to take email seriously. For a channel that nearly every business uses, and that most consumers can’t live without, these changes signal an important shift in a thriving industry—one that designers, developers, and strategists for the web should start paying attention to. Let’s look at how these changes are manifesting themselves. The web comes to email It’s an old saw that email design is stuck in the past. For the longest time, developers have been forced to revisit coding techniques that were dated even back in the early 2000s if they wanted to build an HTML email campaign. Locked into table-based layouts and reliant on inline styles, most developers refused to believe that email could do anything more than look serviceable and deliver some basic content to subscribers. For a few email developers, though, frustrating constraints became inspiring challenges and the catalyst for a variety of paradigm-shifting techniques. When I last wrote about email for A List Apart, most people were just discovering responsive email design. Practices that were common on the web—the use of fluid grids, fluid images, and media queries—were still brand new to the world of email marketing. However, the limitations of some email clients forced developers to completely rethink responsive email. Until recently, Gmail refused to support media queries (and most embedded styles), leaving well-designed, responsive campaigns looking disastrous in mobile Gmail apps. While their recently announced update to support responsive emails is a huge step forward for the community, the pioneering efforts of frustrated email developers shouldn’t go unnoticed. Building on the work first introduced by MailChimp’s Fabio Carneiro, people like Mike Ragan and Nicole Merlin developed a set of techniques typically called hybrid coding. Instead of relying on media queries to trigger states, hybrid emails are fluid by default, leaving behind fixed pixels for percentage-based tables. These fluid tables are then constrained to appropriate sizes on desktop with the CSS max-width property and conditional ghost tables for Microsoft Outlook, which doesn’t support max-width. Combined with Julie Ng’s responsive-by-default images, hybrid coding is an effective way for email developers to build campaigns that work well across nearly every popular email client. (image) Responsive-by-default images with HTML attributes and inline CSS. More recently, two other methods have emerged that address the issues with mobile email using more advanced techniques. Bot[...]



This week's sponsor: ADOBE XD

2016-11-14T05:01:00+00:00

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

(image)



Awaken the Champion A/B Tester Within

2016-11-01T14:00:00+00:00

Athletes in every sport monitor and capture data to help them win. They use cameras, sensors, and wearables to optimize their caloric intake, training regimens, and athletic performance, using data and exploratory thinking to refine every advantage possible. It may not be an Olympic event (yet!), but A/B testing can be dominated the same way. I talked to a website owner recently who loves the “always be testing” philosophy. He explained that he instructs his teams to always test something—the message, the design, the layout, the offer, the CTA. I asked, “But how do they know what to pick?” He thought about it and responded, “They don’t.” Relying on intuition, experienced as your team may be, will only get you so far. To “always test something” can be a great philosophy, but testing for the sake of testing is often a massive waste of resources—as is A/B testing without significant thought and preparation.  Where standard A/B testing can answer questions like “Which version converts better?” A/B testing combined with advanced analyses gives you something more important—a framework to answer questions like “Why did the winning version convert better?” Changing athletes, or a waste of resources? Typical A/B testing is based on algorithms that are powered by data during the test, but we started trying a different model on our projects here at Clicktale, putting heavy emphasis on data before, during, and after the test. The results have been more interesting and strategic, not just tactical. Let’s imagine that Wheaties.org wants to reduce bounce rate and increase Buy Now clicks. Time for an A/B test, right? The site’s UX lead gets an idea to split test their current site, comparing versions with current athletes to versions featuring former Olympians. Wheaties page design. But what if your team monitored in-page visitor behavior and saw that an overwhelming majority of site visitors do not scroll below the fold to even notice the athletes featured there? Now the idea of testing the different athlete variants sounds like a waste of time and resources, right? But something happens when you take a different vantage point. What if your team watched session replays and noticed that those who do visit the athlete profiles tend to stay on the site longer and increase the rate of “Buy Now” clicks exponentially? That may be a subset of site visitors, but it’s a subset that’s working how you want. If the desired outcome is to leverage the great experiences built into the pages, perhaps it would be wise to bring the athlete profiles higher. Or to A/B test elements that should encourage users to scroll down. In our experience, both with A/B testing our own web properties and in aggregating the data of the 100 billion in-screen behaviors we’ve tracked, we know this to be true: testing should be powerful, focused, and actionable. In making business decisions, it helps when you’re able to see visual and conclusive evidence. Imagine a marathon runner who doesn’t pay attention to other competitors once the race begins. Now, think about one who paces herself, watches the other racers, and modifies her cadence accordingly. By doing something similar, your team can be agile in making changes and fixing bugs. Each time your team makes an adjustment, you can start another A/B test ... which lets you improve the customer experience faster than if you had to wait days for the first A/B test to be completed. The race is on Once an A/B test is underway, the machines use data-based algorithms to determine a winner. Based on traffic, conversion rate, number of variations, and the minimum improvement you want to detect, the finish line may be days or weeks away. What is an ambitious A/B tester to do? Watch session replay of each variation immediately, once you’ve received a representative number of visitors. Use them to valid[...]



Let Emotion Be Your Guide

2016-11-01T14:00:00+00:00

We were sitting in a market research room in the midst of a long day of customer interviews. Across from us, a young mother was telling us about her experience bringing her daughter into the ER during a severe asthma attack. We had been interviewing people about their healthcare journeys for a large hospital group, but we’d been running into a few problems. First, the end-goal of the interviews was to develop a strategy for the hospital group’s website. But what we’d discovered, within the first morning of interviews aimed at creating a customer journey map, was that hospital websites were part of no one’s journey. This wasn’t wildly surprising to us—in fact it was part of the reason we’d recommended doing customer journey mapping in the first place. The hospital had a lot of disease content on their site, and we wanted to see whether people ever thought to access that content in the course of researching a condition. The answer had been a resounding no. Some people said things like, “Hmm, I’d never think to go to a hospital website. That’s an interesting idea.” Others didn’t even know that hospitals had websites. And even though we’d anticipated this response, the overwhelming consistency on this point was starting to freak out our client a little—in particular it started to freak out the person whose job it was to redesign the site. The second issue was that our interviews were falling a little flat. People were answering our questions but there was no passion behind their responses, which made it difficult to determine where their interactions with the hospital fell short of expectations. Some of this was to be expected. Not every customer journey is a thrill ride, after all. Some people’s stories were about mundane conditions. I had this weird thing on my hand, and my wife was bugging me to get it checked out, so I did. The doctor gave me cream, and it went away, was one story. Another was from someone with strep throat. We didn’t expect much excitement from a story about strep throat, and we didn’t get it. But mixed in with the mundane experiences were people who had chronic conditions, or were caregivers for children, spouses, or parents with debilitating diseases, or people who had been diagnosed with cancer. And these people had been fairly flat as well. We were struggling with two problems that we needed to solve simultaneously. First: what to do with the three remaining days of interviews we had lined up, when we’d already discovered on the morning of day one that no one went to hospital websites. And second: how to get information that our client could really use. We thought that if we could just dig a little deeper underneath people’s individual stories, we could produce something truly meaningful for not only our client, but the people sitting with us in the interview rooms. We’d been following the standard protocol for journey mapping: prompting users to tell us about a specific healthcare experience they’d had recently, and then asking them at each step what they did, how they were feeling and what they were thinking. But the young mother telling us about her daughter’s chronic asthma made us change our approach. “How were you feeling when you got to the ER?” we asked. “I was terrified,” she said. “I thought my daughter was going to die.” And then, she began to cry. As user experience professionals we’re constantly reminding ourselves that we are not our users; but we are both parents and in that moment, we knew exactly what the woman in front of us meant. The entire chemistry of the room shifted. The interview subject in front of us was no longer an interview subject. She was a mother telling us about the worst day of her entire life. We all grabbed for the tissue box, and the three of us dabbed at our eyes together. And from that point on, she didn’t just tell us her story as though we were three people [...]



Liminal Thinking

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

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



Network Access: Finding and Working with Creative Communities

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

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



This week's sponsor: INDEED PRIME

2016-10-24T04:01:00+00:00

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

(image)



JavaScript for Web Designers: DOM Scripting

2016-10-18T14:00:00+00:00

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



Using CSS Mod Queries with Range Selectors

2016-10-11T14:00:00+00:00

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



A Redesign with CSS Shapes

2016-10-04T14:00:00+00:00

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



This week's sponsor: Adobe XD

2016-10-03T04:01:00+00:00

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

2016-09-27T14:00:00+00:00

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



Why We Should All Be Data Literate

2016-09-20T14:00:00+00:00

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



This week's sponsor: OPTIMAL WORKSHOP

2016-09-19T04:01:00+00:00

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

(image)



Designing Interface Animation: an Interview with Val Head

2016-09-13T14:05:00+00:00

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



Designing Interface Animation

2016-09-13T14:05:00+00:00

A note from the editors: We’re pleased to share Chapter 9 of Val Head’s new book, Designing Interface Animation: Meaningful Motion for User Experience, available now from Rosenfeld. For 20% off all books purchased through rosenfeldmedia.com, use the discount code ALADIA.Each animation in an interface tells a micro story, and as a user encounters more and more animations throughout your site or product, these micro stories add up to reveal the personality and story of the brand or product behind them. The animations create an impression; they give your brand a certain personality. It’s up to us as designers to take control of the combined story that animations are telling about the brand we’re working on. Your animations will be much more effective if you intentionally design the additional messages they’re sending. Brand animation design guidelines aren’t something entirely new, of course. Brands have been expressing themselves in motion in commercials, TV bumpers, video titles, and similar places for years, and they’ve had guidelines for those mediums. What’s new is the idea of needing animation design guidelines for the web or interfaces. Even if your brand will never be in a traditional commercial or video, having a website is enough of a reason to need a motion style guide these days. How Your Brand Moves Tells Its Story Deciding what you use animation for, and how you implement it, for a particular project defines how you express your brand or tell your brand’s story with animation. Often, the decisions of which properties to animate or what easing to use on which elements is done at the component or page level without considering the bigger picture. Assembling a global set of rules about motion and animation for your entire project will help you make more cohesive animation decisions moving forward. These choices lead to more consistent design decisions surrounding animation and make your design stronger overall. It requires you to go back and forth between the big picture of the overall project and the more detailed components, but your entire design will benefit from looking at the project from both perspectives as you work. There are two approaches to begin defining how your brand expresses itself in motion. The first is to go from the bottom up: start by evaluating what you already have and build from there. The second is to go from the top down: first, determine what it is your brand should be saying about itself on a high level, and then determine how individual animations will express that concept. The first approach works best for existing projects that already use animation. There could be hidden gems of communication to build upon in the animations you’ve already designed—ones that will inform the bigger picture you’re working to define. The second approach is generally your only option when starting a brand new project, as there won’t be any existing animation to start from. Whichever approach you choose (or even if you use both), you’ll arrive at the same end result, a common set of guidelines for putting your brand in motion, so they are equally good places to begin. Defining Your Brand in Motion from the Bottom Up Before you start documenting for the future, you need to get a good picture of what you’re currently using animation for. It’s hard to move forward before knowing where you currently stand. (That is, unless you’re planning to throw it all out and start over.) For existing projects that already use animation, you can start with a motion audit to find all the instances and ways you’re currently [...]



This week's sponsor: HIRED

2016-09-12T04:01:00+00:00

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

(image)



Webfonts on the Prairie

2016-09-06T14:00:00+00:00

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