Machines of unknown intent

Around six years’ ago we worked with a client who, as part of the project brief, asked for a website that would “still look great in 5 years”. No doubt there was an element of thriftiness in the request (and perhaps a degree of mischief), but fair play to them. It was a hell of a challenge to set a design team.

Aiming low

So how did we do? Well for one the website is still there (and no, I won’t supply the URL…). While it doesn’t look terrible, it certainly displays all of the traits of having been designed six years ago. The giveaway is the 760 pixel width, catering for the large percentage of users then still with monitor resolutions of 800 x 600 pixels. We interpreted the request as having an influence only on the style of the site, while blindly fixing its dimensions to the standard of the time. Using the same flawed logic, we would now be designing sites with a 320 pixel width to suit the lowest resolutions accessing the site.


The fact is there are very few ways of future-proofing a design, particularly when basing it on a style-only agenda. But our chances of success in this challenge were much better at the time our client made their forward-looking request when web access was almost exclusively PC-based. Steve Jobs has recently repeatedly proclaimed that we are living in a ‘post-PC era’. It’s not the fact that Jobs says this that makes it significant. It’s significant because it’s true.

Knowing the unknown

Although we’ve known they were coming for a long time, web-enabled devices are changing the landscape irrevocably. In the past week for instance, it was discovered that Barnes & Nobles’ Nook eBook reader has a browser embedded in it, waiting to be switched on. How could we possibly have designed or tested for this or any of the myriad of new web-enabled devices hitting the market each day, each with their own particular optimal settings for viewing websites? Quite simply through a more forward-looking approach.

Hard sell

The deluge of blog posts heralding the advent of responsive design was something I’ll admit to greeting with cynicism. If someone tells me I “need” to do something, my initial reaction will be to ask what is in it for them. What are they trying to sell me – a conference? a book? In some cases the answer is both, but that doesn’t change the central truth. The argument in favour of an adaptive approach to web-based design is now overwhelming. It’s early days yet, but this is a shift, not a trend.


This doesn’t require signing up to some new dogma, it simply means assessing each project individually on its requirement to adapt to multiple devices. Put like that, doesn’t it sound like pure common sense, if not an essential part of any professional design process? The approach doesn’t guarantee that a website’s visual design won’t look dated in a number of years time, but it will ensure its credible appearance on browsers of all types for a significant period of time, even those yet to be released.

Future machines

With an adaptive design, we can design for the future. Literally. We can prepare designs and layouts for still-to-be-invented machines and devices whose purpose we simply cannot even begin to guess. But they will access the web. And we can design for them.

Isn’t that fantastic?

A less precise art

There have been a number of natural ebbs and flows in the history of online UI design, times when designers may have felt that full control was coming back to us only to see it move away again.

Shock of the new

Moving to the web from print in the late nineties was like a slap in the face. “You mean… I can’t control what’s going on here? There are different browsers that do what???” etc. Designing for the web was imperfect, approximate and maddeningly unpredictable. Or, from a print designer’s perspective, “hell”.


But we moved on and gradually clawed back some degree of control. Tables became the designer’s saviour; by chopping graphics and wringing every last drop of functionality from tables, we were able to lay out content how we wanted it. Bloated markup, unorthodox layouts and clunky designs were the result, but they were a means to an end: control over the design.


Emerging W3C standards and increasingly ubiquitous CSS put the spotlight on the folly of reliance on tables, and the boundaries were moving once again. As a designer in these circumstances you either accept or go mad, stuck with the misguided delusion that YOUR vision is more important than any constraints.

Comfort zones

Graphic designers prior to this generation had been used to constancy. If a new printing technique emerged, or new paper stock came out it would likely be integrated into the process with little or no impact on working practices or design approach for that matter.

Change = good

But this is exactly why UI design for the web can be so exhilarating. Rarely do such new possibilities and challenges to learn and re-learn emerge with such regularity in other mediums. Online, regular developments in markup or software enable us to conquer new challenges in completely new ways.

No going back

Responsive design ensures that websites will appear elegantly on web-enabled devices, regardless of the viewport size; progressive enhancement means that the more advanced the browser environment, the better rendered the design will be. Neither of these principles however results in (or attempts to achieve) full, pixel-perfect control on-screen. And that is where the game has changed irrevocably for designers in the space of a decade.


Ours is an imperfect art, with countless variables and as-yet unknown methods of consumption; one in which we need to surrender to the medium, not master it. For many, many designers I believe that would be too uncomfortable to live with. For those now entering the industry now however it has another name: normality.

Redefining the homepage

There was a time in the history of web design when the homepage would receive almost all of the designer’s attention.

Na├»ve though it may sound now, it was as if the homepage was the site’s only chance to win over the user. After all, homepages won web design awards, homepages were featured on portfolios, and homepages alone bore the weight of expectation for the project. An inordinate amount of time was spent creating homepages that were self-indulgent and self-serving. I know. I was there, and I was as guilty as anyone.

Clients are understandably keen to have something which objectifies their aspirations for the project; the homepage is usually presented by the designers as the key evidence that the design process is on track. Sign-off for the homepage can be protracted, but when achieved it quite often represents the client’s approval for the overall design direction.

