Subscribe: A List Apart
Added By: Feedage Forager Feedage Grade A rated
Language: English
animation  api  design  don’t  find  it’s  make  much  new  people  project  team  time  user  users  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-09-19T13:00:00+00:00


Considering Open Source Licenses


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


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


The Ten Essentials for Good API Documentation


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 following the best practices of topic-based authoring, you should include all necessary and related information in the explanation of each call. Context.IO, for example[...]

Project Management for Humans


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 get a gut check.) Check your estimates with your team to make sure that the hours actually align with their assessment of the task (This might help with avoiding tha[...]

A List Apart volunteer update


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 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: 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 going slowly through your mails looking for additional editorial help. We’ve already found and added a few very promising people to our volunteer editorial staff, and[...]

Patterns and Purpose, an Excerpt from Animation at Work


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,, 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 reassuring them that they can get back to browsing without much effort. Fig 2.2: On Fluevog’s website, transitions move users from the browsing context to the sea[...]

New A List Apart wants you!


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—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


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 probably won’t fit in a job posting. When appropriate (don’t make promises of growth), test those waters with the people you’re interviewing. Even if you determi[...]

Yes, That Web Project Should Be a PWA


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 Manifest. This is a lot less scary than it sounds. It’s a JSON file with information about your site. You may even have a bare-bones one already if you’[...]

User Interfaces for Variable Fonts


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 possibilities and can open up entire designspaces of creative options to type, graphic and web designers. These aren’t human readable at first—they exist as m[...]

Integrating Animation into a Design System


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 or blur changes, scale changes As you look through the animation examples in your interface, list how the animation should feel, and note particularly effec[...]

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


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 people offering feedback significantly. Maximize the value of every interview While interviewing external customers, we kept an eye on the long term success of our r[...]

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


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 thing I’ve seen is when leaders move people from team to team hoping that they will magically find a group of people that work well together, and work well with [...]

Color Accessibility Workflows


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 simply isn’t true. Experimentation with a color-contrast checker proves that many compliance ratios are quite reasonable and easy to achieve—especially if you are[...]

The Mindfulness of a Manual Performance Audit


As product owners or developers, we probably have a good handle on which core assets we need to make a website work. But rarely is that the whole picture. How well do we know every last thing that loads on our sites? An occasional web performance audit, done by hand, does make us aware of every last thing. What’s so great about that? Well, for starters, the process increases our mindfulness of what we are actually asking of our users. Furthermore, a bit of spreadsheet wizardry lets us shape our findings in a way that has more meaning for stakeholders. It allows us to speak to our web performance in terms of purpose, like so: Want to be able to make something like that? Follow along. Wait, don’t we have computers for this sort of thing? A manual audit may seem like pointless drudgery. Why do this by hand? Can’t we automate this somehow? That’s the whole point. We want to achieve mindfulness—not automate everything away. When we take the time to consider each and every thing that loads on a page, we get a truer picture of our work. It takes a human mind to look at every asset on a page and assign it a purpose. This in turn allows us to shape our data in such a way that it means something to people who don’t know what acronyms like CSS or WOFF mean. Besides, who doesn’t like a nice pie chart? Here’s the process, step by step: Get your performance data in a malleable format. Extract the information necessary. Go item by item, assigning each asset request a purpose. Calculate totals, and modify data into easily understood units. Make fancy pie charts. The audit may take half an hour to an hour the first time you do it this way, but with practice you’ll be able to do it in a few minutes. Let’s go! Gathering your performance data To get started, figure out what URL you want to evaluate. Look at your analytics and try to determine which page type is your most popular. Don’t just default to your home page. For instance, if you have a news site, articles are probably your most popular page type. If you’re analyzing a single-page app, determine what the most commonly accessed view is. You need to get your network activity at that URL into a CSV/spreadsheet format. In my experience, the easiest way to do this is to use WebPagetest, whose premise is simple: give it a URL, and it will do an assessment that tries to measure perceived performance. Head over to WebPagetest and pop your URL in the big field on the homepage. However, before running the test, open the Advanced Settings panel. Make sure you’re only running one test, and set Repeat View to First View Only. This will ensure that you don’t have duplicate requests in your data. Now, let the test run—hit the big “Start Test” button. Once you have a results page, click the link in the top right corner that says “Raw object data”. A CSV file will download with your network requests set out in a spreadsheet that you can manipulate. Navigating & scrubbing the data Now, open the CSV file in your favorite spreadsheet editor: Excel, Numbers, or (my personal favorite) Google Sheets. The rest of this article will be written with Google Sheets in mind, though a similar result is certainly possible with other spreadsheet programs. At first it will probably seem like this file contains an unwieldy amount of information, but we’re only interested in a small amount of this data. These are the three columns we care about: Host (column F) URL (column G) Object Size (column N) The other columns you can just ignore, hide, or delete. Or even better: select those three columns, copy them, and paste them into a new spreadsheet. Auditing each asset [...]

Web Maintainability Industry Survey: How Do We Maintain?


A note from the editors: As a community, we can learn so much from discovering what other developers are doing around the world. We encourage everyone to participate in this very brief survey created by Jens Oliver Meiert. Jens will share the results—and an updated guide to web maintainability based on the findings—in a few weeks.

How often do we consider the maintenance and general maintainability of our websites and apps? What steps do we actively take to make and keep them maintainable? What stands in the way when we maintain our and other people’s projects?

Many of us, as web developers, know very well how to code something. But whether we know just as well how to maintain what we—and others—have written, that is not so clear. Our bosses and clients may not always think about maintenance down the road, either.

As an O’Reilly author and former Googler, I’ve been studying the topic of maintainability since 2008—and we have yet to gather our industry’s views on the subject. To help us all get a better picture of how we maintain and how we can maintain more effectively, I set up a brief, unassuming survey (announcement) and kindly ask for your assistance.

The survey aims to collect specific practices and resources—in other words, your views on current practices (both useful and harmful) and everything you find helpful:

  • What helps maintenance?
  • What prevents maintenance?
  • What resources do developers turn to for improving maintainability?

The outcome of the survey and an updated guide to web maintainability will be published in a few weeks on my website, (and noted on my Twitter profile). Thank you for your support.


Fait Accompli: Agentive Tech Is Here


A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Chris Noessel's new book, Designing Agentive Technology, AI That Works for People, available now from Rosenfeld Media. For a limited time, ALA readers can get 20% off Chris's book by using the code 'ALADAT' on the Rosenfeld Media site.Similar to intelligence, agency can be thought of as a spectrum. Some things are more agentive than others. Is a hammer agentive? No. I mean if you want to be indulgently philosophical, you could propose that the metal head is acting on the nail per request by the rich gestural command the user provides to the handle. But the fact that it’s always available to the user’s hand during the task means it’s a tool—that is, part of the user’s attention and ongoing effort. Less philosophically, is an internet search an example of an agent? Certainly the user states a need, and the software rummages through its internal model of the internet to retrieve likely matches. This direct cause-and-effect means that it’s more like the hammer with its practically instantaneous cause-and-effect. Still a tool. But as you saw before, when Google lets you save that search, such that it sits out there, letting you pay attention to other things, and lets you know when new results come in, now you’re talking about something that is much more clearly acting on behalf of its user in a way that is distinct from a tool. It handles tasks so that you can use your limited attention on something else. So this part of “acting on your behalf”—that it does its thing while out of sight and out of mind—is foundational to the notion of what an agent is, why it’s new, and why it’s valuable. It can help you track something you would find tedious, like a particular moment in time, or a special kind of activity on the internet, or security events on a computer network. To do any of that, an agent must monitor some stream of data. It could be something as simple as the date and time, or a temperature reading from a thermometer, or it could be something unbelievably complicated, like watching for changes in the contents of the internet. It could be data that is continuous, like wind speed, or irregular, like incoming photos. As it watches this data stream, it looks for triggers and then runs over some rules and exceptions to determine if and how it should act. Most agents work indefinitely, although they could be set to run for a particular length of time or when any other condition is met. Some agents like a spam filter will just keep doing their job quietly in the background. Others will keep going until they need your attention, and some will need to tell you right away. Nearly all will let you monitor them and the data stream, so you can check up on how they’re doing and see if you need to adjust your instructions. So those are the basics. Agentive technology watches a datastream for triggers and then responds with narrow artificial intelligence to help its user accomplish some goal. In a phrase, it’s a persistent, background assistant. If those are the basics, there are a few advanced features that a sophisticated agent might have. It might infer what you want without your having to tell it explicitly. It might adapt machine learning methods to refine its predictive models. It might gently fade away in smart ways such that the user gains competence. You’ll learn about these in Part II, “Doing,” of this book, but for now it’s enough to know that agents can be much smarter than the basic definition we’ve established here. How Different Are Agents? Since most of the design an[...]

User Research When You Can’t Talk to Your Users


It’s not breaking news to say that the core of UX, in a vacuum, is talking to your users to gather insights and then applying that information to your designs. But it’s equally true that UX does not happen in a vacuum. So what happens when you don’t have the budget or the timeline to run user tests, card sorts, or stakeholder interviews? What should you do when your company doesn’t want you bothering the paying customers who use their software? In short, how do you do UX research when you can’t get direct access to your users? While the best methods for gathering user insights entail first-hand research, there are other ways to quickly glean qualitative data about your users’ wants and needs—beyond the usual lightweight guerrilla user testing options. For a start, companies that are new or have a smaller digital footprint can benefit from things like forums or even competitor reviews to get a better sense of the users in their industry vertical. And for more established companies, customer service logs and app reviews can be invaluable for learning what users think about specific products. Let’s check out a few techniques I like to recommend. App reviews When products have a mobile app component, I start looking at reviews posted on the App Store or Google Play. The key, in terms of user research, is to focus on the substance of what the user is saying, as opposed to the rating (i.e., one star to five stars). For instance: Is the user simply disgruntled or are they asking for a tangible feature to be added to the product? Is the user truly thrilled with some aspect of her experience using the app or is she just a brand loyalist? While reviews do tend to be rather partisan, keep in mind that users are most likely to leave feedback when motivated by an emotional reaction to the product. Emotionally-driven reviews—whether positive or negative—tend to be outliers on the bell curve, so the next step is taking all those reviews and distilling them into tangible insights. Let’s face it, when you want to improve the featureset and functionality, a general reaction to the entirety of an app doesn’t tend to be particularly actionable. Here are a few questions I always start with: Are there missing features users want to see? Do users seem confused by aspects of the UI? Are they complaining about bugs or performance issues that are popping up and making the app unusable? Do people really love a hidden feature that was put in as an afterthought with minimal prominence—something we should consider placing more front and center? Does it seem like people understand how to use the app or do they need a tutorial on first open? Also, it’s important to remember that feedback on an iOS app may or may not be applicable to an Android app (or mobile web experience), and vice versa. Customer service logs Customer service and help center personnel are on the front lines with your users, helping them with specific struggles they encounter with the usability of your products. In other words, they’re constantly learning how users see the product and go about using it. Since user information can be sensitive, the first thing to try is asking whether service calls and contacts are being logged. If so, ask whether it’s possible to get access to the records for user research purposes. If there are no logs, or if you are unable to get access to them, see if a few brief stakeholder interviews with customer service team members is an option. Use the interviews to learn which types of problems and complaints they routinely field. Given[...]

Focus on What You Do Best and Outsource the Rest


With consumer expectations growing year after year, high quality web design and development services are in top demand. If you want to be the one to deliver those high-end results, then you’ll need to focus on playing to your strengths and be comfortable entrusting everything else to others. Like many of us, you’re probably so occupied by managing the day-to-day and maintaining the base of clients you currently have that you don’t have the time or resources to build your web design or development business out to the next level. Why “no pain, no gain” has no place in web design One of the greatest lessons I’ve learned from working as a project and content manager is that there are times when it just doesn’t make sense to take on a task or project that’s not a good fit. For instance: I’ve seen developers struggle with marketing their business when they barely have enough time to complete their own workload. I’ve seen web designers hire on supplemental designers (such as video designers and animators), only to lose those new hires just as quickly as they got them because they couldn’t manage the payroll aspect properly. I’ve even seen administrative assistants given the responsibility of loading content into a CMS and, on top of that, being asked to optimize it for search despite a lack of training. While I’ve seen this problem crop up with management of medium and large-sized businesses, I think it’s much more prevalent with small business owners and independent entrepreneurs. When you think about how much of your life (personally and professionally) is wrapped up in your business, it seems to make sense to think that by consolidating tasks, cutting corners, or just taking it all on yourself, you’ll save money and time. Here’s the problem with that sort of thinking: it’s a dangerous and highly inefficient way to conduct business when you work in web design. No matter the size of our business, we rely on proven processes and techniques to ensure that what we create is always of the highest quality. Let’s face it, we are specialists, and diluting our offering by trying to do everything isn’t fair to our clients or ourselves. My suggestion? Let more qualified people or tools tackle the “stuff” that forces you to slow down, lose productivity, and create something less than what your clients deserve. Sure, it’s scary to think about how much it will cost to outsource your accounting, your SEO, or anything else that isn’t in your wheelhouse. But think about how much momentum and overall quality of work you lose whenever you let that fear take over. I say: focus on what you do best, outsource the rest, and be happily surprised when you see how much your business soars as a result.Follow your strengths In a recent interview about the cost of doing business, Jeremy Goldman of the Firebrand Group argued that in order for business owners (or any entrepreneurs really) to succeed, they must be willing to accept when they’re not great at something. Once you accept that you’re a bad fit for some tasks, you leave yourself more time to pursue the tasks you’re good at (or want to get better at). Outsourcing may result in additional costs upfront, but if you’re handing those tasks over to someone or something that can handle them more efficiently, I’d argue that you’ll save money in the long run. First, because the outsourced party will spend less time completing a task than it would have taken you. And second, because the investment frees you up to succeed at what you do, which, in tu[...]

Widen Out: Using Your Blog to Attract New Clients


Attracting future clients on autopilot—that’s the whole point of your website, right? Most freelancers accept the story that great work attracts leads, but I’m going to be straight with you: clients have no clue you exist. What usually tips the balance isn’t your portfolio—they see plenty of those. Not many people talk about failures they had promoting their products and services. We struggle and we hide it. It’s one of the reasons I hate to read marketing “success stories” and “How to drive traffic and make money!” posts—they seem hollow and vaguely manipulative. They also invariably circle around an answer we already know: The key to attracting non-referral clients is making it easy for them to discover you. Simple as that is, we fail for two reasons: Most freelancer websites are only concerned with showing portfolio work. We haven’t figured out who we want as clients, what makes them tick, or how they solve problems. We’re focused on showing, not serving. Serving hits the ground running—it answers a question, solves a problem, satisfies a curiosity. There’s a difference between saying you will and proving it with a real takeaway during the first impression. Portfolio-focused sites also don’t give Google much content to index and rank, lessening your chances of ever getting high in organic search results, much less on their radar. Designers are “supposed” to do certain things to find clients. Well, I did all that, for years. And I had a pretty depressing success rate, considering how much time I put into it. Then I tried one thing that single-handedly turned around my freelance career. I started blogging with clients in mind. Do it your way Let me tell you about Brian Dean. Brian Dean of Backlinko gets 130,000 monthly uniques. Want know how many articles he has on his blog—in total? 30. That’s right, 30. Readers aren’t coming because he publishes frequently—they’re coming because he writes about what they want to know and because every piece he’s got is the best on that given subject, hands down! He keeps visitors coming back to the same posts because he’s constantly improving the material little by little to ensure it’s always the best that’s out there. As people come across it—web professionals, curious readers, and potential clients—it’s building up his reputation and making it easier for people to find him via search and re-shared content links. You don’t have to write regularly. Or much. And you don’t need an industry-rocking idea. With your expertise, you have what it takes to say something that other people consider valuable. The key to success is making a target, then sticking it out for a few rounds of research + content creation + promotion to start. The more posts/articles you create, the more properties you have on the Monopoly board called Google. Having a few widely shared articles also kicks off a virtuous loop where all your subsequent articles get a jump start from your existing traffic. This approach is repeatable and scaleable. (One quick heads-up: you can also expect your content to attract the “wrong type” of visitors, such as recruiters and people looking to hire someone for low-end, piecemeal work. It’s possible to turn these inquiries into opportunities by politely refusing their offer and asking if they know anyone who is seeking the type of work you do provide.) Pre-planning your content As you know, Google determines how high your page ranks for certain search terms base[...]