Subscribe: A List Apart
http://www.alistapart.com/rss.xml
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
animation  content  data  design  experience  it’s  make  new  people  svg  task  time  user  web  work  years  you’re 
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-09-27T14:00:00+00:00

 



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 examples of top tasks. If you measure and then seek to improve the performance of tiny tasks (low demand tasks) you may be contributing to a decline in the overall customer experience. Repeatable. Create task questions that you can test again in 6 to 12 months. Representative and typical. Don’t make the task questions particularly difficult. Start [...]



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 design is being able to explain why you made specific design decisions.) If someone emails you a spreadsheet and says, “These numbers say why this design has to be 5 percent more blue,” you need to be able to check the data and evaluate whether this is a good decision or just plain bonkers. Yes, this is part of the job. It’s So Easy Look, [...]



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 can design on the web and another avenue for reflecting on what the rich histories of design, animation, and film can teach us. Mica McPheeters: Do you find that animation often gets tacked on at the end of projects? Why is that? Shouldn’t it be incorporated from the outset? VH: Yes, it often does get left to the end of projects and almost treated as [...]



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 using animation. Collecting these in one place will identify the common threads and even help you eliminate unnecessary duplicated or overly similar animations. A motion audit will focus your animation efforts and the design reasoning behind them. A motion audit gathers up all the interface animations you’re currently using to identify patterns an[...]



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 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, front-line developers don’t get to spend time looking at the big picture…Even folks who are tasked wit[...]



This week's sponsor: ADOBE XD

2016-09-01T00:33:00+00:00

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

(image)



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

2016-08-30T14:00:00+00:00

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 could easily sit in Strategy, Creative, UX, Product, Communications, or PR. And if you’re a content strategi[...]



Why Aren’t You Asking Questions?

2016-08-23T14:00:00+00:00

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 24ways.org: “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 that the client thinks they understand what the end user needs, but they are only working from assumptions. [...]



This week's sponsor: CONTENTFUL

2016-08-22T04:01:00+00:00

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

(image)



Communicating Animation

2016-08-16T14:00:00+00:00

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.” I myself once had to spend six hours converting an animated GIF to SVG by eyeballing it. If the des[...]



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

2016-08-15T14:00:00+00:00

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.

(image)



Practical SVG

2016-08-09T14:00:00+00:00

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 “zap it” icon has a tall and narrow aspect ratio, so it looks wimpy, like it’s floating in the same squ[...]



This week's sponsor: HIRED

2016-08-08T12:25:00+00:00

​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

2016-08-02T14:00:00+00:00

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 software. I can find projects on GitHub of libraries and tools that I regularly use and create a pull request.[...]



Resurrecting Dead Personas

2016-07-26T14:00:00+00:00

Being a user-centered designer means that you deliberately seek out the stories, data, and rationale behind your users’ motivations. You endeavor to keep user concerns at the forefront of every design decision, and regularly conduct research and collect data. But collecting facts about users isn’t the same as knowing your users. Research and data need to be regularly aggregated, analyzed, and synthesized into a format that is both understandable and accessible at critical moments. You need to turn user facts into user wisdom, and one of the most common methods for doing this is to develop user personas. Type “how to build user personas” into your favorite search engine and you will get thousands of results outlining different templates and examples of personas. Across the tech industry, personas “put a human face on aggregated data,” and help design and product teams focus on the details that really matter. Studies have shown that companies can see 4x the return on investment in personas, which explains why some firms spend upwards of $120,000 on these design tools. However, while it is common for design teams to spend considerable amounts of time and money developing personas, it is almost as common to see those personas abandoned and unused after a while. Everett McKay, Principal at UX Design Edge, has pointed out that user personas can fail for a number of reasons, such as: They do not reflect real target users. They are not developed with product goals in mind. They are not embedded into team processes. I agree with everything McKay suggests, but I would add that personas fail largely because of one common misconception: the false idea that once you build a persona, you’re done. As designers, we know that the first version of a product is never perfect, but with multiple rounds of design and research it can be made better. Personas are no different. To recover personas that have become lifeless, here’s how you can iterate on them with periodic research and use them to achieve tangible goals. The following steps will help ensure you see value from the investment you made developing them in the first place. Let’s put your personas (back) to work and incorporate them into your design and development process. How a persona dies Let’s imagine you work at a company called Amazing Childcare that creates tools to help parents find childcare options for their children. Let’s also say you have the following data and statistics for AmazingChildcare.com: 82% of customers are between the ages of 30 and 35, and 73% of those are female. The most common concerns around finding childcare (as reported in user interviews) are cost and quality of care received. AmazingChildcare.com has a homepage bounce rate of 40%. Customer satisfaction survey shows an average satisfaction rating of 6.5 (out of 10). While this data is interesting, it is hard to process and assimilate into your design practice. You still need to go through the arduous work of understanding why the majority of users are who they are, what problems they are trying to solve, and how you can better meet their needs. So, you decide to create a persona. The persona you create is Susan, a 34-year old working mother of a two-year-old. She is interested in finding a qualified nanny that has passed a background check. Susan, like all freshly made personas, is a much more thought-provoking platform for crafting design solutions than a spreadsheet of numbers. She is someone we can imagine, remember, and empathize with. This is the point in the story when Susan dies. At first, the design team enjoys thi[...]



