This is How You Automate

Just received a wonderfully engaging / automated / interesting / human / polite / funny / direct / personal upgrade message (there’s an oxymoron there, I know) from the folk at TeuxDeux. This is how automated marketing should be:

Dearest Tom,

It’s been six months since the launch of the new TeuxDeux and we very much hope you’ve enjoyed it. Given how much you’ve been using it, it’s our guess that you have. In fact, with 1846 items done since you’ve been with us, you are certainly among the most productive people on the planet!

As we mentioned in March, TeuxDeux is moving to a paid subscriptions service and it’s almost time for you to decide whether you want to become a “true believer.” You can subscribe here:

Becoming a subscriber helps us keep TeuxDeux running, fix bugs, update our apps and, soon, shared lists! And that’s just what’s up next.

Before we go, we thought you’d enjoy a couple other fun facts about you & your TeuxDeux:

  1. The to-do that was on your list the longest that you finally completed was: “Complete e-Business models section” (1405 days)
  2. The to-do on your list the longest that you haven’t completed… yet :) was: “Portfolio video” (193 days)

Don’t worry. You’ll get her soon.

Thanks so much for all your support. We love and appreciate you.

The friendly folks behind TeuxDeux’

Lazy Loading Responsive Images

Learn more below or see the Demo →

Most of last week I was rebuilding a website for a longstanding client. Performance ( fast the thing renders) is not only important to this client, it’s imperative. A good proportion of their customers live out in the sticks, and as a result, many have slow internet connections.

Lazy Load to the Rescue

To speed up page load, we decided to use the popular Lazy Loader plugin which defers the initialisation of images until they were needed. Most importantly though, users on slow connections would have the (essential) page content loaded almost instantly, while (complementary) imagery could download subsequently.

Lazy wants to know!

The problem: Lazy Loader demands that we define the width and height of our images.

“Note that you must set image width and height either as attributes or in CSS. Otherwise, depending on your layout, plugin might not work properly.”

Since we were using a flexible grid, we knew that the image width was going to be 100% of its context. However, we couldn’t define a height. If we did, when the grid fluctuated, the ratio of the image would impair.

Actually; Ratios to the Rescue

In theory, we knew we needed to define a ratio in CSS. We needed the height of the image to be relative to its width.

Browser dimensions showing width 100% however the height is unknown

I’ve seen a number of JavaScript plugins which enable this, but I was sure there would be a way of using the browser’s presentation semantic, CSS, to do the job properly. This would prevent flashes, reduce load time and help me sleep at night.

Here’s an example JavaScript flash that’ll keep you up all night vs. the fluid / responsive, lazy-loaded image demo site:

The pixie dust

1] We create our markup; a container element which will house our lazy load image:

<div class="panorama">
    <img data-original="/images/example.jpg" src="/images/lazy-grey.gif" />
</div><!— /.panorama —>

2] We define the styles for our container element “panorama”:

.panorama {
    position: relative;
    padding-bottom: 24%; /* our ratio for this image, you can adjust this accordingly */
    padding-top: 30px; /* IE7 fix */
    height: 0;
    overflow: hidden;

3] Then we define the lazy image like this:

.panorama img {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;        

Here’s what we’ve done…

In short, we’ve created a container element, which, using the height 0 trick in combination with the padding bottom percentage (to define our height) gives us a contextual ratio for our image. Combine this with a cheeky absolutely positioned image with a height: 100%; and width: 100%; statement and we’re laughing all the way home. No flashes on lazy loaded images, no rendering blips and only a few lines of additional code.

If you haven’t already, checkout the Demo →

I’ve made the demo repository public on BitBucket for your downloading pleasure. This has been tested in a whole bunch of browsers but if you run into any problems, drop me a tweet and I’ll see what I can do to help.

Until next time!

Product Design Process

When we have a new product idea (and are lucky enough to have the skills and tools to execute on it), it’s often more than tempting to jump in with two feet and start building the thing. Before we know it, we’re pitching the hows before whys and problem solving becomes a battlefield of miscommunication. As a result, our product concept becomes more complex and less focused.

Over the last few weeks, I’ve been investing a lot of time and energy into a product design process that we’ll be using for an upcoming project.

I insisted we made investments in our process and put this case to the team:

We’ll Make a Better Product

The main reason for using a product design process is ‘to make a better product’. To query our definition of a better product: a product which outperforms its competition by solving its customers’ problems in a more simple and effective way.

We’ll See Where Value Can Be Added

Distilling the big problem that our product is solving into situations will help us visualise all the moving parts and figure out where value can be added.

Ryan Singer writes a brilliant piece on situation value:

Suppose a team is building a “file versions” feature. Two situations define the value differently and lead to different designs.

In one situation, a person catches an embarrassing mistake in a proposal and wants to know who to blame. In order to do this, they need to see information about intermediate versions. They value the product telling them who made what changes and when.

On the other hand, consider a situation where they want to send the latest version of the proposal to the client. They don’t care how it got to its current state. They just want to send the correct file. In this case intermediate versions have no value. The user just wants to know where the latest version is.

Different situations = different values.

Defining situations will align us as team and conversation will be more constructive and focused on the task at hand; getting users from A to B.

In the absence of code we can quickly iterate through our best ideas, fitting all of the moving parts together. This will maximise our potential of designing a product concept which is simple, useable and more effective in its approach.

We’ll Sing from the Same Hymn Sheet

We’ll waste less time and energy mis-communicating and voicing logical speculation. Instead, we’ll be solving real problems based on real situations.

We’ll know the right time to discuss problems and when it’s right to discuss solutions. Better still, we’ll be contributing ideas from our respective areas of expertise, which will open up new opportunities and unblock us.

We’ll Think Conceptually

Freeing ourselves from code will help us to problem solve in a more abstract way. Code is high fidelity; like cemented bricks. Better to think solely about the product in its conceptual form with something low fidelity, like paper mockups.

The beauty of problem solving on paper is that it’s quick and easy. We don’t need to be artists to present our ideas to each other. What’s more; we can quickly hash-out numerous iterations of a design pattern or technique and pitch them against our view of a better product.

We’ll Build a Better MVP

Once we’ve formulated our product concept, we can outline features that we want to exclude for 1.0; this will form our minimum viable product (MVP).

We’ll know that the MVP we’re building, is in fact, the foundations to our product concept. We’ll waste less time as everything we build will count towards the whole. We’ll loop through less iterations as the UX will have a solid direction, cemented on real world problems.

So far…

The process has already helped us in the areas above. We’re still learning though and adapting to a new workflow is always daunting. We’ll put the process through its paces a little more and I’ll share it on here once we have something to show how effective it is.

In the meantime if you’re working on software projects and care about what you ship, I’d suggest you checkout Rick Hickey’s talk on design, composition and performance as well as Ryan Singer’s post on the Vital Elements of a Product Design Process. Both have been central to designing our product design process.’


Had a wonderful time in the Algarve, Portugal. We hired a car for most of our stay and travelled right along the south coast. Check out the full Flickr Set ›

If you ever visit, make sure you check out Silves Castle. It was - by far - the most ethereal place I've been.

Small Stuff

Bijan Sabet on Steve Jobs:

His relationship with friends deteriorated for the most part. His relationship with family wasn’t great either.

Obviously none of us know the real story but the book reflects conventional wisdom: Steve was focused on Apple and Steve. And in that order.

The question which comes to mind (for me) then is: what if Steve was happy and had a balanced life?

  1. Could he have fixed Apple?
  2. Could he have led Pixar and Apple to greatness?
  3. Could he have it all?

Sabet draws a line, pointing out people fall into two camps for the most part:

  • stressed out of their minds, loving their work but wiped out. Relationships strained or worse.
  • relationships stronger than ever but the work isn’t what it used to be.

Interesting observation. Brings to mind Paul Graham's article on good and bad procrastination:

The most impressive people I know are all procrastinators. They're type-C procrastinators: They put off working on small stuff to work on big stuff.

What's "small stuff?" Roughly, work that has zero chance of being mentioned in your obituary.

Question is, do your family and friends qualify as small stuff?