Reboot Heroku as Last Step After Pushing

A computing tip from my friend and WordPress web engineer extraordinaire Chris Marslender.

When pushing code to a Heroku app, make the last step be an action to reboot the app, with something like Hubot. So any time code changes, the server restarts. So if someone is offline and the server isn’t running, you can push a change to get it working again without pinging them.

The Bias of the Absent Visitor

If your software product’s user interface doesn’t support _____, or support them well — your data won’t include _____ in your access logs. You could think they don’t visit often enough to include them in your team’s decisions about the interface. Instead, you can focus on segments of the population based on device, browser, OS, language and location, or any other criteria you feel are important and worthy of attention. It’s simple: make it work for the majority.

This is a blind spot. I call it the bias of the absent visitor. Since they’ve never come by, you can easily fall into assuming they don’t want to or need to use your interface. You might think you can just ignore them safely.

The reality is that they might have stopped by once or many times, had a terrible and unwelcome first experience, and have never come back. They could have seen a blank, white page instead of your carefully crafted design and content. Might have even told their friends not to bother.

This is one of my biggest blind spots. I hope that writing it down will motivate me to remember that the absent visitor is just as valuable as the typical one.

Be a Yardstick of Quality

Inspiration from Steve Jobs, in 1987. This is my milepost for 2017.

People judge you by your performance, so focus on the outcome. Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.

From I, Steve edited by George Beahm (2011).

 

Smarter, Faster, Better

A few findings from reading Smarter Faster Better: The Secrets of Being Productive in Life and Business by Charles Duhigg (Goodreads).

On self-motivation: Ask yourself, why am I doing what I’m doing? If you are doing something you think is stupid and meaningless, you’re not going to care.

Envisioning the day: Make a habit of picturing how things will go, what goals you have from meetings or tasks—it can make you much more productive.

Distractions: We can trick our brain to ignore things by spending time visualizing what we want to occur, like going to the store for only lasagna and ignoring the special display of holiday cookies.

Tests, finances, decisions: Slow down to make better choices, called “disfluency.” Also helps with overload of data; it’s easy to let your eye slide over it without absorbing anything. Fight it by slowing the information down, make it stickier.

Internalize new ideas: Tell someone about it, interact with the idea, and it’ll stick with you better. For example, telling a colleague about a book you’re reading, not to educate them, but to lock in the ideas.

Financial life: Force yourself to interact with the data, even if it seems inefficient. Sit down regularly and see what you spent money on—is it expected? Do you need to change habits? Not only look, but write it down.

Editorial note: I published this with the WordPress desktop app, a superbly focused and native experience to write posts and manage your blog settings.

Design for Real Life

Real life is complicated.

Even after we’ve tested all the important user flows and polished the edges in our app or site, people still stumble. Why? Because we’re humans, and because our products still have:

  1. Broken flows: transition points or interactions, like a form on a site, that aren’t working correctly.
  2. Content gaps: someone needs a specific piece of content, but you don’t have it—or it’s not in the right place at the right time.
  3. Pain points: people get hung up and are likely to abandon the site or app.

Making digital products friendly isn’t enough to make them feel human.

For more on this topic, I highly recommend Design for Real Life from A Book Apart; the ebook is only $11.

design-real-life.png

Instead of treating stress situations as edge cases, it’s time we move them to the center of our conversations—to start with our most vulnerable, distracted, and stressed-out users, and then work our way outward.

The reasoning is simple: when we make things for people at their worst, they’ll work that much better when people are at their best.

Order Design for Real Life from abookapart.com. See also the WordPress.org Flow glossary for terms inspired by this book that we use in testing WordPress.

Review: The Way of the Web Tester

This is a book review of The Way of the Web Tester by Jonathan Rasmusson. Hat tip: Alister Scott.

A beginner’s guide to automated testing, though not specific to the web, despite the title. Covering the quintessential pyramid of UI, integration, and unit tests as well as basic building blocks of HTML, CSS, HTTP and REST APIs, and JavaScript. The book also spends time on best practices for general software programming and testing.

The goal for test automation, according to the author, is to have more time to do the fun things like developing new features, and less time on boring things like fixing bugs. We can’t test everything, yet “with the right 20%, we can sure test a lot.” Agreed. In broad strokes, this book debunks many common misconceptions of automated testing.

Don’t try to automate everything. Instead, automate just enough.

I love the dual audience of testers and developers, and how each chapter addresses the goals for each to learn in the coming text. The chapter ending summaries are handy. The text flows and the examples are easy to follow. Though a quick read, the book ends up covering important topics such as organization, naming, coupling, reusable code, and avoiding flaky tests by making them deterministic.

A few minor nitpicks: I found the metaphor of armor and mobility a tad confusing, and some of the humor seemed off-putting and unnecessary. As a beginner book I didn’t like how it conflated an important concept of CSS selectors and using similar syntax with jQuery to select elements by ID; in my opinion this difference should be understood at a beginner level. The author also doesn’t mention targeting data URIs in HTML attributes for selection, which seems to me to be worth a mention as a useful technique when working without relying on extra IDs or classes everywhere—such as legacy code or HTML output from third-party templates that you don’t control—and is present in popular JavaScript frameworks such as React.

I love the concept of a Developer Productivity team at a software company—at Spotify, Rasmusson describes a squad that went around killing and fixing flaky tests. Making things run better, making everyone happier. I think of Excellence Wranglers at Automattic as having a similar goal in our work as quality advocates.

The Way of the Web Tester does a great job introducing important concepts and covers the basics of automated testing, and I’d recommend it to everyone, even seasoned developers and testers.