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
  • Blue Beanie Day 14: Toque ’em if You’ve Got ’em 

    On Sunday, November 30, web designers and developers across the globe will celebrate Blue Beanie Day 2014, wearing a blue beanie to show their support for web standards. Join in!

    “What’s Blue Beanie Day,” you may ask? Well, it’s possible you’ve seen it in years past: a host of avatars on Twitter and Facebook, with selfies galore, each sporting a little blue toque. Here’s the thing: each is a tribute to the hat that launched a thousand sites: the blue beanie worn by A List Apart’s own Jeffrey Zeldman in that infamous selfie, and that eventually emblazoned the cover of Zeldman’s Designing With Web Standards.

    But this isn’t a plug for a book, or for the man wearing the rather fetching hat: rather, sporting a blue chapeau is a reminder that web standards—standards like semantic markup, neatly separated styles, and DOM scripting—are responsible for much of the work we do today. In the pre-WaSP, pre-DWWS world, we were forced to build to the idiosycrasies of each broken desktop browser—could you imagine anything like responsive web design without web standards? It’s true: we face a lot of challenges as the web moves beyond the desktop. But as wild and woolly as this multi-device version of the web is, it’d be significantly more challenging without the solid web standards support we enjoy today.

    So if web standards have made your life a little easier—and I know I couldn’t do my job without ’em—then upload a shot of yourself wearing a blue beanie, hat, or cap to any of these fine social media locations:

    And there’s no need to wait until November 30: if you’ve got a beanie-enabled shot of yourself, then post away!

  • Driving Phantom from Grunt 

    While building websites at Filament Group, there are a couple tools that consistently find their way into our workflow:

    • GruntJS is a JavaScript Task Runner. It runs on NodeJS and allows the user to easily concatenate and minify files, run unit tests, and perform many other tasks, from linting to minification of images.
    • PhantomJS is a headless (Webkit-based) web browser. A headless web browser renders a page without having a visible window. Using this functionality, we can write code that you would want to run in a browser, but see its results in the command line. This allows us to run scripts and even render snapshots of pages without having to open a browser and do it manually.

    Together, these tools allow us to get consistent feedback for our code, by further automating checks that would normally require opening a browser.

    For this example, we’re going to build a Grunt task that takes a screen shot of the pages we’re building (similar to Wraith, but far less advanced). There are multiple parts to make this work, so let’s break it down. First, we will write a PhantomJS script that renders each page. Second, we make a NodeJS function that calls this script. Finally, we make a GruntJS task that calls that Node function. Fun!

    To get started, we need to make sure that PhantomJS is installed. Since we’re using Phantom from the context of a NodeJS application, a very easy way to install it is by using the NPM PhantomJS installer package. Installing Phantom in this manner allows us to make sure we have easy access to the path for the Phantom command while simultaneously having a local, project-specific version of it installed.

    To install locally: npm install phantomjs.

    Now, we need to write a script to give to PhantomJS that will render a given page. This script will take two arguments. The first is the URL of the page that needs to be opened. The second is the file name for the output. PhantomJS will open the page, and when the page has opened successfully, it will render the page as a PNG and then exit.

    var page = require( "webpage" ).create();
    var site = phantom.args[0],
        output = phantom.args[1];
    
    page.open( site, function( status ){
        if( status !== "success" ){
            phantom.exit( 1 );
        }
        page.render( output + ".png" );
        phantom.exit( 0 );
      });
    

    Let’s create a lib directory and save this file in it. We’ll call it screenshotter.js. We can test this quickly by running this command from our command line (in the same directory we installed phantom): ./node_modules/.bin/phantomjs lib/screenshotter.js https://www.google.com google. This should create a file in the same directory named google.png.

    Now that we have a PhantomJS script, let’s work on making this run from Node. PhantomJS is a completely different runtime than Node, so we need a way to communicate. Luckily, Node gives us an excellent library named child_process and in particular, a method from that library called execFile.

    If we look at the documentation for the execFile method, we can see that it takes up to four arguments. One is mandatory, the other three are optional. The first argument is the file or, in our case, the path to PhantomJS. For the other arguments, we’ll need to pass PhantomJS args (the URL and output from above), and we’ll also want to include our callback function—so we can make sure we grab any output or errors from running Phantom.

    var path = require( "path" );
    var execFile = require( "child_process" ).execFile;
    var phantomPath = require( "phantomjs" ).path;
    var phantomscript = path.resolve( path.join( __dirname, "screenshotter.js" ) );
    
    exports.takeShot = function( url, output, cb ){
        execFile( phantomPath, [
                phantomscript,
                url,
                output
        ],
        function( err, stdout, stderr ){
            if( err ){
                throw err;
            }
    
            if( stderr ){
                console.error( stderr );
            }
    
            if( stdout ){
                console.log( stdout );
            }
            if( cb ){
                cb();
            }
        });
    };
    

    Our example code from above is written as a Node.js module. It has a function that takes three parameters. These parameters are the same parameters that are used in the PhantomJS script from above and a callback function to run when the task has completed. It then calls execFile and passes it three arguments. The first is the path to PhantomJS. The second is an Array with the our passed in parameters. The third is our callback function. This callback function is called with three arguments: err, stdout, and stderr. err is the error thrown by Phantom if something bad happens within that script. stderr and stdout are the standard error and standard output streams. This should give us everything we need to call our script as though it’s a regular NodeJS function, which will make it perfect for a Grunt task. Let’s save it in lib/shot-wrapper.js.

    Now, for the Grunt task:

    var screenshot = require( "../lib/shot-wrapper" );
    
    grunt.registerMultiTask( 'screenshots', 'Use Grunt and PhantomJS to generate Screenshots of pages', function(){
        var done = this.async();
        // Merge task-specific and/or target-specific options with these defaults.
        var options = this.options({
            url: '',
            output: ''
        });
    
        screenshot.takeShot( options.url, options.output, function(){
            done();
        });
    });
    

    Let’s take a look at this piece by piece. First, we require the shot-wrapper library we built above. Then, we create the task screenshots by using grunt.registerMultiTask. Since the takeShot method is asynchronous, we need to create a done callback function that lets Grunt know when to complete the task. The options object sets defaults for url and output in case they aren’t passed in (in this case, they’re empty strings, which won’t work). Finally, pass the options and the done callback into the takeShot method. Now, when somebody calls this Grunt task, your code will run.

    Let’s give it a try. Here’s an excerpt from my Gruntfile:

    screenshots: {
      default_options: {
        options: {
          url: 'http://www.alistapart.com/',
          output: 'ala'
        }
      }
    }
    
    An animated gif running screenshots tasks

    The task has run, so we’ll open the file produced:

    open ala.png

    And voilà: as you can see from this rather large image, we have a full-page screenshot of A List Apart’s homepage. (Note: you may notice that the web fonts are missing in the rendered image. That’s currently a known issue with PhantomJS.)

    Just imagine what you can do with your newfound power. Phantom and Grunt give you ample freedom to explore all sorts of new ways to enhance your development workflow. Go forth and explore!

    For more in-depth code and to see the way this works when building a project, check out the repository.

  • Destroying Your Enemies Through the Magic of Design 

    A note from the editors: We’re pleased to share an excerpt from Jenny Lam and Hillel Cooperman’s new book Making Things Special, Tech Design Leadership from the Trenches, available now. A List Apart readers can also enter to win a copy of the book.

    Hierarchical organizations large and small are rife with politics. In fact, the smaller the stakes, the more vicious they can be. Political organizations are ones where what things look like are just as, or more, important as what you actually do. Dealing with perceptions as well as ego and insecurity is part of dealing with human beings. This is who we are. And as soon as we create situations where there are winners and losers we create politics. And fighting. In some organizations, regardless of how brilliant your design may be, the politics will kill your plans before they have a chance to really blossom. And that’s a shame.

    The single most important thing you can understand about navigating the gauntlet of organizational politics is the relative risks of saying no versus yes. Your job, your dream, your passion is to say “yes.” Yes to your product vision. Yes to your design. Yes to delighting customers. But the road is littered with opponents. These are people who will raise concerns about your proposals, reasonable sounding concerns. Concerns that may or may not be genuine. Maybe they’re good thoughts to consider that have been offered in good faith, and maybe they’re just obstacles designed to trip you up and damage you as a competitor in the organization. If you suspect an opponent’s motivations are personal, you’ll never prove it. That only happens in the movies. In effect, their motivations are irrelevant. Genuine or jerky, your only remaining option is to deal with their issues at face value.

    But how?

    Before we answer, let’s pause for an anecdote.

    Years ago we worked on one of two teams in the same company that worked on competing projects. This happens often. The company’s leadership hopes competition fosters innovation, and people bringing forth their best ideas. The other team was huge and had been working on their project for years. There were smart and talented people on that team doing good work. They even had good design talent, but the team wasn’t design driven. They were technology driven. This is not to say that they didn’t think about customers. They did. It’s just that the high order bit was their technology choice, and then they did their best to design around those choices.

    Our team was small. We had decent ideas and were design led. Our team fashioned a high-fidelity prototype that illustrated our ideas. It was on rails, a glorified slide show. And it was gorgeous. The other team had code. We had beautiful images that moved.

    As things came to a head politically, we finally revealed our design to the other team. After the presentation, they looked like they’d been punched in the stomach. Even though they had code, we just had a better story. We had something inspiring. Their stuff was flat. And boring. Literally and metaphorically. And even though they were creative and smart, the genetics of their team had led them down an uninspiring path. They knew it. And so did the execs who saw both teams’ work.

    Within a week those execs tried to merge our teams. And when it was clear that we were culturally incompatible, their project was killed. Was our design work solely responsible for the end of their project? No. Was it one of the things that sent them over the edge? Without a doubt.

    Now let’s return to our discussion of how you can deal with the people who oppose your plans in your organization. Your first choice is to use the logic of your arguments, your personal charm, and maybe a little horse trading to get those folks on board. And in many cases that works. It’s always your best option. We’re big fans of working together harmoniously. But the larger the organization (and it doesn’t have to be all that large) the higher the odds that there will be some people where reasoned discussion and collaboration doesn’t work. Ever.

    Remember, the political economics of saying “no” in large organizations are so much better than saying “yes.” Saying “no” costs essentially nothing. You don’t need to prove anything. You’ll almost never be proven wrong for saying no. And the optics are great too. The person saying “yes” looks overly enthusiastic, while the person saying “no” in reasonable tones sounds like the grownup. The naysayer just has to raise reasonable doubt to save the company from wasting time and money on some “foolish and poorly thought out initiative.” However, saying “yes” is costly. You’re putting yourself out on a limb. You’re being specific. You’re opening yourself up to attack. You’re trying to do something.

    As a user experience design leader you have a secret advantage. It’s the thing that often overcomes every opponent, every craven naysayer. It’s the High Fidelity Visualization.

    What is the High Fidelity Visualization? It could be anything from a series of beautiful UI mockups, to a user experience prototype on rails, to a freeform prototype that the audience can try themselves, to a beautifully produced video showing customers using the prototype.

    There will always be “no” people. But “no” people rarely have counterproposals. And when they do, they’re usually vague or a set of yawn-inducing PowerPoint bullets. By definition, they don’t want to be out on a limb or they’d be subject to attack. So they keep things light on details. But when you show up with a High Fidelity Visualization, if you’ve done your job, and told a great story, everyone else in the room will fall in love with your plan. Decision makers will get excited. They’ll start defending your ideas against the naysayers. Emotion motivates them to become advocates for your plan, your story. And this is a good thing.

    But take note, we liken these visualizations to nuclear weapons. They’re incredibly powerful tools and can cause collateral damage. You’ve got to get the dosage just right. Sometimes you can do such a good job getting your company’s leadership on board with your ideas that now they bother you every week to find out why the product isn’t done yet. After all, that prototype looked essentially ready to ship, and you didn’t spend a lot of time in your pitch meeting talking about the smoke and mirrors you used to put it together.

    The point is this: with a beautifully executed High Fidelity Visualization that sets the right tone, you can neutralize the people in your organization who love to say “no.” This is your secret advantage as someone with vision, an ability to visualize your plan and bring it to life in people’s imagination, and the leadership skills to deliver on that vision. Tell the right story with your execution here and anyone who’s getting in your way will fall by the wayside.

    And for those of you who feel this is militaristic in tone, you’re right. Hierarchical organizations with more than ten people on the team invariably have a representative population of personality types — including people who will get in your way. If you really want to make something special and deliver it to customers, then you need to get the doubters on board or run them over. Partnering with the doubters is always preferable as long as it’s not at the expense of your ideas. But unfortunately, it’s not always possible. It’s not personal. It’s not about being a jerk. It’s not about beating your chest. It’s about making something great. And if you’re in an organization where people with limited vision and possibly political aims are forever stopping you from delivering something wonderful, you need to arm yourself and fight. Spending your time arguing endlessly with people so you can deliver a watered-down version of the great thing that resides in your head is a waste of your time.

    How do you know which feedback is killing your vision and which is making it better? Listen to everyone, open your mind, but trust your instincts. If you stick to your guns and fail, at least you’ll learn something. If you turn your ideas into some sort of compromise mishmash and you fail, you’ll never know exactly what caused the failure and you truly will have wasted your time.

    Good luck soldier.

  • Knowledge vs. Intelligence 

    About a week ago, I was running into major issues during development of one of my side projects. After a few nights working to resolve whatever was breaking, I was getting frustrated with my lack of progress.

    The next night, I was video chatting with Olivier Lacan, and we started discussing the problem. Since he’s a good friend, he suggested sharing my screen and helping me work through it. I was working in Laravel, the new era PHP framework, which Olivier has never worked with (nor does he work with PHP). But he’s intelligent and a great developer, so I quickly took him up on his offer.

    We pored through the codebase together—I walked him through the application and the framework, and he asked probing questions about what was happening internally. Since Olivier isn’t deeply familiar with Laravel, he asks different questions than I do, and those questions led us to interesting parts of the framework that I wouldn’t have gotten to alone. After about an hour of debugging, we identified the root issue and fixed it.

    I’ve talked about “switch programming” before—trading computers with someone and working through each others’ issues separately—but this is something different. It’s more akin to traditional “rubber ducking,” except with a trusted, intelligent friend.

    The difference between knowledge and intelligence is key here. Knowledge is the collection of skills and information a person has acquired through experience. Intelligence is the ability to apply knowledge. Just because someone lacks knowledge of a particular subject doesn’t mean they can’t apply their intelligence to help solve problems.

    Knowledge is wonderful, but it fades as techniques and technologies come and go. Intelligence sustains. Its borders extend beyond any technique or technology, and that makes all the difference.

  • Overwhelmed by Code 

    I was recently chatting with a friend and he was talking about all the things he wanted to learn. I was exhausted just hearing the list and realized that I am either getting old or I am getting tired; I’m not sure which.

    There is a constant pressure to learn new things and keep up with all the latest ideas: new frameworks, new platforms, new ideas of how to write code, they just keep coming out. In addition, the ebb and flow of what is desired from a front-end developer keeps changing. It used to be that knowing CSS and HTML was enough, then jQuery came along, then responsive techniques, then Node.js and then Angular, Ember, etc., etc., etc. That list, right there, it tires me out.

    So lately I’ve had to do some evaluating. What do I want to focus on, what do I love about the web? What do I actually want to learn, versus what I think I should learn. And to be honest, what I really like about the web, it isn’t always whatever is the sexy new hotness—it’s the bread and butter that makes sites easier for everyone to access and use. I love responsive design, I care about accessibility, and lately I’ve gotten really interested in performance as it pertains to CSS styles and load times.

    There is a lot of pressure out there: to learn new things, to spend all your time coding, to be the super developer. I now believe that to be impossible and unhealthy. It means you aren’t living a balanced life and it also means that you’re living under constant stress and pressure.

    So I’ve started devoting the time I have for learning new things to learning the things that I like, that matter to me, and hopefully that will show in my work and in my writing. It may not be sexy and it may not be the hottest thing on the web right now, but it’s still relevant and important to making a great site or application. So instead of feeling overwhelmed by code, maybe take a step back, evaluate what you actually enjoy learning, and focus on that.

  • Why Responsive Images Matter 

    For the first few years of my career I’d joke that I “type for a living.” That was selling myself short, though, I know—making websites is a complicated gig. It’s more accurate, I think, to say that I’m wrong for a living. I’ve been wrong about damn near everything about this job so far. I’m probably—no, definitely—wrong about plenty of things, as we speak.

    I’m spectacular at job interviews, before anyone asks.

    I should be more specific here: I’ve spent a good part of my career being wrong about matters of browsing context, but I don’t think I’m the only one. It hasn’t been all that long since the days of fixed-width websites, and the era of “looks best in Internet Explorer.” Back then, I was up to my neck in each of those industry-wide wrongnesses, sure that we were doing the right thing promoting the better browser and keeping apace with all the the hottest new CRT monitor sizes. It sure felt like I was right, at those times. It seemed like there were plenty of reasons to think so.

    I’ve been wrong about context more recently than either of those—before web standards changed the way we think about browser support, and before responsive web design changed the way we think about our layouts. For a time—and with just as little realization of how wrong I was—I’d chosen a single familiar, comfortable context for the sites I’d build. I was building websites for my context: the browsing conditions that I was used to. I was doing my work on a fast computer and a high-speed internet connection—that’s what the web was, to me. I have the privilege of assuming high bandwidth and stable networks—I can assume that sending out a request will always result in something being sent back. But we can’t make assumptions about bandwidth that way, any more than we can make development decisions based on a cursory look around our offices, saying, “Everyone here has a pretty big display,” or, “Everyone here is using Firefox.”

    I’m not the only one who made this mistake, either: not long ago, a full 72 percent of responsive websites were sending the same amount of data to mobile and desktop users, while only about six percent of responsive sites were taking significant steps in tailoring assets to mobile devices. Unfortunately, that last statistic doesn’t really track with reality: seventy one percent of mobile users expect websites to load almost as fast, or faster, than everywhere else.

    The people building the web have it the easiest on the web, and perhaps as a result: the average web page is now more than 1.8 megabytes, with images alone accounting for a full megabyte of that.

    That’s more than a case of us creating an minor inconvenience for ourselves. Building enormous websites means us shifting the burden of our mistakes onto every single user that visits our site. It’s us saying that we’re willing to build something that isn’t for some users, because that’s most comfortable for us—no different from “best viewed in Internet Explorer 5.5” or “best viewed at 600x800,” but much more costly.

    That’s not what I want the web to be. That’s not what I want this job to be. The meaning I take from this gig doesn’t come from getting a div to show up in the right place—it comes from knowing that working just a little harder can mean that entire populations just setting foot on the web for the first time will be able to tap into the collected knowledge of the whole of mankind. That’s the philosophy that started the crusade for “responsive images.” Building massive, resource-heavy sites means excluding millions of users worldwide that have only ever known the web by way of feature phones or slightly better. These are users paying for every kilobyte they consume, already keeping tabs on which sites they need to avoid day-to-day because of the cost of visiting them, and not some nebulous hand-wavy “bandwidth cost” either—actual economic cost.

    If every single one of you were convinced that this is a big deal, it still wouldn’t be enough—there are too few of us, and the steps to solve these problems in our daily work aren’t as clear-cut as they need to be. This is something I’ve wanted solved at the browser level for a long time now. I want a feature we could make a part of our everyday workflow—something we all just do as a matter of course, baked right into HTML5.

    That solution is here, thanks to the efforts of developers like Eric Portis. In our latest issue, Eric’s “Responsive Images in Practice” forgoes the rocky history and web standards minutia involved in the search for a native “responsive images” solution and cuts right to what matters most: putting those solutions to use so we can build a better web for our users. Those users will never see any difference; they won’t care what combination of responsive image techniques we used or which use cases we needed to address. They’ll see images, same as they would before. What those users will notice is that the web feels faster.

    Responsive web design is still pretty new, in the grand scheme of things. We’re all still getting the hang of it, myself included. There are plenty more things for us to be wrong about, I’m sure, but I’m excited to find them with you all. Because every time we discover we’ve been wrong about some matter of context on the web, we find a way to fix it together. And the web gets a little stronger, a little faster, and a little more inclusive as a result.

  • Show Your Work: Demonstrating Progress on Your Projects 

    I’ve been thinking a lot lately about how actual progress on a project doesn’t always match the impression of progress—sometimes a lot of code has changed but nothing looks very different, while other times a small change in code gives the sense that the whole project has moved leaps and bounds.

    This came up recently because of how my team had been prioritizing bug fixes on a responsive redesign project. Our normal process is that after sharing an early version of a responsive prototype with the client or internal stakeholder, we create a ton of bug reports (GitHub issues, in our case) that act as to-dos as we move through the project. Depending on the project, the issues are usually grouped by content type (“all the variations of portfolio styles”) or by section (“all the sidebars”). The highest priority issues are any that block other people from doing their work, and after that, order of fixing is largely left to the discretion of the developer.

    On this particular project, lots of fixes were being committed and pushed out to the development site, but when I reloaded the pages nothing looked very different. Two weeks passed and everything still looked pretty much the same. I knew work was being done, but I couldn’t see where.

    Finally, exasperated at what seemed like a lack of progress, I asked the team why they hadn’t fixed what felt like a huge, obvious bug to me: images were being scaled to larger than their actual image size at some breakpoints and looked pixelated and crappy. “Oh,” one developer said, “that’s a popcorn task: super easy and fast, and I like to leave those fixes to the end. I start with the complicated issues first so I have the most time to work on them.” Another developer explained that the display bugs in the header and main navigation weren’t slated to be addressed until she had finished styling the news archives.

    When it comes to front-end development, many of the trickiest issues are subtle—the way a table resizes at a middle breakpoint, or line heights adjust as the viewport size changes. On this site, the glaring issues that were clearest to a non-developer—the ratio of column widths, wonky margins, and broken images—kept getting shoved to the back of the queue, where it looked to me (and our client) like no one was paying attention to them. And of course an ugly and broken header is going to stay that way as long as the team is focused on styling the news section instead.

    For the next few weeks of the project, we tried something new and tagged some of the issues as “visually important.” Those issues got addressed early even if they were simple or not part of the section in focus, based on our judgment that fixing them would add to the impression of progress on the development site. Each week when I reviewed the site, I saw headers now properly aligned, new snazzy CSS transitions, and trendy border-radiused circular profile images.

    By the end of the phase, we had fixed all the same bugs that we normally would have. But by strategically addressing the visually obvious issues, we created an external sense of progress for our stakeholders that was a more accurate reflection of the amount of work going into the code.

    Iteration is a hot topic right now, and many of us are moving toward sharing earlier and messier versions of a site with our stakeholders. We put a lot of care and attention on crafting a great user experience, but the end user isn’t the only one who needs to be pleased with the site. It’s worth adjusting the processes around how we present and work with rough prototypes in a way that provides a good client experience as well.

  • The Couch Cone of Silence 

    This is Geek Mental Help Week. We’re participating because we want to make it safer for people in our industry to talk about mental health. Join in or follow along at @geekmentalhelp and #geekmentalhelp.

    About five years ago, I bought a cushy couch for my office. (Okay, yes, I did get the model that could flatten into an emergency nap station, but let’s just say that I plan for contingencies—it sounds more professional that way.) Our projects required a lot of office-to-office visiting to discuss situations in person, and eventually, said couch (and therefore, my office) became a veritable beacon, attracting anyone looking for an excuse to decompress. Such is the life of a one-couch, 50-chair business.

    Project chats could turn quickly into personal deep dives. I learned which to expect by the way people knocked on my door and asked if I was busy. The biggest tip-off was closing of the door as they came in.

    Most people just wanted someone to listen. I’d hear grumblings about managers and stress, and sometimes they’d ask for advice. But gradually, I sometimes also heard about anxiety, depression, emotional baggage, counseling, complicated diagnoses, and the merits of medications. Finding out what people were dealing with often left me with absolutely no idea what to say. I’m no therapist.

    How was I supposed to respond? Labeling something a “mental health issue” makes it feel amorphous and scary—unknown, subjective territory that’s best left to professionals. But mental health is not a Boolean value; it’s a spectrum we’re all on, and one that’s always fluctuating, though we may define those fluctuations with other names. Some conditions are temporary, some are precipitated by events, some are genetic, and some can be caused by medications taken for innocuous, unrelated reasons. We are complex adaptive systems affected by situations, and no one is on the forever side of “not mentally ill.” In light of that, there is nothing to hide or be ashamed of. No one should feel alone. When our friends and colleagues are struggling, we don’t have to be a professional to help them fight that fight.

    It’s very natural to just jump in, but it’s very, very important to first learn about what is going on under the surface and behind the scenes. Internal struggles aren’t easy to see, mental health-related or not. I have a couple of extroverted, life-of-the-party friends who battle major depression, and even overcompensate for it because they are expected to be “the fun ones.” It must be exhausting. Like many, many conditions, depression doesn’t affect everyone in the same way—it isn’t defined so simply as “noticeably sad and constantly crying.” The signs and symptoms vary because the condition (whether temporary or congenital) is just an overlay, a layer, a facet. It doesn’t define the person. In other words, “you’re still you.”

    Like my friends, people can do a great job at hiding the dark sides of their struggles. Maybe a coworker is 15-20 minutes late to work every day, but it’s a win for them to be there at all. It took three hours for them to gear up the physical energy to simply get dressed, and everything else they’ve got in the tank to make it home later. Or how about the calmest, most mellow person at the office? Perhaps they’re riding a roller coaster without a seatbelt, experiencing states that take them from happy, energized, and on top of the world to despair and crushing loss in a moment. They’re very aware that they aren’t really feeling those things, yet that’s what they’re feeling. And all because their head is trying to keep standard chemicals in the brain perfectly balanced, only theirs slightly over- and under-calibrates.

    Little do you know, they’re making impossible choices—like deciding whether to handle their condition through sheer grit or to take a medication that dulls their symptoms, yet affects acuity as the dosage increases. It might even make them seem glazed over and stoned to someone who didn’t know any better. How do you choose between your health and your job?

    It’s also important to mention that many mental health conditions affect quality of life so significantly that they are classified as disabilities—legally afforded accommodations and protections against discrimination. In reality, disclosing disabilities can be devastating to a career. Even advocates at disability services groups cautiously discuss the potential ramifications of sharing with HR, managers, and coworkers. An employee might just as soon be told to “suck it up,” passed over for promotion, not hired in the first place, or shifted slowly to the door, as have the chance of being granted accommodations that would greatly ease their ability to earn a living. But that’s daily life for some: hacking away at an impossible server issue while exploding inside from anxiety, or somehow channeling creative energy into design work when there’s a pull to just end things. It takes guts to go to work every day.

    When someone bravely opens up about their lives, they aren’t in search of platitudes, yet we tend to lean on what we’ve seen modeled. That might mean grasping beyond the realm of real experiences. With rare exceptions, movies, TV, and books love to present the extremes—stereotypes for the sake of plot. They treat mental health issues like comic relief, reasons the “heros” of the story should be afraid or on guard, or treat others with pity bordering on condescension. This is disrespectful, ill-informed, and only serves to miseducate on a mass scale, leaving stereotypes and stigma to go hand-in-hand. We’re better than that.

    So, how do we respond to and support others in the most respectful and honorable way possible?

    Specifically ask how they would like for you to be there and support them. They might just want an open door or someone to have lunch with sometimes. Don’t assume they’re expecting a rescuer or someone to fix things. In this moment, they are just opening up and talking as a means of easing the weight that’s on their shoulders.

    Do be a friend who “checks in.” Show that you’re around—you don’t have to talk long, just don’t “disappear” on them.

    Do talk about other things, but don’t not talk about the condition, either. They probably don’t want to talk about it all the time, and would love to have a distraction, but it’s also good to ask them about what they’re going through, and for them to explain more about it and suggest good, accurate resources to read.

    Don’t assume they’ve forgotten the internet exists. They have likely already been online and investigated the symptoms or condition thoroughly. Think twice before sending them reading materials and links to websites, blogs, forums, or articles, especially those written by others with similar issues. This implies they haven’t thought to look themselves, and there’s a chance that content written by those in worse situations can bring them down and play on fears that things can’t get better. While you’re at it, don’t suggest (or base suggestions for treatment on) movies, TV shows, or books because a character seems to have similar issues.

    Don’t say things like, “Can’t you take a pill for that?” It not only diminishes the issue by implying that medication is some sort of cure-all (which it isn’t), someone may not even need medication, may be sensitive to it, already be on some, or have tried many already without finding ones that help. They might even have personal reasons not to take it.

    Don’t think they’ve never heard about counseling or treatment. It can be very helpful to talk to a professional, but it is ultimately a personal choice to decide when the time is right to do so, and whom to see.

    If they’re an employee, ask what sort of accommodations would help them at work. A willingness to make accommodations and support them is huge, even if they choose not to ask for those accommodations in the end, or they suggest agreeable compromises. Ask what would be best for the particular person, such as if remote work might help or be too isolating, or if a flexible schedule would be best.

    One of my personal tenets is this: make time for people. Rejection is subtly transmitted in enumerable ways, so be mindful and learn to listen. We don’t have to know what to do, just know how to be there and how to go about it, whether it’s an afternoon coffee run together, a ready couch, or just letting others know they’re worthwhile.

    In our industry in particular, part of our very job is to consider people, their lives, their needs, and how to optimize everything around personal experiences so that no one is left feeling excluded or forgotten. Accessibility and inclusion stand for more than what we craft on a bright screen someplace.

    Note: only a trained mental health professional is qualified to make a diagnosis. If you’re coping with personal struggles, know that you have lots of people out there to support you. Reach out to find them, and don’t give up.

  • Learning to Be Flexible 

    As a freelancer, I work in a lot of different code repos. Almost every team I work with has different ideas of how code should be organized, maintained, and structured.

    Now, I’m not here to start a battle about tabs versus spaces or alphabetical order of CSS properties versus organizing in terms of concerns (positioning styles, then element layout styles, then whatever else), because I’m honestly not attached to any one system anymore. I used to be a one-tab kind of person, along with not really even thinking about the ordering of my properties, but slowly, over time, I’ve realized that most of that doesn’t really matter. In all the projects I’ve worked on, the code got written and the product or site worked for the users—which is really the most important thing. What gets me excited about projects now is the code, making something work, seeing it work across different devices, seeing people use something I built, not getting upset about how it’s written.

    Since I went down the freelance route again earlier this year, I’m working with many different teams and they all have different standards for how their code should be written. What I really want to know when I start a project is what the standards are, so I can adhere to them. For many teams that means a quick look through their documentation (when they have it, it’s a dream come true—there are no questions and I can just get to work). For other teams, it means I ask a lot of questions after I’ve taken a look at the code to verify how they prefer to do things.

    Even more so than just thinking about how to write code, there’s the fact that I may be working in straight CSS, Sass, Stylus, Handlebars, plain old HTML, or Jade and I usually roll right along with that as well. Every team makes decisions that suit them and their way of working—I’m there to make life easier by coming in and helping them get a job done, not tell them their whole setup is wrong. The variety keeps me on my toes, but it also helps me remember that there isn’t just one way to do any of this.

    What has this really done for me? I’ve started letting go of some things. I have opinions on how to structure and write CSS, but whether it’s written with a pre-processor or not, I don’t always care, and which pre-processor matters less to me as well. Any way you do it, you can get the job done. Choosing what works best for your team is what’s most important, not what anyone outside the team says is the “right” or “only” way to do something.

  • Personalizing Git with Aliases 

    Part of getting comfortable with the command line is making it your own. Small customizations, shortcuts, and time saving techniques become second nature once you spend enough time fiddling around in your terminal. Since Git is my Version Control System of choice (due partially to its incredible popularity via GitHub), I like to spend lots of time optimizing my experience there.

    Once you’ve become comfortable enough with Git to push, pull, add, and commit, and you feel like you’d like to pursue more, you can customize it to make it your own. A great way to start doing this is with aliases. Aliases can help you by providing shorthand commands so you can move faster and have to remember less of Git’s sometimes very murky UI. Luckily, Git makes itself easy to customize by setting global options in a file named .gitconfig in our home directory.

    Quick note: for me, the home directory is /Users/jlembeck, you can get there on OSX or most any other Unix platform by typing cd ~ and hitting enter or return. On Windows, if you’re using Powershell, you can get there with the same command and if you’re not using Powershell, cd %userprofile% should do the trick.

    Now, let’s take a look. First, open your .gitconfig file (from your home directory):

    ~/code/grunticon master* $ cd ~
    ~ $ open .gitconfig
    

    You might see a file that looks similar to this:

    [user]
      name = Jeff Lembeck
      email = your.email.address@host.com
    [alias]
      st = status
      ci = commit
      di = diff
      co = checkout
      amend = commit --amend
      b = branch
    

    Let’s look at the different lines and what they mean.

    [user]
      name = Jeff Lembeck
      email = your.email.address@host.com
    

    First up, the global user configuration. This is what Git references to say who you are when you make commits.

    [alias]
      st = status
      ci = commit
      di = diff
      co = checkout
      amend = commit --amend
      b = branch
    

    Following the user information is what we’re here for, aliases.

    Any command given in that screen is prefaced with git. For example, git st is an alias for git status and git ci is git commit. This allows you to save a little time while you’re typing out commands. Soon, the muscle memory kicks in and git ci -m “Update version to 1.0.2” becomes your keystroke-saving go-to.

    Ok, so aliases can be used to shorten commands you normally type and that’s nice, but a lot of people don’t really care about saving 10 keystrokes here and there. For them, I submit the use case of aliases for those ridiculous functions that you can never remember how to do. As an example, let’s make one for learning about a file that was deleted. I use this all of the time.

    Now, to check the information on a deleted file, you can use git log --diff-filter=D -- path/to/file. Using this information I can create an alias.

    d = log --diff-filter=D -- $1
    

    Let’s break that down piece by piece.

    This should look pretty familiar. It is almost the exact command from above, with a few changes. The first change you’ll notice is that it is missing git. Since we are in the context of git, it is assumed in the alias. Next, you’ll see a $1, this allows you to pass an argument into the alias command and it will be referenced there.

    Now, with an example. git d lib/fileIDeleted.js. d is not a normal command in git, so git checks your config file for an alias. It finds one. It calls git log --diff-filter=D -- $1. And passes the argument lib/fileIDeleted.js into it. That will be the equivalent of calling git log --diff-filter=D -- lib/fileIDeleted.js.

    Now you never have to remember how to do that again. Time to celebrate the time you saved that would normally be spent on Google trying to figure out how to even search for this. I suggest ice cream.

    For further digging into this stuff: I got most of my ideas from Gary Bernhardt’s wonderful dotfiles repository. I strongly recommend checking out dotfiles repos to see what wild stuff you can do out there with your command line. Gary’s is an excellent resource and Mathias’s might be the most famous. To learn more about Git aliases from the source, check them out in the Git documentation.

  • This week's sponsor: Proposify 

    Thanks to Proposify for sponsoring A List Apart this week. Learn more about their software to streamline your proposals and get faster sign-off.

  • Planning for Performance 
    I want you to ask yourself when you make things, when you prototype interactions, am I thinking about my own clock, or the user’s?
    Paul Ford, “10 Timeframes”

    We’re not doing a good job

    Page-load times in the ten-second range are still common on modern mobile networks, and that’s a fraction of how long it takes in countries with older, more limited networks. Why so slow? It’s mostly our fault: our sites are too heavy, and they’re often assembled and delivered in ways that don’t take advantage of how browsers work. According to HTTP Archive, the average website weighs 1.7 megabytes. (It’s probably heftier now, so you may want to look it up.) To make matters worse, most of the sites surveyed on HTTP Archive aren’t even responsive, but focus on one specific use case: the classic desktop computer with a large screen.

    That’s awful news for responsive (and, ahem, responsible) designers who aim to support many types of devices with a single codebase, rather than focusing on one type. Truth be told, much of the flak responsive design has taken relates to the ballooning file sizes of responsive sites in the wild, like Oakley’s admittedly gorgeous Airbrake MX site, which originally launched with a whopping 80-megabyte file size (though it was later heavily optimized to be much more responsible), or the media-rich Disney homepage, which serves a 5-megabyte responsive site to any device.

    Why are some responsive sites so big? Attempting to support every browser and device with a single codebase certainly can have an additive effect on file size—if we don’t take measures to prevent it. Responsive design’s very nature involves delivering code that’s ready to respond to conditions that may or may not occur, and delivering code only when and where it’s needed poses some tricky obstacles given our current tool set.

    Fear not!

    Responsible responsive designs are achievable even for the most complex and content-heavy sites, but they don’t happen on their own. Delivering fast responsive sites requires a deliberate focus on our delivery systems, because how we serve and apply our assets has an enormous impact on perceived and actual page-loading performance. In fact, how we deliver code matters more than how much our code weighs.

    Delivering responsibly is hard, so this chapter will take a deep, practical dive into optimizing responsive assets for eventual delivery over the network. First, though, we’ll tour the anatomy of the loading and enhancement process to see how client-side code is requested, loaded, and rendered, and where performance and usability bottlenecks tend to happen.

    Ready? Let’s take a quick look at the page-loading process.

    A walk down the critical path

    Understanding how browsers request and load page assets goes a long way in helping us to make responsible decisions about how we deliver code and speed up load times for our users. If you were to record the events that take place from the moment a page is requested to the moment that page is usable, you would have what’s known in the web performance community as the critical path. It’s our job as web developers to shorten that path as much as we can.

    A simplified anatomy of a request

    To kick off our tour de HTTP, let’s start with the foundation of everything that happens on the web: the exchange of data between a browser and a web server. Between the time when our user hits go and their site begins to load, an initial request pings back and forth from their browser to a local Domain Name Service (which translates the URL into an IP address used to find the host), or DNS, to the host server (fig 3.1).

    Diagram showing how data moves between browsers and servers.
    Fig 3.1: The foundation of a web connection.

    That’s the basic rundown for devices accessing the web over Wi-Fi (or an old-fashioned Ethernet cable). A device connected to a mobile network takes an extra step: the browser first sends the request to a local cell tower, which forwards the request to the DNS to start the browser-server loop. Even on a popular connection speed like 3G, that radio connection takes ages in computer terms. As a result, establishing a mobile connection to a remote server can lag behind Wi-Fi by two whole seconds or more (fig 3.2).

    Diagram showing how data moves on a mobile network.
    Fig 3.2: Mobile? First to the cell tower! Which takes two seconds on average over 3G.

    Two seconds may not seem like a long time, but consider that users can spot—and are bothered by—performance delays as short as 300 milliseconds. That crucial two-second delay means the mobile web is inherently slower than its Wi-Fi counterpart.

    Thankfully, modern LTE and 4G connections alleviate this pain dramatically, and they’re slowly growing in popularity throughout the world. We can’t rely on a connection to be fast, though, so it’s best to assume it won’t be. In either case, once a connection to the server is established, the requests for files can flow without tower connection delays.

    Requests, requests, requests!

    Say our browser requests an HTML file. As the browser receives chunks of that HTML file’s text from the server, it parses them procedurally, looking for references to external assets that must also be requested, and converts the HTML into a tree structure of HTML elements known as a Document Object Model, or DOM. Once that DOM structure is built, JavaScript methods can traverse and manipulate the elements in the document programmatically and CSS can visually style the elements however we like.

    The complexities of HTML parsing (and its variations across browsers) could fill a book. Lest it be ours, I will be brief: the important thing is getting a grasp on the fundamental order of operations when a browser parses and renders HTML.

    • CSS, for example, works best when all styles relevant to the initial page layout are loaded and parsed before an HTML document is rendered visually on a screen.
    • In contrast, JavaScript behavior is often able to be applied to page elements after they’re loaded and rendered.

    But both JavaScript and CSS present bumps on the critical path, blocking our page from showing while they load and execute. Let’s dig into this order of operations a bit.

    Rendering and blocking

    The quickest-to-load HTML document is one without extra external files, but it’s also not one you’ll commonly find. A typical HTML document references a slew of outside assets like CSS, JavaScript, fonts, and images.

    You can often spot CSS and JavaScript in the HTML document’s head as link and script elements, respectively. By default, browsers wait to render a page’s content until these assets finish loading and parsing, a behavior known as blocking (fig 3.3). By contrast, images are a non-blocking asset, as the browser won’t wait for an image to load before rendering a page.

    Diagram showing CSS and JavaScript blocking.
    Fig 3.3: Blocking CSS and JavaScript requests during page load.

    Despite its name, blocking rendering for CSS does help the user interface load consistently. If you load a page before its CSS is available, you’ll see an unstyled default page; when the CSS finishes loading and the browser applies it, the page content will reflow into the newly styled layout. This two-step process is called a flash of unstyled content, or FOUC, and it can be extremely jarring to users. So blocking page rendering until the CSS is ready is certainly desirable as long as the CSS loads in a short period of time—which isn’t always an easy goal to meet.

    Blocking’s value with regard to JavaScript almost always undermines the user experience and is more a response to a lingering JavaScript method called document.write, used to inject HTML directly into the page at whatever location the browser happens to be parsing. It’s usually considered bad practice to use document.write now that better, more decoupled methods are available in JS, but document.write is still in use, particularly by scripts that embed advertisements. The biggest problem with document.write is that if it runs after a page finishes loading, it overwrites the entire document with the content it outputs. More like document.wrong, am I right? (I’m so sorry.) Unfortunately, a browser has no way of knowing whether a script it’s requesting contains a call to document.write, so the browser tends to play it safe and assume that it does. While blocking prevents a potential screen wipe, it also forces users to wait for scripts before they can access the page, even if the scripts wouldn’t have caused problems. Avoiding use of document.write is one important step we can take to address this issue in JavaScript.

    In the next chapter, we’ll cover ways to load scripts that avoid this default blocking behavior and improve perceived performance as a result.

  • Matt Griffin on How We Work: Pricing the Web 

    I probably don’t have to tell you that pricing is slippery business. It requires a lot of perspective, experience, and luck (read: trial and error). There are a number of ways we can correlate monetary value to what we do, and each has its pros and cons.

    It may seem at first glance that pricing models begin and end in the proposal phase of a project. That pricing is simply a business negotiation. But whether we’re talking about design, development, or business methodologies, our processes affect our motivations, and influence outcomes—often throughout the entire project. We’ll be examining both client and agency motivations in our comparisons of pricing models, so you can judge whether those motivations will help you make better work with your clients.

    All of these pricing systems operate with the same set of variables: price, time, and scope. In some systems, such as hourly pricing, variables are directly dependent on each other (e.g. if I work an hour, I get paid my hourly rate, and deliver an hour’s worth of work). In others, like fixed price and value pricing, the relationships can be nonlinear (eg. I am paid a sum of money to achieve some set of results, regardless of how much time I spend doing it).

    These dependencies tend to define each system’s inherent risk and potential for profit. And all the differences can get pretty bewildering. One person’s experience is hardly enough to understand them all well, so I’ve enlisted some friends from web agencies of various sizes to chime in about how they make things work.

    As with most things in life, there’s no perfect solution. But if you want to get paid, you have to do something! Enough gum-flapping, let’s take a look at some of the different ways that people are pricing web projects.

    Fixed price

    With fixed-price projects, you and the client agree up front on a cost for the entirety of the project. Many folks arrive at this number by estimating how many hours they think it would take them to do the project, and multiplying that by an hourly rate. That cost will be what the client pays, regardless of actual hours spent.

    Client motivation

    When the price of a project is fixed, the variable tends to become scope of work. This encourages clients to push for the maximum deliverables they can get for that cost. This can be addressed to a degree by agreeing on a time limit for the project, which keeps requests and scope changes from occurring in perpetuity.

    Agency motivation

    On the agency side, your motivation is to be as efficient as possible to maximize the results while reducing time spent. Less time + more money = greater profit.

    Pros

    Because you know exactly how much money is coming in, revenue is fairly predictable. And since revenue isn’t tied to the time you spend, profit is potentially greater than with a time-based model—especially when the cost is high and the timeline is short.

    Cons

    The same factors that provide the possibility of greater profit create the potential for greater loss. Defining exactly what a client will receive for their money becomes a high priority—and defining things well can be harder than it sounds.

    Eileen Webb, Director of Strategy and Livestock at webmeadow, provides some insight into how she defines scope with her clients:

    I like to define the project boundaries clearly by having a “What’s Not Included” section. This may be a listing of services you don’t offer, like SEO or hosting. It’s also a place to list features that you and the client discussed but decided against for this budget or phase. Defining what falls outside the scope is a good way to help everyone agree on what falls in it.

    Now, getting to this definition in the first place is—I probably don’t need to tell you—hard work. And hard work is something you should get paid for. Starting out with an initial discovery engagement is something nearly any project can benefit from, but for fixed-price projects it can be invaluable.

    Resourcing for a fixed-price project can also be hard to estimate, since scope is not necessarily easy to equate to effort and person-hours needed.

    But the primary difficulty with fixed price may be the innate conflict between a client’s motivation to ask for more, and an agency’s motivation to provide less. For a fixed-price project to be successful, this must be addressed clearly from the beginning. Remember that scope discussions are just that: discussions. More isn’t always better, and it’s our job to help keep everyone on the project focused on successful outcomes, not just greater quantities of deliverables.

    Hourly

    At its core, hourly pricing is pretty simple: you work an hour, you get paid for an hour. Hourly, like all time-based pricing, suggests that what’s being paid for is less a product than a service. You’re being paid for your time and expertise, rather than a particular deliverable. Rob Harr, Technical Director at Sparkbox, explains how hourly projects tend to work for them:

    Since everything we do is hourly, the end of the job is when the client says we are done. This sometimes happens when there is still approved budget left, and other times when the budget is completely gone. Often times our clients come back for additional SOW’s to continue the work on the original project.

    Client motivation

    With hourly, clients are encouraged only to ask for work when that work appears to be worth the hourly cost. Since there’s no package deal, for each feature request or task they can ask themselves, “Is this worth spending my money on, or would I rather save it for something else?”

    Project delays are not a financial concern for the client, as no money is spent during this time.

    Agency motivation

    The more an agency works, the more they get paid. In its purest form, this leads to the agency simply wanting to work as much as possible. This can be limited by a few factors, including a budget cap, or not-to-exceed, on the project.

    Project delays are a major concern for the agency, as they’ll lose revenue during these periods.

    Pros

    Every hour a team member spends is paid for, so the risk of this model is very low. If a company is struggling with profitability, I’ve personally found that this is a great way to get back on track.

    Cons

    Unlike fixed-price models, you can only earn as much as you can work. This means that profit maxes out fairly quickly, and can only be increased by increasing hourly rate (which can only go as high as the market will bear), or expanding the team size.

    Because the agency is only paid when they work, this also means a big imbalance in how project delays affect both sides. Thus clients that aren’t in a big hurry to complete work—or have inefficient decision-making structures—may not worry about long delays that leave the agency financially vulnerable. This can be addressed somewhat by having conditions about what happens during delays (the client pays some sort of fee, or the project becomes disproportionately delayed so the agency can take on new work to fill the gap in their schedule). Even with these measures, however, delays will cause some kind of financial loss to the agency.

    Weekly or monthly

    Though similar to hourly in many ways, charging by weekly or monthly blocks has some distinct differences. With these models, the cost assumes that people work a certain number of hours per week or month, and the client is billed for the equivalent number of hours, regardless of whether or not actual hours spent were more or less than assumed.

    Trent Walton, founder of Paravel, explains why they like this approach:

    Most of our clients operate in two-week or month-long sprints. For many projects, we’ll quote chunks of weeks or months to match. This alignment seems to make sense for both parties, and makes estimating scope and cost much easier.

    Client motivation

    Clients tend to want the agency to work as much as possible during the time period to get the maximum amount of work or value. This can be curbed by having a maximum number of hours per week that will be spent, or understanding limitations like no nights or weekends. Related to this, it’s in the client’s best interest to not let project work succumb to delays.

    Agency motivation

    On the agency side, we’re encouraged to be as efficient as possible to maximize results each week, while spending fewer hours accomplishing those tasks. As long as the results are comparable to what’s expected, this motivation tends not to result in conflict.

    At Bearded we’ve found that with weekly projects we spend, on average, the number of hours we bill for. Some weeks a little more, some a little less. But it seems to all come out in the wash.

    Pros

    Knowing that a time period is booked and paid for makes resourcing simple, and keeps the financial risk very low.

    Because the agency is paid the same amount every week or month, clients will tend to do whatever’s necessary to avoid any delays that are in their control. This completely removes the risk of the agency losing money when projects are held up, but also requires the agency to use a process that discourages delays. For instance, at Bearded, we’ve moved to a process that uses smaller, more frequent deliverables, so we can continue working while awaiting client feedback.

    Cons

    Similar to hourly, the agency’s profit is capped at the weekly or monthly rate they charge. To make more revenue they’ll need to charge more for the same amount of work, or hire more people.

    Value

    Value pricing is a method wherein the cost of the project is derived from the client’s perception of the value of the work. That cost may be a fixed price, or it may be a price that factors in payment based on the effect the work has (something closer to a royalty system).

    Dan Mall, founder of SuperFriendly, explains his take on value pricing using a fixed cost:

    I use a combination of value pricing with a little of cost-plus. I try my best to search for and talk about value before we get to dollar amounts. When my customers are able to make a fully informed price/value assessment, the need to justify prices has already been done, so I rarely have to defend my prices.

    Dan’s approach suggests that if a company stands to gain, say, millions of dollars from the work you do, then it doesn’t make sense for you to merely charge a few thousand. The value of your work to the company needs to be factored in, resulting in a proportionally larger fixed cost.

    Other takes on value pricing tie the cost of the project directly to the results of the work. This can be assessed using whatever metrics you agree on, such as changes in revenue, site traffic, or user acquisitions. This sort of value pricing lends itself to being used as an add-on to other systems; it could augment an hourly agreement just as easily as a fixed price one.

    It’s worth noting that none of the folks I talked to for this article have done this in practice, but the general approach is outlined in Jason Blumer’s article Pricing Strategy for Creatives.

    Client motivation

    This depends primarily on the other system that you’re using in conjunction with value pricing. However, if a client recognizes the tangible gain they expect from the outset, this will tend to focus their attention on how the work will influence those outcomes.

    Agency motivation

    When payment is tied to metrics, the focus for the agency will be on work that they believe will positively affect those metrics. Like client motivations, an agency’s other motivations tend to be the same as the other system this is based on (fixed, hourly, weekly, or monthly).

    Pros

    Because of the nonlinear relationship between labor and revenue, this approach has the highest potential for profit. And as long as the base pricing is reasonable, it can also have very low financial risk.

    Cons

    Since value pricing is potentially connected to things outside your control, it’s also potentially complicated and unpredictable. If revenue is based on future performance metrics, then accurately determining what you’re owed requires knowledge of those metrics, and likely a little legwork on your part. There’s also a certain amount of risk in delaying that payment until a future date, and having its existence in question altogether. As long as the base pricing you use is enough to sustain the business on its own, that risk seems less worrisome.

    With value pricing, there’s also the need to assess the value of the work before agreeing on a price. Which is why—as with fixed-price projects—value-pricing projects often work well as a followup to an initial discovery engagement.

    Patty Toland and Todd Parker, partners and co-founders of Filament Group, explain their approach to an initial engagement:

    Most of the projects we engage in with clients involve fairly large-scale system design, much of which will be defined in detail over months. We provide high-level overall estimates of effort, time and cost based on our prior project work so they can get a sense of the overall potential commitment they’re looking at.

    If those estimates work with their goals, schedule and budget, we then agree to an initial engagement to set a direction, establish our working relationship, and create some tangible deliverables.

    With that initial engagement, we estimate the total amount of time in person-days we plan to spend to get to that (final) deliverable, and calculate the cost based on a standard hourly rate.

    It depends

    So what’s the best approach for you? Blimey, it depends! I’ve talked with many very smart, successful people that use very different takes on various approaches. Each approach has its benefits and its traps to watch for, and each seems to work better or worse for people depending on their personalities, predilections, and other working processes.

    Ultimately it’s up to you. Your hunches, experience, and probably a little experimentation will help you decide which method makes the most sense for you, your team, and your clients. But don’t be surprised if once you find a good system, you end up changing it down the road. As a business grows and evolves, the systems that work for it can, too.

    Now that we’ve talked about pricing methods, we’re ready to move on to something everyone’s really bad at: estimating! Stay tuned for that in part three of this series.

  • This week's sponsor: Pantheon 

    Thanks to Pantheon for sponsoring A List Apart this week—check out their free guide for scaling your digital agency.

  • UX for the Enterprise 

    Imagine this scenario. You’re hired to design a product that has a guaranteed audience of 50,000 users, right out of the gate. Your clients have a dedicated support staff with a completely predictable technology stack. Best of all, your work directly improves the quality of your users’ lives.

    That’s enterprise UX.

    Yes, those 50,000 people use your software because they don’t have a choice. And sure, that completely predictable technology stack is ten years out-of-date. But, despite its quirks, doing UX work for enterprise clients is an opportunity to spread good design to the industries that need it most.

    Enterprise UX is a catch-all term for work done for internal tools—software that’s used by employees, not consumers. Examples include:

    • HR portals
    • Inventory tracking apps
    • Content management systems
    • Intranet sites
    • Proprietary enterprise software

    Since switching from working with smaller clients to tackling the problems of the Fortune 500, I’ve fielded a lot of questions from designers mystified by my decision. Why choose to specialize in enterprise design when you could do more interesting work in leaner, more agile, t-shirt-friendly companies? Isn’t big business antithetical to design culture?

    The answer is: yes, often. Working with enterprise clients can be an exercise in frustration, filled with endless meetings and labyrinthine bureaucracy. It can also be immensely rewarding, with unique challenges and creatively satisfying work. As designers, we live to solve problems, and few problems are larger than those lurking in the inner depths of a global organization. After all, Fortune 500s tend to have a “just get it done” attitude toward internal tools, resulting in user experiences that aren’t well designed or tested. By giving those tools the same attention to experience that you give consumer-facing products, you can improve the lives of your users and support the organization’s values and brand.

    Why bother with enterprise work?

    Enterprise UX is often about solving ancillary problems by creating tools that facilitate an organization’s primary goals. These problems are rarely as compelling or visible as the goals they support, but they’re just as necessary to solve. A company might build the best-designed cars in the world, but it won’t matter if its quality-assurance process is hobbled by unusable software. Good design enables enterprises to do the work they were founded to do.

    Enterprise employees are also consumers, and they’ve come to expect consumer-level design in all the tools they use. Why shouldn’t a company’s inventory software or HR portal be as polished as Evernote, Pinterest, or Instagram? When a consumer app is poorly designed, the user can delete it. When an enterprise app is poorly designed, its users are stuck with it.

    The stakes can be enormously high. The sheer scale of enterprise clients magnifies the effects of good and bad design alike. Small inefficiencies in large organizations result in extra costs that are passed on to the end user in time spent, money lost, and frustration increased. Likewise, when an enterprise prioritizes user experience for its internal tools, it becomes a more effective organization; a recently released business index shows that design-driven companies outperformed the S&P average by 228% over the last ten years.

    A perfect example of the business value of enterprise UX is found in the article, “Calculating ROI on UX & Usability Projects”:

    …if you optimize the UX on a series of screens so that what was once a 5 minute task is now a 2.5 minute task, then you’ve increased a person’s productivity by 100%. That’s huge. HUGE. If the company has 100 phone agents who have an average salary of $40,000 + benefits (~$8,000) (+ an unknown amount for overhead), you could either release or retask those agents on other activities with a savings of $2,400,000/year. (half of 100 agents x $48,000).

    It’s simplified, but the point is dead-on. A company with 100 phone agents could result in millions of dollars of savings. Imagine the impact on a company with thousands of employees? Or tens of thousands?

    We have an opportunity to set the tone in some of the largest industries on the planet. Many big organizations have been defined by engineering and business thinking, with any design being either incidental or unintentional. Now, as those companies wake up to the value of solid design, they have to contend with the years of cruft that have obscured their tools and processes. Design is essential to shedding the excess and building better, leaner, and more human organizations.

    Working on enterprise projects

    There’s no such thing as an average enterprise UX project. The variety of projects within even a single company can be dizzying. I’ve worked on sites with a million visitors in the first week, and apps that fewer than 12 people use in a year.

    Projects that would be iterative in the consumer space may be a one-off in the enterprise space, so it’s crucial to get things right the first time around. Further, due to cost, culture, and the immense hassle of rolling out updates to tens of thousands of employees, enterprise clients are often bogged down with wildly out-of-date solutions. We’ve heard of huge companies begging Microsoft to extend the lifespan of Windows XP; that’s the rule, not the exception.

    Designing internal tools for a Fortune 500 company requires adaptation, but it isn’t a seismic shift from the world of consumer-facing design. Though a set of universal rules governing enterprise UX might not exist, there are a few principles I wish I’d known when transitioning from working with smaller clients.

    Design for the end user, not the client

    As with many design jobs, the end users of your software probably aren’t the same people who commissioned it.

    In large organizations, the divide between the user and the client can be vast. The director of operations might commission an inventory app for warehouse personnel, or someone from IT might commission a reporting tool for the sales team. In an enterprise-scale bureaucracy, the clients in charge of UX projects are often in higher-level management roles. And while they typically have an invaluable grasp of the big picture, they may not completely realize the everyday needs of the people who will use the software.

    Conduct your stakeholder interviews to understand and agree on your client’s business goals, but don’t forget to gather user and empirical data too. Fortunately, that type of research is easier to do in an enterprise setting than in the consumer space. Corporations like to quantify things, so data on productivity and software use may already exist. And, unlike consumers who need an incentive to fill out a survey or participate in an usability study, enterprise users have an inherent investment in the end product—setting aside some time to answer your questions is part of their job.

    A successful enterprise UX project considers the users’ needs, the clients’ goals, and the organization’s priorities. The best user experience sits at the intersection of these concerns.

    Be an educator and advocate, but above all, be flexible

    Being a designer is as much a consultative role as a practical one; to justify our design decisions, we need to explain to clients our guiding principles and teach them the basics of good user experience. Otherwise, we’re nothing more than pixel-pushers.

    Most enterprise clients have their own procurement procedures and project management techniques that don’t jive with a healthy UX workflow. Designers often find themselves needing to shoehorn their process into an existing structure, an exercise which can be frustrating if not approached properly.

    I was recently involved in redesigning a section of a large corporation’s website. My team was responsible for handling the visual design—the content was set, and a development partner had already been hired.

    Ordinarily, we prefer to have plenty of overlap between the design and development phases, to ensure that the live site matches the intentions of the design. However, the tight deadline and the client’s existing workflow made this impossible. Instead, we handed off the final mock-ups to the developers and hoped that everything was implemented without a hitch.

    We didn’t see the site again until a week before launch. Predictably, the soon-to-be-live site had numerous inconsistencies. Issues that would have been obvious with a glance from a designer—incorrect fonts, uneven margins, wrong colors—were left until the last minute to fix. The process provided ample room for the developers to do quality control (remember that ancient tech stack?), but not the designers.

    We wrote a list of crucial changes, ordered by priority, to bring the site in line with our design and the client’s goals. Many items were fixed before launch, and the client fast-tracked a second iteration to fix the rest. But none of those design issues would have launched in the first place had we insisted on more interaction between the designers and developers. Some good did come out of this challenge: we recommended the client reevaluate their design/development workflow requirements, explaining why the two processes needed to overlap. We also examined our own workflow to figure out how to make it more accommodating to the peculiarities of enterprise work—adding a postmortem phase, for instance, enables us to give feedback to a third-party developer while maintaining a tight timeline. If we were asking our clients to be flexible, we needed to be flexible too. Sure enough, the client offered us a greater opportunity to set the terms of the process on the next project.

    Needing to adapt to a new set of restrictions is an opportunity, not a hindrance. One of the most valuable things a designer can offer a large organization is insight into the design process and its importance. Design education and advocacy can extend beyond a single project, giving the client an understanding of how to better accommodate design thinking within the organization.

    Learn the culture, speak the language

    Designing internal tools for an organization requires an understanding of that organization’s culture, from the basic mindset to the quirks that make it unique.

    Corporate clients are often forced into short-term thinking, which can make it difficult to push longer-term design goals. When dealing with enterprise clients, remember their priorities: meeting a quota by the end of the quarter, exhausting a budget so they can secure the same amount next year, or improving a metric to keep the boss happy. Corporate clients are less concerned with design trends or UX best practices—they just want something that works for them. It’s best to frame design decisions around the client’s goals to sell them on your thinking.

    Of course, that’s easier said than done. It isn’t always obvious what the client cares about. Plenty of organizations pay lip service to values that haven’t really permeated the culture, making it hard to know what to aim for in the design process. It’s amazing how many enterprises describe themselves as “design-focused” or “innovation-driven” without anyone below the C-suite knowing what those terms mean.

    So how do we figure out what an enterprise client is really about?

    It takes some time, but one of the best ways is to pay attention to the language your clients use. Different organizations have different vocabularies, which reveal the way they think. You’ll likely encounter jargon, but your job is to listen—and help your clients translate that language into actionable goals. Do employees talk about “circling back” or “talking about this offline”? Structured communication may be important to that company. How about “value-add” or “low-hanging fruit”? Quick wins and return-on-investment are probably cornerstones of that organization’s culture.

    No client wants to learn design lingo just to be able to communicate with you, and corporate clients in particular are busy with a million other things. Learn their language so they don’t have to learn yours.

    Go ahead

    We designers live to solve problems, and enterprise organizations provide fertile ground. They present a different set of constraints than startups and smaller clients, and while some designers balk at the idea of their work being constricted by a bureaucracy, others remember that the best design flourishes within well-defined boundaries.

    Working on enterprise projects is something every UX designer should try. Who knows? You may just like it enough to stay.

  • Cultivating the Next Generation of Web Professionals 

    I’ve spent most of my career at institutions of higher education, and during that time, I have had the good fortune to work with several incredible students. Former interns are now LinkedIn connections working for television shows, book publishers, major websites, ad agencies, and PR firms, and the list of job titles and employers makes me proud. Along the way, I tried to give them interesting projects (when available), enthusiastic references (when merited), and helpful career advice (when requested).

    And despite their success, I feel like I fell short. I could have offered more to them.

    Mentoring opportunities, after all, aren’t limited to internships and official programs. There is a lot that we as individuals can do to serve as role models, ambassadors, and teachers to the web professionals of tomorrow.

    Skillsets will evolve and technologies will come and go, but we can create the digital experiences of the future today through the values and attitudes we instill in the next generation of web workers.

    Finding new layers of learning

    The web has matured significantly since it hijacked my career path back in college, and so have our understanding of and attitudes toward it. “Doing it right” calls for strategic skills like testing, measurement, and planning; interpersonal skills like negotiation, leadership, and collaboration; and technical skills in writing, coding, or design.

    But has the education of the next generation of web professionals matured accordingly? How much are they learning bricklaying versus architecture? This isn’t meant to be a condemnation of curriculums at colleges and universities, where we are beginning to see more courses, certificates, and even degree programs that reflect this approach. This is more an acknowledgement of the new nature of education nowadays—experiential, fluid, occasionally roundabout, and highly networked.

    We often talk about how the success of our work is determined by the strength of our relationships and our ability to work with people. This is what Jonathan Kahn has been talking about and working on with the Dare Conference. We need to extend that way of thinking to the relationships we build with each other, and, in particular, with the future professionals who will one day take our place at the client’s table.

    I’ve always cherished the thoughtfulness that our industry regularly displays, and how, despite serious concerns about sexism, diversity, and harassment, there is an overriding sense of justice and support. Within our profession, we have built a special community. Since our future colleagues are among these students, let’s welcome them into it.

    Bring your experience back to the classroom

    Future web professionals require connections to peers and leaders in the field and to enhanced learning experiences. We can build those connections by meeting students where they are: in their classrooms. What undergraduate or graduate programs offered in your area align with your skillset? Reach out to the relevant faculty—in journalism, public relations, computer science, human-computer interaction, graphic design, technical writing, and other departments—to see if they are looking for guest speakers.

    Brand and content strategist Margot Bloomstein has spoken to undergraduate classes about a half-dozen times, and invited top names in the field to speak to her own content strategy class at Columbia University. My Meet Content partner-in-crime, Rick Allen, teaches a course at Emerson College in Boston on electronic publishing, and he’s been kind enough to invite me to speak to his graduate students twice (and sometimes I think the experience is more rewarding for me than for them!).

    You can also reach out directly to college career centers. Amanda Costello, a content strategist at the University of Minnesota, has had success with this approach, working with them to organize and promote events where she can talk about her work with students who may have an interest in a web profession.

    If you catch the bug after a guest-lecturing stint, reach out to those programs or your local community college to see if they are looking for new adjunct faculty, and teach your own course. It’s a huge time commitment, to be sure, but teaching is a great way to approach your work with fresh eyes and maybe realize a thing or two you didn’t know before—while sharing your knowledge with an eager audience.

    Expand learning opportunities off-campus

    Invite students to the next local industry event. Hackathon? Content strategy meetup? UX book club? It’s all good. Work with professors teaching relevant courses to see if their students can get extra credit for attending, or maybe host a “student night” of lightning talks where they can talk about their research or perspectives on the field so far. Similar to Costello’s approach, send information about your professional networking event directly to career centers so they can promote it to students who may be interested.

    We can also make powerful connections outside the construct of a university setting. Karen McGrane recently wrote about how she pays forward the 30 minutes an academic whose name she can’t even recall gave her that helped steer her toward a graduate program and, eventually, a career.

    With that post echoing in my mind, I recently agreed to meet with a young woman who reached out to me via Twitter. She was intrigued by my job title, curious about how I got to where I am, and wondering what her next steps might be. We closed our 30-minute conversation over coffee on an Au Bon Pain patio with me promising to connect her to a former intern of mine, whom I had counseled as she struggled to find her place postgraduation and watched as she emerged confident with a rewarding job in her chosen field.

    I don’t know if that connection will help her, or if anything I said in those 30 minutes made sense, but if nothing else, I know that I helped reassure her that there are people in the industry who are willing to meet a complete stranger for 30 minutes on a Tuesday and talk shop. For someone just starting out professionally and looking to find her place, that’s significant.

    Make conferences more accessible for young attendees

    We are lucky to work in an industry with several opportunities for professional development, events where we can gather in person and learn from each other. We need to work harder to bring college students into this fold. There are two main obstacles: awareness and budget.

    Building the pathways to make students aware of conference opportunities (both for presenting and attending) is doable over time, but a tougher problem to solve is budget. The average college junior does not have the resources to pay a conference fee, let alone airfare and hotel. Within a university, a student may receive funding from the provost’s office or a dean’s special-projects fund to attend an academic conference. But what about professional events?

    As sponsorship dollars fly fast and furious around various events, let’s consider the possibility of offering scholarships to select student attendees or a discounted student rate, as some conferences (like An Event Apart) already do. In this vein, for two years running, Facebook has sponsored content strategy fellowships that fund three students’ attendance at the annual Confab Central content strategy conference, in addition to extending an opportunity to apply for a content strategy internship with the social-networking giant. Some conferences, like UXPA, organize a student volunteer program that helps staff the conference while providing a free conference experience (complete with networking opportunities) in return. If sponsorships and scholarships aren’t possible, conferences should work with colleges to allow attendance at events relevant to a student’s major to count as course credit.

    But what about taking that a step further and creating a professional development experience just for students? Two such initiatives are currently underway. One is the Center Centre at the Unicorn Institute, a user experience design-focused education project spearheaded by Jared Spool and Leslie Jensen-Inman. Also, the HighEdWeb conference has introduced the CrowdSource Summit, a sub-conference geared toward college students with the stated goal of providing them with a multidisciplinary, human perspective on web professions. (Full disclosure: I spoke at CrowdSource Summit in October.)

    While attendance is great, presenting is even better. In helping to organize Confab Higher Ed for the past two years, I am particularly proud of the fact that we have included sessions that feature not only student-generated communications efforts, but also teams with student copresenters. And offering those opportunities can yield results. Recently, I learned that one of last year’s student speakers, RIT’s Erin Supinka, landed a job as a social media manager at Dartmouth in part thanks to the recommendation of Dartmouth content strategist Sarah Maxell Crosby, who attended Supinka’s session. I hope to see this trend continue, and be echoed at other conferences.

    This increased access for students would have to go hand in hand with making conferences’ social activities less focused around drinking and creating more all-ages social events. A List Apart technical editor and front-end developer Anna Debenham recently wrote about this on the ALA blog, observing that all of the efforts I’ve outlined here would be for naught if we don’t address the social component as well. “The more young people we encourage to join the fold, the more we are excluding from these events,” she observed. (Debenham has even crafted some handy guidelines for event organizers.)

    Expand your interns’ horizons

    If you have interns at your company, don’t limit their involvement to tasks like research, answering emails, or bug fixes. Get them invested in the culture of your organization by discussing clients, projects, process, deliverables, and industry trends and challenges with them. Let them sit in on a kickoff meeting, client pitch, or deliverables presentation, and encourage them to share their ideas in whatever way is most appropriate. Earlier this year, Jim Ross wrote for UX Matters not only about how interns can get the most out of their opportunity, but also how companies can give interns enlightening, productive work experiences. The Boston-based web design firm Upstatement offers a development apprenticeship that seems like it would be one such position.

    The other day, I sat in on a weekly status call with a client. Our project manager called in our co-op student who had worked on a landing page design and asked her to explain to the client the different options and the reasoning behind them. The PM could have easily summarized the work, but instead she asked our co-op to represent her own work—which, I might add, the client liked.

    In addition, have interns talk to people in roles that are distinct from their skillset or comfort zone—programmers, project managers, IAs, UX specialists, content strategists, designers, you name it. These mini job-shadowing opportunities will help establish a well-rounded approach to web work.

    A couple of years ago, I wrote for Meet Content about how student workers can help support content strategy work (both from the staff perspective as the one managing the students and assigning them work, and from the student perspective of someone thinking about a career path and looking for paid work that will help advance them along). Last year, a design intern at Fastspot wrote glowingly on the company’s blog about how deeply involved she became in the agency’s process while working there. It’s within these purposeful, immersive early work experiences that students discover their true callings as professionals—as well as the things they don’t like, which is important too.

    Building the future

    In a 2010 HighEdWeb presentation, Dylan Wilbanks (then at the University of Washington) exhorted the audience not to let the politics of higher ed beat them down and make them bitter. “Love the web, love higher ed, love people,” he implored us.

    In thinking about the importance of mentorship, I am drawn back to Wilbanks’s words. We may love the work that we do, yes, but we also love our field and the people within it. This love is why I care about what not only the web will look like in five, 10, 20 years, but also our profession and our community.

    In an August post on The Pastry Box Project, Brad Frost reminded us of the importance in remaining self-aware as professionals, always asking ourselves why we do what we do and not just getting dragged along by the act of doing. “Understanding why we enjoy doing what we do better prepares us for whatever the future has in store,” he wrote. In short, we need to actively give a damn.

    The more we openly communicate about what drives us, the better off we, our colleagues, and our future colleagues will be. We use forums like this to debate and evolve our understanding both of the web and of ourselves as professionals, to everyone’s benefit.

    By the same token, because we care so damned much, we should be similarly engaged with the next wave of web professionals. We should work to cultivate their senses of passion and exploration, and their appreciation of a well-rounded approach to web work, so they can take the web places we’ve never dreamed it could go. Now that’s being future friendly.

  • Rachel Andrew on the Business of Web Dev: Managing Feature Requests 

    I started my business as a web development consultancy, building sites for clients. As we have moved to become a product company since launching Perch, we’ve had to learn many things. Not least of those has been how to manage feature requests when the “owners” of what you are building number in the thousands rather than a single client.

    When you are building a site for a client, and they ask for a feature that will be complicated or time-consuming to build, or make the UI harder to use, you can push back on it. If they then insist on the addition and are happy to pay for it, you build it. After all, it’s their project. If it adds extra complexity, they are the ones who have to live with it.

    With a product used out of the box by thousands of customers, adding every suggestion is impossible. What seems intuitive to one user baffles another. Adding too many tiny features aimed at meeting very exact requirements soon leads to a complex and confusing UI and adds to the time it takes to get up to speed on the product. This is especially important with my own product, as one of our core values is simplicity. In this column I outline some of the key things we have learned while adding features to Perch over the last five and a half years.

    What problem are you trying to solve?

    People will tend to make very precise feature requests. What they are doing is offering a solution, rather than explaining a problem. Most developers will be familiar with being asked if they can “just add a button here” with no thought to the underlying requirements of that option. When you have a product, you can expect many such requests every day.

    Customers aren’t spending their spare time dreaming up ideas for your product. They ask for a feature because their project has a requirement, and so will propose a solution based on their use case at that time. To get past the specific, you need to get to the problem that the user is having. What are they trying to achieve by way of the solution they have proposed? By asking those questions you can find out the real need, and sometimes you can help them solve it right away, without having to add an extra feature.

    Moving from the specific to the general

    Once you have a problem outlined, and you have discovered the use case of something that is not possible or is only partly possible in your product, what should you do? It’s tempting to jump in and start coding, especially in the early days of a product. You start to worry. A customer has identified somewhere your product is lacking, what if they go away? At this point you need to put that anxiety to one side, and rather than react by immediately starting to code the new feature, decide how any addition fits into the goals for the product and the needs of the majority of customers.

    It is likely that if you have managed to define a more general use case, other people will have similar requirements. If you don’t know what those are yet, then add the feature to a list for consideration. At Perch many feature requests sit in our backlog as we collect more requests for similar features. We can then try and develop a feature that will solve the more general problem. It might be very different to the specific solutions suggested by those customers, but it solves problems they have all experienced.

    What will make the most difference to the most people?

    If you have a popular product, it is easy to feel overwhelmed by feature requests. What do you do when you have a large number of valid requests that you agree would be great additions? It can feel as if whatever you do you will let someone down.

    Sometimes feature requests have a natural order of dependencies—you need to add one feature to enable something else. However, quite often you can find yourself with a backlog of equally interesting, sought-after features. Which to develop first? I tend to make that call based on which of these features would help out the most customers. This approach also gives you a good response to the vocal proponent of a feature that is of use only to a few customers. You can explain that you are ordering requests based on the number of people who need the feature.

    Build for your “ideal”—not your noisiest—customers

    In particular, I want to build features useful to those customers who fit our “ideal customer” profile. Perch has always been aimed at the professional designer and developer market. It assumes, for example, that the person building the site knows how to write HTML. We have a significant number of people, however, who dearly wish to use Perch, but who are tied to a WYSIWYG website building tool and believe Perch should support that. They can be very vocal about their disappointment that we will not build tools into Perch for “non-coders,” implying that we are wrong in turning away all of this business.

    Supporting these customers through the software would make Perch a very different tool, one that would be far less appealing to the front-end developer and web designer audience we serve. When considering feature requests, we always come back to that audience. Which of these features would make the most difference to the most people in that group?

    Only 25 percent of people with a Perch license ever raise a support ticket or post to the forum. Only 10 percent do so more than once. The majority of our customers are happily using the product and buying licenses for new sites without ever speaking to us. Be careful to seek out the opinions of the happy majority—don’t move your product away from something they love and find useful due to a few noisy people.

    Be willing to say no

    While every feature should be considered, logged, and grouped with other similar requirements, it is important to remember that sometimes you do need to say no. The product needs to be owned by someone, a person or a team with the ability to decide that a feature shouldn’t be added.

    Keep in mind the core problems your product sets out to solve and the profile of your target customers when making decisions about features. By doing so, you create a filter for new ideas, and also a way of explaining your decisions to customers who may feel disappointed in your choice.

    Realize you are not your customer

    Like so many other products that have been launched by consultancies, we built Perch to scratch our own itch. Version 1 was very much the product we needed: a product for people who cared about web standards and structured content. We then had to be willing to learn from feedback. We had to accept that some of the things we thought we should decline were real requirements for the people we felt were an ideal fit for the product.

    I believe software should be opinionated. We continue to promote best practices and modern web standards through the implementation of our product. We do this even when those values aren’t seen as important by many of our customers, as they really are the heart of the product. By keeping those core values in mind, digging down to the problems rather than accepting the first solution, and listening to our key customers, we continue to move forward while maintaining the simplicity we aimed for at the start.

  • That Pixel Design is so Hot Right Now 

    There’s a certain comfort, and often inherent cool, in things categorized as “retro.” A ’69 Ford Mustang. A greaser pompadour. Betty White. Pixel design.

    It’s no secret that pixel art is experiencing a resurgence in the digital form by way of video games like Mojang’s Minecraft and Superbrothers’ Sword & Sworcery. The latter game afforded me some inspiration; from what I was seeing online, the style of pixel art it brought to the masses—and popularized in the tangible realm by artists like Michael Myers from drawsgood—increasingly defined the style, and constraints, pixel art was created under. “Ever wonder what the Star Wars characters would look like pixelized?” Elongated single-pixel limbs, very stylized body shape. “[x designer] shows us what The Avengers would look like in pixel form!” Elongated single-pixel limbs, very stylized body shape.

    This got me to thinking of the varied styles and creations of pixel desktop icons from the mid ’90s. During that timeframe, customizing your Mac’s interface was easy and open, and doing so spoke as much to personalization as it did to thumbing your nose at the beige PC towers that defined the norm. While control panels such as Kaleidoscope quickly skinned your entire UI with a single click, some of us dove into desktop iconography, crafting pixel-based mini-mosaics under ridiculous constraints: 256 colors on a 32x32 grid, made in the resource editing app ResEdit.

    The lost medium of pixel art

    If you’re under 30, you’re likely unaware of, or have very finite exposure to, the origins of pixel-based desktop icon design.

    ResEdit itself was rudimentary, yet incredibly robust. Last officially released by Apple in 1994, it was primarily a tool for developers to create and edit resources in the resource fork architecture Macs used to rely on. One such resource, “ICON,” was our focus. Pixel by pixel, we employed common practices as the means to incredibly disparate stylistic ends:

    • Manually dithering via finite tonal variations to simulate depth
    • Stacking pixel units of a shape’s outline conservatively, to avoid “jaggies” and smooth edges
    • Faux anti-aliasing of harsh edges via the six available non-alpha-transparent grey swatches

    From system-level icons to household objects to movie characters to original creations, a varied community of creators crafted downloadable icons that graced the desktops of millions of users the world over.

    With time, nostalgia and grey hairs increase in tandem. To the former, I had a thought: get the band back together.

    Eight icon examples from the 1990s
    1990s desktop icons at scale, and zoomed 400 percent. From left to right, by: Mathew Halpern, Justin Dauer, How Bowers, Brian Brasher, Gedeon Maheux, Ian Harrington, Søren Karstensen, Ilona Melis.

    In a world where icons were king…

    And lo, this is how The Dead Pixel Society came into being: a global collection of ’90s-era icon designers, reunited. We agreed on the general idea for what we wanted to accomplish pretty quickly: to create under the same archaic constraints. But what was our theme? A specific movie or TV show? Too limiting for all participants’ tastes. Finally, considering our “retro medium,” we arrived at an ultimate thought: what if we had still been designing icons all these years, and our tools had never evolved? What would those icons look like? This evolved into a mission statement:

    We as The Dead Pixel Society honor the humble pixel with icon creations we would have done had we continued designing these past 18 years, under the exact same archaic constraints: 256 colors, pixel-by-pixel, on a 32x32 canvas.

    Today, the first Dead Pixel Society collaborative gallery is complete and live, netting out at 72,704 pixels over 71 icons from 12 icon artists in three countries, created over the span of 90 days.

    Eight icon examples from 2014
    2014 Dead Pixel Society icons at scale, and zoomed 400 percent. From left to right, by: Mathew Halpern, Justin Dauer, How Bowers, Brian Brasher, Gedeon Maheux, Ian Harrington, Søren Karstensen, Ilona Melis.

    These icons aren’t just imitations—they’re a designer’s interpretation of the subject matter. Anyone can ⌘-C / ⌘-V a JPG into Photoshop, switch the color mode to Indexed, and call it a day. Free-handing original subject matter—or externally referencing source material—evolves the process from replication into illustration. Take Mathew Halpern’s “Grumpy Cat” icon, for example. His mastery of the medium is best appreciated via this speed art video, and gives a sense of how insanely iterative pixel-icon design is:

    Sharpen your pencil tool and join us

    The first Dead Pixel Society project was a litmus test: “Is this possible?” Can this finite group of icon designers come together, create new icons under near 20-year-old constraints, hit a deadline, and do good work—all in their spare time? It could have very much failed.

    Instead, they focused, shook off the rust, and—via Photoshop’s “Mac OS” color palette—once again crafted pure pixel perfection. Within a couple hours of launch, Apple icon designer Louie Mantia created a pixel version of his Garage Band icon. Tweets came in from around the world with dedications, creations, and the echoing of a desire to submit to the gallery.

    Which brings me to the next Dead Pixel Society collaboration (DPS2: Electric Pixealoo): “Versus.” That’s where you come in. For this theme, we’re opening the doors to new designers, and exploring multiple versions of a single icon. For example, how would my take on a Steve Jobs icon look versus Gedeon Maheux’s? (Spoiler: mine would be shittier).

    It takes some time getting adjusted to what you’re quite literally boxed into, so now’s the time to start acclimating to pixel claustrophobia. If you’re a seasoned pixel artist, the finite color palette and size constraints could prove an interesting challenge. Perhaps you’re a vector-focused icon designer; switching from bezels and paths to manual dithering and faux anti-aliasing may tickle your fancy.

    For more background to it all (spoken with silky-smooth voices, no less), direct your ears to The Big Web Show No. 121. While the contextual derivation of this iteration of pixel design is Grunge-era Mac desktop icons, the draw is the limitations—and blowing them out of the water. It’s about collaboration, and being humbled by the abilities of your peers.

    Creative outlets and passion projects like The Dead Pixel Society help us avoid burnout. They energize and refuel us. As we formalize round two, we would love to have you be part of it.

  • The $PATH to Enlightenment 

    Open source software always involves a bit of tedious setup. While it may seem like it distracts from the end goal (solving problems using the tools), the setup process is often an opportunity to get more comfortable with one of the main tools of our trade: the command line.

    The command line is inherently spooky to many people—it’s the arcane technology wielded by “hackers” and “computer wizards” in popular culture. In reality, though, it isn’t that cool. It’s a set of ridiculously simple tools created by Bell (now AT&T) employees to accomplish mostly simple tasks in the 1970s. It’s about as “space-age” as your microwave oven.

    It’s also extremely useful—like going from building a house by hand to using power tools. And through a few concepts and metaphors, we can shine a light on the darkest corners of this command line.

    One of the most important of these concepts is the Path.

    Several front-end frameworks, CSS preprocessors, JavaScript libraries, and other web development tools rely on either Ruby or Node.js being installed on your machine. Bower is one such tool. Invariably, these tools will lead you to interact with the Path. That’s because the Path will need to be aware of all the tools you install for your development environment in order for your command line to function properly.

    Understanding how the Path works may feel like a step backward, but the more often you use command-line tools, the greater the chances the Path will cause you problems. Before you lose hours of your day—or start throwing heavy things at your screen—let’s walk through the basics of using the Path.

    A humble little variable

    $PATH, as denoted by the dollar-sign prefix and the shouty uppercase, is a Unix environment variable. What is stored inside this variable is a colon-delimited list of directory paths. Something like:

    /root/directory/binary:/root/other_directory/other_binary

    If you’re a variable-naming aficionado, you might wonder why it’s not named $PATHS, since it contains multiple paths. If I had to guess, the singular name probably refers to “the load path composed of multiple individual paths.” Let’s go with that.

    Now, if you’re curious which other kinds of environment variables exist on your system, you can type in the env command in your own command line prompt. Hit Enter and you will see a list of all the environment variables that currently exist.

    Since $PATH is a variable, it can be modified as you wish, on the fly. For instance, you could run this in your shell:

    $ export PATH=banana

    What does this do? Well, try to run the export command above in a new window inside your terminal or in whichever shell app you use, such as Terminal on OS X.

    Next, type any basic Unix command like ls (list directory contents). You’ll now see -bash: ls: command not found when ls used to work like a charm.

    This sneaky sabotage is useful because now we know that without the content inside our $PATH, shit just goes…bananas.

    But why? Because as many load paths do (including in programming languages and web frameworks like Rails), this Path determines what can be executed in your shell. If your shell can’t find anything to match the name you typed, it can’t run it.

    Oh, by the way, just quit and restart your shell application in order to restore all your commands. This was a temporary sabotage. Just be careful to never save this inside your ~/.bash_profile. That would be really bad.

    A tale of so many binaries

    In Unix, some executable programs are called binaries. That’s honestly a pretty poor name since it focuses on their format instead of their function. When you write a Unix program to accomplish a task, you sometimes need to compile its source code before it can be executed. This compiling process creates the binary. Instead of using plain text (like source code), these files use some binary format to make instructions easier for a computer to process.

    Unix comes with multiple directories in which to store binaries. You can see which directory is the default used to load binaries in the /etc/paths file.

    # the cat command can print the content of a file
    $ cat /etc/paths 
    /usr/bin 
    /bin 
    /usr/sbin 
    /sbin 
    /usr/local/bin

    The file contains one directory per line. The paths are listed in a meaningful order. When a binary is found in one path, it is loaded. If a binary with the same name is found in another path, it is ignored. Therefore, paths listed earlier take precedence over paths listed later.

    This is why it’s common to have problems when trying to install a binary for something that already exists on your system. In the case of OS X, if you try to install a different version of Git than the one that comes with the system, you’ll run into such an issue. That’s a bummer because Git 2.0 is really nice.

    If I cd (change directory) into /usr/bin—a common directory to store binaries—and run ls, I receive more than 1,000 results. That’s not really helpful. That said, if I use [grep](http://en.wikipedia.org/wiki/Grep) with ls | grep git instead, I can filter only the results of the ls command that contain git.

    $ ls | grep git 
    git
    git-cvsserver
    git-receive-pack
    git-shell 
    git-upload-archive 
    git-upload-pack

    Sure enough, there was a binary for Git inside of /usr/bin. A clean OS X installation should return /usr/bin/git when you run which git:

    $ which git 
    /usr/local/bin/git

    Why is mine different, then? We can have an even better idea of what’s going on by using the -a option when using which:

    $ which -a git
    /usr/bin/git
    /usr/local/bin/git

    This tells me that there are two versions of Git installed on my system. Only the first one is used when I execute git commands on my command line.

    Changing paths

    Using a package manager for OS X called Homebrew, I installed my own version of Git because I like to have control over the tools I use every day and update them when I feel like it. I could update the system-installed Git from OS X, but I have no idea what other binaries or apps depend on it.

    We saw that binary files are looked up depending on the order stored in a file called /etc/paths, so why not change that order?

    Inside of the /etc/paths file, I can see that the /usr/local/bin folder in which my Homebrew-installed version of Git is located comes last. This means the git binary inside /usr/bin will take precedence over it, and my fancy new version of Git will be ignored. That’s no good.

    Now, you could try to modify the order in /etc/paths so that it suits your needs by putting /usr/local/bin at the very top. The Homebrew-installed version of Git would then load first. But despite how many times you see this advice repeated in Stack Overflow discussions, don’t do it. Ever. Configurations stored in /etc/ affect the entire system. They’re not there to be changed by individual users (yes, even if you’re the only one using your machine), and you could very well cause some unforeseen issues by tinkering in there. For instance, some utility used by OS X could be relying on the original order of /etc/paths.

    Instead, you should modify the $PATH in your environment, using your .bash_profile—the one stored in /Users/yourusername/.bash_profile.

    All you need to do to ensure /usr/local/bin is looked into first is to include the following in your .bash_profile:

    # inside /Users/olivierlacan/.bash_profile
    export PATH=/usr/local/bin:$PATH

    This exports a new $PATH environment variable by printing the existing one and simply prepending the /usr/local/bin path on the left of all other paths. After you save your ~/.bash_profile and restart your shell, this is what you should see when you call echo on the $PATH:

    $ echo $PATH
    /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

    As you can see, /usr/local/bin is mentioned twice in the $PATH, and that’s fine. Since it’s mentioned first, all the binaries that will be loaded the first time around will be ignored when it is visited last. I honestly wish there were a safe and simple way to change the order of paths, but most solutions I’m aware of are a bit too complex. You could always override the default $PATH altogether, but that’s assuming you know exactly what you’re doing and what paths to include.

    A fork in the path

    Now that you’ve changed the $PATH to your liking, you can check that the proper binary is being called when you use the git command:

    $ which git 
    /usr/local/bin/git 
    
    $ git --version 
    git version 2.0.0
    /usr/bin/git --version git version 1.8.5.2 (Apple Git-48)

    There you go. Git 2.0.0 (the Homebrew-installed version) is now the one answering git commands, and the Apple-installed 1.8.5.2 version recedes in the background. If you’d rather not use git 2.0.0, you can simply uninstall it and the default version will take over seamlessly.

    Protect your path

    A host of utilities for developers (and designers) will automatically inject code into your .bash_profile upon installation. Often they don’t even mention it to you, so if you find odd paths listed in your profile, that may explain why loading a new session (which happens when you open a new shell window or tab) takes more time than it should: a bloated $PATH might take a while to load.

    Here’s my path today:

    /Users/olivierlacan/.rbenv/shims:/Users/olivierlacan/.rbenv/bin:/usr/local/bin:/usr/local/heroku/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/MacGPG2/bin

    It’s a little hard to read, so I tend to break it into lines. You can do this easily with the tr command (translate characters):

    $ echo $PATH | tr ':' '\n'
    /Users/olivierlacan/.rbenv/shims
    /Users/olivierlacan/.rbenv/bin
    /usr/local/bin
    /usr/local/heroku/bin
    /usr/bin
    /bin
    /usr/sbin
    /sbin
    /usr/local/bin
    /opt/X11/bin
    /usr/local/MacGPG2/bin

    There’s a lot of stuff going on here, but it’s much easier to understand with some verticality. Try it out, and if you don’t know why one of those lines is in your $PATH, make it your goal to figure it out. You might just learn something useful.

    Being more aware of your $PATH and how it functions may not seem like the most tangible piece of knowledge. Yet, as a web craftsperson you’ll likely have to interact with command line tools while you work—and someday, something may go wrong with one of these tools. Now that you know what your Path is, what it looks like when it’s clean, how to modify it properly, and how to check that it’s aware of your tools, there’s a good chance you’ll spend minutes instead of hours to get back on your own path: the one where you build things for people.

  • Responsive Images in Practice 
    The devil has put a penalty on all things we enjoy in life.
    Albert Einstein

    Sixty-two percent of the weight of the web is images, and we’re serving more image bytes every day. That would be peachy if all of those bytes were being put to good use. But on small or low-resolution screens, most of that data is waste.

    Why? Even though the web was designed to be accessed by everyone, via anything, it was only recently that the device landscape diversified enough to force an industry-wide movement toward responsive design. When we design responsively our content elegantly and efficiently flows into any device. All of our content, that is, except for bitmaps. Bitmap images are resolution-fixed. And their vessel—the venerable img with its sadly single src—affords no adaptation.

    Faced with a Sophie’s choice—whether to make their pages fuzzy for some or slow for all—most designers choose the latter, sending images meant to fill the largest, highest-resolution screens to everybody. Thus, waste.

    But! After three years of debate, a few new pieces of markup have emerged to solve the responsive images problem:

    • srcset
    • sizes
    • picture
    • and our old friend source (borrowed from audio and video)

    These new elements and attributes allow us to mark up multiple, alternate sources, and serve each client the source that suits it best. They’ve made their way into the official specs and their first full implementation—in Chrome 38—shipped in September. With elegant fallbacks and a polyfill to bridge the gap, we can and should implement responsive images now. So, let’s!

    Let’s take an existing web page and make its images responsive. We’ll do so in three passes, applying each piece of the new markup in turn:

    1. We’ll ensure that our images scale efficiently with srcset and sizes.
    2. We’ll art direct our images with picture and source media.
    3. We’ll supply an alternate image format using picture and source type.

    In the process we’ll see firsthand the dramatic performance gains that the new features enable.

    The status quo

    I guess I don’t so much mind being old, as I mind being fat and old.
    Benjamin Franklin (or was it Peter Gabriel?)

    We take as our subject a little web page about crazy quilts. It’s a simple, responsive page. There isn’t much to get in the way of its primary content: giant images (of quilts!). We want to show both the overall design of each quilt and as much intricate detail as possible. So, for each, we present two images:

    1. the whole quilt, fit to the paragraph width
    2. a detail that fills 100 percent of the viewport width

    How would we size and mark up our images without the new markup?

    First up: the whole quilts. To ensure that they’ll always look sharp, we need to figure out their largest-possible layout size. Here’s the relevant CSS:

    * {
    	box-sizing: border-box;
    }
    body {
    	font-size: 1.25em;
    }
    figure {
    	padding: 0 1em;
    	max-width: 33em;
    }
    img { 
    	display: block;
    	width: 100%;
    }

    We can calculate the img’s largest-possible display width by taking the figure’s max-width, subtracting its padding, and converting ems to pixels:

      100% <img> width
    x ( 33em <figure> max-width
       - 2em <figure> padding )
    x 1.25em <body> font-size
    x 16px default font-size
    = 620px

    Or, we can cheat by making the window really big and peeking at the dev tools:

    (I prefer the second method.)

    Either way we arrive at a maximum, full-quilt img display width of 620px. We’ll render our source images at twice that to accommodate 2x screens: 1,240 pixels wide.

    But what to do about our detail images? They expand to fill the whole viewport, whose size has no fixed upper limit. So let’s pick something big-ish with a standard-y feel to it and render them at oh, say, up to 1,920 pixels wide.

    When we render our images at those sizes our status-quo page weighs in at a hefty 3.5MB. All but 5.7kB of that is images. We can intuit that many of those image bytes constitute invisible overhead when delivered to small, low-resolution screens—but how many? Let’s get to work.

    First pass: scaling with scrset and sizes

    Teatherball with a tennis ball for his shoelaces

    Naturally adapt to have more than two faces

    Kool AD, Dum Diary

    The first problem we’ll tackle: getting our images to scale efficiently across varying viewport widths and screen resolutions. We’ll offer up multiple resolutions of our image, so that we can selectively send giant sources to giant and/or high-resolution screens and smaller versions to everyone else. How? With srcset.

    Here’s one of our full-viewport-width detail images:

    <img
    	src="quilt_2-detail.jpg"
    	alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />

    quilt_2-detail.jpg measures 1,920 pixels wide. Let’s render two smaller versions to go along with it and mark them up like so:

    <img
    	srcset="quilt_2/detail/large.jpg  1920w, 
    	        quilt_2/detail/medium.jpg  960w,
    	        quilt_2/detail/small.jpg   480w"
    	src="quilt_2/detail/medium.jpg"
    	alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork.">

    The first thing to note about this img is that it still has a src, which will load in browsers that don’t support the new syntax.

    For more capable clients, we’ve added something new: a srcset attribute, which contains a comma-separated list of resource URLs. After each URL we include a “width descriptor,” which specifies each image’s pixel width. Is your image 1024 x 768? Stick a 1024w after its URL in srcset. srcset-aware browsers use these pixel widths and everything else that they know about the current browsing environment to pick a source to load out of the set.

    How do they choose? Here’s my favorite thing about srcset: we don’t know! We can’t know. The picking logic has been left intentionally unspecified.

    The first proposed solutions to the responsive image problem attempted to give authors more control. We would be in charge, constructing exhaustive sets of media queries—contingency plans listing every combination of screen size and resolution, with a source custom-tailored for each.

    srcset saves us from ourselves. Fine-grained control is still available when we need it (more on that later), but most of the time we’re better off handing over the keys and letting the browser decide. Browsers have a wealth of knowledge about a person’s screen, viewport, connection, and preferences. By ceding control—by describing our images rather than prescribing specific sources for myriad destinations—we allow the browser to bring that knowledge to bear. We get better (future-friendly!) functionality from far less code.

    There is, however, a catch: picking a sensible source requires knowing the image’s layout size. But we can’t ask browsers to delay choosing until the page’s HTML, CSS, and JavaScript have all been loaded and parsed. So we need to give browsers an estimate of the image’s display width using another new attribute: sizes.

    How have I managed to hide this inconvenient truth from you until now? The detail images on our example page are a special case. They occupy the full width of the viewport—100vw—which just so happens to be the default sizes value. Our full-quilt images, however, are fit to the paragraph width and often occupy significantly less real estate. It behooves us to tell the browser exactly how wide they’ll be with sizes.

    sizes takes CSS lengths. So:

    sizes="100px"

    ...says to the browser: this image will display at a fixed width of 100px. Easy!

    Our example is more complex. While the quilt imgs are styled with a simple width: 100% rule, the figures that house them have a max-width of 33em.

    Luckily, sizes lets us do two things:

    1. It lets us supply multiple lengths in a comma-separated list.
    2. It lets us attach media conditions to lengths.

    Like this:

    sizes="(min-width: 33em) 33em, 100vw"

    That says: is the viewport wider than 33em? This image will be 33em wide. Otherwise, it’ll be 100vw.

    That’s close to what we need, but won’t quite cut it. The relative nature of ems makes our example tricky. Our page’s body has a font-size of 1.25em, so “1em” in the context of our figure’s CSS will be 1.25 x the browser’s default font size. But within media conditions (and therefore, within sizes), an em is always equal to the default font size. Some multiplication by 1.25 is in order: 1.25 x 33 = 41.25.

    sizes="(min-width: 41.25em) 41.25em,
           100vw"

    That captures the width of our quilts pretty well, and frankly, it’s probably good enough. It’s 100 percent acceptable for sizes to provide the browser with a rough estimate of the img’s layout width; often, trading a tiny amount of precision for big gains in readability and maintainability is the right choice. That said, let’s go ahead and make our example exact by factoring in the em of padding on either side of the figure: 2 sides x 1.25 media-condition-ems each = 2.5ems of padding to account for.

    <img 
    	srcset="quilt_3/large.jpg  1240w, 
    	        quilt_3/medium.jpg  620w,
    	        quilt_3/small.jpg   310w"
    	sizes="(min-width: 41.25em) 38.75em,
    	       calc(100vw - 2.5em)"
    	src="quilt_3/medium.jpg"
    	alt="A crazy quilt whose irregular fabric scraps are fit into a lattice of diamonds." />

    Let’s review what we’ve done here. We’ve supplied the browser with large, medium, and small versions of our image using srcset and given their pixel widths using w descriptors. And we’ve told the browser how much layout real estate the images will occupy via sizes.

    If this were a simple example, we could have given the browser a single CSS length like sizes="100px" or sizes="50vw". But we haven’t been so lucky. We had to give the browser two CSS lengths and state that the first length only applies when a certain media condition is true.

    Thankfully, all of that work wasn’t in vain. Using srcset and sizes, we’ve given the browser everything that it needs to pick a source. Once it knows the pixel widths of the sources and the layout width of the img, the browser calculates the ratio of source-to-layout width for each source. So, say sizes returns 620px. A 620w source would have 1x the img’s px. A 1240w source would have 2x. 310w? 0.5x. The browser figures out those ratios and then picks whichever source it pleases.

    It’s worth noting that the spec allows you to supply ratios directly and that sources without a descriptor get assigned a default ratio of 1x, allowing you to write markup like this:

    <img src="standard.jpg" srcset="retina.jpg 2x, super-retina.jpg 3x" />

    That’s a nice, compact way to supply hi-DPI imagery. But! It only works for fixed-width images. All of the images on our crazy-quilts page are fluid, so this is the last we’ll hear about x descriptors.

    Measuring up

    Now that we’ve rewritten our crazy-quilts page using srcset and sizes, what have we gained, in terms of performance?

    Our page’s weight is now (gloriously!) responsive to browsing conditions. It varies, so we can’t represent it with a single number. I reloaded the page a bunch in Chrome and charted its weight across a range of viewport widths:

    The flat, gray line up top represents the status-quo weight of 3.5MB. The thick (1x screen) and thin (2x) green lines represent the weight of our upgraded srcset’d and size’d page at every viewport width between 320px and 1280px.

    On 2x, 320px-wide screens, we’ve cut our page’s weight by two-thirds—before, the page totaled 3.5MB; now we’re only sending 1.1MB over the wire. On 320px, 1x screens, our page is less than a tenth the weight it once was: 306kB.

    From there, the byte sizes stair-step their way up as we load larger sources to fill larger viewports. On 2x devices we take a significant jump at viewport widths of ~350px and are back to the status-quo weight after 480px. On 1x screens, the savings are dramatic; we’re saving 70 to 80 percent of the original page’s weight until we pass 960px. There, we top out with a page that’s still ~40 percent smaller than what we started with.

    These sorts of reductions—40 percent, 70 percent, 90 percent—should stop you in your tracks. We’re trimming nearly two and a half megabytes off of every Retina iPhone load. Measure that in milliseconds or multiply it by thousands of pageviews, and you’ll see what all of the fuss is about.

    Second pass: picture and art direction

    srcset if you’re lazy, picture if you’re crazy™
    Mat Marquis

    So, for images that simply need to scale, we list our sources and their pixel widths in srcset, let the browser know how wide the img will display with sizes, and let go of our foolish desire for control. But! There will be times when we want to adapt our images in ways that go beyond scaling. When we do, we need to snatch some of that source-picking control right back. Enter picture.

    Our detail images have a wide aspect ratio: 16:9. On large screens they look great, but on a phone they’re tiny. The stitching and embroidery that the details should show off are too small to make out.

    It would be nice if we could “zoom in” on small screens, presenting a tighter, taller crop.

    This kind of thing—tailoring image content to fit specific environments—is called “art direction.” Any time we crop or otherwise alter an image to fit a breakpoint (rather than simply resizing the whole thing), we’re art directing.

    If we included zoomed-in crops in a srcset, there’s no telling when they’d get picked and when they wouldn’t. Using picture and source media, we can make our wishes explicit: only load the wide, rectangular crops when the viewport is wider than 36em. On smaller viewports, always load the squares.

    <picture>
    	<!-- 16:9 crop -->
    	<source
    		media="(min-width: 36em)"
    		srcset="quilt_2/detail/large.jpg  1920w,
    		        quilt_2/detail/medium.jpg  960w,
    		        quilt_2/detail/small.jpg   480w" />
    	<!-- square crop -->
    	<source
    		srcset="quilt_2/square/large.jpg  822w,
    		        quilt_2/square/medium.jpg 640w,
    		        quilt_2/square/small.jpg  320w" />
    	<img
    		src="quilt_2/detail/medium.jpg"
    		alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />
    </picture>

    A picture element contains any number of source elements and one img. The browser goes over the picture’s sources until it finds one whose media attribute matches the current environment. It sends that matching source’s srcset to the img, which is still the element that we “see” on the page.

    Here’s a simpler case:

    <picture>
    	<source media="(orientation: landscape)" srcset="landscape.jpg" />
    	<img src="portrait.jpg" alt="A rad wolf." />
    </picture>

    On landscape-oriented viewports, landscape.jpg is fed to the img. When we’re in portrait (or if the browser doesn’t support picture) the img is left untouched, and portrait.jpg loads.

    This behavior can be a little surprising if you’re used to audio and video. Unlike those elements, picture is an invisible wrapper: a magical span that’s simply feeding its img a srcset.

    Another way to frame it: the img isn’t a fallback. We’re progressively enhancing the img by wrapping it in a picture.

    In practice, this means that any styles that we want to apply to our rendered image need to be set on the img, not on the picture. picture { width: 100% } does nothing. picture > img { width: 100% } does what you want.

    Here’s our crazy-quilts page with that pattern applied throughout. Keeping in mind that our aim in employing picture was to supply small-screened users with more (and more useful) pixels, let’s see how the performance stacks up:

    Not bad! We’re sending a few more bytes to small 1x screens. But for somewhat complicated reasons having to do with the sizes of our source images, we’ve actually extended the range of screen sizes that see savings at 2x. The savings on our first-pass page stopped at 480px on 2x screens, but after our second pass, they continue until we hit 700px.

    Our page now loads faster and looks better on smaller devices. And we’re not done with it yet.

    Third pass: multiple formats with source type

    The 25-year history of the web has been dominated by two bitmap formats: JPEG and GIF. It took PNGs a painful decade to join that exclusive club. New formats like WebP and JPEG XR are knocking at the door, promising developers superior compression and offering useful features like alpha channels and lossless modes. But due to img’s sadly single src, adoption has been slow—developers need near-universal support for a format before they can deploy it. No longer. picture makes offering multiple formats easy by following the same source type pattern established by audio and video:

    <picture>
    	<source type="image/svg+xml" srcset="logo.svg" />
    	<img src="logo.png" alt="RadWolf, Inc." />
    </picture>

    If the browser supports a source’s type, it will send that source’s srcset to the img.

    That’s a straightforward example, but when we layer source type-switching on top of our existing crazy-quilts page, say, to add WebP support, things get hairy (and repetitive):

    <picture>
    	<!-- 16:9 crop -->
    	<source
    		type="image/webp"
    		media="(min-width: 36em)"
    		srcset="quilt_2/detail/large.webp  1920w,
    		        quilt_2/detail/medium.webp  960w,
    		        quilt_2/detail/small.webp   480w" />
    	<source
    		media="(min-width: 36em)"
    		srcset="quilt_2/detail/large.jpg  1920w,
    		        quilt_2/detail/medium.jpg  960w,
    		        quilt_2/detail/small.jpg   480w" />
    	<!-- square crop -->
    	<source
    		type="image/webp"
    		srcset="quilt_2/square/large.webp   822w,
    		        quilt_2/square/medium.webp  640w,
    		        quilt_2/square/small.webp   320w" />
    	<source
    		srcset="quilt_2/square/large.jpg   822w,
    		        quilt_2/square/medium.jpg  640w,
    		        quilt_2/square/small.jpg   320w" />
    	<img
    		src="quilt_2/detail/medium.jpg"
    		alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />
    </picture>

    That’s a lot of code for one image. And we’re dealing with a large number of files now too: 12! Three resolutions, two formats, and two crops per image really add up. Everything we’ve gained in performance and functionality has come at a price paid in complexity upfront and maintainability down the road.

    Automation is your friend; if your page is going to include massive code blocks referencing numerous alternate versions of an image, you’d do well to avoid authoring everything by hand.

    So is knowing when enough is enough. I’ve thrown every tool in the spec at our example. That will almost never be prudent. Huge gains can be had by employing any one of the new features in isolation, and you should take a long, hard look the complexities of layering them before whipping out your claw and committing to the kitchen sink.

    That said, let’s take a look at what WebP can do for our quilts.

    An additional 25 to 30 percent savings on top of everything we’ve already achieved—not just at the low end, but across the board—certainly isn’t anything to sneeze at! My methodology here is in no way rigorous; your WebP performance may vary. The point is: new formats that provide significant benefits versus the JPEG/GIF/PNG status quo are already here, and will continue to arrive. picture and source type lower the barrier to entry, paving the way for image-format innovation forevermore.

    size the day

    This is the secret of perfection:

    When raw wood is carved, it becomes a tool;

    [...]

    The perfect carpenter leaves no wood to be carved.

    27. Perfection, Tao Te Ching

    For years, we’ve known what’s been weighing down our responsive pages: images. Huge ones, specially catered to huge screens, which we’ve been sending to everyone. We’ve known how to fix this problem for a while too: let us send different sources to different clients. New markup allows us to do exactly that. srcset lets us offer multiple versions of an image to browsers, which, with a little help from sizes, pick the most appropriate source to load out of the bunch. picture and source let us step in and exert a bit more control, ensuring that certain sources will be picked based on either media queries or file type support.

    Together, these features let us mark up adaptable, flexible, responsive images. They let us send each of our users a source tailored to his or her device, enabling huge performance gains. Armed with a superb polyfill and an eye toward the future, developers should start using this markup now!

  • Ask Dr. Web with Jeffrey Zeldman: Help! My Portfolio Sucks 

    What if a lot of your past work reflects times when you satisfied the client, but couldn’t sell them on your best ideas? How do you build a portfolio out of choices you wouldn’t have made? Our very own Jeffrey Zeldman answers your toughest career questions.

    Dear Dr. Web: What do you do when you’re not proud of the work you’ve done for your clients, and don’t want it featured in your portfolio?
    My Shame

    Dear My,

    Everybody does some work they’re not proud of. Paula Scher and Jony Ive have had the occasional project that didn’t work out as hoped. Dieter Rams may have a thing he worked on that he cringes to think about today. Even Ethan Marcotte has some fixed-width, bandwidth-intensive sites on his resume. When I worked in advertising, creatives at lousy shops took shoddy delight in finding out about dull, bread-and-butter accounts the award-winners occasionally had to work on. We all do it. It’s part of making a living. Sometimes you just need a gig, so you take on a project for which you can deliver competence, but nothing more. Other times, you take on a job with high hopes—only to have those hopes dashed because you couldn’t sell your best idea to the client, or because the business was better served by a dull solution than by the groundbreaking one you hoped to put in your portfolio.

    I learned a thing or two about how to gracefully handle less-than-stellar projects from a friend who co-founded one of the leading boutique design consultancies of our age. At one time, this consultancy scooped up every challenging, high-profile strategic gig out there. After they delivered a handful of brilliant strategic bullet points for three-quarters of the client’s budget, my studio would come in—like the guys with brushes who follow the circus elephants—and do all the design, user experience, and front- and back-end coding work for what remained of the budget. Needless to say, I paid attention to how my highly paid strategist friends handled their business. (Rule Number One: don’t hate successful competitors; learn from them.)

    At one point my illustrious friends took on a design project helmed by another pal of mine, who was working at the client company. Let’s just say this one didn’t go as well as hoped. For one thing, my friend who was working on the client side redid their code and design work, which is something a client should never, ever, ever, ever do—and should never feel she has to do. The results were not pretty, and did not in any way reflect the client’s fond hopes or the consulting studio’s work or philosophy.

    So what did the consultants do when the project went live? Instead of featuring the gig in their portfolio, they had their team leader write about the project in their blog. Rather than the work they had done, he discussed the business challenges the client had faced, and explained their strategic approach to solving those problems. The team leader was extremely complimentary (and rightfully so) about the client’s place in its sphere of business. He spoke warmly of the client’s openness to bold ideas. There was no hint of disappointment, and there was also no dishonesty. My friend wrote about the things that had attracted his team to the gig, and left everyone with a nice, warm, vague feeling. And that’s how you handle a job that doesn’t work out to your satisfaction.

    We’ve done the same thing at Happy Cog once or twice, when the work we delivered—although it satisfied the client and did everything it was supposed to do—just wasn’t exciting enough to merit a portfolio showcase. So you write about the business challenges you solved. Or about some innovative coding you did. Or you just share how honored you were to work on behalf of a client who does such wonderful things in the world. (I’m assuming you’re not ashamed of your client, even if you weren’t able to reach new design heights on their project.)

    But there’s another part to your question—or, at least, I have a question about your question. It sounds like you’re not just unhappy with one or two projects you’ve worked on. It sounds like you’re unhappy with most of them.

    Now, that would be another problem entirely. As a designer, it’s not just your job to create something great. It’s also your job to sell that solution to the client. If you can’t do that, then you need to workshop your persuasion skills, just as you would workshop your CSS skills if they had gotten rusty. A designer must sell. That’s part of the work. A decent designer who can sell will have a better career—and do better work—than a brilliant designer who cannot. There are books out there that can help. Design Is a Job is a great one. A List Apart’s Rachel Andrew writes about the business of web development, and Mike Monteiro’s 13 Ways Designers Screw Up Client Presentations may help you stop doing things in presentations that unconsciously undercut your work and convince the client not to buy your best ideas.

    If deep-seated personality issues prevent you from selling—and you should only come to that conclusion after working at least a year to improve your selling ability—then find a partner who is good at it. They’re probably good at business development, too, and will almost certainly justify the percentage you pay them by improving your professional profile, finding you better clients, and helping you raise your pitifully low rates. (Designers who can’t sell always undercharge for their services. I know. I used to be one.)

    Countries and cultures factor in here, as well. There are some places in the world where the designer is always wrong, and the client is a dictator. That is changing everywhere, but change comes slowly in some places, and you may not want to be the evangelist who single-handedly fights to improve the position of all designers in your part of the world. If you live in such a place, consider moving, or find a way to raise your profile so that you can work remotely for a more enlightened class of client.

    Regardless of where you live, one important way to build a great portfolio is to work on open source or community-based projects. Side projects like Fonts In Use can build a designer’s reputation when the work she does for clients is less than satisfactory. I have never hired a designer who doesn’t have at least one interesting non-client project to show for herself, and I never will. When all else fails, create a killer blog. I started A List Apart because there was no magazine that approached web design the way I felt it should be approached, and to show what I could do when my first clients weren’t letting me do my best work.

    I’ll have more to say about side projects 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.

  • An Excellent Week 

    A couple of big announcements are making the rounds this week, both of them exciting for those of us who make web sites:

    Google advises progressive enhancement

    In a blog post explaining updates to its indexing system, Google makes it clear that they’re now parsing web pages in their entirety — not just HTML, but also CSS and JavaScript. Their indexer used to ignore layout and behave as if it were a text-only browser, but now it’s scanning fully rendered pages.

    This means a few things. First, make sure you’re not denying Googlebot access to directories that hold your CSS and JavaScript. Check your `robots.txt` file to make sure.

    Second, from Google’s post:

    Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.
    Pierre Far, Webmaster Trends Analyst

    (Emphasis mine. By the way, this support for progressive enhancement plays very nicely with their strong recommendation for responsive web design.)

    And third: Speed matters. We’ve known for a while that a fast-loading site makes for a better user experience, but with this update it also means Google’s indexing system now explicitly favors faster-loading sites over slower ones.

    How do your sites stack up?

    HTML5 is now an official standard

    After initially taunting us with a release date well into the next decade, W3C has published their official recommendation for HTML5, ending years of of often-frustrating, but productive development.

    Most of us have been using HTML5 for years already (Jeremy Keith published HTML5 For Web Designers in 2010), so this may seem like a small thing to celebrate. But now we can use elements with full confidence they won’t change, we may see quicker adoption by browser makers of all the exciting things HTML5 brings to the table, and any XHTML holdouts may finally be convinced that HTML5 is good to go.

    Let’s get out there.