Nov
21

Driving Phantom from Grunt

Source: A List Apart

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.


Read the full article

Nov
19

Destroying Your Enemies Through the Magic of Design

Source: A List Apart

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.


Read the full article

Nov
17

Big Picture or Detail Oriented? UX Requires Both!

Source: UXMatters

By Baruch Sachs

Published: November 17, 2014

“If you’re not able to analyze and focus on the right patterns, you’ll end up buried. If you focus on catching every little crisis before it touches the ground and festers, you’ll constantly be putting out fires. Neither of these outcomes is a good place to be….”

Autumn is a great time to be a New Englander. While autumnal beauty happens all over the world, New England is the place to be in the United States. Sitting on my back deck and looking at the forest behind my house is one of my favorite ways to get inspired. One day, as I was watching the leaves swirl and fall, I started thinking about user experience and consulting. Weird, I know, but as each leaf fell, I realized that, while each leaf seems small, enough of them will eventually cover the entire ground. If you rake too early, you will have to repeat the process multiple times. If you wait until every single leaf is off a tree, your job becomes that much harder. With leaves, this is a game every New Englander plays. When should you pay attention to them?
Big Picture or Detail Oriented? UX Requires Both!

Nov
17

Fundamental Principles of Great UX Design | How to Deliver Great UX Design

Source: UXMatters

By Janet M. Six

Published: November 17, 2014

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our expert panel looks at the importance of considering the fundamental principles of great design—not just UX design principles, but design principles in general. Our panel also discusses how great UX design takes place within organizations, looking at this topic on many different levels. How can you create great designs when working with a variety of designers with different backgrounds and while working within the constraints of project-defined goals? How can the presence of User Experience at the C-level and, in general, garnering support from the C-level affect our ability to implement great designs. How can we produce great designs in a repeatable manner? Keep reading for the answers to all of these important questions.
Fundamental Principles of Great UX Design | How to Deliver Great UX Design

Nov
17

The Making of a UX Designer

Source: UXMatters

By Traci Lepore

Published: November 17, 2014

“He who knows others is wise; he who knows himself is enlightened.”—Lao Tzu

“The most successful UX professionals aren’t just good at the basic skills that their profession requires. They are well-rounded, self-aware, empathetic, problem-solving beings. Mastery of these soft skills sets a person apart….”

My background is in graphic design, and I’m an artist by nature. I learned the basics of user experience on the ground, in the early days. While those experiences gave me the fundamental skills that I needed to do my work, they didn’t make me the empathetic and insightful designer I am today. I firmly believe that it is my training in acting and theater that has given me the ability to be, not just a good UX designer, but also a successful one.

What Theater Has Taught Me 

The most successful UX professionals aren’t just good at the basic skills that their profession requires. They are well-rounded, self-aware, empathetic, problem-solving beings. Mastery of these soft skills sets a person apart and makes the difference between being employable and being exceptional.
The Making of a UX Designer

Nov
17

About Face: The Essentials of Interaction Design

Source: UXMatters

By Alan Cooper, Robert Reimann, David Cronin, and Christopher Noessel

Published: November 17, 2014

This is a sample chapter from the 4th Edition of About Face: The Essentials of Interaction Design, by Alan Cooper, Robert Reimann, David Cronin, and Christopher Noessel.

Chapter 6: Creative Teamwork

“In design and business, teams are common, but rarely are they successful or productive.”

In the Introduction to this book, we described the Goal-Directed method as consisting of three p’s: principles, patterns, and processes. However, there’s a fourth p worth mentioning—practices. This book mostly concerns itself with the first three, but in this chapter we’d like to share a few thoughts about the practice of Goal-Directed design and how design teams integrate into the larger product team.
About Face: The Essentials of Interaction Design

Nov
17

Parallax Scrolling: Attention Getter or Headache?

Source: UXMatters

By Jacqueline Kyo Thomas

Published: November 17, 2014

“While parallax scrolling can be visually stunning and make a great first impression, it is also unexpectedly user hostile.”

Parallax scrolling is a popular Web design trend, but is it worthy of all the positive attention that it’s getting? While parallax scrolling can be visually stunning and make a great first impression, it is also unexpectedly user hostile. And the metrics for the most popular WordPress themes on Template Monster indicate that parallax scrolling isn’t as popular as one might expect. Let’s take a serious look at the pros and cons of parallax scrolling.
Parallax Scrolling: Attention Getter or Headache?

Nov
15

Knowledge vs. Intelligence

Source: A List Apart

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.


Read the full article

Nov
11

Overwhelmed by Code

Source: A List Apart

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.


Read the full article

Nov
05

Why Responsive Images Matter

Source: A List Apart

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 600×800,” 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.


Read the full article

Older posts «