There's a huge resource of Newsfeeds on the Net which brings up-to-date
information and content on a wide range of subjects.
Here are just a few relating to web development.
Looking for great freelance designers and developers to grow your team? Sponsor Toptal is here to help.
With the newest versions of the two most popular mobile operating systems, iOS 9 and Android M, third-party native applications will be able to respond to URLs, rather than a web browser, enabling deep-linking into applications. Tapping a link to a tweet will open Twitter’s official application and display it there, if the application is installed, rather than navigating to the tweet in the default browser.
This has some major implications for what we think of as “the web,” and how we build experiences for it. I don’t think “the web” consists only of websites. I see everything we build that is connected via the internet as “the web.” As John Gruber said:
We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors.
The things we build are—and should be—peers, but the shared language of the web, the URL, has not been fulfilling its “universal” promise. And yet, the universality of the web is what makes it one of the greatest technological achievements in human history.
After championing progressive enhancement for so long, we know that not all experiences are the same—nor should they be. I see URL-enabled applications as the next level in the progressive enhancement approach: those with the associated app installed will be sent to the app, since we might reasonably assume that’s their preferred experience, those without the app installed (or without it available on their device altogether) will be sent to the website.
I’ve talked before about not drawing such hard lines between experiences, and about letting operating systems handle the parts they can handle best. Application deep-linking is a great example of both. Another level has been opened up for our progressively-enhanced experiences, and it’s up to us to take advantage of that.
“Cool URIs don’t change.” Even cooler ones work everywhere.
Paper books and vinyl records: they’re not just for hipsters anymore. I’ve tried to hold back on commenting on this cultural shift toward more analog products, because it’s such an easy target for jokes. But I think it’s time for us to face the inevitable: there’s a very peaceful and quiet revolution happening right under our noses. And those of us who work in software have to start paying attention to it.
The evidence for this shift is all around us. Craig Mod’s recent essay on reading made a big impact online. In Future Reading he describes his journey there and back again—from paper books to going all-digital for many years, to an almost unconscious shift back to paper. What’s interesting about the article is not only what’s there, but what’s not. Gone is the nostalgic longing for “the smell of books” that is the butt of so many jokes. In its place we find arguments for the tangible benefits of reading non-digital books—their permanence, their design, their readability.
Closer to home, a friend told me recently that he went back to buying CDs because he needs the physical reminder of what’s in his music library. Digital music just kind of disappears once the files go “in the computer.” As for me, I’ve been bearing the brunt of my friends’ ridicule for a while now, since I went back to buying vinyl records. Yes, I think they sound better than digital music, but my reasons also have a lot to do with permanence and tactility—it’s an activity I can enjoy with my daughters, and something that will hopefully bring back positive memories for them once I’m long gone and they sort through their (inherited) collection. And I’m clearly not alone in this.
All of these thoughts have been swimming in my head as I reflected on what I really want to talk about in this column: the idea that “software is never done.” This has become a rallying cry in our industry—a way to push ourselves to constantly make things better. We use those words for anything from excuses to ship terrible MVPs, to arguments with engineers about why we need to move that button 3px to the left. Some of the consequences of this meme are good. Continuous, incremental improvement is a good thing. But there are also some bad parts.
It isn’t that long ago that software actually was done when it came out. Only a couple of decades ago, new operating systems showed up on a CD-ROM and we made VHS videos about how to use them:
When Windows 95 came out, it was done. Yes, there were some patches to it, but they were few and far between, and in general quite difficult to come by. But of course, then the internet and app stores happened, and suddenly everything changed.
The thing about “software is never done” is that sometimes the software gets better, but often it does not. Talk to any long-time Evernote user about the product changes over the past year and see if they’re able to contain their rage. Take a look at the recent release of Paper by FiftyThree and how this beloved product has become close to incomprehensible. Last night I just wanted to watch something, but when I turned on my PS4 I had to wait ten minutes for it to update. I have no idea what changed. Everything still looked the same. But hey, software is never done. Even our updaters need updates sometimes.
Contrast this way of looking at the world to the architect’s view of the buildings they design. Here is Jennifer Fraser in What I Bring to UX From Architecture:
As an architect, the implicit permanence of designing a building carries with it a sense of responsibility… I can’t help but wonder if we would have better designed products if some of that responsibility and sense of permanence of architecture found its way into what we do as user experience designers.
As an architect, the implicit permanence of designing a building carries with it a sense of responsibility… I can’t help but wonder if we would have better designed products if some of that responsibility and sense of permanence of architecture found its way into what we do as user experience designers.
And here’s Tony Fadell, talking about the creation of the Nest thermostat:
Fadell looks out at the Manhattan skyline and says that he always wanted to be an architect; that buildings stay beautiful forever but digital devices are quickly obsolete. “You look at hardware or software five years later? They’re crap. You would never use them again. People use architecture all the time.”
His voice rises. “What is our form of architecture? What is the thing that lasts of beauty?”
Fadell looks out at the Manhattan skyline and says that he always wanted to be an architect; that buildings stay beautiful forever but digital devices are quickly obsolete. “You look at hardware or software five years later? They’re crap. You would never use them again. People use architecture all the time.”
His voice rises. “What is our form of architecture? What is the thing that lasts of beauty?”
So I wonder. I wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the product we make might not only be done at some point, but might be something that lasts for a while? Would we make it fit into the web environment better, give it a timeless aesthetic, add fewer unnecessary features, and spend more time considering the consequences of our design decisions?
All of this brings me back to the analog revolution. I’m fascinated by our renewed passion for things that are permanent (warts and all) and tactile. I think we need to take that trend seriously, and it needs to influence the way we make.
To make this more concrete, I think we need more software that has ties to physical objects. I know we’re a bit disillusioned with the “Internet of Things”—and for good reason. But I know we can do better. Designers like Josh Clark have been thinking and writing about this for a while. It’s within our reach to bring some physicality to some of our designs.
Most importantly, I think we need more software that’s done—not all of it, just more of it. Just like we’re always going to have prefab buildings to serve a particular function at a particular time, software that continues to change and improve pushes us forward and is absolutely necessary. But maybe it’s ok for that app you’re working on to be done. And by going into it with a realization that it’s going to be done some day, you might even make something that lasts for decades.
We don’t have to give up on digital products, or fight the analog revolution. But we must learn from it, take what’s good, and throw away the rest. And on that note, let’s at the very least agree that dragging a file into a trash can isn’t nearly as satisfying as crumpling up a piece of paper and throwing it over your shoulder.
“We want to go viral!” says the chief communications officer. “Can’t help you” used to be our standard answer. But by doing this, we’ve left social media in the hands of marketers and self-appointed “gurus” more concerned with Klout than user needs. It’s about time we reclaimed social media.
If the web industry had a Maslow’s hierarchy of needs, social platforms would be at the very top—the least essential thing. No one ever visited a website and said, “Well, I was not able to register, but they had a really nice blog and quite an impressive Instagram feed!”
But social has its place—and it is tied to so much of the work we already do. Whether you are working to increase conversions, looking for an additional source of user research, or want to enforce a consistent brand, social media should be part of your toolbox.
In most organizations, social content is the messiest content there is, with (even more) distributed ownership and few strategic imperatives besides “get more likes.” Such organizations are in dire need of your governance skills.
The first step is to take an inventory of your social channels. Most companies have tried to participate in every new channel in search of “the next big thing.” There may not have been much of a strategy beyond uploading your logo to another new service. How many social media accounts does your organization have? (You might even find several accounts on the same service).
Create a spreadsheet and list all your channels. Add a column for who controls each account (the answer might be “no one”). Do you have the passwords to all the accounts? Which email was the account registered to? Add that information. Make sure that all the accounts are registered on a company email like firstname.lastname@example.org, not to your intern’s personal gmail. Other useful spreadsheet columns might identify the number of followers on each account and the account’s monthly budget.
Way too often, success in social media is measured in likes, retweets, and reach. But how can you defend spending resources on these channels if you can’t explain how they’re connected to the organization’s bottom line?
You need to ensure that your social media channels will be working in symphony with your other channels, as well as in line with the organization’s overall strategies. To do that, you should create goals that are specific yet channel-agnostic, such as increasing sales, increasing customer satisfaction, reducing costs, and so forth.
Here is an excerpt from Plan International Norway’s goals for their digital channels:
These are truly channel-agnostic goals, which also means that there’s no need to come up with completely new KPIs with every new social channel that pops up.
After you’ve decided on overall goals, subgoals, and KPIs, you need to decide which specific channels should be used for which goals and which audiences.
This will require user research. You need to know which target groups you’ll meet in which channels—and what they need from you. Otherwise, you might be Instagramming away while your customers only use Pinterest. The research techniques you’re already using for your website will work great for social media, too. (If you don’t know where to start, check out Just Enough Research by Erika Hall.)
The users you decide to target on social media might—and probably should—differ across channels, and even differ from your website. It just depends on your business goals and where your target groups are. For instance, Plan International uses Twitter to target journalists, politicians, and opinion leaders to reach their goal of influencing public policy. On their website, however, their biggest target groups are potential donors and existing donors, to reach their goals of increasing earnings.
Social media has so many different but overlapping use cases that there’s usually an ongoing battle about who should be in charge of it. Marketing? Communications? IT? HR? Customer service? Sales? And what about the lawyers who keep sticking their noses in our business?
Because of this, each social media channel needs to have an owner. This owner has a mandate to control the channel in the way they believe will most effectively reach the goals and KPIs that have been ratified by management. This person is in their absolute right to say “No” when someone says, “We need you to get this on Facebook right now!” if it isn’t clearly connected to the ratified strategy.
Channel ownership is not enough, however, if you want to use your digital channels to their full potential. Someone needs to make sure that the channel owners collaborate and work in line with the strategy. In some organizations, we’ve dubbed this role “channel coordinator.” Whatever the title, the main point is that they’re making sure the digital channel strategy is implemented on a day-to-day basis.
In practice, much of social media work is trying to write the right tweet at the right time—always in a hurry.
You can avoid the last-minute panic by planning your posts ahead of time. Some weeks, you may get bombarded with requests for posts; other weeks, you may roam the web for interesting tidbits simply to post something. An editorial calendar can help keep your content in balance.
To identify important dates throughout the year, talk to your colleagues in other departments. What are the biggest events, milestones, and campaigns for marketing, customer service, communications, and so on? What holidays and external events might impact social media involvement? Organize these dates and events in a spreadsheet.
When you have identified all the important dates, you will be one step closer to determining what your most important social content will be. If there will be a big summer campaign, what will you tweet when you launch it? Do you need to order some special content in advance, like videos or infographics?
Here’s a simplified example of a yearly plan from the University of Oslo:
As you can see, their yearly plan includes events that matter to the university—like the Abel prize—and events that revolve around user needs—taking exams and getting grades.
Remember, social media is a push medium. You cannot push content when your audience is not ready to receive it, like interesting science news when everyone is gone skiing during the holidays. An editorial calendar that takes all these different dates into account can help you determine when your audience might be most receptive to your messages.
The yearly plan lets you prepare for the bigger milestones, but a weekly plan helps you manage day-to-day details: which channels should we use, what do we want to achieve, and how should we measure success?
Here’s an example of a weekly plan of Facebook posts for the University of Oslo:
A plan like this makes it easier to craft your posts. You don’t have to scramble at the last minute to come up with ideas. You can make sure you have the pictures you need in advance. By keeping an eye on KPIs, you can track what kind of content your audience responds best to.
Okay, you’ve cleared the clutter. You’ve made a plan. You know what to write about when and where. But how do you create great social content?
Yes, you can improve your writing in five minutes. The secret is writing with a partner, which does wonders for all kinds of copy. (This article was pair-written!) Writing with a partner helps give your copy a more consistent tone of voice. It’s also the quickest way to spot weak copy and avoid writer’s block. Pair writing is an opportunity to teach and learn better copywriting without sending a draft back and forth.
For each post, ask yourself, or your writing partner, seven questions designed to make your posts more purposeful and appealing:
(Credit for this checklist goes to digital fundraiser Beate Sørum; for more on the principles of crafting good content, see Erin Kissane’s great content checklist.)
Let’s dive a bit deeper into each question:
Don’t post just to “inform” or “share” something. You should never start composing a post if you don’t really know why you’re doing it or how it will meet your users’ needs.
This is where our approach to social media connects to the core model approach. A core is a piece of information or functionality where your users solve their task, and you reach a business objective. With a social media post, the key question is: is this post a forward path to something else or a core itself?
If the post itself will solve user needs and help you reach your objectives simply by being perceived by your audience, then the post is the core. For example, one of the University of Oslo’s objectives is to help international students feel at home, so they post their event info directly to Facebook, where international students are more likely to see it, instead of on their website.
Twitter has already forced you down to 140 characters or less, but you should strive for brevity in all channels. You might think you have almost limitless characters on Facebook, but remember that Facebook cuts you short with the so-called blue link of death if your post is too wordy.
Clarity is especially important if you are sharing a link. Users will read your post squeezed in between other posts that might be a lot more interesting than what you’re offering—clarity helps your link stand out in the feed.
The title, the description, and the thumbnail photo should be as clear as possible. Can you tell what the content is about just by reading the excerpt? (Remember that people who share your link will often not bother to add their own commentary).
Sharing is not a question of positive or negative emotions. Intensity and effect are more important. If you want to entice people to share or comment, try to evoke emotions that speed up pulses and make people lean closer to the screen: amazement rather than amusement, surprise rather than mere interest, and so on (as demonstrated by academic research).
To share your content, users have to feel comfortable interacting with your content in front of their own channel audience.
Appealing to emotions can be useful, but it’s not always appropriate for the context or your brand. Instead, it may be more helpful to share content that allows people to demonstrate their knowledge—for instance, content that lets them debate a topic they are publicly engaged in. Humorous content might also appeal to sharing behaviors; humor can make people feel less nervous about sharing more sensitive topics.
Study your copy and ask: Would my users feel comfortable sharing this?
Content must always align with your brand. Emotional or humorous posts attract attention, but may be at odds with your organization’s tone of voice. You can help content creators by creating short guidelines for brand, voice and tone, and editorial style for crafting social media copy. (For further reading, check out these articles on personality in design and how to craft a design persona.)
One of the benefits of writing posts in advance is being able to plan the timing. Use analytics to see when your audience is most active, check your editorial calendar, and choose topics that will resonate for maximum impact. If your target audience has regular jobs, posting during lunch hour might be perfect. But if you are writing for students, posting late at night might not be such a bad idea.
Content strategy and governance didn’t emerge as a field overnight. It took years of baby steps. One of those important baby steps was simple writing guidelines, like using bulleted lists, headings, and links that don’t read “click here.” (Now’s the time to reread Kristina Halvorson’s article on content strategy from 2008.)
Many people still treat their company’s social media channels like we treated our own private accounts in 2009: they get an idea, they post it, they refresh and look for likes, end of strategy. Others are slaves to the ever-changing algorithms of Facebook and lose sight of the long-term goals.
If you take stock of your social channels, assign them key target groups, and establish channel-agnostic goals, you’ll have a head start on the competition. By allocating responsibility, creating a yearly plan, and drafting your posts in advance, your content will be more aligned with both your business goals and user needs. And, if nothing else, you can use pair writing and the seven questions to improve your next tweet straightaway.
In the words of Kristina Halvorson: “The web is content. Content is the web. It deserves our time and attention.” That is true for social content as well. We hope you are ready to reclaim social from marketing. We know we are.
Ever since Ethan Marcotte started talking about responsive web design in 2010, developers and designers have been scrambling to find ways to deal with the issue of responsive images. It’s a thorny problem because we’re serving the same website, with the same image sources, across a wide range of device widths. Do you want a blurry, pixelated image on a large display? Or do you want to load a huge (but oh-so-pretty) image on your mobile phone? Talk about being stuck between a rock and a hard place.
Loads of smart people, namely the Responsive Issues Community Group (RICG), have been working together to solve this conundrum. That’s why the picture element and the srcset and sizes attributes are being drafted into the HTML 5.1 specification. Because we cannot predict where and how users are going to view our websites, we need the browsers themselves to pick the best image for the situation. The new specification will address the following issues:
The spec also introduces two new attributes—srcset and sizes—to the img element. srcset lets us declare a set of image sources, which browsers will serve according to certain conditions we specify using descriptors. x descriptors indicate the pixel-density of the images, while w descriptors indicate the width of the images; the browser will use this information to pick the appropriate image from the list. The sizes attribute provides the browser with some context on the size of the image element to be displayed, and must be included when using srcset with w descriptors. This is especially relevant for variable-width images, which I’ll discuss in detail later.
The point is, we now have the option of serving images of different quality or art direction depending on the user’s viewport, without some complicated server-side setup. Responsive images will become part and parcel of the HTML specification; eventually, all browsers will support this solution.
Now, let’s take a tour of the selection types and how you can make them work for you.
With the introduction of Retina screens, it became necessary to take into account not only screen resolution but also pixel density. Retina screens, 4K displays, UltraHD—all of these have way more pixels packed into them than a standard resolution display of the same size. More pixels = sharper image quality.
If, for some reason, you have an image that will always display at a certain width regardless of screen size—the site logo or a profile image, say—then device-pixel-ratio-based selection is the way to go. The browser will choose which image to load based on its device-pixel ratio.
The srcset attribute basically lists the pool of source images from which the browser can pick to load. It’s a comma-separated list. The x descriptor indicates the device-pixel ratio of the image. Depending on what environment the browser is operating in, it will utilize this information to select the appropriate image. Any browsers that don’t understand srcset will simply load the image declared in the src attribute.
<img srcset="crest-383.jpg 1.5x, crest-510.jpg 2x" src="crest-255.jpg" alt="USWNT crest" />
An example of a fixed-width image might be a site’s logo, which remains the same size regardless of viewport width. Content-related images, however, are usually responsive; their sizes tend to change depending on the viewport. For those types of images, there’s a better method.
For fluid-width images, we use srcset with the w descriptor and sizes. The w descriptor tells the browser the width of each image in the list. The sizes attribute is also a comma-separated list containing two values. As of the latest specification, if the srcset has any images using the w descriptor, then the sizes attribute must be present as well.
There are two values in the sizes attribute. The first is a media condition. The second is the source-size-value, which determines the width of the image given that particular media condition. One important thing to note is that you can’t use percentages as the source-size-value; the only relative CSS length you can use is vw.
<img srcset="uswnt-480.jpg 480w,
sizes="(max-width: 400px) 100vw,
(max-width: 960px) 75vw,
src="uswnt-640.jpg" alt="USWNT World Cup victory">
Here, I’m telling the browser that for viewport widths up to 400 pixels, make the image 100% of the viewport width. At viewport widths up to 960 pixels, make the image 75% of the viewport width. And for everything above 960 pixels, make the image 640 pixels. If you’re unfamiliar with vw, take a look at Tim Severien’s great article explaining viewport units.
The browser utilizes the information from srcset and sizes to serve the image that best matches the stated conditions. If my browser’s viewport is 600 pixels, it would most likely display the image at 75vw. The browser will try to load the first image larger than 450 pixels, which is uswnt-480.jpg. If I’m on a Retina display with a device-pixel ratio of 2, then the browser will try to load the first image larger than 900 pixels, which should be uswnt-960.jpg. We can’t be certain of exactly which image will be served because each browser has some leeway in how their algorithm picks an appropriate image based on the information we provide. This is what “viewport-based selection” means.
Because the first two examples display the same image at different quality levels, the srcset attribute alone is sufficient. Again, if you’re worried about legacy browsers, that’s what the src is for—those browsers will just treat it as a regular image and load from src. If you want to show slightly different images at different widths, for example, showing only the critical parts of an image at smaller widths, then use the picture element.
The picture element is like a wrapper for the image and its sources. Browsers still need img to recognize that an image needs to be served; without img, nothing will render at all. source provides the browser alternate versions of the image to display. Art direction-based selection is used for situations when we want a specific image to display at a specific breakpoint. There is no ambiguity in terms of image selection when you use the picture element.
<source media="(min-width: 960px)" srcset="ticker-tape-large.jpg">
<source media="(min-width: 575px)" srcset="ticker-tape-medium.jpg">
<img src="ticker-tape-small.jpg" alt="USWNT ticker-tape parade">
In this example, when the viewport is larger than 960 pixels, a landscape-oriented version of the image (ticker-tape-large.jpg) is loaded. For widths larger than 575 pixels, the browser loads a cropped portrait-oriented image (ticker-tape-medium.jpg) instead. And for widths smaller than 575 pixels, the image (ticker-tape-small.jpg) loaded has been cropped to focus just on one player.
The picture element is backwards compatible; browsers that don’t support the picture element will display img as usual. All standard attributes for images, like alt, should be applied to img, not picture.
A number of new image formats have come into existence in recent years. These new image formats offer better quality at lower file sizes. Sounds good, right? Until you realize that none of these formats is universally supported across all browsers. Google’s WebP performs very well, but is only natively supported by Chrome and Opera. JPEG-XR, originally known as HD Photo, was a proprietary image format released by Microsoft, supported only by Internet Explorer. If you want to learn more, Zoltan Hawryluk wrote an in-depth examination of these new formats.
<source type="image/vnd.ms-photo" src="wwc2015.jxr">
<source type="image/jp2" src="wwc2015.jp2">
<source type="image/webp" src="wwc2015.webp">
<img src="wwc2015.png" alt="WWC 2015">
Because source also has a type attribute, by specifying the MIME type of each image, browsers can choose the first source that has a type attribute of a supported MIME type. The order of the source matters, in this case, but if the browser doesn’t recognize any of the image types, it will just fall back to the original img element.
At time of writing, picture is supported by the latest stable releases of Firefox, Chrome, and Opera. Safari and Internet Explorer do not support picture natively at all. srcset fares slightly better, with full support on the latest stable releases of Firefox, Chrome, and Opera, and partial support on Safari 8 and Internet Explorer Edge, where they allow for use of the x descriptors for resolution switching, but not the w descriptors.
Quite a few polyfills out there address this support problem. The most well-known is probably Scott Jehl’s picturefill. I currently use Alexander Farkas’s respimage on my own site. We’ve finally reached a point where we’ve agreed on a solution for how to deal with responsive images, and that solution is getting implemented across all major browsers. Even though the specification is still being refined, we’re really close to a native responsive solution.
And if you want to stay up-to-the-minute current, I highly recommend checking out the Responsive Issues Community Group. You can also sign up for their newsletter or follow them on Twitter.
Like many of you, I’m not 100 percent sure what it is that I do for a living.
Some of us are focused on the ever-expanding landscape of Angulars and Embers and Reacts, some of us are interested in learning more about design systems and style guides, and some of us aren’t quite sure which parts of front-end dev are right for us. That’s okay, though—because there’s room here for all of us, as long as we learn how the pieces fit together.
That’s where our next event comes in: It’s filled with smart folks who span the range of front-end work, and it’s designed to help you explore the technologies and career paths that make up today’s front-end teams.
This event is free and everyone is welcome—just sign up to receive the viewing instructions. Here are the details:
Wednesday, November 4
1–2 p.m. EDT
via Google Hangout or YouTube livestream
Register or get more details
We’ll have 30 minutes of conversation between our panelists, and then open things up to questions from none other than you. We’ll also share the full video and transcript after the live show ends.
Join our email list to get updates whenever new events are announced.
Did you know that 60 percent of sites that fail to launch on time? It doesn’t have to be that way. The folks at Pantheon—who’ve generously sponsored our entire events program this year—have some help for you.
Download their latest ebook: The Perfect Website Launch—a guide for your next website project, from planning to deployment.
At a conference I attended several years ago, one of the speakers talked about needing to hire someone to step in and substitute for another designer who had fallen quite ill. The speaker found his new designer from reading their blog. Because that designer wrote and shared his thoughts on the web, he got a job.
I went home from that conference and started writing. I started a blog with a basic WordPress theme that I got for free. I shared my thoughts and ideas. I can say, without a doubt, writing has led to many wonderful things.
It was through writing that I connected virtually with many of the people in the industry that I’ve gone on to meet in-person at conferences. It all started by taking notes at a Mobile Portland meeting and publishing them on my site. I continued to think more about mobile and shared my thoughts on my blog. Those posts were the beginning for me, they were how I realized that I had a voice, that my thoughts mattered, and that sharing them was a way to start a conversation with others who were thinking about the same topics.
Through writing, I solidified my ideas on style guides. When I went to write up a rough post for the company blog about how I created the style guide we were using, it pushed me to think about how I define these tools. That rough post never ended up on the company blog, but it did get published as an A List Apart article. As I worked with an editor to shape that piece, my thoughts on style guides morphed and changed until I knew what I wanted to say about them.
The publication of that article led to speaking about style guides at conferences, giving me some amazing (and nerve wracking) opportunities to talk about them more.
As I’ve continued to write, on my own site and others, it’s led to more opportunities. I believe it was through my writing that I got to work with an amazing team, at an amazing startup that is no longer. As I wrote quick pieces on my site, some of them grew and went on to become more somewhere else, such as my article on CSS audits here on A List Apart.
It can be hard and intimidating to put yourself out there, but you should write. You should take the ideas that you get, and see what happens with them. Submit to publications you think may be interested in your topic (hint, hint) and see what they think. Writing can lead to more than you can imagine.
Often, the pieces I have the most doubts about turn out to be the words that people read and relate to most. So in those moments where you wonder if you should share something, I say do it, publish it. Treat your blog like your drafts folder. When I’ve done that, great things have happened.
Oh, government websites. Bless their confusing little hearts. Every time I log in to make a federal payment (favorite UI copy: “REMINDER! PAY ALL TAX BILLS WHEN DUE!”), or to file paperwork for the Social Security Administration (which gave me this oh-so-helpful warning), I’m greeted by inconsistent and incomprehensible design.
But teams at the U.S. Digital Service and civic consultancy 18F are changing that—and sharing their work as they go. Earlier this week, they released the U.S. Web Design Standards, containing patterns and principles to guide designers across agencies. It’s a great complement to resources like 18F’s growing set of Guides (I, of course, am partial to the content guide). Not only am I excited for better-functioning government websites, but I also love seeing organizations working out loud and sharing their tools—because we could all stand to steal these ideas. —Sara Wachter-Boettcher, editor-in-chief
So, what made you stop trying to learn how to code? I'm curious about the barriers that get erected.— Anil Dash (@anildash) September 29, 2015
So, what made you stop trying to learn how to code? I'm curious about the barriers that get erected.
OMG I love trash pandas so much.
For web platform enthusiasts, the developing ServiceWorker is a wunderkind among APIs. It’s taking a lot on: offline-first control over assets, performance improvements via network interception and cache management, background process enhancements.
It’s cool and I want to use it right away. I want to ride the offline-first wave. But ServiceWorker is in that awkward phase of partial adoption and implementation that raises the question I’ve asked myself before: how do I use this beautiful future thing, now?
Briefly, ServiceWorker provides a proxy, letting you make decisions about how to handle and respond to network requests coming from your (client-side) app.
Want to respond to requests for gif files differently if the browser is offline? ServiceWorker can do that. Want to explicitly retrieve assets from the browser cache for certain requests? ServiceWorker in conjunction with its pal the cache API can do that, too. Neat-o.
ServiceWorker is, in part, a do-over for the API devs love to hate: Application Cache, a.k.a AppCache (though, I should point out, ServiceWorker is considerably more functional than AppCache).
It’s rare that I say “this is really just how it is” about anything to do with web technology but, okay, I’m going to be straight with you: AppCache is awful to work with.
With AppCache, you (ostensibly) create a manifest file of the stuff you want the browser to cache locally. In practice, there are so many ways to get this wrong.
It’s confusing to debug and difficult (sometimes nearly impossible) to rectify if you make a boo-boo—which you will, because it is a cruel master. And it just doesn’t give you fine-tuned control.
AppCache is a beast, but it’s been around for several years and is supported by the majority of modern browsers.
ServiceWorker is partially implemented in about 45 percent of the world’s browsers—newer Chrome, Android, Opera browsers. That seems substantial; however, there is no official word that Safari will ever implement it.
Another wrinkle is that ServiceWorker is partially re-implementing something that already exists. There is no straightforward progressive enhancement from AppCache to ServiceWorker. Supporting both probably means writing certain functionality twice.
That means for real-world project architecture, I have several options, each unsatisfying on some level:
Option 1 won’t fly right now if you have a need to support a broad set of users. Option 2 is technically possible, but requires logic duplication and budget-straining extra time. Option 3 is functional but unappetizing.
We’re caught in the limbo between the web as it is and the web as we hope it will be soon. My heart is in the future; our reality is in the less full-featured now.
There is an ongoing conflict between what we want to believe is immediately doable and what is, in fact, feasible. I don’t want to suggest an academia-industry divide, because we’re all on the same side here. But we sometimes get wrapped up in the promise and energy of new standards and are blind to their growing pains.
Every new standard has to pass through the shadows of doubt as it makes its way to the light of day. We’ll always need to choose which questing API heroes to throw in with, knowing not every contender can be victorious.
The web demands risks and, dare I say it, courage. Its democracy leads to uncertainty—no one’s entirely in control of this crazy thing. Which is why forward-looking web thinking is considered future-friendly, not future-proof.
I’m not clamoring to put the brakes on the pace of change. We are getting what we asked for, for the most part: accelerating invention and improvement of the web.
But I’d like us to recognize that making decisions about fledgling platform APIs and the changing web is another expertise we have, though we may take it for granted.
And that building the web every day is a leap of faith.
Help your developers and writers manage dynamic content on the web (and in apps!) with our sponsor Contentful’s API-first CMS.
At Bluecadet, we didn’t set out to do headless CMS development for its own sake. We were curious about it and could see the potential benefits, but we only ended up doing it when it solved specific problems we faced on two very different projects.
The first was a website for Haruki Murakami. We wanted to create as seamless an experience as possible, which meant experimenting with different animated transitions between sections on the site. We eventually settled on AngularJS to support those transitions, so the challenge was how to merge AngularJS with WordPress, the CMS we were using. There are a few themes that do this, but after some testing and much research we decided to use the JSON API plugin. The client got a familiar CMS to work with, but also a very tightly-orchestrated front-end layer that captured their creative vision for the project.
Why do I tell these stories? The key lesson for us was that a headless CMS helped solve a problem. We didn’t dive into headless CMSes because it was trendy, we did it because we needed to solve specific problems (in the first case an aesthetic/creative one, and in the second a data-management one). The other important outcome was that we could let each piece of the project do what it does best—by letting the CMS simply manage content, we could use better tools for rendering the presentation layer. We were also able to let our team members focus on what they did best: with the James Ensor touchscreen, our CMS developers were able to take care of the data management problem while our Cinder developers could focus on the touchscreen application.
So let’s say that you’ve got some very good reasons to go headless. Maybe you want to have control over the front-end markup and animation in a way that stretches past what your CMS’s theming layer can support. Perhaps you want cleaner separation of front-end and content-management tasks—it can be easier to staff multiple projects when the responsibility for building a site doesn’t require everyone to know both the front-end rendering layer in addition to the backend of the CMS. Or perhaps you’re not building a website at all. Maybe you’re building a native iOS or Android application, but you need a familiar, yet robust, way to provide data for it.
The good news is that your preferred CMS likely already has what you need. WordPress and Drupal both have modules and plugins to enable a RESTful API, which I’ve found to be the most straightforward way to provide data in a headless architecture. For WordPress there’s the aforementioned JSON API plugin, as well as WP-API (which is being developed with the goal of eventual inclusion in WordPress core). Drupal has the Services module and Services Views, which allows developers to turn Drupal output created with Views into API endpoints.
If you’re interested in the WordPress side of things, WPEngine’s Torque magazine has a number of posts that cover the basics. For Drupal, this is a very handy video tutorial covering Services Views.
So far, the examples I’ve described are headless with a one-to-one relationship between the CMS and the front-end rendering application. A useful thing resulted from our work on those applications, however: my teammates and I started to decouple our expectations on the CMS side as well. For all the talk of dividing content from presentation, it’s still absurdly easy to build assumptions into your CMS for a single form of delivery. You start out knowing that the CMS will be used for a website, so everything from the order of the fields to the name of your fields is influenced by the form that it will take on the site. But what if your CMS later needs to support different products besides that initial website? This is something that Jeff Eaton and others on the ALA on Air panel addressed quite well, by drawing a distinction between the intertwined content management and web publishing responsibilities of most CMSes.
I’ve found that having to build CMSes that serve many individual products has made me focus more on flexibility. So even if I’m building something that is only being used for a website right now, in the back of my mind I’m wondering what would be required if we had to support a native iOS or Android application using the same CMS. I’ve started thinking of these as nearly-headless (or headless-ready) CMSes.
That relates back to one of the key tenets of the web: separating content from presentation. It’s why we have CSS separate from our markup, and rely on class hooks so that we can style things in ways that do not affect the semantics of the content.
Right now I’m at the very beginning of a CMS project that has to serve multiple products: multiple different touchscreen applications, iOS/Android apps, and a responsive website. If we hadn’t had the initial experience creating headless CMSes for those individual product types, we’d be nervous. But right now we’ve got confidence that we’ve done all of the separate pieces before, even if we’ve never tried to do everything using one CMS.
This is less an issue for native mobile applications, because those are always going to be separate from the CMS anyway. Still, simply having multiple software systems can be tricky, because each piece comes with its own assumptions and opinions on how things can/should be done. It also means that your team’s expertise has to cover different codebases. (Although that’s potentially an upside, if your team already has that expertise in both camps.)
My litmus test is pretty simple: does going headless with the CMS solve a key problem, and is it enough to outweigh the complexity added to the project?
Accelerate your career with a 12-week immersion course from our sponsor MakerSquare. They’re enrolling soon in SF, ATX, and LA, so prepare your application today!
The first rule of content management systems is that you’re using the wrong one. Using Wordpress? You’re a fifth-grader running a coloring-contest blog. Drupal? You should be using WordPress. An enterprise solution? You’re an open-source Judas.
This is how it often feels, at least, if you hang around the rough parts of web-dev Twitter or loiter in blog comments. But the real first rule of content management systems is that it’s not so much which CMS you use as how you use it. A bottom-drawer content management system implemented with care will often be much more useful than a top-drawer system pulled straight out of the box and shoved onto your server.
As a guiding text for implementing content management systems, I’m going to ruin your day by presenting a quote from Fyodor Dostoyevsky’s The Brothers Karamozov:
Man is tormented by no greater anxiety than to find someone quickly to whom he can hand over that great gift of freedom with which the ill-fated creature is born.
For our purposes, Dostoyevsky meant that the nicest thing you can tell your CMS users is that they don’t have the freedom to mess things up. When implementing a CMS, try to give your users exactly the level of freedom they need—but, when in doubt, err on the side of giving them slightly too much.
That’s the broad view of things, but it’s trickier once you get into the details—the fields and WYSIWYGs and permissions. What makes it even trickier is that, if you’re thinking about CMS implementation, you’re probably in one of two very different situations:
Although these situations each have their own individual troubles—which we’ll get to—they’re both governed not just by the first rule of CMSes but also by the second rule: no two CMS implementations should be exactly alike. Each site will have its own needs, and the CMS should be customized to match those needs.
With that in mind, instead of a set of prescriptions, I offer a handful of questions you might ask to limit your users’ freedom.
With many content management systems—WordPress and Drupal spring to mind—content types come default with a big text field where anything can be entered. Anything you want! Consider limiting this freedom as much as possible by giving discrete elements discrete inputs.
Every element on your page that serves a purpose distinct from other elements should have its own input field. In a staff directory, a person’s job title and name ought to have separate input fields, even if they appear next to each other on the page. The photo should have a separate image-uploader field. The office hours in the sidebar should have their own field. The contact info beneath the office hours should be its own field as well. Remember: just because two items are near each other visually does not necessarily mean they’re related enough to share a field.
For those who think partitioning every element into its own field is excessive and unnecessary, remember that it gives you flexibility for the future. As Karen McGrane points out, breaking your content into chunks gives your content structure, and that structure gives you, the web developer, freedom. It gives you the freedom to make small design changes—like moving the contact info above the office hours—with just a quick bit of backend work. And it also gives you the freedom to make large changes to how that content is displayed, whether it’s on the site you’re working on, another iteration of that site, or a totally different product that taps into that site’s content. That’s the sort of freedom you want.
It’s a good idea to use the most restrictive field you can for an element. If you’re going to use a big text field, ask yourself: could you make this plain text instead of anything-goes HTML? If it’s an image, consider using an image-uploader field rather than a general media field. If it’s a person’s first name, use a plain text field. If it’s a day of the week, make users select one of the seven days of the week. Don’t make them invent their own.
Restricting fields makes it easier for the people using the CMS to do their jobs correctly and quickly, and it can also help bring an editorial and visual consistency to the site. Having users select the day of the week from an array instead of typing it into a text field ensures that all days of the week will always be spelled correctly, and it keeps people from having to pause and remember whether the house style is to abbreviate days of the week or to spell them out. Also, if the house style changes, you can make a small tweak on the backend instead of changing the text in every day-of-the-week input across the site.
Restricting fields is also one of the most significant ways you can let CMS users know that they can’t mess things up. By using a restricted image field, you implicitly assure people that if they try to upload the wrong type of image file, the CMS will reject it. Likewise, using plain text instead of a WYSIWYG or rich text is a way of letting users know that they can copy text from wherever and paste it in without any problems, and that they don’t need to worry about styling the text.
However, there are a few areas where being restrictive will probably cause more harm than good. For example, it’s probably going to be more trouble than it’s worth to have a strict character limit on a text field. Even if it’s a field for, say, someone’s first name in a staff directory, you’re not going to cause much harm by having a character limit of 200 instead of 40. You also don’t stand to gain much by being too strict with so-called special characters. Allowing them might mean a slightly larger font file, but for most sites it’s not possible or advisable to avoid words with diacritics.
Out of the box, WYSIWYG editors sometimes come with a few dozen buttons. Some are classics like bold, italic, and strikethrough. Some are leftovers from word-processing days, like justify text and background color. Some are inscrutable: looking at the full set of buttons on CKEditor, I see a button that looks like a T walking a baby x on a leash, a globe, and three variations on a clipboard.
Most content management systems let you edit which buttons appear in the WYSIWYG. Do it! If the field is a text field that will need an occasional link, get rid of all the buttons except the link button. If a text area only needs basic text formatting, leave the buttons for bold and italic, and maybe ordered and unordered lists and links, if it’s possible they’ll be needed.
For general text fields—like product descriptions or event summaries—I like to keep those same few formatting options. I often omit the button for underlining—it’s best to restrict that style to links. I always include the link button because links make the web go ’round.
For longer texts like articles, I also include buttons for formatting block quotes, punctuation like em dashes (not everyone knows the keyboard shortcut), and maybe indent and outdent options if it’s possible that users will need to create lists within lists. I also usually create buttons that allow users to apply markup like headings, and I label them something like “Heading 2” rather than “h2,” since most CMS users will be more proficient in English than HTML. I generally avoid buttons that change font, size, and color or background color, which are best set through CSS to keep form and content distinct.
Those are just some starting points. Beyond that, know your editorial team. If writers like to sarcastically use strikethroughs, give them a button for it. Or if you only want editors to be able to sarcastically strike through things their writers write, only let users with editor permissions have a strikethrough button.
View-source buttons can be a difficult call. My general rule of thumb is that editor- or administrator-level users should have a view-source button if they know HTML. Funky things sometimes happen in WYSIWYGs—you’ll make something a heading and the whole paragraph will turn into a heading—and users who know HTML will find it easier to look at the source code and fix the markup.
You should use WYSIWYGs as basic formatting tools, not design tools. WYSIWYGs sometimes have a bad rep because users and clients want to treat them like word processors, a tool that gives people full (if clunky) control of how things look. They’re called What You See Is What You Get, after all. But if you restrict the WYSIWYG to its essential functions, you can assure users that what shows up on the website will look great every time, and they won’t have to worry about what they see or what they get.
Restricting a user’s permissions is the easiest way to make sure they can’t accidentally destroy the site. Most content updaters or editors won’t need to mess around with permalinks, so don’t give them permission to do so. If a user is only editing existing content, you should avoid giving them permission to create or delete pages. And so on.
Here’s something you can do to figure out what permissions a user will actually need: when you create a new user, turn off all permissions. Log in as that user in one browser, and then log in as an admin in another. On the non-admin account, go about accomplishing all the tasks that user will need to do and, as you go along, add permissions from the admin account as needed.
What’s accessibility doing in an article about implementing content management systems and 19th-century Russian novelists? Well: you can make your site’s code as accessible as possible, using the coolest ARIA roles and testing everything on an actual screen reader, but if your content updater creates grey text on a dark grey background or doesn’t care about alt text, your hard work goes to waste. You can’t prevent all of this, but you can at least make it slightly more difficult to mess up the site’s accessibility.
Even if you’re not ultimately the person uploading an image, for example, you can often still hard-code alt text right into the backend. If you’re designing a staff directory, for example, you can pull the alt text from other fields, like this:
<img src="cool-guy-optimized.jpg" alt="<?php echo name_field; ?>, the <?php echo job_title_field; ?> of Cool Business Guys, LLC" / >
<img src="cool-guy-optimized.jpg" alt="<?php echo name_field; ?>, the <?php echo job_title_field; ?> of Cool Business Guys, LLC" / >
That way, alt text will always be there—and it’ll even be useful and accurate—and the content updater won’t have to worry about it.
Or: if you’ve given discrete elements discrete input fields, you can guarantee that everything has the proper, accessible structure. Most content management systems do this naturally for h1 headings—they wrap your page title in an h1 unless you code otherwise. You can extend this functionality to other items. Put that callout text in an aside. Put that time in a time.
As a web developer, you’re likely up to date on all the latest image technology. You know when you should use img srcset (most of the time) and when you should use picture (only when you’re doing something art-direction-ish). You know the best image-optimizing plugin that’s only available from this one plugin site you found that one time. When someone asks you to Photoshop an SVG, you’ll tell them it’s not called Vectorshop, and you’ll laugh at your own joke and resolve to have outdoor time this weekend.
Your content updater probably does not know these things. Even if you yourself are the content updater, you do not want to have to remember this when you are just trying to upload a picture of your arugula. That’s why you should code all of this into your system. When possible, every image on your site should have its own image-uploader field, and you should be able to drop an image of any size into that uploader field and have it resized, optimized, and put into the appropriate responsive markup.
All of this content management system stuff takes some work—but you can do it. I believe in you. I saw how robust your arugula was.
Let me guess: you’re dealing with articles that have pictures and embedded Tweets and maybe even an interactive graph, and the person creating the article is going to need to reposition those elements for every article. That’s one of the trickiest and most common CMS issues. Let me point you to Jeff Eaton’s “The Battle for the Body Field” for some answers. That sort of problem is absolutely solvable with a CMS, and while my guidelines will send you in the right direction, Jeff outlines some ways you can approach that specific case.
If the problem you face is that you want your final CMS implementation to make all who use it proclaim its brilliance, check out Eileen Webb’s “Training the CMS.” Among other things, she has some awesome ideas for making the actual setup of your editorial pages helpful and easy to use.
Sometimes when you get into what seems like an intractable problem with a CMS, it’s because you’re thinking of how your content will appear on one particular page and not within your overall content/data structure. For that, check out Karen McGrane’s talk “Content in a Zombie Apocalypse.” She’ll help you rethink content modeling, and also kicks some dirt on WYSIWYGs, which is fun.
At the beginning, I mentioned that CMS implementations come in one of two types: with the first, you’re starting fresh, the world is your delicate cold little oyster, you’re not going to make the same mistakes this time; with the second, you’re refurbishing a CMS, things are broken, love isn’t real, God is dead, and so on. How you get started with asking these CMS questions depends on which situation you’re in.
If you’re in situation one, life is much easier in some ways. Keeping these questions in mind when you’re putting your design into CMS templates will make the field-related parts easier, and starting with reasonable WYSIWYG buttons, a functional image-uploading system, and built-in accessibility will give the site a solid base that you can tinker with later on.
The hard part is predicting exactly how the site will be used. It’s easy to think that you can replace the sidebar field with a location field and a contact information field, but what if someone wants to put a special message about holiday closures in the sidebar but they don’t have a place for it? If you’re redesigning a new site, I recommend using the gnarliest, most edge-case-y content on the current site for your sample content. That can often keep you from limiting things too much. If the site doesn’t have any content yet, that’s not really the best way to build a website, but if you live in the real world and have to do it anyway, you’ll likely have to err on the side of giving users too much freedom, and then restrict it later if you can.
If you’re in situation two, buck up. You don’t need to demolish your current site to implement all of this—you can slide into it gradually. Some parts are easier to do than others, and some of it’s more important. If you have a free afternoon, you can adjust all the user permissions appropriately and remove buttons from the WYSIWYG. You may even be able to adjust your image-uploading system without breaking images already on the site. But it’ll likely be more difficult to divide discrete elements into discrete fields or to restrict field types. Databases are sensitive like that. But the next time you create a new content type, you can make sure it has discrete fields and that they’re restricted appropriately. Even doing little bits and pieces of this can make your CMS more effective.
For both situations—really, for most web-development situations—the technical part will likely be easier than the political part. How do you sell the client or your boss on spending an extra week or so on making the CMS better? Did you pick a bad CMS or something?
In my experience, not only is it possible to get approval to spend time on this, but you can get outright gratitude. I recommend making a financial case: spending x number of hours on the CMS now will save five times as many hours later. The more specific, the more compelling. For example, if you estimate 16 hours of work to implement an image-uploading system that takes care of all the image sizes behind the scenes, you can then estimate how long it would take for the content editor to save three different image sizes and optimize and upload them every time an image needs to be changed.
If that doesn’t work, here are a few sound bites you can use:
Just don’t quote Dostoyevsky and expect it to go over well.
Government snooping. Identity theft. Sale of personal data. Privacy is out there in a big way. But it’s not in here, meaning on most product development teams.
I’m a member of those teams, as an experience designer with a foot in strategy and user research. I’m also a longtime public radio reporter (tech was a big topic of mine), so curiosity is my strong suit. I noticed that, at the agencies and tech companies I’ve worked for, privacy never seemed to be discussed much. And, as reporters do, I wondered why.
Making the case for bringing privacy into the product development process isn’t easy, especially since finding examples of successful companies that value privacy isn’t easy. In fact, the opposite is true—the web is littered with products or design methods that tried to promote privacy and failed, or that gained only small, niche adoption (here, here, here, here, here, and here). Knock-on effects are that privacy sometimes sits on the back burner.
There are good reasons for this: so many factors are at play in developing web products, and privacy gives us just one more thing to think about. But designers and product owners can and should work privacy into the process, and I’ll explain some ways we can do that.
Privacy is one thing, but security is another—and the latter is something that many companies do care about. If users’ information gets stolen, or governments snoop on it, that’s bad for trust and reputation and hence bad for business. When companies like Apple and Facebook call for security measures or legislation, or encrypt their data, it’s because they care about secure user data.
But, even companies that do encrypt (voluntarily—there are no laws around this right now) receive data in an unencrypted fashion, so there’s nothing to stop them from making the most of it for their own purposes, or selling that information to other companies (some secure, some not).
There are many flavors of online privacy violations. Last year’s Uber episode, in which the company singled out a journalist and tracked her movements without consent, was a violation of policies and may allow for legal recourse. (Other companies likely engage in these sorts of activities, but we rarely hear about it. Of course, the Facebooks and Googles of the world have access to all the messages their users write.)
Then there’s the murky area of things that aren’t technically illegal, but are questionable, like companies collecting information on behavior that users are not aware of. Cookies are one example of that. Of bigger concern is something like Target predicting a woman was pregnant before she knew it herself. And, finally, there’s the selling of that data—to advertisers, for example, or during an acquisition.
This data is typically made up of a combination of user-entered values and behavior tracked in the background (a.k.a. analytics): geographic location, clicks, time on a certain page, etc. Many companies claim they don’t care about individually identifying features, but instead, about user behavior or information in aggregate. However, anonymized or partially anonymized data can often be traced to individuals—take, for example, AOL’s search data leak of 2006. One user who had searched for information on murdering his wife was identified—but he turned out to be a TV writer who worked for a crime show.
If a business wants to build some sort of community or audience, it needs to establish trust. You can make the case that privacy will help, and include product requirements and user stories around privacy.
Following privacy legislation isn’t easy, but things are moving. American states pursue their own laws piecemeal, and federal legislation is outdated, though Congress talks about it more and more. Meanwhile, Europe is ahead of the rest of the world when it comes to online privacy laws. If your company has designs on going global, all users will likely be stored in the same online bucket—meaning European privacy protections will need to be extended to all of them. Wherever you do business, being proactive now will save headaches later.
Uber could’ve avoided some pain—and legal hot water—if it had adhered to stated policies. When violations and sketchy behaviors are brought to light, users hear about it. Witness the intense reaction to Facebook’s “social experiment.” Or the response to Edward Snowden.
Some global players are starting to think along the lines of “privacy as selling point,” including IBM, Microsoft, Google, and Apple. Mark Cuban even ranted about it!
The notion that “if you have nothing to hide, you have nothing to fear” is a destructive axiom of Orwellian proportions.
The most common retort you hear when raising issues around privacy is “What are you so scared of?” During a 2014 talk at Carnegie Hall, Glenn Greenwald explained how he responds to this question: he proposes the asker write their email username and password on a piece of paper and give it to him. No one ever takes him up on it. People, he posits, simply want private spaces where they can do things away from others.
There are also very real things to be afraid of—things that we, as user experience designers who care about empathy, should also care deeply about. One example: Weight Watchers sharing personal information in user accounts (weight, health habits, and exercise patterns, for example) with advertisers, which 60 Minutes reported on. In the same report, an expert discussed the emergence of “digital redlining.” Historically, redlining is the practice of denying mortgages to applicants of color in predominantly white areas of town. Digital redlining is similar: you could be denied a mortgage if the socioeconomic status of your online social circle deems you undesirable—and Facebook just patented technology for that very thing. Warrantless snooping by the government can have serious consequences too, leading to unjust detention and arrest.
Down the road, it’ll really suck when health insurance companies start to get access to data from Fitbit to raise premiums (they’re already rewarding users who provide access to their data). And don’t forget about users in countries whose lives may be at risk when their data isn’t private. If we believe that treating users with respect and honesty is essential to a good experience, then we owe it to them to ponder these issues.
We also need to be aware of the processes we’re complicit in—as Mike Monteiro has said, designers have responsibility. Trading in user data is a big part of making a living online today. If you choose to participate, you should know that you’re part of further ossifying the web in this modus operandi. You may be okay with that, but know it.
So, to sum up: Arrests based on erroneous or overblown government intelligence. Insurance companies snooping around in messages and health records. Dissenters being punished by dictatorial regimes. The arrival of robot overlords in the form of targeted advertising. Lack of privacy creates real danger. But even if users don’t want Google cataloging and analyzing a lifetime of their search history just because—well, that’s valid, too. It’s Article 12 of the Universal Declaration of Human Rights.
There’s no tried-and-true path to building privacy into your process, but there are ways to get started. Here are a few.
If your site or app uses a form, or asks the user to enter any amount of data, Caroline Jarrett’s question protocol is an invaluable tool for digging deeper into what you’re doing and why. As she describes it:
A question protocol is a tool for finding out which form fields are required and lists:
every question you ask
who within your organization uses the answers to each question [or, if no one plans to use it now, who can you imagine using it down the line?]
what they use them for
whether an answer is required or optional
if an answer is required, what happens if a user enters any old thing just to get through the form
The question protocol is different from the form itself, because it’s about how you use the answers.
A question protocol is a tool for finding out which form fields are required and lists:
The question protocol is different from the form itself, because it’s about how you use the answers.
Jarrett sees the protocol as bringing web development closer to the rigor of the scientific research process. “For example, during the census,” Jarrett explains, “they will be doing extensive research around what questions to ask, how that data will be used, and the delicate balance between the cost of collecting every piece of data and the benefits. Because collecting census data is incredibly expensive, but it’s very important.”
In the case of product development, every piece of data we collect through a form has a cost, too.
You could apply this method of deeper thinking to any piece of data you’re collecting on a site, not just what gets typed into a form. Say you want to collect GPS data on users: ask why it’s needed, where it’ll be stored, how it’ll be used, and tally up the costs around breach of trust if it comes to that.
We spend a lot of time designing features—features that users experience. But things that happen in the background of an experience can still constitute bad UX.
One way to bring privacy into the conversation early on is to write user stories around a privacy epic. Here are some examples based on an online store:
Here’s another example:
Former Mozilla designer Aza Raskin created a whole slew of privacy icons to instantly communicate to users how their data is used.
These examples are more about informing users than allowing them to take action. Much more could still be done to give control. But explaining—whether through approachable language, content organization, or design—is a great first step.
Developers oftentimes don’t know optimal storage configurations to help protect users. (“Let’s anonymize the logs” is a typical, and unsatisfactory, solution.) Advocate hiring someone for this expertise, such as someone who went through a program specifically studying online privacy—like Carnegie Mellon’s IT master’s with a privacy engineering specialization. Or bring in a consultant to advise on a specific project, like the Privacy Guru. If you’re part of a bigger company, maybe it’s time to consider a chief privacy officer—Acxiom has one.
You probably can’t compete on privacy alone, but combining usability with privacy—like Heartbeat does—can be an advantage. Or, build third-party products that encourage privacy, such as the rating system for apps (PDF) that would let consumers know how private and secure they are that a group of computer scientists proposed. I talked with Columbia professor Henning Schulzrinne, who recommended an Energy Star-like privacy rating system, and futurist Marcel Bullinga, who told me about an idea for a universal dashboard that would allow users to control their privacy across the internet. The Electronic Frontier Foundation’s Privacy Badger blocks advertisers and trackers that collect data, while Lightbeam, a browser add-on for Firefox, shows you who’s accessing data on every site you visit.
Les Orchard and Doc Searls, among others, have written about how ad-tracking software can delay site load speeds, degrading the user’s experience.
Take a course on data analytics. Hold a lunch-and-learn at your office about US privacy laws. Share the W3C’s guidelines on browser fingerprinting and privacy, the FTC’s guidelines for privacy and security for the internet of things and its older report on protecting consumer privacy (PDF), Microsoft’s adherence to the ISO’s guidelines, or the foundational principles of “Privacy by Design.”
It’s tough to keep up, but there are resources to help, like the Electronic Privacy Information Center and writers like David Meyer and Kashmir Hill. Write more articles like this one and come up with other ideas for “privacy by design.” Maybe you’ve built privacy into your process in a cool way. I know I’d love to hear about it.
Bringing privacy into your process is still challenging. First off, usage patterns are one of the basic underpinnings of UX. The vast troves of online data being generated aren’t evil in themselves. On the contrary, they hold possibilities for wonderful insights and improvements to life. But there’s a fine line between that and invasive—possibly even abusive—behavior. (One pretty unambiguous example is Mattel’s Hello Barbie, which records children’s voices and transfers them to an online server to process and respond to them.)
Then, there are the users themselves, who seem to sort of care about privacy, but sort of don’t. A 2014 report from Pew found that while 80 percent of Americans are concerned about third parties accessing data about them on social networking sites, 55 percent “agree” or “strongly agree” with this statement: “I am willing to share some information about myself with companies in order to use online services for free.” Essentially, we’ve grown accustomed to the commerce of personal information online in exchange for free services. There’s the old saw, “If you’re not paying for the service, then you’re the product.” User data is quite the lucrative product, too. There’s arguably a disadvantage to throttling its flow. (See: Google’s market cap of $360 billion.) Many companies have never even considered that there may be alternatives to the current user-data-for-service model of so much of the internet.
Then there’s this notion of “Minimum Viable Product Disease,” where products are rushed out the door before privacy is taken into account. That’s no big surprise—adopting privacy as a foundational principle is time-consuming and expensive, as ad company 4info found.
The fact that it’s hard doesn’t mean we’re off the hook. Just as we have a responsibility to design accessible products, even when it’d be easier not to, we have a responsibility to consider privacy. We all have a role in shaping the way products are delivered, ensuring they serve users’ interests in an era when the notion of private life has been thoroughly compromised. So let’s do it mindfully, not limiting our considerations to features that users see. Instead, let’s look underneath and above, reach further into the future, and think bigger about what user experience is.
Brainstorming is fun! In the early days of a new project, there are tons of ideas flying around, and those ideas spark discussions that spark more ideas. Maybe this new section of the site will have live-chat, and a video tour, and we’ll add voting to the comments!
It can be pretty hairy to narrow down the list of potential features. If the ideas were developed a while ago (which is usually the case in my projects—brainstorming tends to happen before outside consultants are hired), people are often very attached to an idea that they love and don’t want to give up.
I’ve found that what works best for me in these whittling sessions is to have a framework to fall back on. An established framework means that no one is trying to justify their idea to me; all ideas are evaluated in a relatively emotion-free setting so we can decide which solutions are the best ones to pursue.
My framework initially started as a Venn diagram with two circles: “What the business needs” and “What the user wants to do.” Finding features and content that fit in the overlap is basis of the core model and many other great strategic approaches.
This is the level of evaluation that helps nix ideas like “photo gallery of the company golf tournament.” (Because, hint: no user has a task that is completed by seeing your team in dopey hats and spiky shoes.)
I’ve started adding to my Venn diagram. The third circle holds “What is appropriate for the website,” which covers questions of brand intent, technology, and cost. A few years ago, we had a client who wanted to have live-chat crisis counseling on their site—they had trained counselors on staff, it fit perfectly with their mission, and it served the needs of their users. But (at the time) the technology just wasn’t ready: third-party solutions didn’t have the privacy and reporting capabilities they needed, and there wasn’t budget to build something from scratch.
Another client was talking about putting forums on their site, to mimic the engaging dinner table conversations people had at their monthly events. This circle helped us have a discussion about whether that was an appropriate use for the site—and since part of the emphasis of the events was being physically together, we decided that site forums didn’t align with that goal.
My fourth circle is a love letter to all content strategists, and holds “What is sustainable for the organization.” A weekly podcast plan that only lasts a month, lovingly crafted team profiles for two of the 28 staff, a community calendar whose last event was held in 2013—we’ve all seen plans like this fall apart. This circle helps me push on questions of time and energy without sounding so, well, pushy.
This circle also provides opportunities to talk about ongoing needs like photography, in-house versus external development resources, and what happens when the person in charge of this complex taxonomy goes on maternity leave?
I’ve found that grouping feature discussions with these circles has helped me have much more productive conversations with my clients, and has given them a framework for continuing their evaluation discussions when I’m not in the room. I recognize, though, that these particular four labels are based on the type of work I do and the shape of my projects. Do developers, or project managers, or in-house strategists have a different set of evaluation needs? What are the labels in your circles?
You’ve likely heard about the arrest of 14-year-old Ahmed Mohamed for building a homemade clock. This shameful and reactionary response to Ahmed’s creativity has been met with a well-deserved outcry—and a wonderful show of support from the online maker community, which understands the importance of stoking curiosity in young people.
Many have asked how you can help. Until we've heard back from the Mohamed family, here's a form to show your support: http://t.co/ENpjid6boD— Anil Dash (@anildash) September 16, 2015
Many have asked how you can help. Until we've heard back from the Mohamed family, here's a form to show your support: http://t.co/ENpjid6boD
Visit Anil’s form to extend your support in any capacity. He’ll share the feedback with the Mohamed family to “connect Ahmed to any Maker event or hardware hacking community he wants to join.” —Lisa Maria Martin, issues editor
Now I’m imagining a lot of sheep objects and one border-collie object.
Big news from our sponsor MailChimp: new MailChimp Pro, with multivariate testing, comparative reports, and priority support.
You know those moments when you’re shown a new feature to build, a description that needs to be written, or a design that needs to be translated to code, and you just freeze? When you aren’t sure where to go or how to begin?
This happened to me recently; the designer I was working with wanted to include a small animation on the homepage. I’ve taken an animation workshop, and I’ve done very small things on sites before, but I’ve never done something quite like what he asked for. At first I thought it was completely unnecessary, why bother? But as I worked through it, Googling madly and using Mozilla Developer Network a lot, I learned. When I got it working, or at least got it started, it was fun to see.
We’ve all had those moments when we’ve been asked to do something in our work, and cringe. I get it, some days you just want to coast, use the knowledge you have, get the job done. But on those same days, you may be thrown a new idea or concept that you need to make happen. How we handle these moments, can make a difference in how our days go.
Lately, instead of cringing, I’m pausing to think of the task differently when something new is thrown my way. Instead of feeling like I can’t do it, or searching for an argument for why we shouldn’t do it, I’m trying to look at these moments as a possible way to learn.
I can be old fashioned at times; I like the code that I know works, and sometimes I’m slow to warm up to new things. But, I’ve found when I keep an open mind to the possibilities and try something out, I learn and sometimes I even have fun.
We have so many tools at our finger tips that can help us learn quickly, and I know when I learn something on the job, the new ideas stick with me longer. Truth be told, I’ve gotten fond of reading the drier specs and documentation—it’s a way I’ve found I can learn on my own in these moments of uncertainty.
So now, instead of cringing when the new idea is presented to me, I’m pausing to think through what a plan of action could be. Can I figure out how to make it happen? When I get something to work, like I did recently with that animation, it’s a gratifying feeling, knowing that I pushed through the fear and learned. Truth be told, this is often how we grow, by pushing through those moments, we realize that we’re capable of figuring it out and getting it done.
Tuesday’s article on animations and vestibular disorders may have left you wondering what else you can do to make your animations accessible. Here are a few resources to start learning more about how animation and accessibility can work together:
This is a good place to start for the basics of accessible animations. In a nutshell, the WCAG has two recommendations that specifically apply to animation. The first is to provide pause controls for any animation that starts automatically and plays for more than 5 seconds. Auto-updating content and animated carousels could likely fall under this category.
The second is to not have any part of the screen flashing more than three times a second. Flashing any part of the page above this threshold can risk potentially triggering seizures.
Just like static content, there are times when providing alternate content for an animation is a smart thing to do. Webacessibility.com’s best practices for animation offers suggestions on when to provide alternate content and limiting the number of times or duration of animations for assistive technology.
More web animation is being done with SVG—and that’s great news for accessibility. If you include SVG inline in your web page, it’s inherently more accessible than canvas: whereas canvas is simply a drawing area, the content and text inside your SVG elements can be access directly by the browser.
Dudley Storey and Léonie Watson have both published useful lists on how to make SVGs accessible in a variety of contexts. You can also assign ARIA roles to SVG elements for more descriptive power. The a11y project has a helpful primer on ARIA roles to get you started.
Marissa Christina does a wonderful job describing what it’s like to live with a vestibular disorder in her interview on The Big Web Show. Her site, Abledis, is full of great insights and information as well. (The section on motion warnings hasn’t been updated in awhile, but a lot of insight can be gleaned from the comments.)
Also, Greg Tarnoff has proposed using specific Twitter hashtags to warn others of potentially triggering links.
These are all useful resources to check along the way to be sure you’re making your animations accessible. If you have any similar resources that you use, please share them in the comments!
Back in June, our friend Khoi Vinh launched a survey of tools used by designers over on Subtraction.com. Today, he shares the results from 4,000 designers working in some 200 countries. The findings contained a few surprises for our team:
As anecdotal experience may already have suggested, Sketch has pulled into the lead for interface design, edging out Photoshop by 5% among survey respondents. Clearly Photoshop is not dead. And the results might skew differently if the survey had been limited to design studios and agencies, where Sketch weighed in at 27-28% (depending on size of studio). Still, there was a time before responsive web design when no one could have imagined Photoshop winning anything less than the whopping majority of designer desktops.
No surprise here: Dropbox leads the field for version control and file management, followed respectably closely by Github. As you’d expect, Github fares best at startups, but it even does respectably well at small design studios.
When it comes to brainstorming, the industry overwhelmingly favors that lo-fi classic: pencil and paper. The usual suspects in other areas of the survey (Sketch, Illustrator, and Photoshop) lagged further behind here than you might expect.
Check out the full results (beautifully designed by the fine folks at Hyperakt and powered by Typeform), and let us know what surprised you in the comments.
Over the past 12 years, I’ve been in a lot of training sessions; some were company mandated, others were ones I designed and ran myself, still others were sessions I paid money to attend. For a number of years, I’ve been in charge of a design team, and that means being responsible for training and development for my team members. While they are, of course, active participants, it’s important to acknowledge that training is about the transfer of information and the building of skills. The junior members of your team do not spontaneously gain skills. Instead, you need a clear process in place to train and mentor them.
There are a number of things to consider when talking about training designers. My experience has been on an in-house team, so I’ll speak to that type of training and mentorship, but this applies to all kinds of design and development teams. OK, onward.
Your weekly or monthly check-ins with your design team are a time to catch up on how current projects are going, but you should also find out what they need help doing and what new things they want to learn. I try to match designers’ yearly performance and development goals with shorter-term goals, scaffolding them so that we constantly build toward more complex abilities and tasks.
But how to find out these things? A simple exercise often helps. As you do a wrap-up on one project, ask the designer to complete the following sentences:
The second and third answers are where you can focus your training plans.
For many people, there is a temptation to just assign a big new task and “let them get on with it.” But this is only effective for the most motivated people, and actually assumes they already have the skills to complete the task. That’s not really learning anything new, is it? So, let’s look at this in a slightly different light. Assigning tasks means looking at someone’s current abilities and tailoring the assignment to match. I think of this in four levels of difficulty.
Imagine the task is to develop a pattern library for a new web app the company is working on. The development goal is for the designer to learn how to design UIs based on components, code, and systems, not full PSD layouts.
“I’d like you to develop a pattern library for our new web app. You should base it off the corporate pattern library, and build it in Sketch. We need type, button, and menu styles, and it needs to be completed by the end of the month.”
This is the lowest level, and has very little autonomy. All the variables are controlled, from the content, to the references, to the timeline. This is good for a designer who needs to get the basics down.
“I’d like you to develop a pattern library for our new web app. You should base it off the corporate pattern library, and build it in Sketch. It needs to be completed by the end of the month.”
There is still very little autonomy here, but fewer variables are controlled. The designer has the freedom to decide what UI elements will be in the pattern library. You would use this level when someone has their sea legs, and needs experience deciding what is important in their projects.
“I’d like you to develop a pattern library for our new web app. You should base it off the corporate pattern library, and it needs to be completed by the end of the month.”
Here you can see there is much more freedom to design independently. As the design lead, though, you are still controlling important factors like deadlines. The design tool, in this case Sketch, is no longer important, as the designer already has knowledge of what the project will need, and can plan accordingly.
“I’d like you to develop a pattern library for our new web app. Let me know if you have any questions.”
Wow—almost complete freedom. The company goals are still defined, but the designer is given freedom to deliver whatever they think will meet the project goals.
Whatever the designer has identified as a skill they would like to learn, or a project they would like to try, you can use these different levels to assign that project. By offering direction that acknowledges the gaps in their knowledge, you will challenge them without making it an impossible experience.
So, you have assigned a project that will develop new skills for them. They have started on their way. Regular check-ins, especially during team meetings, gives them a chance to share their progress, not only with you, but their teammates. After all, as a senior designer, it’s your job to make sure they are able to complete the task and learn specific new skills. By reviewing both the controlled factors, like deadlines and project goals, and the more creative factors, like tools and visual design, your check-ins create a measurable, achievable pathway through the project. Everyone likes pathways!
I encourage you to use a process like this to build up the skill levels of your more junior teammates. Looking out for the health of your team, and the projects you launch, means also looking out for the learning and development of your team members. This process starts with senior and junior designers working together to identify training needs. It continues with assigned work that builds, not crushes, your teammates. And finally, because few people can just spontaneously learn on their own, you act as a constant mentor through the assignment. The process standardizes the transfer of information and techniques from senior to junior designers, in a clear and understandable way, so that your team members gain the skills they need to grow as designers.
It’s no secret that a lot of people consider scrolljacking and parallax effects annoying and overused. But what if motion does more than just annoy you? What if it also makes you ill?
That’s a reality that people with visually-triggered vestibular disorders have to deal with. As animated interfaces increasingly become the norm, more people have begun to notice that large-scale motion on screen can cause them dizziness, nausea, headaches, or worse. For some, the symptoms can last long after the animation is over. Yikes.
The idea that animation in our interfaces is capable of making our users dizzy wasn’t something we had to contend with much when the web was predominantly a static medium. It’s actually a fairly new revelation in most tech circles. Even Apple discovered this the hard way when the animated transitions in iOS 7 started making some people sick. Just like other elements of design, the way you use animation can have an impact on how accessible the end product is to your audience, especially if they suffer from a vestibular disorder.
Any disease, damage, or injury to the vestibular system—the system around our inner ear and brain that processes sensory information involved in controlling balance and eye movements—falls under the umbrella of a vestibular disorder. There is a long list of specific vestibular disorders, including benign paroxysmal positional vertigo (BPPV) and labyrinthitis. The a11y project discusses the definition of vestibular disorders as well.
These disorders can affect people of all ages, and the severity and symptoms vary from individual to individual. Estimating an exact number of people touched by this, let alone what percentage of your specific audience may be affected, can be difficult to pin down. According to vestibular.org, approximately 8 million American adults report a chronic problem with balance, while an additional 2.4 million report a chronic problem with dizziness.
It’s also worth noting that people with vestibular disorders aren’t the only ones who can be potentially triggered by animation on screen. Animations can have an impact on those with epilepsy and migraine sensitivities as well.
To get a better idea of what sorts of web animation are triggering for people with vestibular disorders, I chatted with Greg Tarnoff and Craig Grannell about their experiences. Greg, who experiences vertigo and migraines, is an accessibility and UX consultant, writer, and speaker. Craig, who experiences dizziness, is a writer and editor who has written about the effects of iOS’s animations for publications like the Guardian. Both of them have been vocal about how interface animations affect people with vestibular disorders.
Greg identified Vimeo’s Cameo, Ice and Sky, and RD Construction as troublesome due to their large areas of motion and the parallax-like effects of background and foreground moving at different speeds.
For Craig, the carousel on Apple.com poses a big problem, especially when it flicks back to the first picture. There are no controls to pause or stop that particular carousel, so there’s no way to avoid it.
The iPhone product page, with its parallax-ish background animations and scrolljacking (where the backgrounds animate in at a speed unrelated to your scrolling efforts), causes problems as well.
Craig also describes the horizontal scroll on wired.co.uk as “a nasty surprise” if you’re not prepared for it. Seeing a huge horizontal shift when you’re scrolling downward is certainly a drastic departure from expectations.
In contrast, Solarbeat was characterized as only “mildly annoying.” And Macaw’s Scarlet site wasn’t much of an issue at all beyond minor problems with the opening animation.
Different people have different conditions and reactions, of course. But these examples show that the triggers are more nuanced than one might think if one simply assumes that any or all animation will be problematic. Three factors, in particular, play a big role: the relative size of the movement, the direction of movement, and the perceived distance an animated object covers.
Animations that move an object across a large amount of space are most apt to trigger a negative response for someone suffering from a vestibular disorder. The physical size of screen matters less than the size of the motion relative to the screen space available—so a small button with a 3D rotation probably won’t cause trouble, but a full-screen wipe transition covering the entire screen likely would. Animation that involves only non-moving properties, like opacity, color, and blurs, are unlikely to be problematic.
Exaggerated parallax and scrolljacking animations are highly likely to be triggering. Much of the time, these effects involve background objects moving at a different speed than foreground objects, sometimes drastically. Animations that move a different direction than the user is scrolling, or in a way not directly linked to the speed at which the user is scrolling, also tend to be problematic. It’s not much of a stretch to see how that could be disorienting.
The amount of spatial distance covered by an animation is a factor as well. It’s virtual space, of course, but animations covering a large perceived distance can be triggering. For example, iOS 7’s 3D zoom transitions caused trouble because of the amount of virtual space covered so quickly.
None of this is to say that we shouldn’t use animations in our websites. Not one person I spoke with said that they want to see all interface animation eliminated. In fact, some still very much appreciate it from a design perspective.
A good animated solution often just feels like it’s easier to use and understand. That’s more than just a gut feeling—there’s science behind it, too!
On a basic level, animating an element’s movement makes its path visible on screen. Your user doesn’t have to keep track of the movement in their head. Instead, that effort is essentially off-loaded from their brain to the animation you created on screen. When you reduce cognitive load, you free up users’ working memory resources to focus on other things—like learning new skills and retaining information.
Beyond the cognitive load benefits, other studies show that animation can improve decision-making (PDF) and even help people learn and remember spatial relationships (PDF). Animating between states can also help prevent change blindness. In short: animation can free up your brain power and make an interface easier to understand—the benefits can’t be ignored.
There are a few things we can do a to make animated movements easier on folks who find it triggering.
Your UI animations should be designed with purpose and have a reason for being there. (That’s a given, right?) If some part of your interface is moving, there should be a design-focused reason why. There are plenty of ways animation can add to the user experience in addition to its storytelling and demonstrational abilities. Starting with thoughtful, purposeful motion also sets you up well for having accessible animations.
A link billed as “the most spintastic WebGL experiment ever” likely contains large amounts of movement, and people can make an informed decision as to whether following that link is worth the risk to them or not.
But not all animation is hidden behind links. Identifying context gets trickier when motion becomes more and more commonplace. With no reasonable expectation of encountering moving content—large movements in a news article, for example—a person suffering from a vestibular disorder may find themselves dealing with an unexpected onset of symptoms.
If you aren’t certain the context is clear, adding it explicitly could be helpful as well. The a11y project suggests providing “an indicator of what movement will happen on the site when a user takes action.” Setting user expectations is important.
If you do have large amounts of movement that cover a lot of visual ground, consider offering an option to turn off, or reduce, motion. There are plenty of cases where large amounts of motion make perfectly good design sense. Providing what essentially boils down to an alternative way to view that content, or a little extra control, can be a big help for anyone sensitive to motion.
This can be accomplished via a button or toggle switch to reduce or turn off animation globally on your site. Think of it like taking the pause controls the WCAG recommends for animations and applying them on a global level. This does take a little more work on your part, but it offers an important option. If it means the difference between being able to spend time with your content or not, even for a small number of users, then it’s worth the effort.
Exactly how much work it takes to implement a toggle will vary based on the web animation option (or options) you’re using, of course. As an exploration of this idea, Greg Tarnoff developed a prototype of a potential toggle switch that could be used by any site.
A simple toggle that’s consistent across many sites would make it easy for someone sensitive to animation to quickly and easily reduce animation. If it’s something you’d like to see made, too, fork the pen and add to the idea. This sort of thing can only be improved with more minds contributing to it.
Even if you have the best of intentions, you might not have the technical skills or time to pull off an effective animation toggle. While it’s a responsible thing to do, the potential effort it requires starts to make it feel like a temporary solution.
Greg’s toggle solution is a good approach, but browsers could provide a more universal and easier-to-implement version. Our browser could notify users of highly animated content without any additional changes or effort required from the developer.
More granular control could come from proposals like User Queries or User Context. Browsers could let developers customize the desired behavior for both motion-full and motion-light versions of their sites based on an API that exposes user preferences.
Addressing this issue at the browser level may not be as far-fetched as it sounds initially. Thanks to the Web Animation API, we already have some very helpful controls in the developer tools for Chrome and Firefox to pause and play animation globally. A user-facing version of this would be a big step toward giving users control over how much animation they encounter.
In April 2015, Google Accessibility released the Animation Control extension for Chrome that targets on image formats like .gif and SMIL animated SVG. Combine that with the global controls in Dev Tools, and the possibility of browser-based controls doesn’t sound too far off.
From what I’m told by those who actually need it, iOS’s “reduce animation” toggle leaves much to be desired. Maybe browsers can do a better job of it? I would love to see the web solve this in a way that shows the operating system makers who’s boss.
On the web, more than in any other medium, the flexibility and control are there for you to design creatively and responsibly at the same time. We absolutely can innovate and push the web forward designing kick-ass interface animations while still being responsible designers. As a web animator, you can have your animation cake and eat it too—with a little creative thinking.
Whenever I had to take standardized tests in high school, I would get anxious over the easiest part: filling out my name.
Tests like the SAT and ACT insist that you fill your name out exactly as it appears on your identification documents. But when I wrote the hyphen in my surname—Gonzalez-Cameron—it would throw back an error, or I would run out of space. Either way, I could not make the information on the form match my documents.
More recently, I found myself in a standardized testing environment again, this time to take the GRE. Although their website is more upfront about how to handle last names, they still require and refuse accuracy in the same breath—particularly frustrating for Hispanic-Americans and many other test-takers:
“Important: The name you use when you register for a GRE test must exactly match (excluding accents, apostrophes and spaces) the name on the identification (ID) documents that you will present on the day of your GRE test. If it does not, you may be prohibited from taking the test or your test scores may be canceled after you take the test. For example, a last name of Fernandez de Córdova would be entered as FernandezdeCordova.” (Emphasis mine.)
This is where design and cultural awareness intersect. What determines the space limitations for collecting last names? Why can’t hyphens, spaces, accent marks, or nonstandard characters be used? What would it take to alter the code to accept a wider range of naming conventions, especially given that Hispanic-Americans make up 17% of the population?
These are seemingly small considerations for the design process. Students shouldn’t stress about instructions or worry that their answers will be thrown out because they can’t complete the first step correctly. Designers have a responsibility to understand their users, and to build forms that can accommodate an increasingly common style of surname—whether that’s for standardized tests, government documentation, health-care forms, or other systems that people use to live their daily lives.
If we want to make the web a better tool for communication, we need to better understand our audiences and capture the correct cultural nuances in our content and experience designs.
Naming conventions are just one of many distinctions for the Hispanic-American population—a group that itself is hardly monolithic, subject to millions of variations by ethnic background, location, age, dialect, and other factors. But understanding how names work and taking them into consideration can go a long way toward a better user experience.
Most Hispanic-Americans have at least two last names. They are not hyphenated; hyphenation is a practice that many have adopted to avoid confusion in the United States’ single-name infrastructure.
Here’s how it works: in traditional marriages, the husband and wife keep their respective two surnames. The wife may add on “de <name>” to show that she is now “of” her husband’s family—so now she’s working with three surnames.
If the couple have children, their surnames will be constructed from the first surnames of the parents. To illustrate:
José Miguel González Haro + María Elena García Rubio (de González) =José Miguel González García
José Miguel González Haro + María Elena García Rubio (de González) =
José Miguel González García
Even without considering accent marks, you can probably already imagine how this would break things on the English-based Internet and backend databases. And this doesn’t even begin to touch on the challenges created by tildes, cedillas, non-Latin scripts, nontraditional naming conventions, and naming systems used by other ethnic groups.
We’ve walked into the spiderweb of intricacies around making our stuff work better for more people, specifically around the accommodation of names. There’s obviously room for improvement—from the tactical aspects of forms all the way up to the culture of our workplaces.
There is already conversation about accommodating names on web forms. For example, in “Personal names around the world,” the W3C provides a great primer on how these issues affect everyone, not just Hispanic-Americans.
Luke Wroblewski literally wrote the book on web forms—in which he walks through the overarching process for designing a good form, focusing on specific aspects such as viewports and inline validation—and has also published a number of informative articles. In “Inline Validation in Web Forms,” Wroblewski points out that “web forms aren’t great conversationalists. They ask a bunch of questions, then wait until you answer them all before they respond.”
I like to use this observation to reimagine forms as dialogues. This makes it easy to spot potential pain points for your audience. For example, the form input of “Name:” can be reimagined as “What’s your name?” Similarly, the form response of “Error: last name not valid” can be heard as, “I’m sorry, I can’t understand your last name, so it’s not valid”—not a particularly kind response.
Form functionality gains traction at the development stage, so it’s useful to look at work on that side as well. Aaron Gustafson’s presentation “Falling in Love with Forms” goes through common form patterns and how to build more intuitive, responsive forms in HTML5. While Gustafson doesn’t address name accommodation directly, his approach supports better form design across the board; he encourages designers and developers to “focus on making the form read naturally and easily. You can’t always make an interface perfect, but you can make it usable.”
It may be helpful for your team to take a day and workshop how you build your web forms. You should look at the challenges and considerations that arise in making forms, building research into the budget and scope of projects, and incorporating more usability testing with diverse testers. Not only will this build skills and provide insights, but it can mark an important shift in your organization’s culture; often people get so bogged down in daily tasks that carving out space for the whole group signals permission to stop and learn more intentionally.
I’m certain no one makes forms intentionally difficult to fill out. To tactfully suggest and work toward improvement, though, requires an understanding of your organization’s digital governance process. Knowing that you have a strong framework in place for getting things done or getting approval makes it easier to work on specific changes.
What if you don’t have a digital governance process or don’t know what it is? I once worked in a government setting where no individual had the authority to decide what would get published, why, or when. Our team knew we needed to overhaul a section of the website because the grant program’s terms were going to change, but no one seemed to have the freedom to try things out or make changes, or the power to make the final call. Meetings became a lot of discussion with little to no decision-making.
When these kinds of meetings are the norm, teams lose momentum, which means nothing changes, and then the old, outdated versions persist. In her fantastic book, Managing Chaos, Lisa Welchman explains that clear digital governance is the way forward:
“Governance is an enabler. It allows organizations to minimize some of the churn and uncertainty in development by clearly establishing accountability and decision-making authority for all matters digital. That doesn’t mean that the people who aren’t decision makers can’t provide input or offer new and innovative ideas. Rather, it means that at the end of the day, after all the information is considered, the organization clearly understands how decisions will be made about the digital portfolio.”
Clarifying your organization’s digital governance plan makes it easier to make changes—whether to fields in your web forms or to the design process that built them.
The strongest step is to begin building a more culturally aware process in your organization. If you’re in a decision-making position, you have the agency to set the tone and make changes. If you’re not in a decision-making position, it’s still possible to take action, if you work carefully and diplomatically.
Names and naming conventions seem like such innocuous, inconsequential details in designing web experiences. But without getting that right, we potentially prevent people from completing forms or executing tasks. We become responsible for telling users that they do not exist or are not valid. How is that improving the web or making it easier to communicate and get things done?
A busy designer or developer can be forgiven for not knowing the nuances of every piece of the mosaic that is the Hispanic-American group. I certainly don’t know, and I’m a member of it.
But we can learn to ask ourselves what we don’t know, and understand concrete aspects that help us do our jobs more thoughtfully. Starting with learning something consistent about the mosaic of “Hispanic-American,” like a naming system, and applying what we learn to our work—such as making forms more accommodating—is a step in the right direction. That direction is toward a strong multicultural awareness, which we all need to do our best work in an increasingly diverse society.
While you do that, I’m going to go talk to Spain about their habit of duplicating people’s single last names to fit their government forms, which require two surnames. (Sarah Smith Smith, anyone?)