Subscribe: A List Apart
http://alistapart.com/feed/rss.xml
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
animation  api  content  design  don’t  find  it’s  make  new  people  project  support  team  time  user  web  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: A List Apart

A List Apart: The Full Feed



Articles for people who make web sites.



Published: 2017-10-17T12:48:00+00:00

 



Web Typography: Numerals

2017-10-17T12:48:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Richard Rutter’s new book, Web Typography.When it comes to numbers we have just ten digits. Throw in a comma and a period and we’ve got grand total of twelve characters. You might not think that would present much of a challenge to a typographer, but to a professional typesetter (that’s you if you’re a designer) numerals require far more nuance and variation than you might think at first glance. Numbers deserve the same care and attention as text - this excerpt reveals the numerical situations you should be looking out for, and how to tackle them to benefit your reader. Use old-style numerals in running text In ‘Ligatures and abbreviations’ we established that writing systems based on the Latin alphabet, in addition to Greek and Cyrillic, use a bicameral script, with each letter represented by two different forms – uppercase and lower (or majuscule and minuscule, to use more formal terms). The same is true of numerals. We have at our disposal ‘uppercase’ numbers 0123456789 called lining or titling numerals, and ‘lowercase’ numerals 0123456789 called old-style or text numerals. Unlike capital and lowercase letters, different forms of numbers do not convey different meanings; they are, however, an essential component of the typographer’s palette. Just as a string of capital letters in the middle of a sentence SHOUTS at your reader, so numbers set in lining numerals call undue attention to themselves. Are pounds, dollars, dates and quotas really more important than the words and ideas which give them context and meaning? Treat numbers as you would letters, making sure they don’t stand out unnecessarily. Do this by using old-style numerals in all your running text. Most modern, professional fonts will include both old-style and lining numerals as OpenType features. One or other of these styles will be used for the default numbers. More often it will be the old-style numerals, but there is no strict rule or consistency, and the choice of default is down to the type designer. It’s also the case that the vast majority of fonts are neither modern nor professional, if modern means OpenType-enabled and professional means designed with both sets of numerals. Take Georgia, for example. Designed by Matthew Carter in 1993 as a screen font for Microsoft, it is extremely well put together, elegant and appealing, and one of the most popular and widely distributed fonts in the world. But it is not packaged as an OpenType font and so only contains one set of numbers, in this case old-style numerals. Times New Roman, which is similarly widespread but, again, not as an OpenType font, is packaged only with lining numerals. Georgia and Times New Roman are so widely distributed because they are bundled free of charge with Windows and Mac operating systems. However, both these fonts – like many others – are available to buy in professional versions, which do come as OpenType fonts complete with both sets of numerals, small caps and many other features. Top: Numerals in Times New Roman Pro.Bottom: Numerals in Georgia Pro. To specify old-style numerals, set the font-variant-numeric property with a value of oldstyle-nums. If most of what you’re designing on a page is running text, then your best approach is to set old-style numerals so that they are inherited from the . body { font-variant-numeric: oldstyle-nums; } For legacy browsers requiring font-feature-settings, use the onum OpenType feature tag. As explained in ‘Ligatures and abbreviations’, you can add an @supports rule to cater for legacy browsers that only support font-feature-settings: body { font-feature-settings: "onum" 1; } @supports (font-variant-numeric: oldstyle-nums) { body { font-feature-settings: normal; font-variant-numeric: oldstyle-nums; } } Many sans serif fonts of the early to mid-twentieth century, including Helvetica, were never designed with anything other than lining numerals. This is one of the r[...]



The Right Way to Select Technology, An Excerpt

