Pragmatic Web Development

Naga IT Services
Filed under: Talk notes

At last week’s Cape Front-end Developers meetup, Mike Jones (@imsickofmaps) of Western Cape Labs and One Less Thing gave a great, opinionated, what-works-for-me talk about Pragmatic Web Development.

Pragmatic Web Development


One of the things that’s core to Mike’s approach is transparency. He talked about openness of communication and honesty, in particular. He shared details of their workflow using Trello boards, adopting the User Voice method (see How we use Trello & Google Docs to make UserVoice better every day

for more details).

Delivering Value

Another point he discussed was keeping a continuous focus on delivering value. The classic user story looks something like this:

As a <user>, I want <feature> so that <value>

Mike’s version looks more like this:

So that <Value>, As a <Persona>, I can <Do Something>

This sounds a lot like a user-centered approach, so it makes me very happy. There’s an expansion on this story format at Feature Injection User Stories on a Business Value Theme by Antony Marcano. Another alternative is looking at Job Stories:

When <situation>, I want to <motivation>, so I can <expected outcome>

Pick + Stick

I think my favourite message from Mike’s talk was “Pick and Stick.” He started by phrasing this as

Stop always starting over

Stop continually reinventing

Start being consistent

This ties in nicely with the most recent Argumentative Morning: Bleeding Edge vs Old Faithful.

Mike talked about the importance of longevity of tools, and how using them for a while lets you become an expert at their use. He said they use one version behind the latest version for many libraries, so that other people have found and fixed the bugs in it by the time his team starts using it. He talked about about how they use Twitter Bootstrap for their front-end because it’s fast and when you search for more information about a particular bit, you get a lot of results for bugs and fixes.

Next meetup

The next Cape Front-end Developers meetup will be at the end of April: keep an eye on the meetup group for more details.

Content-first and Content-out

Naga IT Services
Filed under: Uncategorized

Content is at the heart of everything we do working on the web, so it’s not surprising that Content First is as much a rallying cry as Mobile First. Two content-y articles were published last week that make a nice pairing.

Over on the Gather Content blog, Liam King writes about How Content-First Agencies Win Clients.

content-first is about positioning and emphasis on content processes, activities and thinking. It is about demonstrating to prospective clients that you consider content at all points to ensure the project and longer-term success of the site.

Even though clients generally know about Responsive Web Design these days, the wider picture of Mobile First and Content First can still be a bit of a tough sell. One part of Liam’s article is about proving that designing content-first actually works. He suggests pulling a case study into new business presentations to share stories of previous successes with this approach.

Moving on to the more visual side of things, Nathan Ford writes about Content-out Layout at A List Apart.

A ratio-based, modular approach to grids allows us to navigate a medium where we cannot know the container size, nor what type of content will flow into that container. We can build layout systems from our content, and rely on ratios to keep harmonious compositions from these disparate parts.

He provides an excellent introduction to using ratios and scales for your grids, and goes on to highlight some common problems / constraints that cause a layout to look a bit off: 7s, drifts and pinches.

Here are a few more articles and tools on the topic:

You might also like to check out my Pinboard bookmarks tagged with typography.

(Responsive) Web Design

Naga IT Services
Filed under: Industry, Responsive

There’s lots of discussion around the intertubes at the moment around Responsive: what it is and how we define it. Over the past few days, more of the heavyweights of the web development and design industry have chimed in. Here’s a quick round-up of who said what.

One viewpoint is that Responsive Web Design is really just good web design or web design done right. Back in July 2011, Andy Hume wrote about being Responsive by default, and how the principles and ideas are behind it are core to what we do as a web developers. A few months before that, Andy Clarke was saying similar things:

Web design is responsive design, Responsive Web Design is web design, done right.

(Specific) Responsive Web Design

In his post “Evolving Responsive Web Design”, Blue Beanie man Jeffrey Zeldman talks about how, although the Responsive Web Design is good web design (and vice versa), Responsive as a thing in itself is important. He insightfully points out that the reason RWD has caught on is because of the specific definition that Ethan Marcotte set up:

If Ethan hadn’t included three simple executional requirements as part of his definition, the concept might have quickly fallen by the wayside.

