The accessibility of media queries and user choice


The humble media query has given us a lot of power to help target and tame layout and presentation for different screen sizes. That same power though has introduced a problem in that if you wrap your content in a media query it is very much a one way street.

As responsive web design has gained favour, there have been some brilliant examples of optimising designs for smaller screen sizes, which genuinely offer a better experience than leaving it up to the browser to deal with and then using pinching/tapping to zoom. But for every successful small screen layout there’s at least 10 awful ones, which are so painful to use you’d rather take the larger desktop view and struggle through.

The problem is you can’t. Once that media query matches and fires, you get what you’re given and you better bloody well like it. Even if you don’t.

That seems to be like a pretty broken implementation. I’d at least like the choice to see if the experience is better using a different media query than the one that matched my browsing conditions. This seems like something a browser ought to be able to do, in the same way you can kill Javascript or Styles altogether - why not have a user setting for killing certain styles, or choosing to have the site render with a different media query than the one detected.

Web content should be accessible in every sense of the word, forcing content into occasionally subpar experiences defined by a condition that I cant influence, without a way out again feels contrary to that.


Touchy Subject


The industry trend towards touchscreens gained further momentum today with the release of Google’s Chromebook Pixel

Despite there being little in the way of tangible benefit to desktop interaction on current UI’s - the onset of touch adoption is an industry initiated (rather than problem solving*) inevitability. Scrambling for points in the innovation race, touch has become the de facto add-on to get the jump on the next guy - regardless of how subpar the experience is for the poor sods that have to use these devices.

Touch, as an interaction model is clearly brilliant in context. Phones, tablets, even basic kiosk type devices work well. But the common factors holding that success together are simplicity and ergonomics. Dedicated apps distill functionality down to brass tacks and UI’s are shaped around those simple needs and sit back engagement.

As is often written about - much to the chagrin of manufacturers like Apple, consumption constantly trumps creation on these devices. Sure there are edge cases where unique products find a niche that can be exploited by the medium, but the posit for scaling that same idea up to something that you no longer hold in your hand, just doesn’t hold water.

Devices like the Pixel are doomed to create frustration in users by virtue of the fact they’ve introduced a new interaction layer on top of a surface that was not intended for touch, or really ready for it on so many legacy sites and products - particularly so in the case of the Pixel, where that surface is entirely based around a web browser. Josh Clark suggests the solution is to make everything we design suitable for touch. That’s a lovely simplistic approach, but that presupposes that the product or site is A) suitable for touch** B) the business constraints of the project allow that to happen.

We’re at a juncture where this forced compromise could become such a burden that experiences get diluted at all ends of the spectrum to become average everywhere rather than appropriate for the user.

The notion of one UI to rule them all is a compelling one, but without decent detection and tailoring for touch (which we can’t do right now) we’re going to have to live with a glut of over-sized Fisher Price style products that hinder other experiences because of the injection of the need for touch support.

*What was broken with the desktop interaction model we had? No-one seems to have identified that in the excitement of the new and shiny.

**Some stuff is just too complex or precise it won’t work well with touch. Like Ever.


Time for a bit of a change


After a whirlwhind couple of years, the time has come for me to move on from MBD.

I’ve been privileged to work with some of the best designers in the world on some truly incredible projects. But, as much as I love the work, I’ve been doing this stuff for clients for over a decade and a half now and I felt like it was time for a little bit of a change.

Over the last couple of years I’ve been looking at ways to make authoring for the web a little bit easier - not just for beginners but for us old timers too. I’m a firm believer in having the right tools for the job, and right now we’re at yet another transition in how the web is made - and our tools haven’t quite caught up… yet :)

So… in a few weeks time i’ll be joining the guys at Adobe to try and build some of those tools - to help designers and developers like us make the modern web a little bit easier. 


Don’t hate on the Skeu


Trends come and go on the web and in digital design in general. When one gets overused we get tired and the inevitable backlash follows. 

We’ve already seen it happen many times over in our relatively young industry. From bitmap art, to grunge and the faux metal glass and plastic of those hazy crazy aqua web 2.0 days. 

Truth is though, the ideas weren’t all bad. It’s all too easy to react against some of the more horrific examples of bad skeuomorphism, but used with consideration, and a deft touch, using metaphors in our design isn’t just a nice idea, but (as if it needs saying) a massive benefit to UX too.