But there is a definition of the homepage that made the penny drop for me. It’s plain, it’s simple and it is self-explanatory:

The homepage is the first step of a user journey.

It is a launch-pad for any one of a number of user journeys, depending on the users being catered for. Not a destination in itself. If the homepage successfully serves its purpose as the first step on the journey for your key users, then it is successful. If not, then no amount of embellishment, enhancement or deft application of branding is going to make a difference.

It can not be the designer’s goal to produce a ‘killer’ homepage. That is the realm of designers who see their contribution as more important than the goals of the users they are trying to serve. The homepage is not an end in itself, it is a beginning.

So what do you want to empower the user to do? Where do you need to take them? Make sure the answer is on the homepage.

Deconstructing Build

A collection of circumstances prevented me from getting along to Build Conference this year, much to my shame. And while videos of all the events – main talks and fringe events – are available, I know from experience that nothing can replace just being there, with your peers, having your head sent into a spin by the words of those preeminent in their field.

Andy McMillan – Build’s architect – has put together what he calls a ‘hand-crafted’ web design conference. Post-event his head must have been spinning with the torrent of praise coming his way. The thought he put into it was evident at every turn, with no detail left untended to. He is but one man yet made all this happen, the likes of which is rarely seen in Belfast.

The event has become something much bigger than it arguably set out to be. With a heavy emphasis on fringe and social events, spread out over a week, and with a much broader appeal than its humble tagline suggests, Build is as close to a design festival as it gets. Although a web conference, the wider design community beats a path to Build’s door and the whole shebang is spread over a week. Speakers’ topics this year extended to typography and the design process, while fringe events pushed the ‘web design conference’ description beyond breaking point. This was a festival of design by any other name.

I’ve been around long enough to see at least one national design body try and fail to motivate successive generations of designers and engender a sense of community. Through Build (and a not insignificant amount of other activity such as Refresh Belfast) Andy has achieved it within a couple of short years. Build it and they will come indeed.

I don’t know Andy and have no idea what he has in mind for future years, but his seemingly endless drive will surely result another landmark event in 2011. For what it’s worth I hope Build retains its unique ‘belfastness’. I also hope it ditches it’s increasingly inappropriate “love us because we’re small” marketing bent. Those tickets aren’t cheap, and for good reason. This is a first class design event, worthy of the title of festival, and deserves to be enjoyed and lauded far far beyond the often clique-y world of online design.

Forget #buildconf. Next year’s Twitter hashtag should be #buildfest

Leaving Flash behind

Even before the Apple vs. Adobe bunfight erupted, we were beginning to assess every rich media requirement on every one of our projects to see if it could be done without Flash. If it could be done in code, then we would avoid Flash. That is now standard practice.

Flash, as the default choice for delivery of rich media, has had its day. For us at least.

Adobe has had plenty of time to look for alternative directions for its product, but have preferred to continue the ‘all-things-to-all-men’ marketing approach. “It’s a video deployment platform! It’s an animation tool! It’s a fully-fledged development platform! It’s… give us a while to think of something else!”.

For me, and for many others, the leap to AS3 was too much. In trying to appeal to developers, Flash lost part of its core user base: those designers who had managed to develop rich media experiences in AS2. Adobe eventually realised this, and spent a lot of time trying to convince us that AS3 was the way to go.

I’ll hold my hands up: for years, I threw myself into conquering Flash, so sure that it would yield a fantastic future. But let’s be brutally honest: Flash was never quite the universal, cross-browser, cross-OS platform that Adobe would have had us believe. It never really worked quite in that way.

One of my abiding memories of working on advanced Flash projects was that moment when you suddenly felt very alone. You had promised the client some feature or other, completely convinced that of course Flash would be capable of it. And then you would try and implement something relatively straightforward. Then you would get stuck. Then you would hit the Live Docs, the Flash forums, and everything would go silent. You would find yourself pursuing the issue in some obscure forum, the web equivalent of a country road with grass growing in the middle. You would get that sinking feeling somewhere in the pit of your stomach, and realise that you may actually be asking something of Flash that it was never able to deliver. I had that feeling too many times, and I never want to go there again.

Adobe and its bloggers may post all they like and try to retro-evangelise that we were never meant to develop certain work on their highly legitimate platform. The fact is that for years we were asked to buy in to the idea of Flash as a site development tool. Hundreds of dire ‘Macromedia Site of the Day’ examples – usually the more complex, the better – will testify to what Flash’s masters were trying to promote. Adobe never seriously tried to change the agenda, except when early warning signs started to show, and video delivery became Flash’s saviour.

The simple fact is that the medium has had its time. At 12 years, it has had a good innings. The truth is we are finding other ways of doing what Flash used to show off about. In the early days of this migration, it even irked me. “Why is all this stuff suddenly cool to do in code, when Flash has been able to do it for years” I would whine. Then the penny dropped.

I am no anti-Flasher now. I’m a realist. So long Flash. Sorry Adobe. It’s not you, it’s me.