Mark Boulton brings that around to the business side of things, reminding us that it matters what clients think, and they’re beginning to know about the term responsive, and ask for it:

You see, responsive design is a useful term and one that will stick around for a while whilst we’re going through this change. How else do we describe it, otherwise? Web design? I don’t think so. No board member is going to get behind that; it’s not new enough.

(Device-agnostic) Responsive Web Design

Trent Walton’s article, Device Agnostic, rounds the discussion off nicely, and is well worth a read. He talks about the number of variables and unknowns that we have to take into account (screen resolution, input method, browser capability, connection speed):

With such a wide range of possibilities, the sensible thing to do is to zero in on the harshest conditions (or toughest things to deliver) and build from there.

He talks about Hostile Browsers: how a user’s choice of browser can sometimes be acting against design and modern web technologies. He also talks about flux. See Frank Chimero’s beautiful essay What Screens Want for more about that.

Trent also offers a timely reminder that it’s not all about the new and shiny:

As web designers, it is our role to consider (and plan for) maximum reach and access, even when final results might seem underwhelming or less immersive.

Building things for the One Web

Naga IT Services
Filed under: Industry, Reading, Responsive

There were a few articles doing the rounds recently that touch on some deep, fundamental, aspects of modern day web development. They had some common themes: the importance of being flexible and that this stuff is hard (developing for the multi-device world). We’re still finding our feet, and one area that’s seeing lots of change is deliverables.

Given the fluid nature of the web, what are the right deliverables for designing and building a web site? How can we show work in progress on a web site without showing the whole, fluid, web site? Whose job is it to decide what we show, how many deliverables there are, and to explain why they’re different from “traditional” deliverables?


Jeremy Keith’s Continuum and Ethan Marcotte’s response: Platformed both discuss the squishiness and universality of the web. Jeremy pointed out that despite the fact that there are differences in browsers and operating systems we can still support every browser that can connect to the internet by using a strategy of Progressive Enhancement.

the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.

you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.

He points out that it’s our responsibility to explain this diversity of consumption of the web, to educate clients who don’t understand.

Explaining your design work is part of your design work. It’s the same with web development.

Mike Monteiro often talks about this, too: What Clients Don’t Know (and Why It’s Your Fault). Ethan added to this, saying that because of the fluid, chaotic, nature of the web as a design medium:

we play the long game in this business.

The web is One Web, and it does (and will) go everywhere that it can. Designing and developing something that’s pixel-perfect across a small range of today’s browsers and devices already puts you behind the times. We need to play the long game and build for the unknown: well-formed and structured HTML with Progressively Enhanced CSS and JavaScript that lets our sites go anywhere.


The next day I picked up Laura Kalbag’s excellent article: Delivery Logistics, on A List Apart.

In web design, the deliverables we create are rarely the final product; they’re rarely the thing we’re going to “put live” to any users.

We need to stop acting as though deliverables are the be-all and end-all of web design, and treat them as the communication tool that they are.

This is really important. Style Tiles are an excellent example of this. They provide provide a catalyst for discussions: interface elements without layout, so that we can focus on pieces that make up the design and the layout. The deliverables along the way are essential to the process: we’d never make it to the end, or build the right thing, without things like Personas, Customer Journey Maps, Style Tiles, and so on. We should be treating them more like signposts to the end product than the end products in and of themselves, though.

Even the web site (the “real” deliverable), once it’s gone live, is in a state of flux: content gets updated and moves or breaks things; styles get updated for new branding elements.

Closing thoughts

It’s an ongoing process of discovery and learning. One thing I do know is that, as an industry, our tools need to keep changing to keep up.

Building a mobile and a desktop prototype and testing them extensively is great (and very practical), but it’s important to remember that these are just two very thin slices of how the site will be experienced: browsers accessing the web have a lot of dimensions to consider. More on that soon.

Of course there’s a balance to be had. It’s impossible to test across every configuration, and impractical to test across large numbers. It’s also true that many of the lessons learned at these two points on the spectrum can be applied widely. I think that it demonstrates the importance of getting into testing with browsers earlier rather than later, though.