There’s been a lot of chatter about authenticity recently. Oliver wrote this last night in response to Microsofts new branding and slightly dubious “UX” strategy.

I couldn’t agree more. There is no authentic state for digital design. Lets face it - we’re all making this up. Everything we put down in pixels is either a pastiche of something tangible, or complete fiction. There is no frame of reference through which to establish what is authentic. 

So it boils down to what is most appropriate for a given use case. Does a calendar app need or warrant a fake leather UI? Definitely not. Does a kids flash game need to look more like something physical with big shiny plastic controls? Probably more so.

Everything in-between is a choice we as designers make. Sometimes things need more metaphor to help tell a story or communicate a function. The important thing is to use discretion. The world doesn’t need a leopard skin email client, but at the same time we’d like a little texture, contrast, light and shade to help us find our way around these made up things we spend all day using. 


An un-appley apple experience


This weekend my trusty iPhone started getting hot. Really damned hot. So hot, I was concerned it may explode or something.

It was in good shape too; no drops, no spills, no abuse - and it was still in warranty by a  good couple of months.

So I duly booked my genius appointment at my local Apple Store in Cardiff, rocked up and explained the situation to the genius dude.

He plugged my poorly phone into some diagnostics gadget and stone-faced told me there was nothing wrong with the phone.

Computer says no.

So we start the discussion around how something that is working fine (according to a gadget) is able to get so hot that you can’t hold it. 

It’s “working fine” he repeats. At this point i’m starting to get a little pissed. This is not the friendly can-do attitude of an Apple employee that i’m used to. It actually felt more like dealing with a Dixons employee. Ironic huh.

So then he gets out his next little weapon. A little magnifier with a light that he pokes in the headphone port. “Ahhhh” he nods sagely. “Water damage”.

What the hell? Firstly the phone hasn’t had water on or in it, secondly the diagnostics has already told us things are fine. But yet some weird little litmus sensor seems to think it’s had a shower or something. 

So we’re left doing the who’s fault is it dance and the guy just won’t budge. He’s resolute the phone is fine, despite me having told him the phone hasn’t had water in it and that i’m concerned it’s dangerous. 

I’m really getting annoyed now. Not just because it’s looking more and more likely I need to buy a new phone, but more that this is not how it’s supposed to be when you come to an Apple store. I’ve bought and used Macs and apple products for many, many years and of course stuff has gone wrong. But in every situation prior to last night, the staff have bent over backwards to help out.

This truly sucked.

I didn’t have the heart or the energy to get into some big fight though, and like some chump I stumped up for the new phone and left feeling like i’d just been mugged.

I’m not some fanboy but I do appreciate good service and as an Apple user - have no doubt paid the premium for it.

If that was my first experience of Apple support I’d probably not want to go back. There’s a John Lewis store 100 yards away and they really know how to look after customers. Maybe next time i’ll go there…


UX is simple


If something is unclear - clarify it 

If something is arduous - lighten the load

If something is complex - make it simpler

If something is over verbose - strip it back 

If something is ambiguous - clarify it 

If something is big - make it feel manageable 

If people get lost let them find their way out

If something goes wrong - let people recover 

If something seems pointless - show the value 

If something is dry add some levity 

If something is dreary add some delight 

If something needs explaining - explain it carefully 

Make the important stuff important and the other stuff less so

Less is more (but you probably knew that)

Make desired actions obvious - show the way

If something feels daunting - provide support

If something goes right - say it did 

If something goes bad - say it did 

If something requires effort - set expectations 

If something feels risky provide reassurance

If something feels fragile make it feel solid

If somethings looks great it’ll help to make it feel great

Bring structure to the unstructured

Don’t presume anything

Don’t try to be clever


The killer feature of iOS6 that just missed the mark


Last week Apple debuted iOS6, an evolutionary update to their mobile operating system that typically offered a smattering of refinements dotted amongst a few headline feature updates.

One such headline pricked my ears up more than others, as this particular feature is something i’ve craved since jumping on the iOS wagon back in 2007. It might not sound like much but the “Do not disturb” feature is something that I vehemently believe every smartphone should have by default.

The thing is Apple seem to have missed the mark just a wee bit - well for my needs anyways. 

Do not disturb essentially kills calls and alerts to your phone based on a schedule and/or rules you set. That’s great, but actually calls and alerts are the least of my problems. As most people I know tend to use the iPhone for everything but a phone, the biggest intrusion into my personal life is data. Twitter beeping away here, email farting away there… it’s a constant bombardment of stuff that I could really do without when i’m trying to relax. And willpower alone sometimes isn’t enough. When I find myself with no data - like at the Do Lectures last year, it was such a relief, to not even be able to get to email even if I wanted to. 