Adapting to Input

2016-07-19T14:00:00+00:00

Jeremy Keith once observed that our fixed-width, non-responsive designs were built on top of a consensual hallucination. We knew the web didn’t have a fixed viewport size, but we willfully ignored that reality because it made our jobs easier. The proliferation of mobile devices forced us into the light. Responsive web design gave us the techniques to design for the rediscovered reality that the web comes in many sizes. And yet there is another consensual hallucination—the idea that desktop equals keyboard and mouse, while phones equal touch. It’s time to break free of our assumptions about input and form factors. It’s time to reveal the truth about input. Four truths about input Input is exploding — The last decade has seen everything from accelerometers to GPS to 3D touch. Input is a continuum — Phones have keyboards and cursors; desktop computers have touchscreens. Input is undetectable — Browser detection of touch‚ and nearly every other input type, is unreliable. Input is transient — Knowing what input someone uses one moment tells you little about what will be used next. Being adaptable In the early days of mobile web we created pitfalls for ourselves such as “mobile context.” We’ve since learned that mobile context is a myth. People use their phones everywhere and for any task, “especially when it’s their only or most convenient option.” When it comes to input, there is a danger of making a similar mistake. We think of a physical keyboard as being better suited to complex tasks than an onscreen keyboard. But there are many people whose primary access to the internet is via mobile devices. Those same people are comfortable with virtual keyboards, and we shouldn’t ask them to switch to a physical keyboard to get the best experience. Even for those of us who spend our days on computers, sometimes a virtual keyboard is better. Perhaps we’re on a plane that has started to descend. In that moment, being able to detach a keyboard and work on a touchscreen is the difference between continuing our task or stowing our laptop for landing. So who are we to judge what input is better? We have no more control over the input someone uses than we do the size of their screen. Becoming flexible Confronting the truth about input can be overwhelming at first. But we’ve been here before. We’ve learned how to design for a continuum of screen sizes; we can learn how to adapt to input—starting with these seven design principles. Design for multiple concurrent inputs The idea that we’re either designing for desktop-with-a-mouse or touch-on-mobile is a false dichotomy. People often have access to multiple inputs at the same time. Someone using a Windows 10 laptop or a Chromebook Pixel may be able to use the trackpad and touchscreen concurrently. There are many web pages that detect touch events and then make incorrect assumptions. Some see the touch events and decide to deliver a mobile experience regardless of form factor. Others have different branches of their code for touch and mouse and once you’re in one branch of the code, you cannot switch to the other. At minimum, we need to ensure that our web pages don’t prevent people from using multiple types of input. Ideally, we would look for ways to take advantage of multiple inputs used together to create better experiences and enable behavior that otherwise wouldn’t be possible. Make web pages that are accessible When someone uses a remote control’s directional pad to interact with a web page on a TV, the browser sends arrow key events behind the scenes. Th[...]



The Itinerant Geek

2016-07-14T14:00:00+00:00

