EW Resource

Newsfeeds

There's a huge resource of Newsfeeds on the Net which brings up-to-date information and content on a wide range of subjects.

Here are just a few relating to web development.



A List Apart: The Full Feed
  • Initiation to Code 

    When you imagine a programming mentor, certain archetypes might flash into your mind. Maybe you see the wise monk who’s meditated on design patterns for decades. Perhaps it’s the sophisticated keynote speaker with a staggering list of open source contributions. Or it might be that mad scientist polyglot obsessed with a dozen languages you’ve never heard of.

    But if these characters aren’t on your team when the new hire straight out of school joins up, who’s going to take the reins of training?

    You, of course.

    With the rise of coding boot camps and increased enrollment in computer science courses at universities, the pool of junior developers is larger than ever. But when it comes to nurturing all this talent, many teams don’t know where to start. Some developers think they don’t yet know enough to be a good mentor, while others think they’re just too busy for it.

    Whatever your initial reservations may be, you can mentor, and you can do it well. All you need are the right guidelines and a little bit of structure.

    Starting the mentor–mentee relationship

    When you’re seeking a mentee, look for “someone who has something to teach you, but doesn’t know it yet,” as a friend of mine who mentors at RailsBridge recently suggested.

    I take this to mean two things. The first is to stay open to a range of personality types. Look for a mentee who’s not similar to you. It can be tempting to compare juniors to yourself-three-years-ago and jump to conclusions from there. But mentorship is a two-way street—it’s not about lecturing. In fact, it’s not even about passing your knowledge down to another person. It’s about making a mutual agreement to get better at what you both do. You’ll learn more from each other if you have different ways of thinking.

    The second is to choose someone you want to learn from. If your mentee isn’t the type of person you’d be happy to march into code battle with, you won’t get anywhere. The primary quality to avoid is arrogance; an arrogant person will have a slower rate of growth than someone who takes feedback gracefully.

    Because team dynamics are constantly in flux, you might not often establish formal mentor–mentee relationships with people on your team. That doesn’t mean you won’t find opportunities to mentor. Look for little moments to step in and help; you’ll be viewed as a leader, and more mentoring opportunities will begin to materialize.

    Agility is the key

    The key to being a good mentor is a concept you’re already familiar with, since it’s also the key to developing good software and learning new information effectively. That key is agility.

    Of course, “agile” has become a pretty loaded term that tends to confuse more than it clarifies. In a 2014 blog post, Dave Thomas, one of the original signatories of the Agile Manifesto, acknowledged this confusion. Then he reminded us how to do anything in an agile fashion:

    • Find out where you are
    • Take a small step toward your goal
    • Adjust your understanding based on your goal
    • Repeat

    Or as the Scrum Guide puts it: “inspect and adapt.” Inspecting and adapting are foundational to being a good mentor. If you don’t take the time to check up on your mentees and listen to their concerns, travails, and triumphs, then you will have no metric for achievement.

    Employing agility as a mentor requires sensitivity, creativity, and solid communication skills. It also requires the foresight to see what your mentee should be aiming for, and the hindsight to see what your mentee has already accomplished.

    To establish a framework for gauging your mentee’s progress, consider the three phases every new team member goes through in some form. The first phase is total unfamiliarity and constant discovery; the second is a transitional period with a clear trajectory of progress; and the third is self-driven competence. In all three phases, remember that agility remains your most vital tool.

    Phase 1: a little respect

    On the very first day, have a conversation with your mentee in which your goal is to discover exactly what their level and type of experience is right now. This conversation serves a dual purpose. First, it establishes a two-way discourse, a communicative relationship that will underpin your agile approach to mentorship. Second, it gives you a basis to decide what to assign to your mentee first. Starting off with a direct conversation can prevent an incredible amount of confusion and wasted time.

    Pair programming at this stage is pretty much mandatory. It’s far and away the best method for getting a new developer up to speed, especially if you have a large or confusing code base. A recent article by Sarah Mei makes some excellent points about how to pair effectively, but the most salient one is this: don’t touch the keyboard (much). Ask questions, and answer questions with more questions. The closer you are to your mentee’s level of experience, the harder it is to take the backseat approach, since you’re often just figuring things out yourself. But whenever you feel the urge to barge ahead and solve the problem, resist! Your mentee will learn much more effectively in the Socratic style.

    Keep in mind, though, that you aren’t only a technical guide. Early on, gaining technical experience probably won’t be the first thing on a junior developer’s mind—much to their surprise. They’ll be confronted with social puzzles and process nuances that everyone else takes for granted. Clear away confusion over all the things surrounding the work so your mentee has no obstacles to digging down into the work itself.

    As eager as you might be to keep things moving, make sure to be honest about your own limitations, too. Consider phrases like: “I don’t understand this, either.” “I need to take a break.” “I can’t help right now, but try asking Oleg.” All of these can be music to a beginner’s ears. The more truthful you are about when and how you and others can help, the more realistic your mentee’s outlook will be. And a realistic outlook leads to good decisions.

    Phase 2: challenge accepted

    With a solid communicative relationship established, your mentee will quickly move past the green stage. You’ll know that they’re in Phase 2 when they can easily figure out what needs to be done on a ticket, even if they don’t know quite how to do it. This means they’re starting to get comfortable, and it’s also when things get really fun. It’s time to add challenge to the mix.

    Whatever you do, don’t simply assign your mentee whatever happens to come up. Instead, inspect, adapt, and select assignments that build on what your mentee has done before. If possible, try to tell a story with your assignments. Something in the next ticket could elaborate on or reinforce a concept from the previous ticket. Or you could tell the story of a single request, from UI to database and back again.

    If you must assign your mentee something that looks relatively simple, use it as an opportunity to train them in looking at code with a pessimistic eye. What would a null input do? Does this open any vectors for attack? Could you have refactored another component to make this change easier? Do your tests cover all the new code? Even if your mentee decides that the code is airtight (which it never is), they’ll exercise their programming muscles trying to answer your questions.

    While you challenge your mentee at every turn, don’t forget to take a lot of opportunities to encourage. A task that seems routine to you might feel like a triumph for your mentee, so when they finish something, congratulate them. And never underestimate the power of a simple “Good job.”

    Phase 3: the initiation game

    Your ultimate goal is to transform your mentee into a productive, contributing team member—an equal. With enough time and practice, they’ll eventually get there. But why wait? There’s a better, faster way. When your mentee is ready, you can help the transition along with a tool as old as humankind: initiation.

    No matter who you are or where you’re from, you’re familiar with the narrative of initiation. Joseph Campbell identified it as one of the major elements of the hero’s journey, the underlying pattern shared by epic tales all across the world. From ancient mythology to pop culture mainstays like Star Wars and Fight Club, initiation stories have taken countless forms. The framework, however, is always the same: a harrowing ordeal that, if survived, yields the initiate to a new and higher level of awareness.

    Initiation isn’t just for epic heroes. It’s a powerful tool for transformation in any context. When you feel your mentee is ready to take a big step, assign a task that seems a little too complex, a little too far outside the scope of what has been done before, and just difficult enough to accelerate the transition into an equal, independent team member.

    An effective initiation for a software developer should have three qualities:

    1. It would not be trivial for someone with a few more years of experience.
    2. It demands communication with senior-level people. Ideally, the mentee will gain some insight into the factors that go into a high-level technical decision. Overhauling a UI component, modifying your deployment architecture, or hand-rolling a new caching strategy are all good candidates for this type of experience.
    3. It has a demonstrable, preferably quantifiable, value. It might be a new front-end feature, or it might be a graph that shows a decrease in page load time, but ideally, your mentee will be able to point to a visual representation of the change and say, “I’m responsible for that.”

    Often, initiations are accidental, a natural outgrowth of increasing experience and responsibility. But if you do set up a conscious initiation for your mentee, you don’t need to tell them that you’re doing it. In fact, you probably shouldn’t. Show your mentee you believe in them by treating them like a regular engineer.

    If the initiation is successful, your mentee will become an equal—though an equal who still has a lot to learn. They’ll be able to drive their own progress without much hand-holding, and pairing sessions will feel more collaborative than instructive. After this transition, you can take a big step back, but continue to guide and challenge when necessary. After all, as Robert Anton Wilson said, a true initiation never ends.

    Mentoring benefits the whole team

    When I first joined my team, I was the only junior developer. Now, our membership has grown and shifted, and almost half of us are juniors.

    I’ve seen firsthand how much this shift has changed our dynamic for the better. Experienced engineers pose questions to the juniors, motivating them to refine their knowledge—and the juniors pose questions right back. Instead of a couple good communicators bearing the brunt of training, everyone is actively skill-sharing all the time. Where once individuals were siloed, there’s now a spirit of collaboration and fun. Willingness to learn and adapt has become a core value for the entire team.

    It has also observably driven up our code quality. Fresh eyes are great at identifying anti-patterns, style issues, and confusing bits of code. With a healthy mix of juniors, we’ve become better at balancing technical debt repayment and pushing out new features, and the new code we merge is easier to maintain. Without mentorship, these improvements would never have come about.

    Software engineers are fortunate to work in an industry where the tools and processes for collaboration are both well-defined and popular. But to paraphrase the Agile Manifesto, it’s the people and interactions that really make or break a product. Mentorship is a powerful interaction that, done right, can elevate your team’s quality of both life and code, and lay the groundwork for a more successful organization.

  • Let Links Be Links 

    The concept of the web as an application platform has never been more popular, but the tools used to create these so-called “web apps” are still fraught with pitfalls that are often ignored or misunderstood. Single-page web app frameworks have gained traction because they can easily be used to create fast, complex applications that feel much more solid and interactive than traditional websites. But this benefit, and the changes in mindset and development practices that accompany it, comes at the cost of basic browser functionality that web developers sometimes take for granted.

    JavaScript can be fragile

    With vendors making it increasingly difficult to disable, we can get lulled into thinking that we don’t need to provide a fallback for users whose browsers don’t execute JavaScript. But explicitly choosing to disable JavaScript is far from the only reason a user’s browser might not run it. Government Digital Service (GDS), the team that maintains the UK government website, found that, out of every 500 visitors to GOV.UK, five did not receive JavaScript, but only one had JavaScript explicitly disabled. The other four could be missing out on JavaScript for any of several reasons: an overzealous corporate proxy server; a request for JavaScript timing out due to high latency; or even an unnoticed syntax error.

    Furthermore, JavaScript—unlike CSS and HTML—does not degrade gracefully. This means that if developers use a single ES6 syntax feature, or even make a single standard library function call without checking that the function has been defined first, their JavaScript could either stop running midway through execution or not run at all. When JavaScript is used to enhance websites, this doesn’t matter so much—visitors can still follow links and submit forms and generally use the web as intended. But when JavaScript is a requirement, anyone using even a slightly older browser is likely to get a blank page—and no explanation of what to do about it.

    Semantic structure is still important

    As designed by Tim Berners-Lee in 1993, HTML defined a common structure for the mesh of interconnected documents we now know as the web. The semantic meanings imbued in this common structure provide machine-readable context for the information contained in a web page. In practical terms, this extra information enables web browsers to enhance the user experience. For example, a web browser can implement a way to add events defined with time elements to a user’s calendar; a screen reader can read through a list differently than it would a paragraph. The difference between a list and a paragraph is clear to human viewers of a document; the common structure provided by HTML makes it clear to computers, too.

    The semantic meaning behind HTML sets the web apart from native application environments like Cocoa, Windows Presentation Foundation, and Qt. Structured information matters more to the web because of the diverse ways in which it can be accessed. When I create an iPhone application, I can safely assume that every person using that application will use it in a similar way. The information my app presents will always be presented in much the same way, and I will always have complete control over that presentation. Even if someone using my app interacts with it through VoiceOver (Apple’s assistive technology for people with vision impairments), they still interact with the application in a similar way to a sighted user: by tapping around on the screen. They just happen to be hearing the text instead of seeing it.

    The web doesn’t work that way. Websites aren’t viewed solely through web browsers. People consume websites through apps like Pocket or Instapaper, which try to use the structured information of a web page to extract its relevant content. A browser on a smartwatch might ignore your layout and present your information in a way that’s more suitable for a one-inch screen. Or—who knows?—your website might be used through some future device that will transform the information into thoughts beamed directly into a user’s brain. Even web screen readers don’t work like VoiceOver does on an iPhone, reading out the text in the order it’s laid out under a user’s finger. Web screen readers read through the whole document, ignoring layout, and infer meaning from the standardized semantic definitions of HTML tags. A simple example of when semantics like this matter is the recently introduced main element, used to define the main part of a document. To a sighted user viewing your website through Google Chrome, whether you use <main> or <div id=“main”> makes no difference. To someone using another web client, though, such as a screen reader or Instapaper, the meaning implied by the main element is very important to their software in helping them navigate your document.

    Developing an application for the web, therefore, is not as simple as developing for a native platform. Making sure it works the way we want it to in the five major browsers and pushing it out isn’t good enough for the web. We need to test our work in screen readers. We need to review our markup to make sure it provides as much semantic metadata as possible—not just for today’s web clients, but for tomorrow’s as well.

    Single-page web app frameworks

    When using “single-page web app” frameworks like Angular and Ember, the trend is to treat websites like native apps, with little regard for the nuances that make the web unique. Developers make assumptions about their users that can seriously damage the experience of people who don’t meet those assumptions. As an example of what this mindset can result in, consider the markup for a login button (since changed) that I recently found on Patreon’s site:

    <span class="patreon-button sub-section navigation-active" data-ng-click="triggerChangeWindow(navigation.login_url)">Log In</span>
    Example of a login button that once appeared on Patreon’s site
    Patreon’s fairly standard login button acts just like a link. No need for special JavaScript here.

    This link works fine for me in Safari, but in any environment other than a current mainstream browser, this button is totally useless. Let’s say we have a hypothetical smartwatch browser called WatchBrowse. Maybe it displays a list of links for the user to navigate through because this particular smartwatch doesn’t have a cursor that can interact with the page. Because HTML defines a standard way to create links on a web page (the a element), WatchBrowse could theoretically just list every a tag on the page with its href attribute and content—until a site like Patreon comes along and decides to shun web standards in favor of reimplementing basic browser functionality from scratch.

    If Patreon had used an a tag instead of a span, WatchBrowse could perhaps find the link and display it in the list. When a user selected the link, it could simulate a click event instead of just using the href attribute. But what about functionality that requires the browser to know where the link is going to lead ahead of time? A browser extension might allow you to search links on a page by their href values, which would be useful if you wanted to quickly find where somebody links to their Twitter account, for example. Firefox shows where a link is going to take me when I hover over it. When link href attributes are no longer static values but are, instead, decided by arbitrary JavaScript in click handlers, these helpful features are no longer possible.

    Patreon’s site is built with Angular, and while Angular is not at fault here per se, the mentality of treating HTML as a view layer that goes along with using these frameworks probably contributed to Patreon’s poor decision.

    What if we created the same link the way the framework developers recommend in their documentation? A more standard way to make a link in Angular might look like this:

    <a ng-href="/login">Log In</a>

    When rendered into the DOM by client-side JavaScript, that snippet turns into this:

    <a ng-href="/login" class="ng-binding" href="/login">Log In</a>

    Ember handles this similarly. A link is defined in an Ember template like so:

    {{#link-to sessions.new}}Log In{{/link-to}}

    And when it’s rendered into the DOM, it becomes this:

    <a id="ember-563" class="ember-view" href="/sessions/new">Log In</a>

    Ember and Angular then intercept the link’s click event to render the new content without reloading the page. Crucially, though, if the click event were never fired and the browser loaded the value of href, there would be no visible difference to the user other than an extra page reload, because Ember and Angular by default don’t try to reinvent the wheel by defining their routing in terms of URLs.

    In their current forms, however, Ember and Angular still require JavaScript to render their templates and create those links in the first place. Four out of every 500 people who visit a website built with Angular or Ember will encounter a completely blank page.

    A solution?

    When dynamic web page content is rendered by a server, rendering code only has to be able to run on that one server. When it’s rendered on a client, the code now has to work with every client that could possibly visit the website. Developers are now moving away from server-rendered websites because they don’t offer the sort of rich application experience that client-rendered sites can provide. But I think there’s still a role for server rendering in the new world of client-side applications.

    At the moment, requiring JavaScript is a tradeoff that developers using single-page web app frameworks have to make, but it seems to me that this is exactly the sort of problem that should be handled by a framework. We are fortunate as web developers in that we write application code for the web in one of the most universal programming languages that has ever existed. If framework developers could put in the effort (which, admittedly, seems large) to get apps running in Node just as they run in the browser, initial page rendering could be handled by the server, with all subsequent activity handled by the browser. Crucially, if a server can render links into a tags, like Ember currently does on the client, it would be possible for a user who did not receive JavaScript (for whatever reason) to navigate around the website. It might be possible to get forms working as well, by running all the validation and submission logic on the server instead of on the client. If this effort could be made at the outset by a framework maintainer, then every developer using that framework could immediately transform an app that only worked on the latest web browsers into a progressively enhanced experience compatible with virtually any web client—past, present, or future.

    Progressive enhancement has been important to web developers for a while now. It recognizes that the vital part of the web experience is content, and that any additional improvement to the user experience should not undermine the universal availability of content provided by the web. Current approaches to single-page web apps tend to abandon this principle, but progressive enhancement and single-page web apps are not fundamentally incompatible.

    In fact, progress is being made in this arena. To improve Ember’s compatibility with search engines, for example, an in-house team is working on implementing server-side rendering. But the solution to the problems caused by single-page web apps is not purely technical: there’s a growing problem in the way people think about the web. It has become commonplace to treat the web as just another application platform—but the web is so much more than that. The web is the universal information platform. It doesn’t matter if somebody visits a website on a $2,000 iMac, or a $50 Android tablet, or the $5 web client of a future we can’t even imagine yet—in theory, at least. In practice, it’s important to make sure that we don’t sacrifice the experiences of a small number of users just so we can slightly improve the experiences of the rest, damaging the universal nature of the web in the process.

  • On Our Radar: Self-Centered Edition 

    Okay, we admit it: it’s all about us. From steps to sleep to social activities, we’re counting every kind of personal data you can think of. But what’s all that data add up to? How could we look at it—and ourselves—differently? This week, we’re asking ourselves—and our self—the tough questions. 

    My so-called lifelog

    While waiting for an invite from gyrosco.pe, which promises to help me lead a healthier and happier life by harnessing my personal data, I started reading about life resource planning: the idea that we can administer every aspect of our lives using our timeline, our life feed, as a tool. LRP isn’t just the lifelogging data gathered by all the apps we use (health, finance, commuting, social graph, etc.). It’s about a user interface to make sense of it—a personal agent telling my story.

    This has me thinking, how can I ever reinvent myself if my life feed becomes part of a documented history? The answer seems to lie in the notion of storytelling, becoming active autobiographers ourselves, using the same tools that tell our history, only to tell it better. When people are prompted to “tell a story” rather than state “what’s on their mind,” a character emerges—a qualified self (as opposed to the notion of the quantified self)—that may defy “big” data.

    Michelle Kondou, developer

    Mirror, mirror

    A couple of days ago, I came across dear-data.com, a project by data visualization pros Giorgia Lupi and Stefanie Posavec. Instead of building digital charts and graphs, they’re documenting details of their lives onto handmade postcards—translating quiet moments of the everyday into colors and lines of self-awareness, and reinventing the rules each week. With a flickering edge of whimsy and objectivity, those moments are real life—through a filter.

    What I love about Dear Data is that their conditions create new filters; they end up with a different view of themselves each week. Getting out of their usual medium and having to create new ways to tell each story is a tactic for hunting down catalysts. I also like how they went to something so square one: paper and colored pens, no expectations to be fancy, no need for neat lines.

    Dear Data has me thinking about how we can all gain momentum from reimagining our digital selves every once in a while—from ditching our habitual means of describing and defining. How I can so easily show myself a new mirror and allow a situation to filter through me—I’d discover a different result each time. Those moments are grounding: they’re a sharp instant of humility, a moment of recognition that you’ll never see anything in the same way again.

    Mica McPheeters, submissions and events manager

    My birthday, my self

    Ah, spring—that special time of year when a young developer’s fancy soon turns to thoughts of lexical scoping, and I’ve got ECMAScript 6 arrow functions on the brain.

    Defining a function as usual introduces a new value for the this keyword, meaning we sometimes need to write code like the following:

    function Wilto() {
    	var self = this;
    	self.age = 32;
    
    	setInterval( function constantBirthdays() {
    		self.age++;
    		console.log( "I am now " + self.age + " years old");
    	}, 3000 );
    }

    Since the meaning of this is going to change inside the constantBirthdays function, we alias the enclosing function’s this value as the variable self—or sometimes as that, depending on your own preference.

    Arrow functions will maintain the this value of the enclosing context, however, so we can do away with that variable altogether:

    function Wilto() {
    	this.age = 32;
    
    	setInterval(() => {
    		this.age++;
    		console.log( "I am now " + this.age + " years old");
    	}, 3000 );
    }

    Thanks to ES6, we can finally start getting over our selfs.

    Mat Marquis, technical editor

    A gif about: self(ie) love

    President Obama using a selfie stick
    Haters gonna hate.
  • Laura Kalbag on Freelance Design: The Illusion of Free 

    Our data is out of our control. We might (wisely or unwisely) choose to publicly share our statuses, personal information, media and locations, or we might choose to only share this data with our friends. But it’s just an illusion of choice—however we share, we’re exposing ourselves to a wide audience. We have so much more to worry about than future employers seeing photos of us when we’ve had too much to drink.

    Corporations hold a lot of information about us. They store the stuff we share on their sites and apps, and provide us with data storage for our emails, files, and much more. When we or our friends share stuff on their services, either publicly or privately, clever algorithms can derive a lot of of detailed knowledge from a small amount of information. Did you know that you’re pregnant? Did you know that you’re not considered intelligent? Did you know that your relationship is about to end? The algorithms know us better than our families and only need to know ten of our Facebook Likes before they know us better than our average work colleague.

    A combination of analytics and big data can be used in a huge variety of ways. Many sites use our data just to ensure a web page is in the language we speak. Recommendation engines are used by companies like Netflix to deliver fantastic personalized experiences. Google creates profiles of us to understand what makes us tick and sell us the right products. 23andme analyzes our DNA for genetic risk factors and sells the data to pharmaceutical companies. Ecommerce sites like Amazon know how to appeal to you as an individual, and whether you’re more persuaded by social proof when your friends also buy a product, or authority when an expert recommends a product. Facebook can predict the likelihood that you drink alcohol or do drugs, or determine if you’re physically and mentally healthy. It also experiments on us and influences our emotions. What can be done with all this data varies wildly, from the incredibly convenient and useful to the downright terrifying.

    This data has a huge value to people who may not have your best interests at heart. What if this information is sold to your boss? Your insurance company? Your potential partner?

    As Tim Cook said, “Some companies are not transparent that the connection of these data points produces five other things that you didn’t know that you gave up. It becomes a gigantic trove of data.” The data is so valuable that cognitive scientists are giddy with excitement at the size of studies they can conduct using Facebook. For neuroscience studies, a sample of twenty white undergraduates used to be considered sufficient to say something general about how brains work. Now Facebook works with scientists on sample sizes of hundreds of thousands to millions. The difference between more traditional scientific studies and Facebook’s studies is that Facebook’s users don’t know that they’re probably taking part in ten “experiments” at any given time. (Of course, you give your consent when you agree to the terms and conditions. But very few people ever read the terms and conditions, or privacy policies. They’re not designed to be read or understood.)

    There is the potential for big data to be collected and used for good. Apple’s ResearchKit is supported by an open source framework that makes it easy for researchers and developers to create apps to collect iPhone users’ health data on a huge scale. Apple says they’ve designed ResearchKit with people’s privacy values in mind, “You choose what studies you want to join, you are in control of what information you provide to which apps, and you can see the data you’re sharing.”

    But the allure of capturing huge, valuable amounts of data may encourage developers to design without ethics. An app may pressure users to quickly sign the consent form when they first open the app, without considering the consequences. The same way we’re encouraged to quickly hit “Agree” when we’re presented with terms and conditions. Or how apps tell us we need to allow constant access to our location so the app can, they tell us, provide us with the best experience.

    The intent of the developers, their bosses, and the corporations as a whole, is key. They didn’t just decide to utilize this data because they could. They can’t afford to provide free services for nothing, and that was never their intention. It’s a lucrative business. The business model of these companies is to exploit our data, to be our corporate surveillers. It’s their good fortune that we share it like—as Zuckerberg said—dumb fucks.

    To say that this is a privacy issue is to give it a loaded term. The word “privacy” has been hijacked to suggest that you’re hiding things you’re ashamed about. That’s why Google’s Eric Schmidt said “if you’ve got something to hide, you shouldn’t be doing it in the first place.” (That line is immortalized in the fantastic song, Sergey Says.) But privacy is our right to choose what we do and don’t share. It’s enshrined in the Universal Declaration of Human Rights.

    So when we’re deciding which cool new tools and services to use, how are we supposed to make the right decision? Those of us who vaguely understand the technology live in a tech bubble where we value convenience and a good user experience so highly that we’re willing to trade it for our information, privacy and future security. It’s the same argument I hear again and again from people who choose to use Gmail. But will the tracking and algorithmic analysis of our data give us a good user experience? We just don’t know enough about what the companies are doing with our data to judge whether it’s a worthwhile risk. What we do know is horrifying enough. And whatever corporations are doing with our data now, who knows how they’re going to use it in the future.

    And what about people outside the bubble, who aren’t as well-informed when it comes to the consequences of using services that exploit our data? The everyday consumer will choose a product based on free and fantastic user experiences. They don’t know about the cost of running, and the data required to sustain, such businesses.

    We need to be aware that our choice of communication tools, such as Gmail or Facebook, doesn’t just affect us, but also those who want to communicate with us.

    We need tools and services that enable us to own our own data, and give us the option to share it however we like, without conditions attached. I’m not an Apple fangirl, but Tim Cook is at least talking about privacy in the right way:

    None of us should accept that the government or a company or anybody should have access to all of our private information. This is a basic human right. We all have a right to privacy. We shouldn’t give it up.

    “Apple has a very straightforward business model,” he said. “We make money if you buy one of these [pointing at an iPhone]. That’s our product. You [the consumer] are not our product. We design our products such that we keep a very minimal level of information on our customers.”

    But Apple is only one potential alternative to corporate surveillance. Their services may have some security benefits if our data is encrypted and can’t be read by Apple, but our data is still locked into their proprietary system. We need more *genuine* alternatives.

    What can we do?

    It’s a big scary issue. And that’s why I think people don’t talk about it. When you don’t know the solution, you don’t want to talk about the problem. We’re so entrenched in using Google’s tools, communicating via Facebook, and benefitting from a multitude of other services that feed on our data, it feels wildly out of our control. When we feel like we’ve lost control, we don’t want to admit it was our mistake. We’re naturally defensive of the choices of our past selves.

    The first step is understanding and acknowledging that there’s a problem. There’s a lot of research, articles, and information out there if you want to learn how to regain control.

    The second step is questioning the corporations and their motives. Speak up and ask these companies to be transparent about the data they collect, and how they use it. Encourage government oversight and regulation to protect our data. Have the heart to stand up against a model you think is toxic to our privacy and human rights.

    The third, and hardest, step is doing something about it. We need to take control of our data, and begin an exodus from the services and tools that don’t respect our human rights. We need to demand, find and fund alternatives where we can be together without being an algorithm’s cash crop. It’s the only way we can prove we care about our data, and create a viable environment for the alternatives to exist.

  • Matt Griffin on How We Work: Readable Wearables 

    A few weeks ago we added our first wearable to the Bearded device lab, and it was an eye-opening experience. The same day that Apple showcased the soon-to-arrive Apple Watch, a Samsung Gear S showed up at our door. This device is a large smartwatch with pixel dimensions slightly greater than the iPhone 3GS. It has Opera Mini and its own cellular and wifi connections, so it functions as a standalone web interface.

    So will people use their watch-like devices for browsing the web? Though some may scoff at the idea (and believe me, there’s been plenty of scoffing), stranger things have happened. And if the last few years have taught us anything, it’s that if you can use something to get on the web, people will get on the web with that thing.

    After some personal use, it seems to me that these watch-sized screens are a totally reasonable way to access web content. And it’s equally reasonable for us to present our content in readable ways on these screens.

    As Brad Frost recently wrote, responsive design and future-friendly strategies go a long way to making sure our websites work and display the best they can on devices that haven’t even been invented yet. And it’s true that my first reaction to seeing the sites we’ve built displayed on the Gear was “not bad.” But, as I began to look closely and interact with these familiar sites via a tiny curved screen on my wrist, my perspective began to subtly, but significantly, shift.

    My gut reaction to these new smallest-of-screens: I’ve been starting with too big of a browser window. Lucky for us, if we’ve been prescient enough to be writing our CSS in extensible ways (and goodness knows mobile has given us plenty of reasons to do this already), there’s some pretty great low-hanging fruit for us to grab.

    The current Bearded site is super simple; a static two-pager with no navigation and very little in the way of bells and whistles. It struck me as a perfect candidate to try out some wearable-friendly optimizations without a lot of distractions. So let’s have a look at what could be done in an afternoon to make it more pleasurable to read on a watch.

    Let’s get small

    The Samsung Gear S, according to my tests, registers with media queries as a 213px-wide viewport. This is a far cry from the 300px-wide starting point I’ve become accustomed to when styling.

    On this new screen size, the range of acceptable type sizes is tighter than what I’ve been used to. My type was mostly either huge and unwieldy or eye-strainingly small. The original site styles utilized headings set in Quadon Regular, which range from 0.875em to 2.5em. But a 213px-wide viewport, to my sensibilities, only tolerates type sizes from 1.1em to 1.6em with that same typeface.

    Boldly oversize type loses its appeal on the very small screen. (Left: before; right: after.)

    A closing of the typographic aperture seemed called for, but how to do that without reworking a ton of CSS? Enter Past Bearded being kind to Future Bearded. Here’s how, thanks to Sass, we’ve been writing our heading styles for years. First we define the font stack:

    
    @mixin title-face {
    	font-family: Quadon-Regular, arial, “helvetica neue”, helvetica, sans-serif;
    	font-weight: normal;
    }
    

    Then we roll that mixin into our general heading mixin, where we add margin-bottom, line-height, and color:

    
    @mixin heading {
    	@include title-face;
    	margin-bottom: 0.35em;
    	line-height: 1.2;
    	color: $heading-color;
    }
    

    Next, we snowball all of that into the various specific heading mixins, and add font-size:

    
    @mixin heading-1 {
    	@include heading;
    	font-size: 2.5em;
    }
    
    @mixin heading-2 {
    	@include heading;
    	font-size: 1.8em;
    }
    
    ...
    

    Which we can apply to all our headings by default:

    
    h1 {
    	@include heading-1;
    }
    
    h2 {
    	@include heading-2;
    }
    
    ...
    

    This approach may at first seem a little overwrought, but it provides some terrific practical benefits over time. For instance, should you have something that semantically deserves to be lower down the chain from an h1 (say a paragraph or an h2), but you want it to have the visual appearance of an h1, you can just apply the heading-1 mixin:

    
    h2 {
    	@include heading-2;
    
    &.title {
    	@include heading-1;
    }
    

    Best of both worlds, right?

    As is often only possible with Sass, this approach also abstracts major styling decisions away from the low-level CSS implementations. This allows for us to be more agile with changes, even later in the project when our CSS files have grown more unwieldy.

    For our wearable type hierarchy issue, I was able to easily make adjustments to my heading sizes by adding media queries to those mixins, like so:

    
    @mixin heading-1 {
    	@include heading;
    		font-size: 1.6em;
    
    	@include breakpoint($breakpoint-s) {
    		font-size: 2.5em;
    	}
    }
    

    Then I got to sit back, refresh my browser, and watch my sitewide heading typography do its thing. Past Bearded, thank you for being awesome.

    Limitations breed innovation

    The tiny screens of wearables further restrict the design options we have at our disposal, even more so than mobile screens did before them. But working within this more limited palette is not necessarily a bad thing.

    In the letterpress world, for example, we’re restricted to the type we have physically sitting in our cabinets. The weights, sizes, typefaces, and variations we have to work with are extremely limited. And this can lead to some very exciting design work that otherwise we’d never be forced to do.

    When we work to come up with a sensible typographic hierarchy for any size screen, we must first consider what we have to work with:

    • font-family
    • font-size
    • font-weight
    • font-style
    • font-variant
    • font-weight
    • text-transform
    • color

    The most obvious things (aside from size) that you can use to accentuate your headings are uppercase and bold. Small caps, italics, a new font-family, or color changes may be reasonable options for you, as well.

    Though you may not have enough variations in font-size between 1.6em and 1.1em to effectively distinguish six heading sizes from each other, you can mix up font size changes with other type qualities to have that effect, then shift back to your size-based hierarchy as screen size allows for it.

    For instance, with the Bearded site headings I chose to use uppercase as a differentiator for two headings with the same font-family and font-size. Then, when the screen is wide enough, I can use media queries inside the mixins to return to my font-size based hierarchy, like so:

    
    @mixin heading-3 {
    	@include heading;
    		font-size: 1.1em;
    		text-transform: uppercase;
    
    	@include breakpoint($breakpoint-xs) {
    		font-size: 1.4em;
    		text-transform: none;
    	}
    }
    
    @mixin heading-4 {
    	@include heading;
    		font-size: 1.1em;
    
    	@include breakpoint($breakpoint-xs) {
    		font-size: 1.2em;
    		}
    }
    

    Where’s that breakpoint gonna go?

    Speaking of which, at what point should one add this no-longer-wearable breakpoint? The answer: at a width at which your larger screen design decisions start making sense again. The Gear clocked in at 213px, but it seems like those smallest-screen decisions would be beneficial for widths wider than that. When enlarging my browser up from 213px, my wearable-focused design decisions applied for the most part up until 290px, at which point typography could stretch out a little more, and some multi-column grid layouts could comfortably be put to use.

    But not all of the layout decisions from the existing mobile-centric site design made sense at 290px. What’s interesting is that, working at that scale, I actually needed an extra breakpoint. Previously I’d been working with these breakpoints:

    1. < 400px
    2. 400px
    3. 550px
    4. 700px

    Now, starting with smaller widths, I’d arrived at:

    1. < 290px
    2. 290px
    3. 350px
    4. 550px
    5. 700px

    Not surprisingly, the smaller the screen, the greater the impact that a few pixels has. The difference between 1000px and 1050px may not warrant any design changes at all, whereas the difference between 250px and 300px almost certainly does.

    Too small for small

    The last thing I addressed was a bit surprising to me: my 1em (16px) body copy type was too small to comfortably read. I’ve always thought of 1em as a font size that was great for web reading. It feels almost clunky, in fact, when compared to the 8pt reversed type I frequently saw in the world of print design. But on this tiny screen on my wrist, there seemed to be a huge difference, at least with this font-family, between the 1em body type and the 1.1em intro paragraph copy.

    Increasing the font-size from 1em to 1.1em helped readability. (Left: before; right: after.)

    On this site, fixing that was a breeze—I could just increase the font-size of all paragraphs to 1.1em. There was no need to worry about accidentally missing anything, because there was no non-paragraph body copy (i.e. lists or tables). But for a bigger site, this would be too specific of a solution. I could easily end up with well-sized paragraphs and—on some forgotten page—a tiny definition list or errant span. So what might a more extensible solution look like?

    Easy—we can just bump up the site-wide font-size for everything below a certain breakpoint! Something like:

    
    html {
    	font-size: 110%;
    
    	@include breakpoint($breakpoint-s) {
    		font-size: 100%;
    	}
    }
    

    Of course, now our small screen heading sizes are 10 percent too big. Oh man! Good thing we used those mixins, huh?

    Thanks to the Sass-based typographic system we established earlier, adjusting those values a second time won’t be so bad. Who knows, we might even be in pretty good shape when those web-enabled holographic refrigerators finally hit the market in 2016.

  • Don’t Forget About Contrast 

    Several years ago I wanted to get an external monitor to go along with the laptop my work provided. I was a remote worker and decided to buy one myself that I could hang on to even if I left that job. But I was also a bit cheap. I drooled over the Apple Cinema displays, but I didn’t want to spend that kind of money.

    Enter the big-box electronics store and their wide range of displays. I stood in front of one, decided on a size, and purchased it. I bought an LG that seemed “good enough” for my need for more screen real estate for windows of code, browsers, and dev tools. To be quite honest, this monitor has met those needs. I’m still using it.

    It also pointed out a glaring issue that rears its head in a lot of our designs: we aren’t using enough color contrast to accommodate users who may not have the latest and greatest screens. I surfed the web the way I think a lot of people do, on a monitor that they took out the box and started using without doing any calibration. I was astounded by the lack of contrast all over the place. We like gray a lot and often we like it to be very subtle.

    So, even though this monitor is not exactly what I would have bought if I could have afforded something nicer at the time, I’m now grateful for it. While I’m working on client projects, I’m often pointing out to the designers when their design cues or colors may be a little too subtle. If I’m dragging a design over to my laptop screen to be able to differentiate the contrast and colors, then it’s probably a good idea to punch things up a bit.

    You don’t have to go out and buy a cheap monitor to see this, you can also test on older devices that don’t have the latest and greatest screens on them. Many cities have Open Device Labs where you can test on devices for free. If something like that is unavailable to you, there are other ways to find devices for inexpensive testing—Brad Frost has a great post on how to do that. There are many instances where our sites or applications aren’t going to be used on high-end, Retina devices or monitors and I think we have an obligation to consider that as we design so all our users can easily interact with the things we build.

    As an example of this, I recently worked on an application that was intended for use in hospitals. I couldn’t help but wonder, were those monitors going to be able to show subtle color differences? Many of us are making applications that may be used places like hospitals, or other settings where the screens being used aren’t calibrated to perfection so subtle contrast can get lost. That’s just one example of an audience where I would want to be careful about what I expect out of a screen or monitor.

    If you don’t have a cheaper monitor around, I highly recommend using developer tools to help you check for accessibility issues such as contrast. The accessibility team at Google has been doing a great job making tools that can help point out where there may be issues, so if you use Chrome, run an accessibility audit to see where you may need to make changes. Jenn Lukas wrote a great blog post here on ALA to describe testing color in the Chrome Dev Tools.

    I’m grateful for this monitor because it points out contrast issues and reminds me frequently that those issues exist, and like color blindness variations, need to be taken into account as we work. Color contrast plays a large role in our designs, so make sure you test for it, check out designs on less capable screens, and audit your sites with the tools available, so that your users can easily see all the pieces of your design.

  • 80/20 Practitioners Make Better Communicators 

    I spent the better part of 2014 working on two redesigns: one for a major pizza chain, the other for a major bike retailer. The five of us working on the redesigns were excited beyond words—two large-scale sites about two things we loved: pizza and bikes! We all wanted to be heavily involved in every phase of these projects to ensure their success. Along the way, we learned important lessons about how to fine-tune that involvement to arrive at a better outcome.

    Working with the same team on two simultaneous projects allowed us to experiment a little with our process and compare notes. The ecommerce-driven Pizza Site had a strong focus on user flows, so we began by creating HTML wireframes for every page. What had once seemed like a bunch of grandiose ideas on whiteboards morphed into actual working prototypes. As we moved into design, the prototypes came to life in all their melted-cheese glory. But by month nine of the engagement, as we started to polish up the templates, we realized that we were looking at the third installment of the same redesign.

    This isn’t an unusual occurrence. Teams often inadvertently recreate designs multiple times across phases; the end result looks almost nothing like what the team set out to achieve. What causes this disconnect?

    In my experience, it comes from insufficient communication among teams with varying skillsets. Some teams are composed of specialists who all want their ideas and voices heard (yielding vastly different results) while fighting for time, resources, and budget. Alternately, when a generalist works on the entire site, they risk getting spread too thin; the struggle to explore and iterate can produce stale, predictable solutions. Either too much specialization or too much generalization can overwhelm practitioners (and budgets)—and neither approach works.

    How to become an 80/20 practitioner

    Luckily, there’s a better way. When designers and developers (and entire web teams) work closely together with flexibility and shared understanding, they can use their time and resources more efficiently and creatively. Whether your process is waterfall or agile, a solid team foundation applies to everyone: it allows you to shape a solution that benefits all teammates on a project.

    To avoid the mistakes we made on our Pizza Site process, we balanced our responsibilities differently with the Bike Site. We became what I call 80/20 practitioners, focusing 80 percent of our time on our own respective strengths while distributing the remaining 20 percent across other disciplines to benefit the entire project.

    80/20 collaboration is about people. It’s about passions. Sounds great, right? So, where do we start?

    Establish the foundation

    Being a good practitioner means seeing beyond yourself to your team’s broader needs and goals. While molding your process, it’s important to maintain an open, honest discussion with your teammates. Take a comprehensive inventory of the people on your team. Instead of labeling someone a “designer” or a “developer,” take stock of their true skillsets and passions. I’ve worked with amazing graphic designers, amazing UX designers, and amazing interaction designers, all of whom had the same title: designer. What works depends on the person.

    We’ve all heard the argument that designers need to code. And while that might be ideal in some cases, the point is to expand your personal spectrum of skills to be more useful to your team, whether that manifests itself in the form of design, content strategy, UX, or even project management. A strong team foundation begins by addressing gaps that need to be filled and the places where people can meet in the middle. This is also how you, as a practitioner, can identify where you should develop your 20 percent of surplus abilities for a given project.

    If you imagine your team as a spectrum of skills, each person should have a skillset that covers one part of that spectrum (overlapping to some extent with another part). Let’s pretend this spectrum goes from graphic design (red), to code (blue), with every shade of purple in between. As a designer, I span from the reddest of reds to a reddish purple. That leaves the rest of the purple and blue to be picked up. Let’s say my team includes a designer/developer hybrid, Ava, who is all the varying shades of purple. And let’s say I also have a strictly blue backend developer, Carter, on my team. In this instance, we’ve covered all our bases. If it was just Carter and me, though, we’d be left with a significant void in the middle. We would need either to extend our 20-percent skillset into the purple area or to bring in an additional person to bridge the gap. The spectrum’s endpoints will vary from person to person and team to team.

    Strengthen weaknesses

    Whenever someone told me, “You should code!” I would think: “But Developer McCoderson can do it so much better and faster than I ever could!” Which was true, so I continued my deep dive into design. Over time, though, working very closely with my developers every day on the Pizza Site, my interest was slowly piqued. Once I started incorporating HTML wireframes into my design process, I began to see how it benefitted me. I could make faster content updates, my layout was automatically responsive, and I could focus purely on content hierarchy rather than worrying about resizing boxes every time content changed.

    The more I realized that coded deliverables could be design deliverables, the more I understood that I could get interactions in front of a client earlier. Animations, dropdowns, popovers, etc.—these things are design. We want the client’s feedback on this early, because seemingly minor details like hovers reflect the brand and reinforce the design just as much as an image or color choice do.

    This discovery was so liberating that I actually wanted to include code in my process from then on because I preferred working that way, not just because I thought “This will make me a better designer.” I now catch myself voluntarily reading about things like inline SVG and the picture element and almost don’t recognize myself!

    Take a candid look at your process and see where you want to expand your 20 percent, not where you think you should expand it. Let’s go back to Carter, the backend developer, for a second. Maybe he wants to improve his front-end skills—but by “front-end,” does he mean his code or his design eye? What’s missing is probably not a talent for writing beautiful DRY code, but rather the ability to recognize design nuances. Maybe the place to start is by reading articles about typography or checking out other design resources, instead of plunging into JavaScript.

    Once you start recognizing these secondary areas, you can begin to take your newfound interests offline and look into different meetups or talks than you’d normally attend. I discovered that nothing helped me improve my 20-percent skills more than simply befriending wildly talented developers, both in and out of the workplace.

    Learn from each other

    The developer on the Bike Site team created a Grunt file to accommodate our entire team’s needs, including design deliverables and how we handle wireframes. Once everything started being delivered within a code-based project hub, we were all on the same page—literally. We could jump in and help each other as necessary, especially on stressful delivery days. Even the project manager was able to use and update the hub.

    And the developers learned from me, too. Having them involved from day one meant that they were included in a lot of our design reviews. They began to understand the thought process behind our design decisions, and everyone could holistically understand the system we all were building together. When we began to figure out the wireframing and user-experience part of the site, every member of the team had behavior- and experience-driven suggestions that found their way into the project, both in terms of how it would ultimately look and how it would be built. With everyone involved from the beginning, new ideas that previously never would have been considered cross-pollinated the deliverables—whether it was a developer suggesting an out-of-the-box design pattern or a designer creating a performance budget.

    When these conversations happen, barriers between teammates gradually fall away. You’ll probably suggest tools to one another and start to merge processes; in that merging, a new collaborative process will take shape. When we borrow one another’s tools, we begin to learn their benefits and how they may work for our own needs, and we ultimately start speaking the same language. Being aligned on objective project goals helps to keep reviews on track and to more easily settle discrepancies. It isn’t about making anyone’s job easier; it’s about focusing on what’s best for the project. Shared process isn’t something that you can just decide to do; rather, it emerges from learning how another person works.

    Let go of ego

    To rapidly take a design to code, the overall direction needs to be mostly approved by the client. I say “mostly” because the best iterations happen in the browser once we begin interacting with our designs. This is where our 20-percent-spectrum overlap really kicks in. There will be holes in the design that need to be filled, and it’s up to the developer to create a useful roadmap for the designer to iterate on. Imagine that an early homepage concept is approved and we jump into developmental iterations, but I haven’t had a chance to style the navigation dropdowns yet. I love it when developers take a stab at styling these things. If need be, I can always tweak details that feel off to me. When developers have some design sense, they are able to jump in and make design decisions that the designer may not have considered in a fluid layout or behavior. Designers love to be perfectionists, but we need to learn to let go and not be afraid to allow developers to jump into coding a template of an “imperfect” mockup.

    There’s nothing wrong with piece-designing parts and modules as the developer finds holes in the page or media queries. As Dan Mall has stated, it’s about deciding in the browser, not designing in the browser. Everything might not be figured out yet, but that’s okay: we’ll figure it out together. Our websites are fluid; our process should be, too.

    Shaking up a process isn’t easy

    Change can be hard for any organization, especially when strict guidelines are in place for current processes. You have to work toward breaking down any barriers in communication—whether by getting to know a new teammate on a new project, working within your organization to dissolve silos, or trying to introduce a new workflow idea to your boss. A malleable process is a strong one.

    The best place to start is with your project manager. It’s difficult to fit a new process into an ongoing project retroactively, so try to address this at the planning stage. If you’re about to begin a project, make the manager aware of your ideas and how the project plan could be shaped a little differently. It’s important for the project manager to understand the plan so that they can set the expectations with the client accordingly. It’s equally important for them to understand how the timeline will be affected, as it may depart from the typical flow your team is used to.

    In large organizations, managers may need to run ideas past the managers of other departments. See if your next project can be a trial run for experimenting with a new process, and volunteer to head the initiative. Samantha Warren gave a fantastic presentation at An Event Apart on getting design ideas moved through an organization. If this doesn’t seem feasible, try building relationships with your counterparts yourself. See if they are open to trying new methods and working more closely together. If you get multiple people on board, it may be easier to convince the powers that be to try something new. Teams organically working well together are a powerful demonstration of just how effective collaboration can be.

    Everybody benefits

    Dive deeply into your passions while understanding the moving parts around you. Mastering your specialty is not only crucial for professional development and personal satisfaction, but it will also serve your team as you help to stretch that spectrum further. Projects benefit from experts who understand the whole while focusing on their strengths.

    When we speak openly about shared end goals, our teamwork gets stronger. When we jump in and help out on cross-discipline deliverables, our teamwork gets stronger. Most importantly, when we combine our collective strengths and work together fluidly, it gives us the perfect recipe for an amazing project.

    Remain true to your passions, but take the time to learn something about the skillsets of others to help you craft a unique team dynamic. The 80/20 guideline is a place to strive for—a place where we push our own skills and passions while rounding out our knowledge so that we can work better with our teammates. Being an 80/20 practitioner makes a stronger you and a stronger team.

  • Pluralization for JavaScript 

    Seventy-one percent of today’s internet users don’t speak English as a first language, and that number keeps growing. But few people specialize in internationalization. As a result, most sites get it wrong—because things that seem straightforward are often anything but.

    Take pluralization. Turning singular words into plurals within strings gets tricky quickly—even in English, where most plural words end with an s. For instance, I worked on a photo-sharing app that supported two languages, English and Chinese. It was easy to add an s to display “X like[s]” or “Y comment[s].” But what if we needed to pluralize “foot” or “inch” or “quiz”? Our simple solution became a broken hack.

    And English is a relatively simple case. Many languages have more than two plural forms: Arabic, for example, has six, and many Slavic languages have more than three. In fact, at least 39 languages have more than two plural forms. Some languages only have one form, such as Chinese and Japanese, meaning that plural and singular nouns are the same.

    How can we make sense of these complex pluralization issues—and solve them in our projects? In this article, I’ll show you some of the most common pluralization problems, and explain how to overcome them.

    Problems with pluralization

    Pluralization gets even more complex: each language also has its own rules for defining each plural form. A plural rule defines a plural form using a formula that includes a counter. A counter is the number of items you’re trying to pluralize. Say we’re working with “2 rabbits.” The number before the word “rabbits” is the counter. In this case, it has the value 2. Now, if we take the English language as an example, it has two plural forms: singular and plural. Therefore, our rules look like this:

    • If the counter has the integer value of 1, use the singular: “rabbit.”
    • If the counter has a value that is not equal to 1, use the plural: “rabbits.”

    However, the same isn’t true in Polish, where the same word—“rabbit,” or “królik”—can take more than two forms:

    • If the counter has the integer value of 1, use “królik.”
    • If the counter has a value that ends in 2–4, excluding 12–14, use “królika.”
    • If the counter is not 1 and has a value that ends in either 0 or 1, or the counter ends in 5–9, or the counter ends in 12–14, use “królików.”
    • If the counter has any other value than the above, use “króliki.”

    So much for “singular” and “plural.” For languages with three or more plural forms, we need more specific labels.

    Different languages use different types of numbers

    You may also want to display the counter along with the pluralized noun, such as, “You have 3 rabbits.” However, not all languages use the Arabic numbers you may be accustomed to—for example, Arabic uses Arabic Indic numbers, ٠١٢٣٤٥٦٧٨٩:

    • 0 books: ٠ كتاب
    • 1 book: كتاب
    • 3 books: ٣ كتب
    • 11 books: ١١ كتابًا
    • 100 books: ١٠٠ كتاب

    Different languages or regions use different number formats

    We also often aim to make large numbers more readable by adding separators, as when we render the number 1000 as “1,000” in English. But many languages and regions use different fractional and thousand separators. For example, German renders the number 1000 as “1.000.” Other languages don’t group numbers by thousands, but rather by tens of thousands.

    Solution: ICU’s MessageFormat

    Pluralization is a complex problem to solve—at least, if you want to handle all these edge cases. Recently, International Components for Unicode (ICU) did precisely that with MessageFormat. ICU’s MessageFormat is a markup language specifically tailored to localization. It allows you to define, in a declarative way, how nouns should be rendered in various plural forms. It sorts all the plural forms and rules for you, and formats numbers correctly. Unfortunately, many of you probably haven’t heard of MessageFormat yet, because it’s mostly used by people who work specifically with internationalization—known to insiders as i18n—and JavaScript has only recently evolved to handle it.

    Let’s talk about how it works.

    Using CLDR  for  plural forms

    CLDR stands for Common Locale Data Repository, and it’s a repo that companies like Google, IBM, and Apple draw on to get information about number, date, and time formatting. CLDR also contains data on the plural forms and rules for many languages. It’s probably the largest locale data repository in the world, which makes it ideal as the basis for any internationalization JavaScript tool.

    CLDR defines up to six different plural forms. Each form is assigned a name: zero, one, two, few, many, or other. Not all locales need every form; remember, English only has two: one and other. The name of each form is based on its corresponding plural rule. Here is a CLDR example for the Polish language—a slightly altered version of our earlier counter rules:

    • If the counter has the integer value of 1, use the plural form one.
    • If the counter has a value that ends in 2–4, excluding 12–14, use the plural form few.
    • If the counter is not 1 and has a value that ends in either 0 or 1, or the counter ends in 5–9, or the counter ends in 12–14, use the plural form many.
    • If the counter has any other value than the above, use the plural form other.

    Instead of manually implementing CLDR plural forms, you can make use of tools and libraries. For example, I created L10ns, which compiles the code for you; Yahoo’s FormatJS has all the plural forms built in. The big benefits of these tools and libraries are that they scale well, as they abstract the plural-form handling. If you choose to hard-code these plural forms yourself, you will end up exhausting yourself and your teammates, because you’ll need to keep track of all the forms and rules, and define them over and over whenever and wherever you want to format a plural string.

    MessageFormat

    MessageFormat is a domain-specific language that uses CLDR, and is specifically tailored for localizing strings. You define markup inline. For example, we want to format the message “I have X rabbit[s]” using the right plural word for “rabbit”:

    
    var message = 'I have {rabbits, plural, one{# rabbit} other{# rabbits}}';
    
    

    As you can see, a plural format is defined inside curly brackets {}. It takes a counter, rabbits, as the first argument. The second argument defines which type of formatting. The third argument includes CLDR’s plural form (one, many). You need to define a sub-message inside the curly brackets that corresponds to each plural form. You can also pass in the symbol # to render the counter with the correct number format and numbering system, so it will solve the problems we identified earlier with the Arabic Indic numbering system and with number formatting.

    Here we parse the message in the en-US locale and output different messages depending on which plural form the variable rabbits takes:

    
    var message = 'I have {rabbits, plural, one{# rabbit} other{# rabbits}}.';
    var messageFormat = new MessageFormat('en-US');
    var output = messageFormat.parse(message);
    
    // Will output "I have 1 rabbit."
    console.log(output({ rabbits: 1 }));
    
    // Will output "I have 10 rabbits."
    console.log(output({ rabbits: 10 }));
    
    

    Benefits of inlining

    As you can see in the preceding message, we defined a plural format inline. If it weren’t inlined, we might need to repeat the words “I have…” for all plural forms, instead of just typing them once. Imagine if you needed to use even more words, as in the following example:

    
    {
      one: 'My name is Emily and I got 1 like in my latest post.'
      other:  'My name is Emily and I got # likes in my latest post.'
    }
    
    

    Without inlining, we’d need to repeat “My name is Emily and I got…in my latest post” every single time. That’s a lot of words.

    In contrast, inlining in ICU’s MessageFormat simplifies things. Instead of repeating the phrase for every plural form, all we need to do is localize the word “like”:

    
    var message = 'My name is Emily and I got {likes, plural, one{# like} other{# likes}} in my latest post';
    
    

    Here we don’t need to repeat the words “My name is Emily and I got…in my latest post” for every plural form. Instead, we can simply localize the word “like.”

    Benefits of nesting messages

    MessageFormat’s nested nature also helps us by giving us endless possibilities to define a multitude of complex strings. Here we define a select format in a plural format to demonstrate how flexible MessageFormat is:

    
    var message = '{likeRange, select,\
      range1{I got no likes}\
      range2{I got {likes, plural, one{# like} other{# likes}}}\
      other{I got too many likes}\
    }';
    
    

    A select format matches a set of cases and, depending on which case it matches, it outputs the corresponding sub-message. And it is perfect to construct range-based messages. In the preceding example, we want to construct three kinds of messages for each like range. As you can see in range2, we defined a plural format to format the message “I got X like[s],” and then nested the plural format inside a select format. This example showcases a very complex formatting that very few syntaxes can achieve, demonstrating MessageFormat’s flexibility.

    With the above format, here are the messages we can expect to get:

    • “I got no likes,” if likeRange is in range1.
    • “I got 1 like,” if likeRange is in range2 and the number of likes is 1.
    • “I got 10 likes,” if likeRange is in range2 and the number of likes is 10.
    • “I got too many likes,” if likeRange is in neither range1 nor range2.

    These are very hard concepts to localize—even one of the most popular internationalization tools, gettext, can’t do this.

    Storage and pre-compiled messages

    However, instead of storing MessageFormat messages in a JavaScript variable, you might want to use some kind of storage format, such as multiple JSON files. This will allow you to pre-compile the messages to simple localization getters. If you don’t want to handle this alone, you might try L10ns, which handles storage and pre-compilation for you, as well as syncing translation keys between source and storage.

    Do translators need to know MessageFormat?

    You might think it would be too overwhelming for non-programming translators to know Messageformat and CLDR’s plural form. But in my experience, teaching them the basics of how the markup looks and what it does, and what CLDR’s plural forms are, takes just a few minutes and provides enough information for translators to do their job using MessageFormat. L10ns’ web interface also displays the example numbers for each CLDR plural form for easy reference.

    Pluralization isn’t easy—but it’s worth it

    Yes, pluralization has a lot of edge cases that aren’t easily solvable. But ICU’s MessageFormat has helped me tremendously in my work, giving me endless flexibility to translate plural strings. As we move to a more connected world, localizing applications to more languages and regions is a must-do. Knowledge about general localization problems and tools to solve them are must-haves. We need to localize apps because the world is more connected, but we can also localize apps to help make the world more connected.

  • On Our Radar: Present Tense 

    It seems like we’re always anxiously awaiting the future, complications and all. Take the present moment: HTTP/2 is on its way, with intriguing changes for web development; web publishing has never been easier, but Medium’s latest direction is a mixed bag for authors; and our attention is increasingly in demand (and for sale). We’re living in the future, and we’ve got some mixed feelings about that.

    Here’s what’s on our radar:

    HTTP/2: On the horizon

    HTTP/2 is on the horizon, a long-awaited upgrade to the web’s primary protocol. It promises better security and performance, but I’ve been curious about how it will impact development. Fortunately I came across two interesting posts that are a nice introduction to what HTTP/2 does and how it will affect the way we build websites:

    Speaking of better performance, have you seen Tim Kadlec’s What Does My Site Cost? If you live in Angola, this page may have cost $0.32 (USD) to download—something you can bet we’ll be taking a hard look at.

    Tim Murtaugh, technical director

    Mediummm?

    Last month, in a long Atlantic piece about the state of writing for the web, Robinson Meyer asked—for, like, the millionth time—“what is Medium, tho?” Is it publisher, or is it platform? Is it both?

    Is it “just Tumblr for rich people”?

    “All of the above” seems like the most accurate answer after yesterday’s announcement: custom domains for publications. Now, instead of going to medium-dot-com-slash-whatever to get the latest, you might head to cool-url-dot-biz, and find that it’s actually Medium now, too. You can already see this in action with Midcentury Modern. The magazine’s URL is midcenturymodernmag.com, but once you’re there, it’s Medium all the way down.

    So what’s this mean for people like us—people who make websites and work with web content? Will publications flock to replace their custom sites with Medium? Probably not. But many organizations that otherwise might have cobbled together a Wordpress blog could easily end up launching a Medium publication instead, and I’m not sure how I feel about that. On the one hand, Medium’s invested heavily in design and extremely thoughtful typography. It’s great to see so much content written to be read (not to mention discussed and shared). On the other, as both publisher and platform—both the magazine and the paper it’s printed on at the same time—Medium controls everything about how the content published with it is presented, regardless of the URL it ends up on: layout, type, functionality. Does that leave enough space for authors and organizations?

    Sara Wachter-Boettcher, editor-in-chief

    We’re living in a future predicted 60 years ago

    In my youth, old science fiction short story compilations were a mainstay of my summer reading. One story I vividly remember is Frederik Pohl’s “The Midas Plague,” set in a world so rich in stuff that the poor are obliged to consume constantly, while the wealthy can afford emptiness and silence.

    I was reminded of that world as I read Matthew Crawford’s “The Cost of Paying Attention.” It becomes even more real in light of Daniel Levitin’s explanation that the brain runs on a daily ration of fuel that is depleted with every target of focus and every decision—and it makes no difference whether they’re important or insignificant.

    Attention is a limited and very valuable resource that we have to protect when it’s our own, and respect when it’s our neighbor’s.

    Rose Weisburd, columns editor

    A gif about: uncertainty

    I am having second thoughts.

    What about you?

    What stories are drawing your attention? Got any posts, pictures, tools, or code you want to share? (We love sharing!) Tweet us what’s on your radar—and what should be on ours.

  • Nishant Kothary on the Human Web: There Is No Data vs. Intuition 

    Few things have widened the chasm between data and intuition as much as Marissa Mayer’s infamous matter of the 41 Shades of Blue a few years ago.

    For those of you who live under a rock, let me catch you up.

    Back when there were just 41 shades

    Back in the golden age when Google wasn’t evil, they used two different shades of blue for the hyperlinks in Search and Gmail ads. The decision was made to determine the one true blue, and it was ultimately Mayer’s to make. Her intuition to split the difference between two final contenders left her uneasy. So naturally, she devised a most elaborate A/B test to determine the best blue among 41 different blues.

    And then everyone wrote about it. Bowman. Clark. Fast Company. CNET. Gawker. Gigaom. The New York Times. Even I piled on in my own little way. And the verdict that came out at the end of the human centipede was a collective, “Eww, she did what?!”

    Taking a page from Kim Kardashian, who recently owned her own narcissism in this (really, quite effective) T-Mobile commercial, Google’s design team themselves embraced and commemorated their data-driven philosophy late last year in the Googliest of ways. In 41 successive tweets they tweeted—you guessed it—those infamous 41 shades of blue. And the 42nd tweet, in classic Google form, a puzzle:

    We have Will Kirkby to thank for bit-shifting his heart to the solution, an inspirational quote: “we seek to synthesize classic principles of good design with the innovation and possibility of technology and science…”

    *Slow clap*

    All made up but nowhere to go

    Judging by the fun and games, it seems like we’ve all made up. As much as I’d love to applaud us all for putting our demons to rest and working it out, it’s hard to ignore the underlying cause of this years-long kerfuffle: the data vs. intuition debate (if I can even call something this dogmatic a debate).

    The debacle quietly renewed the old, tired, artificial, and patently false, division between data and intuition. And from where I stand, divided they remain.

    Back to square one. Designers vs. Engineers. Emotions vs. Logic. Intuition vs. Data.

    So, before it gets too late, let me just get this on the record: if you find yourself arguing at dinner parties that intuition has no place in the decision-making process (have you noticed that nobody ever seems to do the opposite?), well, then first off: stop lying because nobody invites you to dinner parties. But more importantly, I want to do you a solid and tell you that you may be the accidental modern jackass. Because you’re plain wrong.

    And there’s a mound of data that supports that.

    Data vs. and intuition

    If you’re curious about the data supporting the intelligence of the gut, you can start with Malcolm Gladwell’s Blink. But I recommend it with acute awareness of the polarizing effect of referencing Gladwell as a case for science. So before you cut your losses and head back to your timeline, my second recommendation is the source of much of the great research out there on intuition: Gerd Gigerenzer’s very readable treatise on the topic, Gut Feelings: The Intelligence of the Unconscious. Its extensive bibliography will satiate those of you who want to dive into the p-values of the randomized control trials, while it doubles as a jumping-off point for the topic as a whole.

    You don’t have to go very far into the research before you realize something you’ve always known in your gut: that your gut is frikkin’ smart. From catching a flyball to becoming a world-class athlete, from picking winning stocks to dreaming up entirely new markets, the intelligence of the gut is awesome in the truest sense of the word: it draws awe.

    But, here’s the thing: data is just as awesome. 

    Data has a way of turning a suspicion into a verifiable fact. It has the ability to replace dogma with truth. To provide answers to vexing problems simply with math. As Christian Rudder writes in Dataclysm: Who We Are, “It’s like looking at Earth from space; you lose the detail, but you get to see something familiar in a totally new way.”

    Some of you already know where I’m going with all of this: we’re punching ourselves in the, well, gut, by continuing to pit intuition against data. It’s not one or the other. It never has been, and as much as we try to sell the narrative, it never will be. They are both mandatory in sound decision-making (there’s a good book on that, too, by the way).

    The fact is that there is no data vs. intuition.

    Finally

    Ironically, Mayer’s rationale for her design decision—her execution (or its reporting and our understandable reactions) notwithstanding—was actually pretty sound: “Every design starts with an instinct: It should look like this, or it should look like that. You can actually test it with data. The humbling thing about that is sometimes the data proves you wrong. So for every change I propose, you know, three out of four, four out of five the data will support the change.”

    And if you’re to believe the press, it was worth $200m a year. But who knows.

    Regardless, here’s a thought experiment: can you see an alternate universe where a Jobs-esque genius gets a standing ovation for employing Mayer’s line of reasoning?

    Let your gut noodle on that for a bit.

     

  • Brevity vs. Clarity 

    A few months ago, my good friend, Olivier Lacan, tweeted:

    He rightly points out that a lot of commonly-accepted abbreviations exist only because a critical mass of people use them. We understand what “btn” means because we’ve seen it before, not because it’s a clear shortening of “button.”

    Is the loss of clarity outweighed by the benefits of a shorter class name? In an era where most text editors provide autocompletion, three letters isn’t a huge difference from an authoring perspective.

    Inevitably, someone else will come along someday and work with the code we write. Even if you work by yourself, future you will be a different person because of the work you’ve done and the experiences you’ve had between the times you focus on a project. Clarity is invaluable when others (or our future selves) come in to work on something—we don’t have to struggle to understand what is happening, we can get work done more efficiently, and the overall process will be much smoother.

    On the technical side, brevity certainly has its place. The savings made by using a fewer letters each time a name is written can add up if your codebase is large enough. Better yet, minification and compression of CSS and JavaScript source files can save precious kilobytes and shorten page load times noticeably. There’s really no shortage of micro-optimizations you can find out there, all in the name of brevity and speed.

    There are clearly good reasons for both approaches, so like most things in our work, it all comes down to how you decide what’s right for you and your situation. Is there a tangible, data-proven benefit of brevity? If not, be descriptive, expressive, and clear.

    Hal Abelson and Gerald Jay Sussman said it best in their MIT Structure and Interpretation of Computer Programs course:

    Thus, programs must be written for people to read, and only incidentally for machines to execute.

    I let that guide me, but the lines between what’s for humans and computers can get blurry sometimes—JavaScript and CSS files are for both humans and machines, so it’s best to find a way to play to both sides’ advantages. Minification and compression are good tools here: clear source code for development, minified and compressed files for production.

    No matter what, avoid abbreviating for abbreviation’s sake. The benefits of clear, readable code are almost always greater than typing fewer characters. And if brevity is applied thoughtfully in technical situations, you’ll use resources more efficiently, and that will make everyone happy.

     

  • Rachel Andrew on the Business of Web Dev: Looking Outside 

    Running a business with your spouse has advantages. A year ago we decided—after asking Twitter where was nice to live—to move from Maidenhead to Bristol. We were able to relocate home and business easily because our work and life together is one thing. We can head out for a walk or a run together and chat through a possible new feature for Perch or a business decision that needs making. Our life and business goals are one and the same.

    My husband Drew McLellan and I are each a 50 percent shareholder in the business, while my college-aged daughter works for us part time. Other roles are fulfilled by contractors and freelancers. Major business decisions, from product features to financial issues, are made by the two of us.

    We do have defined roles. I started the company, so a lot of the business of doing business comes down to me. I also enjoy the activity of running a business, and have a good head for accounting and legal issues. Drew is lead developer on Perch, and the direction of the product and codebase is his. We discuss most decisions, but there are distinct areas of the business that we each take the lead on.

    However, when decisions need to be made that one partner is unhappy with, the overspill into non-work life can be difficult. How do we support each other as husband and wife while being able to argue the pros and cons as business owners? Where most people can leave work and head home to get outside input from their partner, couples in business can find themselves without that outlet.

    Even when things are going well, there is a danger of becoming insular. On many issues, Drew and I come to a shared conclusion quickly. Is that because we are right or just because we read the same things, have the same experiences? These are difficult questions to answer.

    Our small part of the web industry can be a navel-gazing place at times. Just watch how the same tweets circulate, the same products are mentioned, by the same small group of people. Asking advice from my friends in the industry can be very similar to asking advice from my partner. They know me and what I do too well, and are probably being influenced by the same books, blog posts, and speakers as I am.

    Sometimes it takes an outsider to point out the mistakes you are making, and to open up conversations and ask questions that you might never ask yourself.

    Getting some “business therapy”

    Drew and I really enjoy watching business reality shows on TV—especially the sort of thing where an experienced businessperson goes into a failing business to help them out. A show airing in the UK at the moment has hotelier Alex Polizzi performing this role in family businesses. We cringe as we see the TV businesses making seemingly obvious mistakes. We sometimes wonder how much our own perspective prevents us seeing our own errors and the opportunities we miss out on.

    Having an outsider look at your business can be incredibly helpful. We recently applied for, and were accepted into, the UK Business Growth Service’s Growth Accelerator scheme. This comes with several benefits, but the most interesting to us is the chance to work with a business advisor. When I first heard about the scheme, I had visions of being paired with an ex-bank-manager type, someone from a very traditional business. I imagined I’d spend more time explaining how our business worked than getting any real advice. That hasn’t been the case. Our advisor, Matt Spry, has enough technical background to understand what it is we do, but enough distance and wider business experience to be able to ask us questions we’d not ask ourselves.

    We’ve been led through exercises that we know are a good idea but that seem a bit odd to do on our own, especially as a couple in business. Last week we covered a table in a local café in sticky notes to work out which aspects of our product are most important to different groups of customers. Every time we meet with Matt, it sparks conversations we might not have had with each other. It does sometimes feel a bit like “business therapy.” Even though Drew and I tend not to have too many conflicting ideas for the business, having a third party pose questions that are very much in one of our areas of responsibility is certainly helpful.

    We’re still in the middle of this process with the Growth Accelerator scheme. It is too early to judge whether this input will increase the success and growth of the business. We have already found, however, that voicing concerns and considering a different viewpoint has started to make us confident to try changes we might have avoided before.

    Finding your own outside help

    We’re involved in a formal scheme, but there are other ways in which you could get input for your own business, whether you work alone or run a family business of some sort. Many of my peers are part of mastermind groups, groups of three or four people who meet regularly to offer input into the businesses of each member of the group. Episode 167 of Startups for the Rest of Us talks about how to set up and run such a group. Another method would be to try to find a business mentor. In that case, I’d advise looking a little outside of your direct field in order to gain a true outside perspective. Close friends are unlikely to ask the hard questions, and may just confirm the things you think you already know.

    It’s so tempting to think we know it all. It’s so easy to become inward looking, especially when working alone, or with a partner or close friend. I’ve come to realize just how valuable an outside perspective can be. I’d encourage every business to look for ways to get that kind of input.

  • Quantity Queries for CSS 

    Don’t you just hate documentaries that don’t deliver? They have enticing names like In Search of the Giant Squid, and tease you with shots of murky underwater shapes and excited scientists pointing far out to sea. You settle down to watch, eyes narrowed with suspicion, thinking, “I better see some squid or I’m writing an angry letter to the network.”

    Sure enough, 90 minutes of interviews with bored-looking fishermen later, the presenter is forced to conclude, “No… no, we didn’t find any big squids. But maybe one day [majestic orchestral flourish].” Great. You wanted Finding Nemo and got Not Finding Nemo instead.

    I wouldn’t do that to you, friends. This is your guide to creating style breakpoints for quantities of HTML elements, much as you already do with @media queries for viewport dimensions. I’m not pointing at some blurry specification in the distance or a twinkle in an implementer’s eye. We’re going to do this today, with CSS that’s already available.

    Dynamic content

    Responsive web design is primarily concerned with one variable: space. In testing responsive layouts, we take an amount of content and see which spaces it will successfully fit into. The content is deemed constant; the space, variable.

    The @media query is the darling of responsive web design because it allows us to insert “breakpoints” wherever one layout strategy ceases to be viable and another should succeed it. However, it’s not just viewport dimensions, but the quantity of content that can put pressure on space.

    Just as your end users are liable to operate devices with a multitude of different screen sizes, your content editors are liable to add and remove content. That’s what content management systems are for.  This makes Photoshop mockups of web pages doubly obsolete: they are snapshots of just one viewport, with content in just one state.

    In this article, I will be outlining a technique to make CSS quantity-aware using specially formed selectors. I will be applying these selectors to one classic problem in particular: how to alter the display of items in a horizontal navigation menu when there are too many to suit the initial layout mode. That is, I will demonstrate how to switch from a display: table-cell to a display: inline-block layout when the number of items in the menu becomes “more than or equal to 6.”

    I will not be relying on any JavaScript or template logic, and the menu’s list markup will remain devoid of class attribution. By using CSS only, the technique honors the separation of concerns principle, according to which content (HTML) and presentation (CSS) have clearly defined roles. Layout is CSS’s job and, where possible, CSS’s only.

    Comparing the initial menu bar layout for fewer than six items with the layout for six or more items

    The demonstration is available on CodePen and will be referred to throughout the article.

    To help me illustrate this qualification of quantity, I’ll be employing diagrams of squids in the article to represent HTML elements. Green squids with ticks represent elements that match the CSS selector in question, red squids with crosses are unselected elements, and grayed-out squids denote elements that don’t exist.

    A key for the three squid symbols to be used in following diagrams. A green squid (for selected elements), a red squid (for unselected elements) and a grey squid for elements that don't exist

    Counting

    The key to determining the quantity of elements in a given context is to count them. CSS doesn’t provide an explicit “counting API,” but we can solve the same problem with an inventive combination of selectors.

    Counting to one

    The :only-child selector provides a means to style elements if they appear in isolation. Essentially, it lets us “style all the child elements of a particular element, if counting those children returns 1 as the total.” Aside from its stablemate :only-of-type, it is the only simple selector that can be described as quantity-based.

    In the following example, I use :only-of-type to add a special style to any buttons that are the only elements of their element type among sibling elements. I give these lone buttons an increased font-size because singularity suggests importance.

    
    button { 
      font-size: 1.25em;
    }
    
    button:only-of-type {
      font-size: 2em;
    }
    
    

    Here’s the crucial part. If I were to start out with one button, replete with a larger font size, and add buttons before or after it, each button would then adopt a smaller font size. The style of all the elements in the set is dependent on a quantity threshold of two: if there are “fewer than two” elements, the larger font size is honored. Take a look at that code again with the “fewer than two” notion in mind:

    
    button {
      font-size: 1.25em;
    }
    
    button:only-of-type {
      font-size: 2em;
    }
    
    
    The fewer than two logic means one selected element (green squid) becomes two unselected elements (red squids) when an element is added

    If it feels more natural, you can turn the CSS logic on its head using negation and make the condition “more than one.”

    
    /* "More than one" results in a smaller font size */
    button {
      font-size: 2em;
    }
    
    button:not(:only-of-type) {
      font-size: 1.25em;
    }
    
    
    The more than one logic means one unselected element (red squid) becomes two selected elements (green squids) when an element is added

    Quantity n

    Styling elements based on the “more than one” and “fewer than two” thresholds is a neat trick, but a flexible “quantity query” interface would accept any quantity. That is, I should be able to style “more than or equal to n” for any value of n. Then I can style “more than or equal to 6” in our navigation menu.

    With a view to achieving this final goal, what if I were able to style discrete quantities like “exactly 6 in total” or “exactly 745”? How would I go about that? I would need to use a selector that allowed me to traverse sets of elements of any quantity numerically.

    Fortunately, the :nth-last-child(n) selector accepts the number “n”, enabling me to count sets of elements from the end of the set toward the beginning. For example, :nth-last-child(6) matches the element that is sixth from last among sibling elements.

    Things get interesting when concatenating :nth-last-child(6) with :first-child, introducing a second condition. In this case, I am looking for any element that is both the sixth element from the end and the first element.

    
    li:nth-last-child(6):first-child {
      /* green squid styling */
    }
    
    

    If this element exists, the set of elements must be exactly six in quantity. Somewhat radically, I have written CSS that tells me how many elements I am looking at.

    Of six squids, the first is green and the rest red. The first is subject to the nth-last-child(6) selector as well as the first-child selector

    All that remains is to leverage this key element to style the remaining elements in the set. For this, I employ the general sibling combinator.

    Six green squids because the first green squid is combined with the general sibling combinator to make all the red squids that follow green

    If you’re not familiar with the general sibling combinator, the ~ li in li:nth-last-child(6):first-child ~ li means “any li elements that occur after li:nth-last-child(6):first-child.” In the following example, the elements each adopt a green font color if there are precisely six of them in total.

    
    li:nth-last-child(6):first-child, 
    li:nth-last-child(6):first-child ~ li {
      color: green;
    }
    
    

    More than or equal to 6

    Targeting a discrete quantity—whether it’s 6, 19, or 653—is not especially useful because it pertains to such a specific situation. Using discrete widths rather than min-width or max-width in our @media queries would be similarly unhelpful:

    
    @media screen and (width: 500px) {
      /* styles for exactly 500px wide viewports */
    }
    
    

    In the navigation menu, I really want to switch layouts at a threshold: a quantity watershed. I want to switch at six or more items—not exactly six items. When I reach that threshold, I would like to change from a distributed table layout to a simpler, wrappable inline-block configuration. Importantly, I would like to retain that switched configuration as the number of items further increases.

    The question is, how does one begin to construct such a selector? It’s a question of offsets.

    The n+6 argument

    Another arithmetical argument adoptable by the :nth-child() selector takes the form “n + [integer]”. For example, :nth-child(n+6) styles all the elements in a set starting from the sixth.

    A set of red squids that become green at the sixth squid for the remainder of the set (which can be of any size), counting upwards.

    Though this has conceivable applications all its own, it’s not a “quantity-aware” selection method as such: we’re not styling anything because there are six elements or more in total; we’re just styling the ones that happen to enumerate higher than five.

    To begin solving the problem properly, what we really need is to create a set of elements that excludes the last five items. Using the opposite of :nth-child(n+6):nth-last-child(n+6)—I can apply the switched layout properties to all “last elements” starting from the sixth, counting back toward the beginning of the set.

    
    li:nth-last-child(n+6) {
      /* properties here */
    }
    
    

    This omits the last five items from a set of any length, meaning that when you reduce the length of the set below six, you cease to see any selected items. It’s a sort of “sliding doors” effect.

    A set of green squids (to the left) and red squids (to the right) become a set of just red squids when the set becomes fewer than six in number

    If, indeed, the set is greater than or equal to six in total, then all that remains is to style those last five items as well. This is easy: where there are more than six items, one or more items that “return true” (in JavaScript-speak) for the nth-last-child(n+6) condition must exist. Any and all of these extant elements can be combined with “~” to affect all items (including the last five) that follow it.

    When a set of red squids has squids added to it, the squids to the right of the set become green and can be used to make the rest of the red squids green too (with the general sibling combinator)

    The surprisingly terse solution to our problem is this:

    
    li:nth-last-child(n+6),
    li:nth-last-child(n+6) ~ li {
      /* properties here */
    }
    
    

    Naturally, 6 can be replaced with any positive integer, even 653,279.

    Fewer than or equal to n

    As in the earlier :only-of-type example, you can turn the logic on its head, switching from “more than or equal to n” to “fewer than or equal to n.” Which brand of logic you use depends on which state you consider the more natural default state. “Fewer than or equal to n” is possible by negating n and reinstating the :first-child condition.

    
    li:nth-last-child(-n+6):first-child,
    li:nth-last-child(-n+6):first-child ~ li {
      /* properties here */
    }
    
    

    In effect, the use of “-” switches the direction of the selection: instead of pointing toward the start from the sixth, it points toward the end from the sixth. In each case, the selector is inclusive of the sixth item.

    nth-child versus nth-of-type

    Note that I am using :nth-child() and :nth-last-child() in the preceding examples, not :nth-of-type() and :nth-last-of-type(). Because I am dealing in <li> elements and <li>s are the only legitimate children of <ul>s, :last-child() and :last-of-type() would both work here.

    The :nth-child() and :nth-of-type() families of selectors have different advantages depending on what you are trying to achieve. Because :nth-child() is element agnostic, you could apply the described technique across different element type siblings:

    
    <div class="container">
    
      <p>...</p>
    
      <p>...</p>
    
      <blockquote>...</blockquote>
    
      <figure>...</figure>
    
      <p>...</p>
    
      <p>...</p>
    
    </div>
    
    
    
    .container > :nth-last-child(n+3),
    .container > :nth-last-child(n+3) ~ * {
      /* properties here */
    }
    
    

    (Note how I am using the universal selector to maintain element agnosticism here. :last-child(n+3) ~ * means “any element of any type following :last-child(n+3).”)

    The advantage of :nth-last-of-type(), on the other hand, is that you are able to target groups of like elements where other siblings of different types are present. For example, you could target the quantity of paragraphs in the following snippet, despite them being bookended by a <div> and a <blockquote>.

    
    <div class="container">
    
      <div>...</div>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <blockquote>...</blockquote>
    
    </div>
    
    
    
    p:nth-last-of-type(n+6),
    p:nth-last-of-type(n+6) ~ p {
      /* properties here */
    }
    
    

    Selector support

    All of the CSS2.1 and CSS3 selectors used in this article are supported in Internet Explorer 9 and above, including all reasonably recent mobile/handheld stock browsers.

    Internet Explorer 8 support is good for most selector types, but technically partial, so you might want to consider a JavaScript polyfill. Alternately, you could pair the selectors for the “safer” of the layout strategies with IE9-specific classes. In the case of the navigation menu, the safer option is the one catering to more items, using inline-block. The declaration block would look something like this:

    
    nav li:nth-last-child(n+6),
    nav li:nth-last-child(n+6) ~ li, 
    
    .lt-ie9 nav li {
      display: inline-block;
      /* etc */
    }
    
    

    In the real world

    Suppose our navigation menu belongs to a content-managed site. Depending on who is administering the theme, it will be populated with a greater or fewer number of options. Some authors will keep things simple with just “Home” and “About” links provided, while others will cram their menu full of custom page and category options.

    By providing alternative layouts depending on the number of menu items present, we increase the elegance with which we tolerate different implementations of the theme: we address variable content as we might variable screen dimensions.

    Comparing the initial menu bar layout for fewer than six items with the layout for six or more items

    So, there you have it: squid ahoy! You can now add quantity as a styling condition to your repertoire.

    Content-independent design

    Responsive web design solves an important problem: it makes the same content comfortably digestible between different devices. For folks to receive different content just because they have different devices would be unacceptable. Similarly, it’s unacceptable for a design to dictate the nature of the content. We wouldn’t tell an editor, “Lose that, will you? It makes the design look wrong.”

    But what form the content takes, and how much of it there is at any one time, is frequently indeterminate—another unknown. And we can’t always rely on text wrapping and truncation scripts. To get a real handle on content independence, we need to develop new tools and techniques. Quantity queries are just one idea.

    Web design is about mutability, difference, uncertainty. It’s about not knowing. Uniquely, it is a mode of visual design not about manifesting a form, but about anticipating the different forms something might take. To some it is unbearably perplexing, but to you and me it is a challenge to relish. Like the elusive giant squid, it is a seriously slippery customer.

  • Stopping the Infighting About Digital Standards 

    I grew up in Columbia, Maryland, a planned community (see Figure 5.1). And as with the word “governance,” people tend to react to the phrase “planned community” in a not-so-positive way. “Planned” sounds dull and uncreative to people: cookie-cutter homes, on cookie-cutter lots, on cookie-cutter streets—“Little Houses Made of Ticky Tacky,” to invoke Malvina Reynolds’ well-known song. And Columbia was all about that: a city built quickly based on a template. There were street naming conventions, standard model homes, standardized lot sizes, and a standard “village” configuration complete with strategically placed shopping and swimming pools.

    Map showing the neighborhoods of Columbia, Maryland.
    Figure 5.1: Columbia, Maryland—a planned community that opened in 1967.

    So what do you get when you build a city on a standards-based framework? Those who focus on the standards part like to say “boring,” “all the same,” “not diverse,” because they believe that any standardization leads to a lack of creativity or innovation. But that wasn’t all there was to it. Once you factor in the context and intent of Columbia, the picture becomes different. Columbia was one of the first planned communities intended to be racially and economically integrated. Its founder, James Rouse, had a vision about creating a place for people to live—a place that would make you feel good, a place where everyone would just get along. And there was the timing: Columbia was founded in the mid-sixties and started its initial growth spurt in the 1970s.

    In standardized fashion, villages and neighborhoods were often named after literary figures with streets being named after lines in their works. That standard resulted in street names like Evening Wind Lane, Wood Elves Way, and Plaited Reed. No Main Street. No Church Street. No School Street. Sure, there are some boring people in Columbia, but Columbia has spawned some interesting people, too, including the following:

    • The late Randy Pausch: The Carnegie Mellon professor who gave us “The Last Lecture: Really Achieving Your Childhood Dreams.” This one touched home, as his mother was an English teacher at the high school I attended.
    • Michael Chabon: Pulitzer prize-winning author. I like to think that Mike’s rich writing style was informed by the literary tradition of Columbia street names. But that might be a stretch. I think he just has a gift.
    • Dave McClure: Founder of 500 Startups and a rule-breaker if ever there was one.
    • Aaron McGruder: Of The Boondocks comics fame; another iconoclast.
    • Edward Norton: Okay, he’s just the grandson of James Rouse, but cool nonetheless. I mean, Fight Club, right?

    All this is to say that, contrary to popular belief from some of my clients, standardization does not have to give way to things boring or flat or uninteresting. It doesn’t mean that the standardized interface can’t be beautiful, or that your customer’s experience of your seamlessly integrated process that takes them from desktop to mobile to call center won’t be sublime. The belief that standardization necessarily leads to the boring and uninteresting is too simple. It’s what’s going on inside the structure that is important. You could have a beautiful, old, organically grown, charming town with nothing creative going on for it except that it looks good. Or you can have tract housing turning out really interesting people, music, and thought. It’s all about the substance and interactivity of the interior. What comes out of a community, planned or unplanned, is really contingent upon the intention and people within it.

    So, if you’re going to take the time to establish and implement a standards framework, it had better be around the right intention. And that intention is expressed through your digital strategy. Your standards are the tactical manifestation of your strategy that will bring into existence the intent of your digital strategy. That’s why organizations that have no real digital strategy struggle so much with coming up with a quality online presence and why their digital team spends so much time arguing and debating about standards. In the absence of clear business intent, standards can be left up to a matter of taste and debate. So, if you are undertaking to develop standards without first having defined a digital strategy, you may develop a standards compliant website and have consistently moderated social channels. But your digital target will likely not resonate as well as it could with your customers. Only standards derived from clear vision have the capacity to create a high user experience and deliver on the mission of your organization.

    I was lucky. I learned early that standards could enable rapid growth and provide a framework for coherent development, all the while creating a space for real creativity. Standardization can be, and often has been, the platform for creative and important work. But I’ll go further. Standards, in fact, might be an essential ingredient.

    Standards frame and limit what you can do so that you can get across a certain message or get a particular piece of work done. And that’s the message you should carry to digital teams who are reluctant to adopt a standards-based framework. Likewise, you can have a World Wide Web operating within the open standards of the W3C with the whole of humanity trying to express itself freely and creatively, or you could have something else, like an Internet and Web controlled by a few businesses and political interests. It’s about clarity of intention and the quality and sustaining quality of your implementation. It’s about having a vision and figuring out how to make it happen and holding true to your aims and your standards.

    Why Digital Standards Are Important

    Practically speaking, having digital standards enables an organization to put into place details for execution so that digital work can be performed consistently and effectively. From a governance perspective, knowing who has the authority to define standards saves time by minimizing the time that resources spend making decisions about the same factors, over and over again. For instance, it’s good to know which Web browsers your organization’s digital presence supports, what fonts you use for mobile applications, and when and where it’s acceptable to use your organization’s mark. It might also be good to know that your organization operates on a .NET platform, or that when you refer to staff on a public website it’s always “Ms. Welchman” and not “Lisa.”

    In an ecommerce environment, standards make sure that the right content gets to the right customer at the right point in the sales cycle. For example, it’s good for customers to know that whatever they are buying on a site, the sales checkout process will be the same. And it makes customers more comfortable knowing that whether they are purchasing a pair of trousers or a jacket, they will still have the same interface for toggling between garment color choices. In addition, it doesn’t just make the user’s task easier to accomplish, it also takes stress off internal digital workers.

    Adopting a standards-based framework takes the stress out of development. When you have standards in place, more time can be spent having conversations about the substance and purpose of the work that is to be done instead of arguing about the details of execution or who has the authority to make decisions about application coding standards or a graphical user interface.

    An organization’s digital standards steward’s job is to establish and maintain a standards-compliant environment within the organization (see Figure 5.5). Standards compliance exists in an environment where certain activities have occurred:

    • Standards have been defined and documented.
    • Standards have been effectively disseminated to all digital stakeholders.
    • Standards have been implemented.
    • Standards compliance is measured and managed.
    Illustration of the forces that influence the cycle of standards compliance.
    Figure 5.5: Creating a standards-compliant environment.

    The reason why most organizations have trouble with standards compliance is because they miss or incorrectly address these activities and then are only left with one alternative—to enforce (usually undocumented) standards after the non-compliant content and applications are already posted (or nearly posted) online. This reactive dynamic can lead to a stressful dynamic for digital teams. Too often, the core digital team is perceived as the last-minute bad guy, telling teams that the look and feel isn’t right or that the flow of the application screens is unusable.

    The core digital team shouldn’t be in the position of having to ask their colleagues to remove content and applications that might represent weeks or months of effort. In the best of cases, the organizational standards steward is not an enforcer, but someone who is able to create an environment where bad things don’t get online in the first place. Let’s take a look at what the standards steward does to make that happen (see Table 5.1).

    Table explaining the differences between policies, standards, and guidelines.

    Standards Definition and Documentation

    If you want your extended digital team to follow your standards, it’s important to write them down. This might seem self-evident, but many organizations, when asked, are unable to produce documentation of the standards that they claim their stakeholders will not comply with. This “I’m an expert, so do what I say” dynamic is hardly fair to digital stakeholders because these stakeholders often have some digital domain expertise and are heavily impacted by the business outcomes of their online efforts (so they are informed and they have a vested interest). Here are a few things to keep in mind when documenting standards.

    • Develop a standard for documenting standards. The first standard you should define is the structure you will use to document your standards. Having a consistent format for standards will allow your digital team to be able to access the information more efficiently and will enable you to consistently cross-reference standards. You also want to consider the platform you will use. A wiki can be a good platform for documentation. It allows for revision and version control and can be accessed by multiple standards authors. Some standards can also be integrated with various digital production systems [like a Web content management system (CMS)] so that the standards appear in the context of a workflow. For instance, there might be ready access to editorial and design standards within the context of a text editor in a CMS.
    • Determine what should be a standard. There is almost an endless list of standards that can be defined. It’s important to figure out which ones are most relevant to your organization. For instance, if your organization is getting ready to ramp up on mobile, standards related to responsive design might be important. Or, if your organization’s aim is multichannel content delivery, component content authoring standards might be a priority. Sometimes organizations will place high priority on documenting standards that have caused a lot of debate, such as graphical user interface or information architecture. Let your own organizational dynamics drive the standards prioritization process.
    • Leverage what you already have. The standards steward will also need to understand what standards your organization has already documented or where a digital standard can be largely informed by an already existing standard. Brand guidelines, style guidelines, applications development protocols, compliance mandates, and records management schedules are examples of information that might help inform or greatly impact the substance of your standards. It’s important to perform an audit and detail what information exists and where it is. That way, when standards authors sit down to write standards, you’ll be able to reference relevant standards easily and consistently.

    Standards Dissemination

    A common problem in digital teams is that they’ve often forgotten that their internal digital stakeholders are users as well. Typically, the experience of accessing and understanding digital standards for internal users in organizations is very low. For example, if you are a digital stakeholder trying to understand the rules of development for your organization, you are probably not interested in browsing through a beautifully designed PDF of a style guide. You just want to find the information quickly so you know, say, what font color to use for a visited link reference. The digital standards steward can help facilitate that information by being more strategic about standards dissemination.

    • Tell people about the information. If you have established a digital community of practice (CoP) inside your organization, be sure to discuss new standards and standards revisions as they arise. Frequently, resources aren’t told that a standard has changed until the standard is violated. Digital CoPs are effective because they bring together all the people in your organization who work with your digital channels. As you’ll see in Chapter 8, “The Decision To Govern Well,” these communities are ideal for sharing information and for training.
    • Web- or Intranet-enable your standards repository. It is essential to produce standards in Web-ready format. Often, digital standards are authored in word processing applications or published as large PDF files. Instead, organizations should make an effort to leverage the power of the hyperlink, making it easy for stakeholders and developers to click through to corresponding and related digital standards (and policy) to get the whole picture. Sometimes, there may be standards that individuals would not typically seek on their own, but might be relevant to their work at hand.

    Standards Implementation

    Digital standards stewards usually feel that their job is complete when they have documented the standards and placed them online. In reality, their job has just begun. The real work lies in ensuring that the standards are implemented.

    • Use tools. When possible, an organization should use tools to implement and ensure compliance with digital standards. If content contributors and developers must build through a narrow standards-based gate in order to get their content on the server, it’s less likely that you will end up with “rogue” or non-compliant content and Web pages. You can help support the implementation of standards for visual design page structure by establishing templates in a Web content management system. For example, you can raise the quality of writing by implementing an editorial review process and workflow. If you have certain metadata tagging requirements for an online catalogue, you might implement a sophisticated auto tagging system. This is a straight gate and narrow way, however, and not all outcomes can be achieved via tight constraints. Certain standards, particularly some editorial and design standards, need to be implemented via other means, such as employee training and education.
    • Training and education. Not everything that is a standard can be implemented with a tool. Certain editorial concerns, for instance, might require training from internal or external experts. Many teams have found value in providing education for areas like writing for the Web or graphic design for the Web. You often won’t get 100% standards compliance with training and education. People are unique, and they will interpret standards in different ways. At the end of the day, this means that you need to staff your digital team with the right people and trust them to do their job correctly.

    Standards Compliance Measurement

    Hopefully, if you have defined, disseminated, and implemented your standards well, compliance will be high. Still, websites and intranets are large, complex environments. Even in the best of circumstances, standards will be misunderstood or ignored in haste. That is why it is import to measure standard compliance in a consistent and automated way. You can monitor standards through spot checks and prepublication reviews, but in a large production environment, this is often a daunting task. Implementing a website auditing tool is often helpful because it allows the core digital team to provide quantified reports on things such as broken links, terminology language use, usability, compliance, and SEO. Reporting back to stakeholders about which standards they are upholding and which they are not, and creating a plan to lead the team to higher rates of compliance, is a more positive method of standards enforcement than threats that content or applications will be removed from the server.

    Even after you’ve implemented your standards lifecycle, there will still be exceptions to the rule. There will be times when digital workers will want to break with the standards. And then each organization will have to determine when it’s okay to break the rules and when it’s not. These types of situation can be touchy, particularly if the resources involved in the standards breach are fairly senior in the organization (like a CEO who insists on having the picture on a homepage or wants to write lengthy, dense blog posts). In the end, these types of situations will have to be negotiated by the standards steward, authors, and the “standards breaker.” During the discussion and negotiation, it is important to emphasize how the business is being put at risk due to a standards breach and how the business could benefit if the standards were complied with. At the end of the day, you’ll never have 100% compliance, but hopefully the vast majority of your digital presence will follow the rules as defined by digital standards authors.

  • On Our Radar: Communication Builds Community 

    This week, we at ALA have been thinking about processes of inclusion—that is, how we communicate with our communities. Who (and what) gets to be included? How do we use vocabularies, fonts, even emojis, to make those choices? And how do those choices create our culture?

    Here’s what’s on our radar:

    Anna Debenham, technical editor:
    The UX team at Salesforce have written about the difficulties they’ve had coming up with color schemes that look good and meet the WCAG2 guidelines on color contrast—so they’ve built a wonderful site called Color Safe that generates color palettes that meet these guidelines. It’s great to see companies release tools like this that help make everyone’s sites more accessible.

    Marie Connelly, blog editor:
    I really loved this piece over on Hopes & Fears on how the Deaf community is incorporating new terminology (think: selfie, photobomb) into American Sign Language. It touches on so many things I love: words, the subtle complexities of language, and the beautiful messiness of community collaboration. I think the examples of how the Deaf community works through this process offer great food for thought for any of us working on content and communication.

    Caren Litherland, editor:
    “I’m pretty content,” writes Indra Kupferschmid in a pragmatic survey of the current state of web typography. Almost anything we could ever do in print, we can now do on the web; the web “forces us to think about typography in terms of parameters and to get clear about content versus form.”

    Ethan Marcotte, technical editor:
    Kathy Sierra’s essay on skater culture is a fascinating, moving look at a once-inclusive industry that, over time, marginalized its female members. It’s also an urgent warning for the digital industry, which faces a similar crisis.

    A gif about a music video we are into:

    A gif of Tina from Bob's Burgers jumping up and down.
    No outline will ever hold us.

    What about you?
    What stories are drawing your attention? Got any posts, pictures, tools, or code you want to share? (We love sharing!) Tweet us what’s on your radar—and what should be on ours.

  • Antoine Lefeuvre on The Web, Worldwide: Designing for Post-Connected Users — Part 1, the Diagnostic 

    I toured the world twice—first in 2009–10, then in 2013–14. Only four years between the two trips, but it felt like a century internet-wise. Where I had to go wifi-hunting in 2009, in 2014 the web was absolutely everywhere—even in places with no mobile coverage, such as remote El Chaltén in Argentine Patagonia. Yet, I had the feeling this advent of a truly connected world wasn’t much cause for celebration. Indeed, I met many who struggled with an increasing need to disconnect.

     

    I’m so glad I’m taking a year off. Off from work, off from stress, off from modern life.

    …Do you have WhatsApp?

    Twenty-something European trekker in Northern Laos

    I heard this line from fellow travelers numerous times, be it in Laos, Costa Rica, or New Zealand. I actually said it myself! As absurd as it sounds, it’s a perfect illustration of our ambiguous relationship with the internet.

    Hyper-connected, hypo-social

    Has the internet become repulsive? It certainly has in the eyes of Italian artist Francesco Sambo. His HyperConnection series depicts a dark and creepy humanity transformed—or tortured—by technology. Strikingly, Sambo is a savvy internet user, showcasing his work through Behance and SoundCloud.

    HyperConnection, CC BY-NC-ND, Francesco Sambo.

    Artists are often the first to capture the collective unconscious. Antisocial network I and II by Congolese artist Maurice Mbikayi are skulls made out of keyboards. “The […] sculptures ask questions such as to whom such technological resources are made available and at what or whose expense? What are the consequences impacting on our people and environment?” states Mbikayi. Less morbid but equally shocking is the alienation depicted in the Strangers in the Light series by French photographer Catherine Balet. In a very visual way, she questions us: are our babies born in a mad world?

    Digital malaise

    Not only does hyper-connection alter our social relationships, it also makes us dumber, as pointed out as early as 2005. It threatens our health too. Twenty-first-century afflictions include digital fatigue, social media burnout or compulsive internet use.

    Cures for these rising internet-related disorders include such radical solutions as rehab centers, or disconnection.

    “I was wrong”

    Most of the experiments in living offline have begun with the same cause and led to the same conclusion: the internet drives us crazy, but it brings us much more than we realize.

    “The internet isn’t an individual pursuit, it’s something we do with each other. The internet is where people are,” says journalist Paul Miller in his famous “I was wrong” piece on The Verge. When you disconnect, you’re not just cutting the link with a network of computers, you’re actually isolating yourself from the rest of society. Miller also emphasizes that there is no such thing as a divide between virtuality and reality. To me, the best example of this is the sharing economy of “virtual” communities such as AirBnb or Kickstarter that is all about changing the “real” world.

    The cure is worse than the disease

    A lot of people today feel torn between two extremes. They aren’t against modern ways of interaction per se, but they won’t close their eyes to the excesses. The concern becomes even greater when the developing minds of children and teenagers are at stake. Many parents believe their digital-native offspring aren’t capable of using the internet moderately. You can’t blame them when you come across stats such as 20 percent of French young people are addicted to their mobile.

    Is disconnection the only alternative to unhealthy internet use? That cure is worse than the disease. There must be another way.
    Internet users are ripe for a new era, for the next step. A “more asserted, more mature” use, in the words of Thierry Crouzet, another famous disconnectee. Neither hyper- nor dis-connected: post-connected.

    I see the advent of post-connected users wary of addictive or invasive tools. Post-connected users are also well aware that a social network centered on the individual, rather than on the group, inevitably leads to narcissism. They see the internet as a means for more direct human relationships—not a thing that feeds on our continual attention.

    The internet pictured as monstrous should sadden us all, for it is one of mankind’s greatest inventions, one which has done so much for knowledge, education and human rights. Besides, it isn’t addictive by nature, we have turned into a drug.

    We are the drug dealers

    We love it if other people listen to us. Why else would you tweet?

    Psychologist James Pennebaker at the University of Texas at Austin interviewed by WSJ

    We, the web makers, have designed interactions which encourage selfishness and competition. We created tools that cause fatigue and stress. We practically invented hyper-connection.

    It is therefore our responsibility to design for post-connected users. If we’ve been powerful enough to create addiction, then we must surely have the resources to imagine post-connected user experiences. How? I’ll give you some leads in my next column.

    In the meantime, I would very much like to discuss this topic with you. Have you ever felt the urge to disconnect? Do you agree there is such a thing as post-connected users? Would you say addiction is the sign of a successful design? Your comments, criticism, and true stories are most welcome.

  • 10 Years Ago in ALA: Attribute Anarchy 

    WARNING: there are experimental elements and deeply controversial syntaxes ahead! Proceed at your own peril! You have been warned, and the website you save…could be your own. Ten years ago, right here in ALA, a wild-eyed hell-raiser going by “PPK” made a radical proposal: custom attributes in markup.

    In my opinion, using custom attributes to trigger the behavior layer … will help to separate behavior and structure and to write simple, efficient scripts.

    Besides, triggers can grow to be more complicated than just a “deploy behavior here” command. Sometimes you’ll want to add a value to the trigger.

    Well, okay. At the time it was radical. Here in the future, we have perfectly valid HTML5 data- attributes to contain all manner of information and act as behavioral triggers for our scripts.

    The front end of a website consists of three layers. XHTML forms the structural layer, which contains structural, semantic markup and the content of the site. To this layer you can add a presentation layer (CSS) and a behavior layer (JavaScript) to make your website more beautiful and user-friendly. These three layers should remain strictly separate. For instance, it should be possible to rewrite the entire presentation layer without touching either the structural or the behavior layer.

    All of this holds as true today as it did a decade ago. I know I’ve used data- attributes for both: to invoke custom behavior without touching the classes I use for styling—keeping my behavioral layers and presentation layers separate—and to pass relevant configuration information to said scripts. Picturefill 1’s data-srcset="1x source.jpg, 2x hd-source.jpg" comes to mind: we could define an attribute and write a script that dictates how the associated element should behave, all in one perfectly valid package.

    The presence of the maxlength attribute alerts the script to check user input in this textarea, and it can find the maximum length of this specific textarea in the value of the attribute. As long as we’re at it we can port the “required” trigger to a custom attribute, too. required=“true”, for instance, though any value will do because this trigger just gives a general alert and doesn’t carry extra information.

    maxlength? required? These custom attributes that once so daringly flew in the face of conventional web standards are now part of the HTML5 standard.

    Maybe it’s best that the web didn’t linger too long on our warning at the top of the page.

     

  • Rian van der Merwe on A View from a Different Valley: Managing and Making: It Doesn’t Have to Be One or the Other 

    We work in interesting times. We recognize and accept that if you want to move “up” at a company, you have to become a manager. So, to rise up in the ranks means doing less of the thing you’ll be more responsible for. For a design manager, this means more time in email and Evernote, less time in Sketch and Photoshop. That doesn’t make a lot of sense, but it’s the way it is.

    I’m not saying we don’t need managers—we desperately need good ones. But I started thinking about our blind acceptance of this cornerstone of modern business, and I wonder if there might be a way to create a system that values doing as much as managing—while also improving the skills of both groups.

    I moved into my first management role about six years ago. I can’t quite remember the motivation behind it, but it was some combination of company need and my desire to further my career (and a little bit of “I wonder if I can do it,” I guess). I also had the good fortune of having an excellent manager in one of my first jobs. It opened my eyes to the challenges and opportunities of management, and I wanted to contribute to that. It’s been a huge learning experience (I would say it was humbling, but hashtags have ruined that word forever) and I’m glad I did it.

    But a couple of years ago something about being a manager started to bother me. At first it was just a a small voice in the back of my head: How can you be a good design manager if you don’t design any more? I tried to ignore it, but that voice grew louder over time, and eventually I had to deal with the question head on.

    The problem is, if you’re a manager, you have career opportunities. Manager turns into Senior Manager turns into Director turns into Senior Director, and so on. If you’re “just a designer,” the path is less clear. Sure, there are Senior and Lead roles out there, but they’re very rarely equated with real career progress. And that’s a problem. It forces some individual contributors to become managers even if they prefer to let someone else take the lead, and it creates a management culture that can become extremely out of touch with day-to-day design activities.

    So at the end of last year I made a change. Partly because I was tired, partly to test this theory, I stepped away from management and became “just a designer” again. At first it was weird. Where did all the meetings go? What is this flat surface that I get to sit and work at for most of the day? But then the weirdness subsided and it just got… enjoyable. I now spend most of my days designing products, talking about and helping teams implement those designs. I realized I fell behind on design skills a little bit, so I went into a learning phase, and it was fun.

    What does this mean? Am I done with management? Is anyone who chooses a life of management doomed to heartache and despair? Absolutely not! If anything, going back to being an individual contributor has cemented my belief that good managers are as important as they are hard to find. And I certainly hope and plan to be in that role again in the future. Just not right now.

    So here’s how all of this comes together. I think we need a career system that encourages people to oscillate between individual contributor roles and manager roles. Maybe we provide “manager sabbaticals” where a manager becomes an individual contributor on a team for six to nine months. Maybe when a manager goes on vacation, an individual contributor takes on their role for a period of time (or for the duration of an entire project). I don’t know exactly what this looks like yet, but I think it’s important for us to figure it out.

    Being an individual contributor makes you a better manager because you understand the day-to-day frustrations of your team better, and it ensures that you keep your technical skills up to date. Being a manager makes you a better designer because you understand the needs of leadership teams better, which allows you to communicate more effectively. One feeds the other, so we shouldn’t be forced to “pick a track.”

    There are, of course, caveats. People shouldn’t be forced into management by the stigma that only management = career advancement. Some managers have no desire to become individual contributors again, and they shouldn’t have to. It’s about choice. If we encourage (and reward) people to have the freedom to explore different kinds of roles, it can only be a good thing for our industry—and, more importantly, for users.

  • Prioritizing Structure in Web Content Projects 

    Most web content projects have both structural and editorial aspects: for example, the information needs to be structured to support the new responsive design, and the current copy needs an update so it adheres to messaging and brand guidelines.

    I’m often asked which is the best order to approach the work: structure first and then rewrites, or the reverse? I didn’t used to have a strong opinion, because it seemed to me like a chicken-and-egg problem. If the project starts with structure, I’m building content models off of bad information. If, instead, we start with rewrites, the writers don’t know what pieces we need to fill the models, because the models don’t exist yet. It felt like both directions were equally fraught, and I didn’t have any strong reasons to recommend one over the other.

    (Note that I’m not talking about starting without the editorial foundations of a project: understanding the business goals, establishing a message architecture, and knowing what the work is supposed to accomplish are core pieces of any project. I’m talking instead about rewriting poor content—editing and creating new copy based on those foundations.)

    Structure the content first, then do rewrites

    I recently finished up the second phase of a project that we organized to focus on structure first, and reasons to stick with this approach piled up in my lap like turkeys going to roost. I think that a structure-first approach does make sense for the majority of my projects, and here’s why.

    Content models are based on what content is for, not what it says

    On this particular project, the existing copy was horrible. Jargony, clichéd, and almost stubbornly unhelpful. How could I build a useful content model off of bad content?

    As I was working, I realized that the quality of the copy—even if it’s terrible—doesn’t really affect the models. I don’t build models off of the exact words in the content, but instead I build off of what purpose that copy serves. I don’t actually care if the restaurant description reads like teen poetry (sorry teens, sorry poets): it’s the restaurant description, and we need a short, teaser version and a long, full version. The banquet facilities should include well-lit photos taken within the last decade, and the captions should use the appropriate brand voice to describe how the rooms can be used. I don’t actually need to see decent photos or strong captions to build space for them into the models.

    Structure decisions influence development and design direction

    A complex content model will help inform all kinds of site decisions, from CMS choice to data formatting. Developers can make better architecture decisions when they have a sense of what kinds of relationships exist between content types, and designers can organize a pattern library that matches the granularity of the content model. The earlier the structure work is done, the easier it is to build integrated design and development plans.

    Cramming bad content into strong models is an incredibly compelling argument for editorial intervention

    When projects are focused on the structural aspects of the work—we want to recombine content for different channels, or make a clever responsive experience using structured fields—people often start out convinced that the current content is decent enough to do the job. “Sure, it could probably use some spiffing up, but that’s just not in the cards right now.”

    I have never seen a more effective argument for the importance of editorial work than taking existing copy and seeing how inadequately it fills a model that we’ve already agreed meets our business goals.

    A model I built recently had a content type for holding gushy snippets about the business’s amazing customer service. When we went to move the existing content into the new models, the only copy we could find to migrate amounted to “free ice water” and “polite employees.” We had already agreed that telling the story of the brand experience was a key job of the new website, and seeing how thoroughly their current content failed to do that was the kick in the pants they needed to find budget for an editorial assist.

    Content models are easy to iterate

    Waterfall isn’t a great match for content development any more than it is for design and code, so editorial rewrites often trigger adjustments to the content models. I may split one large field into two smaller ones, or the writers will find a place where I left out an important piece of content altogether. Refining the models is an expected part of the process.

    On projects where editorial rewriting has been done first, though, I often end up with copy that, although now written beautifully, has no place in the model. In the course of structuring the information, we combined two pages into one, or are reusing the same description in three places, and so the editorial effort that went into fixing that copy is thrown out before it ever sees the light of day. That’s discouraging, and can lead to content creators feeling like I don’t value their time or their work.

    What works for you?

    It’s nice to have some strong reasoning behind my structure-first leaning, but of course my experiences may not translate to your project needs at all.

    If you’ve worked on a project that organized structure work first, what advantages or drawbacks did that process uncover? From a design and development perspective, are there pros or cons to either direction that aren’t covered here?

    If you’re a writer, does creating copy within a content model free or stifle your best work? If you prefer to start with editorial rewrites, what are the hidden benefits for the structural side of the project?

    I believe there are real benefits to taking a structure-first approach to organizing content activities, and I’d love to hear how and if that works for your projects as well.

  • The Specialist-Generalist Balance 

    A couple of years ago I hit a crisis point. There was a distinct divide between disciplines at my company; I had been labeled a “backend developer,” and it was starting to feel restrictive. The label wasn’t wrong: I spent most of my working hours writing server-side code. I enjoyed it, and I was good at it—but it wasn’t all that I could do.

    I’ve always considered myself to have a fairly generalist skill set, and slapping a label on me meant that I wasn’t allowed to work on anything other than that which fell under my remit as a backend developer. I felt typecast. And, unfortunately, it’s not a divide found solely at that company; it’s ubiquitous across the industry.

    So what’s the problem?

    Consider the following project scenario: someone in marketing has an idea. They discuss it with a designer, who mocks it up in Photoshop. The designer hands it over to the front-end developer, who complains that the designer hasn’t considered how difficult X is to implement without major JavaScript hacking. She finishes her work and tosses it over to the backend developer, who flips out because the front-end developer hasn’t given a single thought to how Y is going to work with the company’s CMS.

    Sound familiar?

    Creating narrow groups of specialists divides teams and restricts the way we work together. In his article “Development is Design,” Brad Frost describes this divide as a fence over which specialists throw their respective pieces for other specialists to catch and run with. It’s not uncommon to see individual teams of “specialists” all sitting apart from each other. The larger the company grows, the more specialist stations are added, each with their own tasks to complete, and mostly working in isolation—isolation that fosters unhealthy environments, restricts collaboration, and creates silos.

    The key is to find the right balance of specialists and generalists on your team—to use both to their advantage and to nurture healthy, productive environments. Ultimately, the question is: how can experts collaborate better together?

    Balancing your team

    The appeal of generalists

    In my formative years, I worked as a developer at a small software agency. There was complete freedom—absolute trust and no red tape. If one of the live sites had a bug, I had free rein to jump on the live server and peruse the logs, or check the configuration file for errors. I was not only allowed, but often required to do anything and everything. It was such a small company that there simply were no specialists.

    In this way, I picked up some rudimentary design skills; I learned to navigate my way around a server and a database; and I became fairly confident in developing on the client-side.

    This type of generalist approach to developing websites clearly has advantages: generalists learn how each component works with the others. They develop an understanding and appreciation of the whole process. They’re also good at just getting things done; there’s no waiting around for a specialist to do the database work for you.

    Generalists can apply their hands to most things, but they’re never going to master everything. Sometimes, having someone who roughly knows their way around something just isn’t enough.

    If you have a rock band made up of members who can play “Smoke On The Water” on every instrument, but you don’t have individuals who can belt out a Slash solo, or drum like John Bonham, then you’re never going to play to a sold-out house.

    Making the most of specialists

    Specialists are the experts in their field. They have spent their careers honing their skills on a given subject, and so it stands to reason that they’re going to be better at it than someone who doesn’t have their experience.

    But misusing them will result in barriers to strong team collaboration. For example, once, at a large software company, I was tasked with investigating why our team’s build had broken. I identified that the problem was a missing dependency reference in the build definition. So, easy fix, right? Just pull up the build definition and fix the dependencies—until I realized I didn’t have access. I couldn’t edit the build definition directly, and was told I needed a “configuration specialist” to implement the fix.

    What should have been a quick edit ended up taking hours while I waited for a specialist on another team to fix a problem that I knew how to solve. Unfortunately, this is a common scenario: rather than collaborating with the rest of the company, insular groups of specialists are given sole ownership over particular tasks.

    Specialists are best placed in roles where they work alongside other team members, rather than separately. As Henrik Kniberg from Spotify says, “It’s like a jazz band—although each musician is autonomous and plays their own instrument, they listen to each other.”

    Tear down the walls

    Removing obstacles to a high performance culture is how innovation happens throughout an organization.
    Adrian Crockroft, Netflix

    Collaboration is the ultimate goal when forming a team, since it allows ideas to flow freely and encourages innovation. Creating specialist groups with total ownership and little to no cross-team communication will erect unnecessary barriers to collaboration. So how do we identify and remove these barriers?

    Open up bottlenecks

    I once worked with a company where the generalist development team outnumbered the specialists by fifteen to one. When developers required alterations to an automated build, they had to submit a ticket for a specialist to address. At one point, developers were submitting tickets faster than specialists could pick them up—resulting in a workflow bottleneck.

    If the developers had been able to manage the automated builds themselves, the bottleneck could have been avoided. The knowledge held in the configuration team could have been shared among the developers, creating a more generalist approach and eliminating a silo.

    To identify and open up your own bottlenecks, ask yourself:

    • What part of the process is the slowest, and why?
    • Are you relying on a single person to do all of your front-end development? Why?
    • Are there any other people in the team who have similar skills, or show an aptitude for learning those skills?
    • Do restrictive job titles prevent people from benefiting from each other’s skills and expertise?

    Encourage communication

    I’ve seen companies where software testers and developers were entirely independent teams. Testers were often only engaged at the end of the development process, when they received a test module based on the original requirements. But requirements can and do change during the development process—which, when teams operate completely independently, can lead to a lot of misunderstandings and lost productivity.

    Including the testers throughout the development process would have improved communication and performance. Instead, project releases suffered as a consequence of the teams’ separation.

    There are many ways to limit these kinds of divisions and foster communication on teams:

    • Try to arrange the workspace so project teams can sit together. If they can’t sit together, then make sure that they have at least one conversation about the project every day.
    • Remote working is a privilege, but it’s only possible if you make yourself available for discussions. A huge benefit of working in an office is being able to wander over to a colleague’s desk and just ask them something; remote working can make people seem unreachable. If you must work remotely, then make sure your colleagues feel comfortable contacting you.
    • Scrum is a great tool for encouraging communication, especially the daily stand-up, during which each team member describes what they’re working on and any problems they need help with.

    Fill in the skill gaps

    Does your team lack the skill necessary to complete a project or deliver it efficiently? Is the team unfamiliar with a particular approach or technology? Do they lack the confidence required to successfully overcome a problem? Use specialists as a means to train your staff:

    • Bring in a specialist from elsewhere in the company or, if the skills don’t exist internally, hire a consultant.
    • Don’t allow specialists to solve the problem in isolation. Give your team members the opportunity to work closely with them, to learn from their experience, and to begin building the skills they lack.
    • Encourage your specialists to conduct workshops. Workshops are also a nice way to build an interactive relationship between specialists and generalists; they open communication and foster a knowledge-sharing environment.

    Promote knowledge-sharing

    I once worked in a team that made a point of identifying silos. We were encouraged to work on the whole system and no single developer owned a specific area, though people had their preferences—I gravitated more towards client-side, while a colleague favored web services.

    When I admitted that I was unfamiliar with how the company’s internal web services functioned because I hadn’t worked on them for so long, my colleague and I decided to alternate between client-side and web-service work during the next sprint, thus sharing our knowledge.

    There are many ways to promote this kind of knowledge-sharing, which is fundamental to innovation and a collaborative culture.

    Brown-bags

    At my current company, we hold regular brown-bag lunches—everyone brings their own lunch to eat while a colleague gives an informal talk on a topic that they’re interested in. Brown-bags often spawn interesting discussions among participants: I can recall a few occasions where a technical feature or procedure has made its way into our formal processes following a fervent brown-bag.

    Scott Hanselman at Microsoft suggests that companies “host technical brown-bags at least twice a month and encourage everyone to present at least every year.” It’s a good opportunity to encourage a healthy debate among colleagues with whom you don’t necessarily collaborate on a regular basis.

    Guilds

    In his article “Scaling Agile at Spotify with Tribes, Squads, Chapters and Guilds” (PDF), Henrik Kniberg defines a guild as “a group of people that want to share knowledge, tools, code, and practices.” Spotify uses guilds to bridge gaps between teams across the organization. For example, a developer is likely to encounter a problem that another developer in the organization has already solved. Where’s the sense in duplicating work?

    Forming a guild allows common solutions to be communicated. It’s an opportunity to share experiences among teams.

    At my current company, each team has at least one tester; the testers also belong to a separate QA guild, which allows them to pool their knowledge. It has been a big success: testing procedures have been standardized across the teams, and technologies like Selenium have been introduced into the test stack.

    Internal open-source models

    Limit the perception of ownership by introducing internal open-source models. Give everyone the ability to contribute to your source code or designs by replacing ticket-based systems with a model similar to GitHub’s pull requests. If you’re competent and comfortable making a change to a codebase that sits within another team’s “area,” then why shouldn’t you? The other team can act as curators of the project by reviewing any code submissions and feedback—but guess what? Now you’re collaborating!

    Hack days

    Are the projects you’re working on feeling a little stale? Try entering a competition as a company, or use a hack day to get ideas moving again:

    • Arrange a company-wide Ludum Dare, where the best game at the end of the hack day wins.
    • You don’t even need to restrict it to a day. Spotify holds regular hack weeks. You might even end up with something you can present to the business or a client.
    • The National Health Service holds annual hack days in the UK, which local digital professionals are encouraged to attend. They work to solve the problem presented by NHS doctors and staff with whatever technology they have at hand. It’s incredibly empowering, and an amazing opportunity to give back to such an important organization.

    Hack days don’t have to be IT-related; encourage people outside of the development team to take part by following the NHS model. Hack days allow people to work with colleagues they wouldn’t normally work with, in a situation where fresh ideas are encouraged and innovation is rewarded.

    Go forth and collaborate

    Strong collaboration is crucial to building a successful team—and collaboration is fostered by breaking down barriers. Make good use of your specialists by integrating them with your generalists and positioning them to guide, teach, and instill passion in your teams.

  • A New Way to Listen 

    To develop empathy, you need to understand a person’s mind at a deeper level than is usual in your work. Since there are no telepathy servers yet, the only way to explore a person’s mind is to hear about it. Words are required. A person’s inner thoughts must be communicated, either spoken aloud or written down. You can achieve this in a number of formats and scenarios.

    Whether it is written or spoken, you are after the inner monologue. A recounting of a few example scenarios or experiences will work fine. You can get right down to the details, not of the events, but of what ran through this person’s mind during the events. In both written and spoken formats, you can ask questions about parts of the story that aren’t clear yet. Certainly, the person might forget some parts of her thinking process from these events, but she will remember the parts that are important to her.

    A person’s inner thought process consists of the whys and wherefores, decision-making and indecision, reactions and causation. These are the deeper currents that guide a person’s behavior. The surface level explanations of how things work, and the surface opinions and preferences, are created by the environment in which the person operates—like the waves on the surface of a lake. You’re not after these explanations, nor preferences or opinions. You’re interested in plumbing the depths to understand the currents flowing in her mind.

    To develop empathy, you’re also not after how a person would change the tools and services she uses if she had the chance. You’re not looking for feedback about your organization or your work. You’re not letting yourself ponder how something the person said can improve the way you achieve goals—yet. That comes later. For developing empathy, you are only interested in the driving forces of this other human. These driving forces are the evergreen things that have been driving humans for millennia. These underlying forces are what enable you to develop empathy with this person—to be able to think like her and see from her perspective.

    This chapter is about learning how to listen intently. While the word “listen” does not strictly apply to the written word, all the advice in this chapter applies to both spoken and written formats.

    This is a different kind of listening

    In everyday interactions with people, typical conversation does not go deep enough for empathy. You generally stay at the level where meanings are inferred and preferences and opinions are taken at face value. In some cultures, opinions aren’t even considered polite. So, in everyday conversation, there’s not a lot to go on to understand another person deeply. To develop empathy, you need additional listening skills. Primarily, you need to be able to keep your attention on what the person is saying and not get distracted by your own thoughts or responses. Additionally, you want to help the speaker feel safe enough to trust you with her inner thoughts and reasoning.

    There’s virtually no preparation you can do to understand this person in advance. There are no prewritten questions. You have no idea where a person will lead you in conversation—and this is good. You want to be shown new and interesting perspectives.

    You start off the listening session with a statement about an intention or purpose the person has been involved with. In formal listening sessions, you define a scope for the session—something broader than your organization’s offerings, defined by the purpose a person has. For example, if you’re an insurance company, you don’t define the scope to be about life insurance. Instead, you make it about life events, such as a death in the family.1 Your initial statement would be something like, “I’m interested in everything that went through your mind during this recent event.” For listening sessions that are not premeditated, you can ask about something you notice about the person. If it’s a colleague, you can ask about what’s on her mind about a current project.

    Fall into the Mindset

    How often do you give the person you’re listening to your complete attention? According to Kevin Brooks, normally you listen for an opening in the conversation, so you can tell the other person what came up for you, or you listen for points in the other person’s story that you can match, add to, joke about, or trump.2

    It feels different to be a true listener. You fall into a different brain state—calmer, because you have no stray thoughts blooming in your head—but intensely alert to what the other person is saying. You lose track of time because you are actively following the point the other person has brought up, trying to comprehend what she means and if it relates to other points she’s brought up. Your brain may jump to conclusions, but you’re continually recognizing when that happens, letting it go, and getting a better grip on what the speaker really intends to communicate. You’re in “flow,” the state of mind described by Mihaly Csikszentmihalyi.3 You are completely engaged in a demanding and satisfying pursuit.

    It’s a different frame of mind. You don’t want to be this focused on someone else all the time—you have to do your own thinking and problem-solving most of the time. But when needed, when helpful, you can drop into this focused mindset.

    Explore the Intent

    Developing empathy is about understanding another human, not understanding how well something or someone at work supports that person. Set aside this second goal for a bit later. For the time being, shift your approach to include a farther horizon—one that examines the larger purposes a person is attempting to fulfill.

    The key is to find out the point of what the person is doing—why, the reason, not the steps of how she does it. Not the tools or service she uses. You’re after the direction she is heading and all her inner reasoning about that direction. You’re after overarching intentions, internal debates, indecision, emotion, trade-offs, etc. You want the deeper level processes going through her mind and heart—the things that all humans think and feel, no matter if they are old or young, or you are conducting the session 500 years ago or 500 years in the future. These are the details that will allow you to develop empathy. Collecting a shallow layer of explanation or preferences does not reveal much about how this person reasons.

    To remind the speaker that you’re interested in answers explaining what is going on in her mind and heart, ask questions like:

    • “What were you thinking when you made that decision?”
    • “Tell me your thinking there.”
    • “What was going through your head?”
    • “What was on your mind?”

    If you suspect there might be an emotional reaction involved in her story that she hasn’t mentioned yet, ask: “How did you react?” Some people ask, “How did that make you feel,” but this question can introduce some awkwardness because it can sound too much like a therapist. Additionally, some people or industries eschew talking about “feelings.” Choose the word that seems appropriate for your context.

    Avoid asking about any solutions. A listening session is not the place for contemplating how to change something. Don’t ask, “Can you think of any suggestions…?” If the speaker brings up your organization’s offering, that’s fine—because it’s her session. It’s her time to speak, not yours. But don’t expand upon this vein. When she is finished, guide her back to describing her thinking during a past occurrence.

    Make Sure You Understand

    It is all too easy to make assumptions about what the speaker means. You have your own life experience and point of view that constantly influence the way you make sense of things. You have to consciously check yourself and be ready to automatically ask the speaker:

    • “What do you mean?”
    • “I don’t understand. Can you explain your thinking to me?”

    Keep in mind that you don’t have the speaker’s context or life experience. You can’t know what something means to her, so ask. It takes practice to recognize when your understanding is based on something personal or on a convention.

    Sometimes, you will probe for more detail about the scene, but there’s nothing more to say, really. These kinds of dead-ends will come up, but they’re not a problem. Go ahead and ask this kind of “please explain what you mean” question a lot, because more often than not, this kind of question results in some rich detail.

    You don’t need to hurry through a listening session. There’s no time limit. It ends when you think you’ve gotten the deeper reasoning behind each of the things the speaker said. All the things the speaker thinks are important will surface. You don’t need to “move the conversation along.” Instead, your purpose is to dwell on the details. Find out as much as you can about what’s being said. Ignore the impulse to change topics. That’s not your job.

    Alternatively, you might suspect the speaker is heading in a certain direction in the conversation, and that direction is something you’re excited about and have been hoping she’d bring up. If you keep your mind open, if you ask her to explain herself, you might be surprised that she says something different than what you expected.

    It’s often hard to concede you don’t understand something basic. You’ve spent your life proving yourself to your teachers, parents, coworkers, friends, and bosses. You might also be used to an interviewer portraying the role of an expert with brilliant questions. An empathy listening session is completely different. You don’t want to overshadow the speaker at all. You want to do the opposite: demonstrate to her that you don’t know anything about her thinking. It’s her mind, and you’re the tourist.

    Sometimes it’s not a matter of assumptions, but that the speaker has said something truly mystifying. Don’t skip over it. Reflect the mystifying phrase back to the speaker. Ask until it becomes clearer. Don’t stop at your assumption. Teach yourself to recognize when you’ve imagined what the speaker meant. Train a reflexive response in yourself to dig deeper. You can’t really stop yourself from having assumptions, but you can identify them and then remember to explore further.

    Another way to explain this is that you don’t want to read between the lines. Your keen sense of intuition about what the speaker is saying will tempt you to leave certain things unexplored. Resist doing that. Instead, practice recognizing when the speaker has alluded to something with a common, casual phrase, such as “I knew he meant business” or “I looked them up.” You have a notion what these common phrases mean, but that’s just where you will run into trouble.

    If you don’t ask about the phrases, you will miss the actual thinking that was going through that person’s mind when it occurred. Your preconceived notions are good road signs indicating that you should dwell on the phrase a little longer, to let the speaker explain her thought process behind it.

    Footnotes

    • 1. If you’re a researcher, it helps to know that listening sessions are a form of generative research that is person-focused rather than solution-focused. Thus, it’s easy to remember to keep them from dwelling on how solutions might work for people.
    • 2. This was my epiphany from the UX Week 2008 workshop (PDF) by Kevin Brooks, PhD. Sadly, Kevin passed away from pancreatic cancer in 2014.
    • 3. Mihaly Csikszentmihalyi, widely referenced psychologist and author, Flow: The Psychology of Optimal Experience, New York: Harper Collins, 1991, and Finding Flow: The Psychology of Engagement with Everyday Life, New York: Harper Collins, 1997, plus four other book titles on Flow. Also see his TED Talk and YouTube presentations.
  • On Our Radar: In the Key of F 

    Welcome to a new kind of blog post from the A List Apart staff, where we share stories and ideas that caught our eye. This week was all about Fs—no, not the kind you mutter every time your boss says “put it above the fold.” Our staff’s been buzzing about Flipboard, feminism, and facilitating great events. Also, feelings—so many feelings.

    Here’s what’s on our radar:

    Tim Murtaugh, technical director:
    Flipboard has finally released a web-based version of their platform, and it’s generating some interesting conversations. Their choice to use canvas to render the entire site gives them total control over the user experience, but leaves the site completely inaccessible. Faruk Ateş expressed dismay, while Allen Tan offered another perspective.

    Lisa Maria Martin, issues editor:
    “Which Women in Tech?” by Nicole Sanchez was a great read—and it made me realize, quite shamefully, how little I’ve thought about my own role in building truly inclusive events. This was a clarion call to make sure my diversity work is intersectional, and to remember to “give up the mic wherever possible.”

    Jeffrey Zeldman, founder and publisher:
    “How to Organize a Conference: 18 Amazingly Useful Tips” by Louis Rosenfeld is exactly what you think it is. From “validate the need” to “programming is curation and design,” it’s 18 pieces of golden advice solicited from the founders of 18 great web, design, and UX conferences.

    A gif about our feelings:

    A gif of a cat looking unamused by a blizzard outside.
    We’re excited to share these links with you!
    Have we mentioned that many of our staff members are in Boston right now!

    What about you?
    What stories are drawing your attention? Got any posts, pictures, or code demos you want to share? (We love sharing!) Tweet us what’s on your radar—and what should be on ours.

  • Ask Dr. Web with Jeffrey Zeldman: The Love You Make 

    In our last installment, we talked about what to do when your work satisfies the client, but doesn’t accurately reflect your abilities, e.g. how do you build a portfolio out of choices you wouldn’t have made? This time out, we’ll discuss choices you can (and should) make for yourself, free of any client-imposed restrictions.

    As an employer, how important do you feel open source contributions are in a modern portfolio?
    Dip My Toe
    In your opinion, what is best way to present your work online today? Sites like Dribbble? or custom portfolio? or something else?
    All A-Tizzy


    Dear Dip and Tizzy,

    The best thing any web designer or developer can do is learn to write and speak. The heyday of blogging may be over, but that’s no reason not to create a personal site where you share your best ideas (and occasionally, your biggest frustrations) as a professional.

    Design and development use different parts of the mind than verbal expression does. Spending day after day in Photoshop or Coda can get you into a wonderfully productive and inspired groove. But growth comes when you step away from that familiar, comforting environment where you already know you shine, and practice articulating ideas, arguments, and rationales about what you do and why.

    Daring to speak—unblocking your inner voice—can be scary, but it’s worth it. Only by writing my thoughts and speaking publicly do I actually understand what I’m thinking; only by sharing those verbalized thoughts with others can I begin to see their broader implications. The Web Standards Project would not have existed—and the web would be a very different place—if those of us who co-founded it hadn’t spent almost as much time articulating our ideas about the web as we did creating websites. And the same is true for everyone who works to improve our medium by sharing their ideas today.

    By daring to publicly speak and write, you will become better at selling your ideas to tough clients, better at evangelizing methodologies or causes to your peers, better at thinking and therefore at doing, and better at those all-important job interviews. I’m a sucker for design talent, but I’ve never hired anyone, however gifted, if they couldn’t talk, couldn’t argue, couldn’t sell, couldn’t put their passion into words a client could understand.

    I’ve also never hired a designer or developer who didn’t have a blog or some equally meaningful and living web presence. I hired Jason Santa Maria in 2004 because of a blog post he wrote, and over a decade later, we still work together on meaningful projects like A Book Apart (the book arm of the magazine you’re now reading). Moreover, I’ve never hired anyone who didn’t have a personal web presence of some kind—be it a blog or something more unexpected. Don’t get me wrong: communities like Dribbble are fantastic for sharing glimpses of your work, learning from others, and building a following. If you’re an illustrator, a Dribbble or Behance page and a personal portfolio will suffice. If you’re an exceptionally gifted illustrator, one whose work leaps off the screen, I might not even need that personal portfolio—Dribbble or Behance will be enough.

    But if you design, develop, or project manage websites and applications, or do other UX, strategy, or editorial work for the web, you need a voice—and a blog is a terrific place to start building one. (And once you’re comfortable writing on your blog, start reaching out to industry publications.)

    The other thing that really helps you stand apart from your peers is contributing to someone else’s project, or starting your own. If you’re a developer, I should be able to find you on Github; if you’re a designer, start or contribute to a project like Fonts In Use.

    You don’t have to believe in karma to know that, in this field at least, the more you put out, the more you get back. Even if you have the misfortune to work for a series of less-than-stellar clients, or at a shop or company that doesn’t promote your best work, you must never let those circumstances define you. As a designer, you are responsible for what you put out into the world. If your job sucks, design something for yourself; if everything you build is hidden behind corporate firewalls, contribute code to an open source project, link to it from a personal site, and write about it on your blog. That’s how others will discover and appreciate you. Rich Ziade’s studio designed million-dollar projects for banking institutions, and I never saw or heard of one of them. (Secrecy comes with that turf.) But I met Rich, and became his friend and fan, after he and his team released Readability, an app dedicated to un-sucking the online reading experience.

    Don’t wait for someone to offer you a dream job or a dream project. Shake what your momma gave you: create something, pay it forward.

    How do I know this advice is good for your career and our community? A List Apart began as a side-project of mine, back when I was designing less-than-stellar websites for clients I couldn’t sell good work to. And the rest, I believe, you know.

    Hope this helps, and see you again soon in a future installment of “Ask Dr Web.”

    Have a question about professional development, industry culture, or the state of the web? This is your chance to pick Jeffrey Zeldman’s brain. Send your question to Dr. Web via Twitter (#askdrweb), Facebook, or email.

  • A List Apart: On Air 

    We keep busy here at A List Apart: publishing articles, columns, and blog posts; sharing our forays into open source; and coming up with features like email notifications for new content.

    Something was still missing, though.

    We’ve always prided ourselves more on our focus on the designer and developer community than on our technical acumen. Anyone can help make a better website, but we consider it a unique privilege—and responsibility—to be able to help developers become better developers. So, we’re trying something brand new: community-focused events where our readers can get to know A List Apart’s authors and staff.

    Our goal is to bring the feel of a local web development meetup to the web. We want to combine the best and brightest voices from ALA’s past with new voices and new perspectives on designing and building for the web. We want to discuss the events of the day—or hour. We want Q&A sessions where you ask us the tough questions; we want to know what questions don’t yet have answers, so we can figure them out with you.

    If this piques your interest, well, I have some good news: we’re kicking things off right away. We’ve assembled some of the best minds in web performance to talk about every facet of building smaller, faster websites—from getting buy-in at every level of your organization to the steps we can incorporate into our day-to-day work.

    Designing for Performance: Can We Have it All?

    Thursday, February 26, 2015
    1:00 – 2:00 p.m. EST

    Building a faster, leaner web means contending with a number of challenges, not all of which are strictly technical. “But,” your CEO argues, “our massive, high-resolution images are worth the wait.” How do we manage those kinds of expectations? How do we get our teams—and our bosses—as excited about building performant websites as we are? Most important, though: where do we get started, and how?

    Our panelists are here to answer all these questions for you, and then some. Get the details and register now.

    Lara Hogan

    Lara Hogan champions performance as a part of the overall user experience, and is the author of Designing for Performance (O’Reilly, 2014). She believes in striking a balance between aesthetics and speed, and in building performance into company culture. Lara speaks and tweets, and is currently senior engineering manager of performance at Etsy.

    Scott Jehl

    Scott Jehl releases projects on GitHub that focus on accessible, sustainable, and performance-oriented practices for cross-device development. He speaks at conferences around the world and recently authored Responsible Responsive Design (A Book Apart, 2014). Scott is a web designer and developer at Filament Group; his clients include the Boston Globe, LEGO, Global News, and eBay. He tweets early and often.

    Yesenia Perez-Cruz

    Yesenia Perez-Cruz is a Philadelphia-based designer working at Intuitive Company. She is also a speaker at international conferences, in demand for talks specializing in balancing performance with design, cross-team collaboration, and how to be flexible with your design process. She honed her design and user experience skills while working at Happy Cog for clients like Zappos, MTV, and Jose Garces. She also acts as an acquisitions scout for A List Apart.

    And as your humble moderator, I’ll be doing my best to stay out of their way.

    More events are in development, and we’ll be sure to keep you updated. We’re looking forward to talking with all of you.