So waaay back just after the iOS introduced the App Store, I did what most people with half a inkling about development did and downloaded the SDK with a problem and a solution in mind. I spent all of a week messing around with my idea until I hit a wall that basically kiboshed the whole thing. Apple locks down certain functions of the phone inside software frameworks marked as Private. Apple get to use these, we don’t. The thing I was trying to do was buried deep down in about three of these private frameworks and no amount of fudging was going to get me what I needed.

The app was called meTime. It even preceeded facetime with the whole word with time tacked on as a name :) This is a ropey old mockup of the UI.

Essentially it did a lot of what Do not disturb does now. Scheduling, time profiles etc. But the thing that I really wanted was the ability to shut off specific Data services during personal time. So, toggle certain email accounts on and off, disable twitter, maybe kill text messaging - but still retaining services that were helpful or useful in my downtime.

Basically anything work related that would bother me when I wasn’t at work. 

That separation between work and life is so important and yet we all suck at drawing a line between the two. The iPhone for all it’s brilliance has really done a lot of harm in blurring that distinction.

I’d love Apple to put this feature into iOS, so i’m putting my idea out there and hoping that someone at Apple might have a thing for reading obscure blogs. Fingers crossed eh?




Mobile vs Full vs Responsive. Which wins?

Seems some people think there’s one true way®



It would be nice if it was that simple eh?

Thing is - sometimes what’s right for one scenario probably won’t be for another.

And even then, that won’t always be the case. Sometimes.

Context is often the argument to dictate which way to go - but how can we possibly know the context in which these sites are being used? 

Sometimes I want the whole site, sometimes I don’t.

Sometimes I need the whole site. Sometimes I don’t.

I could just as easily be browsing an airline site on my phone, sat on my sofa with a 30mb broadband hookup, as running through a crowded street in a foreign country trying not to bankrupt myself with data roaming fees.

And of course conversely I could be using my macbook air on a train with the shoddiest of connections (actually i often am).

Context and intent are not directly linked, so let’s stop ASS U ME - ing shall we? ;)

I might occasionally prefer to use the full and zoomed version of a site, to a version someone has deemed to be a better experience, by virtue of the fact they have shrunk it to fit my screen.  

It’s really not black and white. The idea of one web is nice as a philosophy - but it is just that - and not the most pragmatic one either.

What we need is better detectors, better switches - maybe even better browsers.

Instead of running around trying to pre-empt and second guess the best way to hit this moving target, why not put the power back in the users hands. Let them tell us the context instead of trying to guess it, let them set contextual profiles to kill graphics, switch off webfonts, let them view the version they like - and then use better detection to make helpful suggestions regardless of device and help people learn…

Your bandwidth is low - would you like images to be temporarily blocked?

We’re very guilty as an industry of blindly running into burning buildings trying to put out fires that maybe aren’t our responsibility. Sure, it’s valiant and proactive, but maybe this is one of those situations where we’re better served by moving the fight elsewhere.

Sometimes we need to accept we’re unable to do the right thing all the time, but instead work towards providing mechanisms to get closer to that point.


Responsive columns - the odd problem


I’ve been wondering if there’s a smarter way to handle layouts that use odd numbers of columns for responsive sites…

Seems unless you run even column numbers you’ll always end up with orphaned or widowed content as things stack for smaller screens.

Obviously we don’t want to have to force layout constraints if at all possible but it seems like it might be a necessary evil?


Upscaling raster/bitmap images for retina


Retina throws up quite  a few headaches with regards to scaling raster/bitmapped images so they look decent with no nasty jaggies.

For photos where you have higher resolution source material it’s not an issue but if you need for example to upscale a screenshot which was captured at 72dpi you don’t have many options.

This is where one of our old print tricks come into play. 

In Fireworks or Photoshop under the “Image Size” dialog, set the size to 200% and from the “Resample” drop-down, choose “Nearest neighbor (preserve hard edges)”.

This will upscale the image, but tells all the pixels it makes up, to originate from their closest neighbour. Which in essence provides a closer approximation of your original, just with the visual equivalent of bigger pixels.

The end result once viewed @2x on retina will be a pixel perfect sharp screenshot.