2017-10-12T14:00:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 4 of Tony Byrne and Jarrod Gingras’s new book, The Right Way to Select Technology, available now from Rosenfeld Media.After establishing a solid business case, enterprises will typically turn to assembling the oft-dreaded “requirements document”—or more accurately, a set of documents, spreadsheets, and diagrams that compose a multiheaded requirements package. Large requirements packages actually provide a false sense of security. Modern digital technology entails real people interacting with screens. Technology selection leaders need to capture those interactive requirements, but also remain realistic at this phase about their inability to fully know what their enterprise really needs and will adopt eventually. This section will show how long spreadsheets full of “what” requirements really don’t work, and instead will focus on “how” a solution might work. The best way to reveal key differences among suppliers is to craft narrative “user stories” with “personas” (rough equivalent to use-cases with actors). In other words, tell testable stories. Business users have stories; so do customers, partners, developers, sysadmins, designers, auditors, and others. This section will lead you through an approach to telling those stories in a way that’s more conducive to differentiating among technology suppliers. Capture requirements that don’t suck A solid understanding of your organization’s requirements is essential to project success. Getting that understanding will involve information gathering from various stakeholder groups, potentially utilizing a variety of techniques. Note that at this stage, your requirements should be business- and user-focused, rather than detailed technical specifications. (We’ll get to those in Chapter 6, “Ask Questions That Really Matter”). The final key step here is to analyze and prioritize your requirements, in order to determine which ones to emphasize in the RFP and subsequent demos and bake-offs. How not to articulate requirements Whatever you do, avoid “check box” requirements sheets where you ask the vendor: “Can you do this, can you do that?” As a practical matter, vendors have seen all these questions and have figured out how to check all the boxes. But what’s worse is that such spreadsheets convert the understanding of what should be a human-centered, interactive activity into a bloodless series of row-by-row activities better suited for robots repeatedly performing rote tasks. The typical pitfall here starts like this: a business analyst (BA) goes around interviewing users and other stakeholders, and she ends up with a long wish list of features. Excel allows her to categorize those features, which is handy, but because of the limitless rows, her spreadsheet will tend to emphasize comprehensiveness over business impact. .main-content .aside-content { background: #f9f9f9; margin: -12px 0; padding: 36px 0 12px; }.main-content .aside-content h3, .main-content .aside-content p { margin-right:132px; margin-left:132px; }.main-content .aside-content h3 { font-family:"Franklin ITC",sans-serif;font-weight:bold;font-style:normal;text-transform:uppercase;margin-bottom:3px;font-size:16px;line-height:28px }.main-content .aside-content p { margin-bottom:24px }@media only screen and (max-width: 61.5em) {.main-content .aside-content { margin-left: -3%; margin-right: -3%; padding-left: 3%; padding-right: 3%; }.main-content .aside-content h3, .main-content .aside-content p { margin-right:0; margin-left:0; }} Don’t include the kitchen sink While it’s critical to identify your requirements, it will prove even more important to prioritize them. Noncritical requirements can hijack the product selection process by distracting you and your vendors from what’s really important. Remember that you are not specifying out an actual implementation at this phase. You are trying to contrast potential suppliers and solutions. So while complete requir[...]



UX for Lizard Brains

2017-10-10T13:35:00+00:00

Technology can make magic happen. In seconds, you can find all the blue sandals in a warehouse of millions of shoes. A million people can read the same article without killing one tree. You can undo, unsend, and even unfriend! But here’s the buzzkill: if unanticipated or unwelcome, the magic of technology is confusing, disorienting, and unintuitive—a UX designer’s worst nightmare. So how can we ensure that the magic we create is intuitive? Designers will often say, “If a design is intuitive, it behaves how a user expects it to.” Well, then … what do users expect? We want to know the following whenever we find ourselves in a new environment (physical or digital): What are the objects? Where are the objects? How do these objects relate to me? How do these objects relate to each other? What is my role as an object within this environment? In physical spaces, these don’t require explicit thought to answer. However, in digital spaces, they often do. That is because our “lizard brains”—the part of the brain involved in motivation, emotion, learning, and memory—evolved alongside the physics of solid objects. Consequently, users may feel unsure when designers flout the perceptual expectations forged in the physical world. Without knowing what and where the objects are, we feel blind. Navigating feels uncomfortable. Taking action might even feel impossible. The remainder of this article introduces three ways to design digital objects that “play nice” with our evolved expectations of the physical world. By doing our best to concretize the dematerialized things of our screen-based world, we give our lizard brains better affordances for understanding. Lesson one: avoid shapeshifting objects The properties of user interfaces need to be consistent for us to learn them well. We hunger for stable landmarks in the often ambiguous maze of digital interfaces. Andrew Hinton, Understanding Context Objects in the real world don’t usually change form as they change context. When I bring a new toaster home from the store, it doesn’t change into a different toaster. When I remove a vase from the cabinet, it doesn’t turn into a coffee mug. Humans expect object permanence; we are taken aback when objects unexpectedly change shape. Why do babies love peekaboo so much? It’s a great way to practice the fundamentals of object permanence, an important lesson in survival (e.g., just because the tiger went behind the rock does not mean it has disappeared). Because babies are still coming to terms with this concept, peekaboo makes for a rollicking good time. So we might assume that if we up the ante on the surprise-factor, the game would be even more fun, right? Nope. Researchers measuring the level of toddlers’ delight during a series of hacked games of peekaboo discovered that the game loses its appeal when a different face pops up after hiding. The older the child, the more this hack kills the game. Evolution seems to be telling us: it’s not cool when objects suddenly change. But all that peekaboo practice is for naught when trying to navigate a digital world of shapeshifting objects. For instance, when this article was in the form of a Google Doc, it lived in both the Google Docs and the Google Drive environments. Depending on the environment, the article’s module changed form and function. Different menu options in Google Docs and Google Drive. Moving from Docs to Drive, the shape of the document module shifts from about a 3:5 rectangular ratio to a 1:1 square ratio. If I want to see when I last opened a document, I will find that information directly on the module while in Docs; but within Drive, I must look to a disembodied side panel (not shown). Both modules have a menu of actions, but accessing it requires different interactions. (In Docs, I click the “more” icon; in Drive, I right-click the module.) Worst of all, the menu contains almost completely different options in each module! Only “Remove” and “Rename” are found [...]



Be a Mentor

2017-10-05T12:22:00+00:00

Looking back over my eleven-year career in the web industry, I owe most of my success to two people from early on: Holly and Rebecca. Both were supervisors; but, more importantly, both were mentors. I wouldn’t be where I am today without their mentorship. Three years into my career, I got a promotion and became a supervisor myself. It was so exciting to be in a position to mentor others and give back to the community! I only had one question: how the heck do I do that? Mentorship has always been a part of the web industry. One of the first pieces of advice given to young web professionals is to find a mentor, and many experienced web professionals are where they are today because of their mentors. I think most of us would agree that mentoring others is a great thing. But when do you start mentoring? How do you provide good mentorship? How do you find people to mentor? In short, how do you do this? The truth I learned is that just about anyone with professional experience has something to offer novice or aspiring web professionals. You don’t have to be a director or an international speaker to be a good mentor—you can start today, and it’s probably easier than you think. You just need to be present, positive, patient, and productive. Finding opportunities You don’t need to be a supervisor to be a mentor, but if you’re not, finding someone to mentor can be intimidating. You can make this process much easier by having a few things in order and looking in the right spots. Before you seek out a mentee, you need to have demonstrable expertise to offer them. Make sure your personal website or portfolio is up to date. Try to build a professional following on Twitter or Medium to showcase your expertise. Answer some questions on StackOverflow or another forum, or write some tutorials. These will all help you in your career, and, when done well, can be mentorship opportunities in their own right. Workplaces are usually ripe with opportunities for mentorship. If you hold a manager or senior title, mentorship is an expectation; but even if you don’t, there’s always a need for showing new or younger employees the ropes. Make sure to check with your supervisor first, but there’s usually a strong need for enthusiastic and experienced mentors. Outside of work, mentorship opportunities still abound. If you’re experienced and successful in your field, you might talk with the local college (or even high school) about sharing your experience with interested students. Meetup groups are also a great place to meet people in search of an experienced mentor. Even if your area is completely devoid of others in the same field, the internet is not. Browse forums and online user groups—it won’t take long to find someone looking for a mentor. Be present A while back, I got some personal business cards printed up. I wasn’t looking for work. I meet a lot of people new to the web industry who could use someone to answer a few questions or provide feedback. I gave out about twenty business cards to friends, colleagues, and willing strangers with the explanation that I would answer their questions or review their projects. Want to guess how many used the card to contact me? Zero. That’s how many people reached out to me for feedback. The reason? Just like it’s harder to keep up with friends who move away, it’s hard to ask for feedback from someone who doesn’t seem available. People don’t think about it, or they feel bad about bothering you, or they get busy—whatever the reason, it’s a lot harder to reach out to someone who’s not present. Being present means creating opportunities for meaningful interaction. This doesn’t just mean proximity, but that’s a big part of it. If your job involves mentoring someone, sitting next to them will make this much easier. If you’re trying to mentor someone outside of work, checking in from time to time will do wonders. Lunch and coffee are amazing catalysts for mentorship. A persona[...]



Using Webfonts

2017-10-03T12:25:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 2 (“Using Webfonts") of Bram Stein's new book, Webfont Handbook, available now from A Book Apart.Now that you’ve selected a font, let’s put it on your website. Webfonts are defined in CSS through the @font-face rule. If you’re a web developer, you’ve most likely written, copied and pasted, or at the very least seen an @font-face rule. For the sake of completeness, though, let’s quickly run through a basic example: @font-face { font-family: Elena; src: url(elena-regular.woff); } This creates a new webfont family that can be referenced through the font-family or font shorthand property. But something’s missing here. When referencing a webfont in a font stack, always make sure to include at least one fallback font in case the webfont fails to load. Here, if Elena fails to load, the browser will fall back on the generic serif font family: p { font-family: Elena, serif; } We’ll talk more about fallback fonts and how they can be used to make your site appear to load faster in Chapter 3. For now, let’s keep our fallback stack simple by including only the generic serif and sans-serif font families. Font Families Creating a font family with multiple styles is accomplished by creating an @font-face rule for each style and using the same font-family name. The following @font-face rules create a family with a normal and bold style: @font-face { font-family: Elena; src: url(elena-regular.woff); font-weight: normal; } @font-face { font-family: Elena; src: url(elena-bold.woff); font-weight: bold; } You can use this font family in your CSS by referencing the family name and weight in your selectors. This applies the regular style to paragraphs and the bold style to strong paragraphs: p { font-family: Elena, serif; } p strong { font-weight: bold; } Besides font-weight, @font-face also accepts the font-style and font-stretch property descriptors, which define styles such as italic and condensed. All three property descriptors can be used to create a single font family with multiple styles. Theoretically, this lets you create a family containing 243 individual styles (nine font-weight values × three font-style values × nine font-stretch values). In practice, however, you’re limited to twenty-seven values, since some browsers don’t support font-stretch (Fig 2.1). Internet Explorer 8 Internet Explorer 9-11 Edge Chrome Firefox Safari Opera Android System No Yes Yes Yes Yes No Yes No Fig 2.1: Browser support for font-stretch at time of writing. (Check caniuse.com for current and version-specific browser support.) With luck, the remaining browsers will implement the font-stretch property soon, and you will be able to use all 243 font classifications. Font Formats The src descriptor tells a browser where to get a font file. The previous examples used a single font format, but you’ll often see URLs to multiple font formats combined with format hints, which are appended after the URL using the format("value") syntax. Format hints tell the browser what the format of the font file at a given URL is. @font-face { font-family: Elena; src: url(elena-regular.woff2) format("woff2"), url(elena-regular.woff) format("woff"); } If you list multiple formats, modern browsers will pick the first format they support based on the format hint. Therefore, it’s important to list webfont formats in the order of best compression to least. Even though format hints are optional, always include them—they let the browser know about the format without needing to download the font. For example, if a browser does not support WOFF2, but does support WOFF, it can skip the WOFF2 font file based on the format hint. Browsers support several webfont formats: OpenType (TrueType), EOT, WOFF, and WOFF2. Some browsers also support SVG fonts, but they’re deprecated and should no longe[...]



What I Talk About When I Talk About Sorting: Untangling Array#sort

2017-09-28T12:47:00+00:00

Sorting things is a fundamental part of our daily lives—it’s something we do everyday to make our lives easier, following all kinds of criteria. Whether you’re looking for a person’s phone number, the location of your favorite book, or even matching up your socks, sorting allows us to find what we are looking for in a faster and more effective way. This is also the case in the world of web development. But if you thought you knew exactly how JavaScript’s Array#sort works under the hood, think twice. Scratchin’ the surface No matter your skill level, if you’re a JavaScript developer you’ve probably come across the Array#sort method at some point. Do you remember the first time you tried sorting numbers in JavaScript? You were probably astonished to discover (just like the rest of us) that the sort method does NOT sort things quite as we might expect.  You don’t know what I’m talking about? Let’s dive into some code: const myArray = [33, 2, 98, 25, 4] myArray.sort() // [ 2, 25, 33, 4, 98 ] Wait, what? Is JavaScript nuts? In which world are 25 and 33 smaller than 4? Before you start rethinking your whole life, let’s figure this out. Lexicographical sorting What is actually happening here is that JavaScript is sorting our numerical array in a lexicographical manner—think alphabetical order, where every value is treated as a string. The catch here is that Array#sort can take a compare function as a parameter, but if you don’t supply it, “elements are sorted by converting them to strings and comparing strings in Unicode code point order” (according to the MDN docs). This means that JavaScript will treat the following arrays in a similar fashion when calling the sort method: const numbers = [80, 9] numbers.sort() // [80, 9] const strings = ['80', '9'] strings.sort() // ['80', '9'] In this case, “80” comes before “9” because it has a smaller Unicode code point. If you don’t believe me, let’s take a look at the code point value of the first character of each: "8".codePointAt(0) // 56 "9".codePointAt(0) // 57 Basically the function codePointAt() is simply a method of the String object that is used to get the Unicode code point value of any character at a given index. At this point, the following code shouldn’t be shocking to anybody because now we know that JavaScript is just converting all the elements in those arrays to strings and comparing their Unicode values. (Yes, Emojis also have Unicode code point values.) const emojis = ["😍","😂","😰"] emojis.sort() // ["😂", "😍", "😰"] const wtfJavaScript = [390, "😂", 1, "2325"] wtfJavaScript.sort() // [1, "2325", 390, "😂"] Numerical sorting After all that mumbo jumbo, what if we actually JUST wanted to sort our array numerically? As stated before, we need to provide a compare function that will sort the array elements according to the return value of that compare function. If the return value of compareFunction(a, b) is less than 0, a will come before b. If the return value is greater than 0, b will come before a. If the return value is 0, a and b will remain unchanged. To compare numbers instead of strings, provide a function that subtracts b from a. Here is an example: const myArray = [33, 2, 98, 25, 4] myArray.sort((a, b) => a - b) // [ 2, 4, 25, 33, 98 ] Rollin’ in the deep During all this JavaScript sorting fun, I bet you wondered at some point about the algorithm used by the native JavaScript sort method. No? That was just me? Either way, let’s check it out. Now, here’s the thing: the ECMAScript standard doesn’t specify which algorithm should be used, so each JavaScript engine is allowed to use whatever algorithm it wants. Why should you care about this? Keep reading, but first let’s find out which engines use which algorithms. (The good thing is that most of these engines are open source s[...]



Considering Open Source Licenses

2017-09-26T14:00:00+00:00

So you have a project that you want to use open source tools to create—well, I tip my hat off to you as a developer. But do you know the questions you need to answer before you get started? What stage of development is your project in right now? Have you finished the planning phase? Are you going to work with a team? Will the project be split up into different modules? And so on. The principle of DRY (Don’t Repeat Yourself) has become an unwritten rule for developers. Instead of always starting from scratch on each new project, find ways to build upon previous work. This will save you time and other resources. In other words, do not reinvent the wheel; put to use the great work that others have perfected and made “freely” available for you to build upon. This principle of DRY can also be applied to open source works. When starting a new project, most developers first search carefully for frameworks, libraries, and packages that they can build on or modify to fit their needs. Best of all, there are thousands upon thousands of open source projects (OSes, frameworks, IDEs, libraries, database management systems, and so on) available for you to choose from. But wait just a minute! Imagine your project becomes a huge hit, only to get knocked flat by licensing issues required by the works you built it with. Do you really understand what it means to use open source work in your project? As the adoption of open source keeps increasing, so does the risk of non-compliance with licensing terms—which in turn leads to an increase in the number of litigations involving open source works. One of the most recent examples [...]



How People Perceive Lossy Image Quality: A Study

2017-09-21T12:30:00+00:00

The notion that lossy image quality is subjective is not an unreasonable hypothesis. There are many factors that play into how humans perceive quality: screen size, image scaling, and yes, even performance.

Many research projects have tackled this subject, but I’ve recently launched a survey that attempts to understand how people perceive image quality in a slightly different way: in the context of performance.

This image quality assessment serves up 25 different specimens, each of which is presented in a random lossy quality setting between 5 and 100, in both JPEG and WebP formats. As participants complete the survey, navigation, resource and paint timings are collected (when available) from the browser, as well as other client details such as a device’s resolution, pixel density, and many other pertinent details.

The real work of gathering data begins. This is where you can help out. If you have five to ten minutes to spare, please head over to https://imagesurvey.site and participate. When the survey is finished, I’ll post the raw data and write and article (or two) on the findings. If further experimentation is required, that will be pursued as well. I don’t know what we’ll find out, but we’ll find out together with your input. So please participate!

Thank you!

Note: If you have feedback for how to improve the survey, feel free to comment! Just be aware that your feedback can’t be implemented in this run of the survey, but it could be useful in constructing any follow-up surveys.

(image)



The Ten Essentials for Good API Documentation

2017-09-19T13:00:00+00:00

API documentation is the number one reference for anyone implementing your API, and it can profoundly influence the developer experience. Because it describes what services an application programming interface offers and how to use those services, your documentation will inevitably create an impression about your product—for better or for worse. In this two-part series I share what I’ve learned about API documentation. This part discusses the basics to help you create good API docs, while in part two, Ten Extras for Great API Documentation, I’ll show you additional ways to improve and fine-tune your documentation.  Know your audience Knowing who you address with your writing and how you can best support them will help you make decisions about the design, structure, and language of your docs. You will have to know who visits your API documentation and what they want to use it for.  Your API documentation will probably be visited and used by the following audiences.  Developers Based on their skills, experience, and role in projects, developers will generally be the largest and most diverse group. They’ll be using your docs in different ways. At Pronovix, we started conducting developer portal workshops with our clients to help them learn more about what developers need and how to best support their work—and what they’re really looking for in API documentation. This is also supported by solid research, such as the findings published in Stephanie Steinhardt’s article following a two-year research program at Merseburg University of Applied Sciences. Newcomers: Developers lacking previous experience with your API tend to need the most support. They will take advantage of quickstart guides that encourage them to start using your API—clear, concise, step-by-step tutorials for the most important topics, and sample code and examples to help them understand how to use it in real projects. If you can make onboarding pleasant for newcomers, they will be more likely to devote themselves to learning every nuance of your API. External developers: Developers already working with your API will come back repeatedly to your docs and use them as reference material. They will need quick information on all the functionality your API offers, structured in an easy to understand way to help them quickly find what they need. Debuggers: Developers using your API will encounter errors from time to time and use your documentation to analyze the responses and errors that crop up. Internal developers: API providers tend to focus so much on their external audience that they forget about their own developers; internal teams working on the API will use the API documentation, as well. These are just the most common use cases. Decision makers Decision makers like CTOs and product managers will also check out your API documentation and evaluate your API. They need to determine whether your API will be a good fit for their project or not, so it’s crucial to your business that this group can easily and quickly find what they’re looking for. Other audiences Although not as common, journalists, technical writers, support staff, developer evangelists, and even your competition might read your API documentation.  Remember the purpose of documentation The foundation of your API documentation is a clear explanation of every call and parameter. As a bare minimum, you should describe in detail: what each call in your API does each parameter and all of their possible values, including their types, formatting, rules, and whether or not they are required. Context-based structure People won’t read your API documentation in order, and you can’t predict which part they will land on. This means, you have to provide all the information they need in context. So follow[...]



Project Management for Humans

2017-09-14T18:40:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 6 of Brett Harned's new book, Project Management for Humans, available now from Rosenfeld Media.I loved the game Tetris as a kid. I played the Game Boy version for hours. It’s easy to get wrapped up in the concept of little shapes coming together in a logical way to clear a goal. The pieces complement one another, yet they all naturally work in different ways. The game has stuck with me since I was a kid (and, no, I’m not a gamer). I now have it on my phone and iPad and find myself playing it when I’m on a flight or bored, waiting for something to happen (which is never these days). Whether I’m playing the game a lot or not, the idea of making tiny boxes fit in neatly and clearing out rows of work is ingrained in my brain. It’s the project manager in me. But here’s the thing: What project managers do on a daily basis when it comes to managing resources or staffing is similar to Tetris, and it’s a big project management challenge that we all face. The biggest difference between resourcing and Tetris? The team members we’re trying to assign tasks to aren’t blocks. They’re human beings, and they need to be treated as such. Your Team Are People, Too! Let’s move away from calling people “resources,” please. We’re really just staffing projects or assigning tasks. We’re not using people to just get things done. We’re asking them to solve challenges that are presented in our projects. Set the Stage for Organized Resource Planning The challenge of managing a team is making sure that they stay busy and working on tasks, yet are not completely overbooked. It’s a difficult balance to find, particularly when your projects require a variety of skills at different times, which seem to change all too often. At the most basic level, you want to set up a system for tracking your projects and your team members’ time on those projects (see Figure 6.1). A simple goal is to ensure that you can confidently commit to deadlines on projects with the knowledge that your team is actually available to do the related work. It seems like a simple goal, but it’s often a difficult one to keep up with due to changes on projects, changes in personal schedules (hey, life happens), and an influx of new work and requests. But it’s not an insurmountable challenge. In fact, a simple spreadsheet could help you, particularly if you’re managing a smaller team. At the core, you want to track these items: Projects (List them all, even the non-billable ones, or the other things that aren’t projects but end up taking a lot of time—like business development.) People (List every person you work with.) Estimated time (Track hours, days, weeks, etc. Make your best guess—based on your timeline or calendar—on how much each person will spend on a project or a task.) Figure 6.1: Use a Google Spreadsheet, Numbers, or Excel to input your project and team data. A couple of notes on how to use a spreadsheet to forecast team availability: This should be set up on a week-by-week basis to minimize confusion (use tabs in your spreadsheet for each new week). Always consider the “nonbillable” things that people must do (like stand-up meetings, internal tasks, sales, etc.). The final cell contains a formula that tallies the hours for you; if the hours go over your typical limit (think of a 40-hour work week), it will turn red to notify you. You’ll want to have a good idea for just how “utilized” someone should be (32 hours/week is usually a good target). You can input the actual hours logged in your time tracking system if you’d like. It could help with future estimating. (If you’re not tracking time, check in with your team on time percentages to g[...]



A List Apart volunteer update

2017-09-13T13:08:00+00:00

A note from the editors: A few days ago, we announced a reimagined A List Apart, with you, our faithful readers of nearly 20 years, contributing your talents. The response from this community was humbling, thrilling, and, frankly, a bit overwhelming. If you volunteered to help A List Apart and haven’t heard back from us yet, here’s what’s up.To the many wonderful souls who have so far volunteered to help A List Apart, thank you very, very much for your emails! And if you haven’t heard back from us yet,  please excuse the delay. We’ve been inundated with messages from hundreds of potential volunteers across a wide spectrum of disciplines and potential task groups, and we are going through your messages slowly and carefully, responding personally to each one. Some of you have written asking if we might be interested in having you write for us. Gosh, A List Apart has always welcomed articles from our community. Guidelines (plus how to submit your first draft, proposal, or outline) are available at alistapart.com/about/contribute. Please check them out—we’d love to look at any topically appropriate article you care to submit. 
 But writing articles is far from the only way to support and make your mark at the new (19-year-old) ALA. Meet the groups! If you’ve expressed an interested in organizing or hosting an ALA-themed monthly meet-up, or have other ideas that can help grow community, we’ll invite you to join our newly forming COMMUNITY group. If EDUCATION AND OUTREACH is more your thing, we are starting a group for that, as well. There are other groups to come, as well—a list of our ideas appears in the original post on the topic, and there may be more groups to come. How these groups will work, and what they will do, is largely going to be determined by the volunteers themselves. (That’s you folks.) As we’re starting the work of supporting and organizing these groups on Basecamp, you can’t just add yourself to a group, as you could on, say, Slack. But that’s okay, because we want to approach this somewhat methodically, adding people a few at a time, and having little written conversations with you beforehand. Our fear was that if we launched a bunch of Slack channels all at once, without speaking with each of you first, hundreds of people might add themselves the first day, but then nobody would have any direction as to what might be expected—and we might not have the resources ready to provide guidance and support. By adding you to Basecamps a few at a time, and hopefully identifying leaders in each new group as it begins forming, we hope to provide a lightly structured environment where you can design your own adventures. It takes a little longer this way, but that’s by design. (A List Apart started in 1997 as a 16,000-member message board. Big open channels are great for letting everyone speak, but not necessarily the best way to organize fragile new projects.) If you are interested in contributing to those projects, or curious about a particular area, and told us so in your initial email, we will eventually get to you and assign you to the right slot. If you haven’t yet volunteered, of course, you can still do so. (See the original post for details.) Editors, developers, and designers
 But wait, there’s more. Developers: if you have standards-oriented front-end development experience and would like to help out on day-to-day site maintenance, occasional minor upgrades, and an eventual redesign, just add yourself to A List Apart’s Github front-end repo: github.com/alistapart/AListApart. Those with backend experience (particularly in ExpressionEngine and WordPress), you will hear from us as we work our way through your emails. Editor-in-chief Aaron Gustafson and I have also been goin[...]



Patterns and Purpose, an Excerpt from Animation at Work

2017-09-12T13:59:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Rachel Nabors's new book, Animation at Work, available now from A Book Apart.So we can use animations to tap into users’ visual systems and give them a cognitive speed boost, terrific! But before animating every element of our designs, we must learn when and how to use this new tool: with great power comes great responsibility, and so forth. And as animation must vie with many other concerns for development and design time, it makes sense to spend our resources where they’ll go the farthest. This chapter sets you up with some core animation patterns and shows you how animation applies to a greater system. Then you’ll learn how to spot cognitive bottlenecks and low-hanging fruit, maximizing the impact of the animations you do invest in. Common Animation Patterns If you’ve looked at as many examples of animation on the web and in app interfaces as I have, certain patterns start to emerge. These patterns are helpful for identifying and succinctly verbalizing the purpose of an animation to others. Here are the categories I’ve found myself using the most: Transitions take users from place to place in the information space, or transition them out of one task into another. These tend to have massive impacts on the content on the page, replacing large portions of information. Supplements bring information on or off the page, but don’t change the user’s “location” or task. They generally add or update bits of additional content on the page. Feedback indicates causation between two or more events, often used to connect a user’s interaction with the interface’s reaction. Demonstrations explain how something works or expose its details by showing instead of telling. Decorations do not convey new information and are purely aesthetic. Let’s have a look at each of them and see how they impact the user’s experience. Transitions The web was originally designed as a series of linked documents. Clicking on a link caused the browser to wipe the screen, often causing a telltale flash of white, before painting the next page from scratch. While this made sense in the context of linked text-based documents, it makes less sense in an era where pages share many rich design elements and belong to the same domain. Not only is it wasteful of the browser’s resources to be recreating the same page layout over and over, but it also increases users’ cognitive load when they have to reorient and reevaluate the page’s content. Animation, specifically motion, can facilitate the user’s orientation in an information space by offloading that effort to the brain’s visual cortex. Using a transition between changes in task flow or locations in information architecture ideally reinforces where the user has been, where they are going, and where they are now in one fell swoop. For example, on Nike’s SB Dunk page, when a user clicks a navigation arrow, the current sneaker moves out of the way while the next sneaker moves in from the opposite direction (Fig 2.1). These transitions clearly show the user how they are navigating along a linear continuum of sneakers, helping them keep track of their place and reinforcing the spatial model of perusing a real-world row of sneakers. Fig 2.1: On this Nike page, transitions are used to navigate forwards and backwards along a linear continuum of sneakers. (Watch the accompanying video.) On another shoes site, fluevog.com, transitions move the user from task to task (Fig 2.2). After a user starts typing in the search field, the results are animated on top of a darker backdrop. This transitions the user from the browsing context to refining their search results, streamlining their focus while also rea[...]



New A List Apart wants you!

2017-09-07T14:00:00+00:00

As A List Apart approaches its 20th anniversary—a milestone in independent, web-based publishing—we’re once again reimagining the magazine. We want your feedback. And most of all, we want you. We’re getting rid of advertisers and digging back to our roots: community-based, community-built, and determinedly non-commercial. If you want to highlight local events or innovations, expand your skills, give back, or explore any other goal or idea, we’re here to support you with networking and backing from the community. In recent years, we’ve seen our rich universe of diverse, creative blogs and sites implode—leaving fewer and fewer channels available to new voices. As more content centralizes into a handful of all-powerful networks, there’s a dreary sameness in perspective and presentation. This creeping monopolization is a sad echo of how media worked in the 20th century. It doesn’t reflect 21st century diversity and empowerment. It’s not the web’s promise. It’s not how it’s supposed to be. We have no beef with networks like Twitter or Facebook, or with companies like Apple and Google that currently dominate our communal digital space. We just think diversity is about expanding and speaking up—not consolidating and homogenizing. Define the next decade with us A List Apart has always been more than a publisher; we’re an ecosystem of practitioners who are passionate about our craft. We’ll keep finding and sharing great articles—we’re just taking it to the next level. Two ways to pitch in If you want to put your favorite skills to use, expand your professional experience, or have a goal or idea for A List Apart, we’re here to listen. And if you’d like to support us in some other way, we’ve made that easy, too. Currently there are two ways to pitch in: Teams Use the email address at the bottom of this message to let us know if you want to create or join a team that “owns” some area you’re interested in, such as: Design & development Community service and local meetups/events Education and entry level/advanced resources Book/resource coverage and reviews Editorial: Editing, acquisitions, and email Social media, SEO, or marketing Project management Your suggestions! Membership If you don’t have time to volunteer but still want to support us, you’ll be able to offer other forms of help—for instance, making a small, monthly donation via Patreon to help cover our expenses. This will also grant you membership benefits. (Details at Patreon.) Sharing is caring More about all of this will soon be revealed. Meantime, if you have feedback or questions about what we’ve shared so far, kindly fire away in the comments. (Hey, how’s that for an idea? A comments section that’s positive and not divisive.) As we imagine the next 20 years of web design, there’s a lot we don’t know—other than a strong hunch that accessible, semantic HTML will continue to be the bedrock of it all. But one thing we do know: the web, in its reach and its potential, is too important to be left to the mercies of a few powerful companies, however well-intended they may be. If you’ve a mind to do so, please help us keep our little corner of the indie web alive and well. Help the open web stay open. Help us build the future. To get involved, email us at contact@alistapart.com—or share your thoughts in the Comments section below. The independent content producer refuses to die!   Jeffrey Zeldman, Publisher Aaron Gustafson, Editor-in-chief & the gang    [...]



Conducting the Technical Interview

2017-09-05T17:41:00+00:00

I vividly remember my first interview as a manager. My hands were shaking as I led the candidate up the stairs to the conference room I had booked. When we got there, I went into a panic. What if I don’t ask a vital question? How do I even know what the vital questions are? What if I hire him and he’s completely unprofessional? How can I tell if he really knows JavaScript? Wait a second—does he have a prosthetic leg? Did I just take a candidate with a prosthetic leg up the stairs? Oh no, I’m failing this interview already! Even if you’re familiar with the basics of interviewing, technical interviews can be nerve-wracking. Whether you’re a new team lead or you’ve been in leadership for years, concerns and insecurities like the ones I had in my first interview can haunt you, and even well-established interview processes can fail to adequately screen candidates. Interviewing for technical positions is, in many ways, a balancing act. You look at past, present, and future; you look at soft skills and hard skills; you have to think as both a buyer and a seller; you even have to worry about company image and reputation management. There are some basic things you can do to keep that balance and best represent your company. Define the ideal role I’ll admit, for my first round of interviews, all I was looking for was someone who could tick off all the technical skills on a checklist. As I progressed in my management career, I started to learn that I never looked for the same person twice—each time I had an opening, the team had different needs, and I had to take those into account when hiring someone. Even though the job description for a front-end developer didn’t change much each time, my expectations for the ideal candidate did. That gap between the job description and the ideal role tripped me up for a long time. Before you start interviewing, you’ll need a solid written description of what you’re looking for in an ideal candidate, beyond what job postings typically go into. The job posting may say Senior Front End Developer, but if you need someone to be your CSS animation specialist and help define standards and best practices—whether now or in eight months—you’ll need to take that into account when hiring. Be future-oriented with your description: ask yourself what happens when the employee outgrows his or her role. Could this person be a supervisor, or would they even want to be? Is there an opportunity to be a technical leader or architect at your company, if that’s the route this person chooses? Could this person one day replace you? (Remember, you’re probably not getting promoted until there’s someone to take your place.) If you have no answer to the question of what happens when an employee outgrows the role, the answer is usually found at another company. Also ask what happens if the team continues to grow. Does this person have the aptitude to pick up new skills and responsibilities as needed? How will this person respond to change? What if you have to put this person in front of a client? At a healthy company, growth is inevitable, both in size and scope. Your definition should describe someone who can grow with you and not get left behind. Define not only the technical skills, but also the soft skills needed for the role you have in mind. If you need someone to take the lead on collaborating with the Creative team, you’ll need to define what would make an employee successful in that role and hire for that. This can actually be more important than the technical skill requirements. Technical skills can be easily trained—soft skills cannot. When you do all of this, you’ll have a list of expectations for a role that prob[...]



Yes, That Web Project Should Be a PWA

2017-08-30T18:30:00+00:00

It seems like ever since Frances Berriman  coined the term “Progressive Web App” in an effort to describe a new class of website, there’s been a great deal of confusion over exactly what a Progressive Web App (PWA) is. Sure, her husband, Alex Russell, put together a handy guide to the characteristics of a PWA, and they have been the subject of reams of documentation, dozens of blog posts, and equally as many conference talks. Even with so much well-written, accessible content about PWAs freely available, misinformation abounds. Maybe you’ve run into one or more of these: If you’re building a PWA, you need to use a JavaScript framework. To build a PWA, start with a single page app. PWAs only make sense for “apps” your users want to install. PWAs only make sense in mobile. PWAs are an Android thing. None of these are true, but like so much misinformation these days, each contains a shred of truth that has been contorted into a falsehood. If you’re considering building a PWA, you might use a JavaScript framework or build it as a single page app, but it’s by no means necessary. They’re an option for building a PWA just like they’re an option for any other web project. After all, every PWA is (or at least should be) a website. PWAs just have some features that empower them to do more than websites have traditionally been able to ... like install. But, similarly, installation is not the raison d’être of every PWA. And, while many of the first PWAs were focused on mobile and only worked on Android, PWAs are not limited to small screen devices anymore. They’re also more than a Google thing too; Microsoft, Mozilla, Opera, and Samsung are all on board. Apple recently declared their intent to implement Service Workers (one of the technical underpinnings of PWAs), but time will tell if they’ll support aspects like installation. No matter, as Progressive Web Apps work really well in Safari anyway! Sadly, misinformation like this has convinced many designers and developers (and their management teams) that PWAs aren’t appropriate for their projects. They are! Your site—every site—should be a PWA. This approach offers benefits for every project on the web, but I’ll get to that in a minute. Before I do, I want to level-set on what, exactly, makes a PWA a PWA. If you’ve been tracking PWAs closely or have already built one, you can skim or skip the next section. If you aren’t all that familiar or don’t feel like you have a good grasp on what they are, no worries, the next section is a very brief primer that will get you up to speed quickly. So what is a PWA? As I mentioned, a PWA is a website with special powers. The term “app” in the “Progressive Web App” is not indicative of the sort of content or experience users should expect with a PWA. You shouldn’t get hung up on it; “Progressive Web App” is a marketing term. PWAs have the ability to connect with the operating system (and, thereby, its users) on a deeper level through installation and APIs offering capabilities like notifications, access to the address book, and more. Not all of these APIs require installation for access, but some do. It may help to think about a PWA as being a website++. What makes a PWA a PWA? Not much, actually; there are only three requirements: You need to be running under HTTPS. PWAs can be granted a whole host of extra privileges in an operating system, so it’s critical that the connection to your web server be secure. If you need help with this, you should check out the free SSL service Let’s Encrypt. You need a Web App[...]



User Interfaces for Variable Fonts

2017-08-25T14:00:00+00:00

The tools we design with have a unique effect on the way we work, constraining and empowering us while we explore, examine and create. Variable fonts give us a new, wide open typographic space with which to work. Instead of prescribing value to individual UI elements in a vacuum, we should take a hybrid and calculated approach to variable font interfaces. How do we structure our design tools to adapt to the new advantages variable fonts provide us with? Despite being ahead of their time, variable font precursors—Multiple Master and GX—didn’t see widespread adoption for several reasons—one key reason being the lack of effective user interfaces that could communicate their creative utility to designers. Since their introduction, variable fonts have moved forward quickly, landing with various degrees of experimental support across major browsers. With this comes the exciting ability for fonts to responsively adapt to different layouts and context. While responsive design has become more standard, effective variable font user interfaces have yet to be adopted. A number of approaches can make variable fonts (which can house effectively any number of variations) easier to understand and use. Through design exploration and looking at prexisting examples we can see how each UI element has different benefits and drawbacks. We find that few patterns should be applied to every case. Enabling Variable Fonts Within our design tools, variable fonts present a unique challenge, allowing users to select and change different properties of the typeface that are exposed by the typeface designer. These changes occur along an interpolation axis—or a line that reflects variation values of a font: Previewing Dunbar, a variable font with two axes by CJ Dunn within Fontview. AxisPraxis and Typeshift (my own design tool) are some other great places to check out variable fonts! A variable font can have any number of axes, but these can generally be reduced down to a few commonly used axes mostly likely to be used for Responsive Design. These default axes are called registered axes in the spec. Each one has a different set of use cases: Font Weight – (wght): For adapting font weight to the container size, the weight of other elements, changes to hierarchy and screen resolution Font Width – (wdth): For fitting the width of the typeface to the width of a container Font Italicization – (ital): For changing how italicised the type is Font Slant – (slnt): For changing how oblique the type is Font Optical size – (opsz): For adapting to container size, font size and adjusting hierarchy and typographic color These axes take advantage of much of the layout-based adaption variable fonts provide. Some of these concepts are best illustrated in Erik Van Blokland’s responsive lettering project: Along with some of the amazingly beautiful Type and Media work to date: In these examples, the glyphs’ optical size, weight and width shift at the same time as you resize the window. While a large portion of variable font axes directly correlate to layout, any number of arbitrary, non registered axes can also be created by the type designer. These can be for any type of change to the typeface in addition to interacting with the layout. David Berlow’s Decovar ornamental typeface is an example of this at one extreme. Decovar sports a wide number of settings for adjusting the font’s decorative terminals and skeleton of the font. The limit here is the type designer’s imagination. New Spaces Variable fonts carry with them a broad range of possibi[...]



Integrating Animation into a Design System

2017-08-17T17:09:00+00:00

Keeping animation choreography cohesive from the outset of a project can be challenging, especially for small companies. Without a dedicated motion specialist on the team, it can be difficult to prioritize guidelines and patterns early in the design process. What’s more likely to happen is that animations will be added as the product develops. Unsurprisingly, the ad-hoc approach can lead to inconsistencies, duplications, and rework in the long run. But it also provides space for creative explorations and discoveries of what works and what doesn’t. As useful as it is to be able to establish system foundations early, it is also ok to let the patterns emerge organically as your team experiments and finds their own voice in motion. Once there are enough animations, you might start thinking about how to ensure some consistency, and how to reuse existing patterns rather than recreate them from scratch every time. How do you transition a few odd animations to a cohesive system? I find it helpful to start by thinking about the purpose of animations and the feel they’re designed to evoke. Start with purpose and feel Purpose Like any other element in a design system, animations must have a purpose. To integrate animation, start by looking through your interface and noting how and why you use animations in your particular product and brand. For example, at FutureLearn we noticed that we primarily use animation in three ways—to indicate a state change, to add an emphasis, or to reveal extra information: A state change shows that an object has changed state due to user interaction. For example, a state can change on hover or on click. Animation here is used to soften the transition between states. Emphasis animations are used to draw attention to specific information or an action, for example a nudge to encourage users to progress to the next step in the course. Reveal animations are used to hide and reveal extra information, such as a menu being hidden to the side, a drop down, or a popover. There are no “standard” categories for the purposes of animations. Some products use a lot of standalone animations, such as animated tutorials. Some use screen transitions, others don’t. Some make personality and brand part of every animation, others group them into their own category, like in the Salesforce Lightning Design System. Animation types in Salesforce Lightning Design System are categorized in a different way to FutureLearn. The categories are specific to your interface and brand, and to how you use animation. They shouldn’t be prescriptive. Their main value is to articulate why your team should use animation, in your specific project. Feel As well as having a purpose in helping the user understand how the product works, animation also helps to express brand personality. So another aspect to consider is how animation should feel. In “Designing Interface Animation,” Val Head explains how adjectives describing brand qualities can be used for defining motion. For example, a quick soft bouncy motion can be perceived as lively and energetic, whereas steady ease-in-outs feel certain and decisive. Brand qualities translated to motion Brand feel Animation feel Effect examples Lively and energetic Quick and soft Soft bounce Anticipation Soft overshoot Playful and friendly Elastic or springy Squash and stretch Bouncy easing Wiggle Decisive and certain Balanced and stable Ease-in, Ease-out Ease-in-out Calm and soft Small soft movements or no movement at all Opacity, color o[...]



Practical User Research: Creating a Culture of Learning in Large Organizations

2017-07-27T15:00:00+00:00

Enterprise companies are realizing that understanding customer needs and motivations is critical in today’s marketplace. Building and sustaining new user research programs to collect these insights can be a major struggle, however. Digital teams often feel thwarted by large organizations that are slow to change and have many competing priorities for financial investments. As a design consultant at Cantina, I’ve seen companies at wildly different stages of maturity related to how customer research impacts their digital work. Sometimes executives struggle to understand the value without quantifiable numbers. Other times engineering teams see customer research and usability testing as a threat to delivery dates. While you can’t always tackle these issues directly, the great thing about large organizations is that they’re brimming with people, tools, and work practices forming an overall culture. By understanding and utilizing each of these organizational resources, digital teams can create an environment focused on learning from customers. I did some work recently for a client I’ll call WorkTech, who had this same struggle aligning their digital projects with the needs of their customers. WorkTech was attempting to redesign their entire ecommerce experience with a lean budget and team. In a roughly six month engagement, two of us from Cantina were tasked with getting the project back on track with a user-centered design approach. We had to work fast and start bringing customer insights to bear while moving the project forward. Employing a pragmatic approach that looked at people, tools, and work practices with a fresh set of eyes helped us create an environment of user research that better aligned the redesign with the needs of WorkTech’s customers. Get comfortable talking to People in different roles Effective user research programs start and end with people. Recognizing relationships and the motivations held by everyone interacting with a product or service encourages goodwill and can unearth key connections and other, less tangible benefits. To create and sustain a culture of learning in your company, find a group of users to interview—get creative, if you have to—and enlist the support of teammates and stakeholders. Begin by taking stock of anyone connected to your product. You won’t always find a true set of end users internally, but everyone can help raise awareness of the value of user research—and they can help your team sustain forward progress. Ask yourself the following questions to find allies and research resources: What departments use your product indirectly, but have connections to people in the user roles you’re targeting? Is there a project sponsor who can help sell the value of research and connect you to additional staff that can assist in some capacity? Are there employees in other departments whose individual goals align with getting better feedback from users? Are there departments within the organization (sales, customer service) who can offer connections to customers wanting to provide candid feedback? Our WorkTech project didn’t have a formal research budget for recruiting users (or any other research task). What we did have going for us was a group of internal users who gave our team immediate access to an initial pool of research participants. The primary platform we were hired to help redesign was used by two groups: WorkTech employees and the customers they interacted with. Over time, our internal users were able to connect us with their external counterparts, amplifying the number of peop[...]



Team Conflict: Four Ways to Deflate the Discord that’s Killing Your Team

2017-06-27T14:00:00+00:00

It was supposed to be a simple web project. Our client needed a site that would allow users to create, deploy and review survey results. Aside from some APIs that weren’t done, I wasn’t very worried about the project. I was surprised that my product manager was spending so much time at the client’s office. Then, she explained the problem. It seemed that the leaders of product, UX and engineering didn’t speak to each other and, as a result, she had to walk from office to office getting information and decisions. When two people have a bad interaction, they can work it out or let the conflict grow, spreading it to other team members and their leaders. The conflicts probably started small. One bad interaction, then another, then people don’t like each other, then teams don’t work together well. The small scrape becomes a festering wound that slows things down, limits creativity and lowers morale. Somehow as a kid working my way through school I discovered I had a knack for getting around individuals or groups that were fighting with each other. I simply figured out who I needed to help me accomplish a task, and I learned how to convince, cajole or charm them into doing it. I went on to teach these skills to my teams. That sufficed for a while. But as I became a department head and an adviser to my clients, I realized it’s not enough to make it work. I needed to learn how to make it better. I needed to find a way to stop the infighting I’ve seen plague organizations my entire career. I needed to put aside my tendency to make the quick fix and have hard conversations. It’s messy, awkward and hard for team leaders to resolve conflict but the results are absolutely worth it. You don’t need a big training program, a touchy-feely retreat or an expensive consultant. Team members or team leads don’t have to like each other. What they have to do is find common ground, a measure of respect for one another, and a willingness to work together to benefit the project. Here are four ways to approach the problem. Start talking No matter how it looks at first, it’s always a people problem. Gerald M. Weinberg, The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully Resist the urge to wait for the perfect time to address team conflict. There’s no such thing. There will always be another deadline, another rollout, another challenge to be met. In our office, a UX designer and product manager were having trouble getting along. Rather than take responsibility, they each blamed our “process” and said we needed to clarify roles and procedures. In other words, they each wanted to be deemed “in charge” of the project. Certainly I could have taken that bullet and begun a full-on assessment of our processes and structure. By taking the blame for a bad company framework, I could have dodged some difficult conversations.  But I knew our process wasn’t the problem. First, I coached the product manager to be vulnerable, not an easy thing for him to do. I asked him to share his concerns and his desire to have a more productive relationship with the UX designer. The PM’s willingness to be uncomfortable and open about his concerns lifted the tension. Once he acknowledged the elephant in the room—namely that the UX designer was not happy working with him—the designer became more willing to risk being honest. Eventually, they were able to find a solution to their disagreements on the project, largely because they were willing to give each other a measure of respect. The worst[...]



Color Accessibility Workflows

2017-06-06T14:00:00+00:00

A note from the editors: We’re pleased to share an excerpt from Chapter 3 of Geri Coady's new book, Color Accessibility Workflows, available now from A Book Apart.The Web Content Accessibility Guidelines (WCAG) 2.0 contain recommendations from the World Wide Web Consortium (W3C) for making the web more accessible to users with disabilities, including color blindness and other vision deficiencies. There are three levels of conformance defined in WCAG 2.0, from lowest to highest: A, AA, and AAA. For text and images of text, AA is the minimum level that must be met. AA compliance requires text and images of text to have a minimum color contrast ratio of 4.5:1. In other words, the lighter color in a pair must have four-and-a-half times as much luminance (an indicator of how bright a color will appear) as the darker color. This contrast ratio is calculated to include people with moderately low vision who don’t need to rely on contrast-enhancing assistive technology, as well as people with color deficiencies. It’s meant to compensate for the loss in contrast sensitivity often experienced by users with 20/40 vision, which is half of normal 20/20 vision. Level AAA compliance requires a contrast ratio of 7:1, which provides compensation for users with 20/80 vision, or a quarter of normal 20/20 vision. People who have a degree of vision loss more than 20/80 generally require assistive technologies with contrast enhancement and magnification capabilities. Text that acts as pure decoration, nonessential text that appears in part of a photograph, and images of company logos do not strictly need to adhere to these rules. Nonessential or decorative text is, by definition, not essential to understanding a page’s content. Logos and wordmarks may contain textual elements that are essential to broadcasting the company’s visual identity, but not to conveying important information. If necessary, the logo may be described by using an alt attribute for the benefit of a person using screen-reader software. To learn more, check out accessibility specialist Julie Grundy’s blog post on Simply Accessible, where she goes into the best practices around describing alt attributes. Text size plays a big role in determining how much contrast is required. Gray text with an RGB value of (150,150,150) on a pure white background passes the AA level of compliance, as long as it’s used in headlines above 18 points. Gray text with an RGB value of (110,110,110) passes the AA level at any text size, and will be AAA compliant if used as a headline above 18 points (Fig 3.1). A font displayed at 14 points may have a different level of legibility compared to another font at 14 points due to the wide diversity of type styles, so keep this in mind, especially when using very thin weights. Fig 3.1: Text size also plays a role when calculating compliance ratios. Personally, I recommend that all body text be AAA compliant, with larger headlines and less important copy meeting AA compliance as a bare minimum. Keep in mind that these ratios refer to solid-colored text over solid-colored backgrounds, where a single color value can be measured. Overlaying text on a gradient, pattern, or photograph may require a higher contrast value or alternative placement, such as over a solid-colored strip, to provide sufficient legibility. These compliance ratios are often what folks mean when they claim that achieving accessible design by “ticking off boxes” can only come at the cost of stifled creativity or restricted color choices. But that si[...]