This spring I spent almost a month on the road, and last year I delivered 26 presentations in eight different countries, spending almost four months traveling. While doing all of this I am also running a business. I work every day that I am on the road, most days putting in at least six hours in addition to my commitments for whichever event I am at. I can only keep up this pace because travel is not a huge stressor in my life. Here are some things I have learned about making that possible, in the hope they are useful to anyone setting off on their first long trip. Add your own travel tips in the comments. Before you go During the run-up to going away, I stay as organized as possible. Otherwise I would lose a lot of time just preparing for the trips. I have a Trello board set up with packing list templates. I copy a list and remove or add anything specific to that trip. Then I can just grab things without thinking about it and check them off. I also use Trello to log the status of plans for each trip; for example, do I have a hotel room and flights booked? Is the slide deck ready? Do I know how I am getting from the airport to the hotel? This way I have instant access to the state of my plans and can also share this information if needed. It is easy to think you will always have access to your information in its original form. However, it is worth printing a copy of your itinerary to keep with you just in case you can’t get online or your phone battery runs out. For times when you don’t have physical access to something at the moment, take photos of your passport and car insurance (if it covers rentals), and upload them somewhere secure. Your travel may require a visa. If your passport is expiring within six months of your trip, you may want to get a new one — some countries won’t issue a visa on a passport that is due to expire soon. You can in some cases obtain pre-authorization, such as through the American ESTA form for participating in its Visa Waiver Program. This might have changed since your last trip. For example, Canada has introduced an eTA system as of March 2016. I’ve traveled to Canada for ConFoo for the last four years - if I attend next year, I’ll need to remember to apply for this beforehand. Tell your bank and credit card company that you are traveling to try and avoid their blocking your card as soon as you make a purchase in your destination. Make sure you have travel insurance that covers not only your possessions but yourself as well. Be aware that travel insurance will not pay out if you become sick or injured due to an existing condition that you didn’t tell them about first. You will have to pay an increased premium for cover of an existing issue, but finding yourself with no cover and far from home is something you want to avoid. Make sure that you have sufficient of any medicine that you need. Include some extra in case of an unscheduled delay in returning home. I also usually pack a few supplies of common remedies - especially if I am going somewhere that is not English speaking. I have a vivid memory of acting out an allergic reaction to a Polish pharmacist to remind me of this! I also prepare for the work I’ll be doing on the road. In addition to preparing for the talks or workshops I might be giving, I prepare for work on Perch or for the business. I organize my to-do list to prioritize tasks that are difficult to do on the road, and make sure they are done before I go. I push tasks into the travel period that I find easier on the small screen of my laptop, or that I can complete even[...]



Strategies for Healthier Dev

2016-07-12T14:00:00+00:00

Not too long ago, I was part of a panel at the launch event for TechLadies, an initiative that encourages women to learn to code. Along the way, I mentioned a bit about my background as an athlete. As we were leaving to go home, the woman next to me jokingly asked if I was a better basketball player or a better developer. Without missing a beat, I said I was a better basketball player. After all, I’ve been playing basketball for over half my life; I’ve only been coding for two and a half years. We’ve probably all come across the stereotype of the nerdy programmer who is all brains and no brawn. I’m a counterexample of that cliché, and I personally know developers who are avid cyclists or marathon runners—even a mountain climber (the kind who scales Mount Everest). And yet a stereotype, “a widely held but fixed and oversimplified image,” often comes into existence for a reason. Think of Douglas Coupland’s Microserfs. Think of any number of mainstream dramas featuring wan (usually white, usually male) programmers staring at screens. Many so-called knowledge workers are too sedentary. Our lives and work stand to benefit if we become less so. Now, no one likes to suffer. And yet when it comes to exercise or training, it’s too easy for us to think that fitness is all about self-discipline—that we just need to have the willpower to persevere through the agony. But that’s not a good strategy for most people. Unless you genuinely find pleasure in pain and suffering, you have to want something badly enough to endure pain and suffering. Ask any athlete if they enjoy running extra sprints or lifting extra weights. Even Olympic medalists will tell you they don’t. They do it because they want to be the best. My point is this: forcing yourself to do something you don’t enjoy is not sustainable. I’ll be the first to admit that I’m not a big fan of running. A little ironic coming from someone who used to play basketball full-time, maybe, but the only reason I did any running at all, ever, was because competitive basketball required me to. When I stopped training full-time, I simply couldn’t muster the energy or motivation to get up and run every day (or even every week, for that matter). So I had to come up with a different game plan—one that required minimal effort, near-zero effort, and minor effort. You can do it, too. No excuses. Ready? Minimal effort I’m lazy. I’m pretty good at talking myself out of doing things that require extra effort to get ready for. For example, going swimming requires that I pack toiletries, a fresh set of clothes, and goggles. Then I actually need to make it to the pool after work before it closes, which means I have to plan to leave the office earlier than I usually might, and so on. Guess what? Eight out of ten times, I end up telling myself to go swimming next time. By contrast, I commute to work on my bicycle. Yes, it helps that I love to ride. I thoroughly enjoy swimming, too—just not enough to overcome my laziness. But because cycling is my main mode of transportation, I don’t even think about it as exercise. It’s just something I do as part of my day, like brushing my teeth. The “while-you’re-at-it” technique works very well for me, and maybe it’ll work for you, too. In a nutshell: build healthy habits into things you already do. Kind of how parents hide vegetables in more palatable stuff to get their kids to eat them. Near-zero effort Let me list some simple activities that involve minimal effort, but have significant returns [...]