Tagged with: ‘design’

Posts: 13

Our Duty

Firstly, think about what your pages do, not what they look like. Let your design flow from the services which they will provide to your users, rather than from some overarching idea of what you want pages to look like. Let form follow function, rather than trying to take a particular design and make it “work”.

For us wonderful folk who make websites, it’s our duty to read John Allsopp's seminal A Dao of Web Design at least once a year. For an article that was written way over a decade ago, many of those points still offer so much significance today.


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 (i.e.how 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.’


What’s next?

When we hit the bottom of your web page, what do you want us to do? Where should we go next? What are other people saying about this service? Should we get in touch with your team or look at the tech specs for this ground-breaking new product?

Too many websites fail to answer these simple questions.

Think about it: It’s a bit like visiting a supermarket with aisles that lead to dead ends. You either walk all the way back up the aisle, or you loose interest altogether and are forced to use the fire exit.

When we reach the end of your web page, show us where to go next. Better still, you know where we are, so show us other things that might be of interest. You’ll be amazed at how much longer we stay and how much more we’ll learn about you, your story and your products.


The Future of Interaction Design

Check out this video that sheds some light on what we can expect from the future of interaction design.

Lots of discussion around the 'internet of things' and how user experiences will become less intrusive and more natural as this area matures.

I guess this dovetails with my analogy that we're moving further and further away from abstract computer interfaces. To piggyback on Luke Wroblewski's paradigm, we can see where we're heading by acknowledging the big interface developments:

  • The Command Line Interface
  • The User Interface
  • The Natural Interface: interacting with the content (i.e. pinching your photos to zoom) or thing (i.e. switching the lamp on) itself.

I think that video might have been the nudge I needed to get myself along to the next Maker Night.