Stuff in my head

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.

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.

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 :)

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.

IMO, flat graphic design is not more "digitally authentic" than the more… metaphoric stuff. But what do I know: imprint.printmag.com/logos-2/micros…

— Oliver Reichenstein (@iA) September 10, 2012

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.

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 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

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.

Mobile vs Full vs Responsive. Which wins?

Seems some people think there's one true way®

http://www.useit.com/alertbox/mobile-vs-full-sites.html

http://www.netmagazine.com/opinions/nielsen-wrong-mobile

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.

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.

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. 

Since the new iPad launched, I've read numerous complicated methods for handling retina graphics. Most of which have left me scratching my head as to why they haven't just used media queries. Even Apple seem to have missed the mark a little with some complex js solution that actually pulls two versions of the image in - adding a rather pointless overhead to page load.

So, without preaching to the choir. Here's the technique using media queries to target retina and only pull the images you need for the appropriate device. You can of course tailor this further to target iPhone or iPad too.

<link rel="stylesheet" type="text/css" href="1x.css" media="only screen and (-webkit-min-device-pixel-ratio: 1)" /> 

<link rel="stylesheet" type="text/css" href="2x.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)"/>

I'm sure you can see what's going on here, but in a nutshell - by adding some specificity over pixel ratio in your media query you can isolate styles (and thus images) based on whether the device is retina or not. The beauty of using that specificity is only the correct size images get pulled so you have no overhead on page load.

Here's a preview in desktop and on a retina iPhone 4s.

Here's the proof of the pudding.

Been putting off doing this for ages but turns out the solution is pretty simple and requires no terminal voodoo.

We had this situation because we've switched exclusively to a MacBook Air for our primary home machine so we moved all of our media to a NAS. 

The MacBook never gets switched off, just closed and opened as we need it and that was causing the NAS to lose connection and require a painful manual mount each time.

So here's the fix:

Grab Scenario from the Mac app store http://itunes.apple.com/gb/app/scenario/id423444193?mt=12 (£2.99)

Open Applescript editor, and create a new script thus:

try

mount volume "smb://path-to-your-volume"

end try

Save the script.

Open the Scenario prefs panel and enable "Computer wakes from sleep"

Click "Open Script Folder" and move your newly created applescript into the folder called "Wake Scripts". Job Done.

I posted a rather flippant tweet the other evening as a reaction to yet another frustrating experience with wireframes.

Anyone can draw a wireframe. This is another reason why wireframes have to die.

Now, I can appreciate on it's own that statement sounds pretty dumb out of context, and as was pointed out, it doesn't matter how easy is it to wireframe - they are just an artefact with differing value depending on the process of creation and also of their creator.

I do however stand by the notion that wireframes really must die - as a client or user facing deliverable.

As scamps, as means to capture an idea, as a way to get something down - they certainly have a value if you're not comfortable doing all that with a crappy hand drawn scribble.

If doing all that in a diagramming tool is easier for you that's perfect. But, beyond that we're now at a stage where spending significant amounts of ours and our clients time, working up a wireframe, iterating on it, annotating it and maintaining it before we even start thinking about making something we can test properly - really has to change.

Wireframes aren't the things we end up making. They are at best an approximation. A faked version of the experience we aim to design. Testing something fake really doesn't provide the best value to us or our users, or allow us to really shape that experience in a genuine way. In fact i'd go so far to say it's a dangerous assumption to base design decision on. We need much more proximity to the actual things we design, and we are incredibly fortunate in that the medium in which we work with on the web is free, simple to work with, flexible and disposable if needs be.

Not many other industries have that luxury and yet we somehow feel the need to abstract this vital part of the design process through diagrams, convoluted software that mimics interaction terribly and end up working with static pictures of stateful and reactive things.

I used to sit on the fence about UX designers knowing HTML but I'm shifting more towards the opinion that not only is a good idea, it's getting to the point where it should be de facto. There is no other way to design responsive sites for one thing, and with device fragmentation growing by the day that's a serious consideration for anyone working in this field.

Cennydd Bowles pushed out a diagram earlier that explained why he no longer used wireframes much these days, so I figured i'd show my own rationale diagrammatically too.

One point of controversy that i'm sure to get hauled up on is not giving wireframes a mark for testing or interactivity. Of course you can make clickable diagrams but really, what is the point testing something so removed from the actual experience?

To me it seems pretty clear where the issues are here, but that's just my take. I'd love to hear what you think in response.

The web design industry has a habit of hopping on board bandwagons as they roll by.

And boy do they roll by...

Aligning responsive design with a bandwagon doesn't really befit the genuine benefit the technique can afford when done right and used in the right circumstances. But let's get this on the table right off. Responsive isn't right for every circumstance. It's not a silver bullet that magically solves our multi-device problems.

In many situations - with planning, consideration and care, a responsively designed site can definitely provide a better experience than leaving it to the device to figure out. But for every site that works there's an equal number of sites that don't.

Retrofitted responsiveness is often to blame. Anyone with half and hour and a text editor can throw media queries at an existing desktop site, and stack and scale their existing layout to suit smaller screens. You see it everywhere, and they make for a truly horrible experience.

Unconsidered and vertically stacked content on a mobile screen is vile. I lose all control over my own consumptive behaviour. I can't scan, I lose all waymarking and any comprehension of site geography and scale, I can't easily browse or select what I want to engage with, I'm forced to digest more than I want to and HOLY CRAP!!! what the feck is up with all that huge type!??

Oh, and don't get me started on navigation in the footer either...

Worst of all, beyond any complaints you may have about alternate versions of sites - with responsive its's a one way street. You can't opt out of the media query that's driving this thing. And that really sucks, so you better be pretty sure you can pull this thing off sonny Jim.

So I guess the point i'm trying to get to is this. Responsive is not a panacea. It's a mechanism for presentation (for now at least) that only works when you have the ability to apply consideration to every eventuality, and that means figuring out the best thing for your site or product including crafting that interface and content to make a genuinely better experience at every level.

It's not fashionable but I personally don't buy into a single device first doctrine. Do what's right for the product, mobile first, desktop first, fridge first whatever... just be aware that every decision you make has an impact. Source order is your new best friend and worst enemy at the same time. Your grid and typography needs to adapt. Navigation is no longer set in stone so rethink your IA and site taxonomy. Media and images are massively problematic, and advertising... well... forget it (for now at least).

I like tinkering with bikes a lot. Somewhere along the line I even picked up Cytech accreditation so I guess that makes me a qualified cycle mechanic too.

Working on a bike is pretty satisfying if you have the right tools. Sure, you can get by with some improvisation and a bit of ingenuity but if you want to do a great job, you really need the proper kit, or at best you'll do a shoddy job or damage the component you're working on, or at worst do such a crap job you'll put yourself in danger.

My toolbox - or should I say toolboxes at home have grown over the years to accommodate changes in standards, weird little edge case components and newer developments like hydraulics and suspension. I don't buy crap stuff, because cheap tools are a false economy. 

Park tools are the best you can get without resorting to silly money and as you can see even from the small array above there's a specialist tool for pretty much anything you want to do on a bike.

Now compare that to this...

Amazingly this little thing can do a whole lot of what that huge Park kit can do. It will get you out of a bind, get you rolling again - but man, it's no fun at all. After skinning your knuckles for the fifth time, or rounding off an awkward allen bolt head you'll be swearing at the little shit - and it may end up in a hedge.

I like tools a lot, and in my work they may well not be physical things, but they are the things that let me get my job done. Right now my toolkit looks a bit like this. It changes a little day to day, but in the main if I have these I can get by. 

These are the Park tools of my profession.

Now, I could do a lot of what I need with maybe just one of these but it's the same principal as using a multitool to work on a bike. One tool can't rule them all. And actually that's fine. 

However, I still think we're missing some of the tools we need to work better, smarter and with more proximity to the things we're building. Diagrams are dying, prototypes are thankfully becoming more the norm, and although I can write HTML/CSS pretty well - I don't really want to.

So at Mark Boulton Design we're looking at better ways to do the things we do. One of those things is something we announced last week - Gridset. Gridset evolved from our internal prototyping framework into something that stops us having to write code and lets us get on with the stuff we're paid to do - designing experiences that present content back to the user on pretty much any device you can think of.

Not only that but it frees us up to be more respectful to the content and layout in which that is presented. Fixed column grids somehow became the norm on the web, but a side effect of responsive design is that we've been forced to rethink how layout works. How hierarchy and flow adapts dependant on the screen you're viewing that content on. Fixed columns don't do that. So referencing the desktop publishing grid layout tools a lot of us were weaned on, we're making it so you can create any type of grid from a traditional symmetrical grid through to incredibly complex asymmetric and compound grids. All the while without having to do a single piece of maths or worry about writing layout CSS.

I was thinking this yet again just the other day after observing yet another train carriage full of white-earbudded travellers, merrily swiping and tapping their way home on various apple branded gadgets.

In a carriage full of people using mobile devices the ratio was easily 10:1 in favour of Apple. This plays out pretty much everywhere I go - and yet Android numbers claim to be putting a dent in Apple marketshare.

Sure there are plenty of bona fide geeks running Android and they certainly use the phones in a similar vein to those on iOS, but i'm guessing they're in the minority.

I saw some fairly startling stats from a recent site launch today - factoring in desktop and iOS, the site had a cumulative bias of 75% Apple browsers. Not webkit - Apple.

That's crazy.

One thing that cropped up during a discussion on how better to handle responsive images at the responsive summit last week was an idea I put forwards for a (very) hypothetical solution based on a similar idea to how icon files work (specifically mac OS .icns files)

ICNS files are essentially a package or bundle of multiple image variants designed to suit a multitude of uses - all the way from 16x16 favicon sizes right through to 1024x1024 monsters for Lion. Dependant on where the icon is used the correct (or closest fit) version of the icon gets used. Sounds eerily familiar right?

So what if we could have something similar for images on the web?

Partnered with some intelligent detection on the client side, we could render the appropriate size to the screen no matter which context it was used - all from a single tag, which feels semantically more appropriate than multiple references in the HTML.

eg: <img src="myresponsiveimage.img" />

Then by exposing an index in metadata for the image in the form of an array you could also access a specific key of a variant directly - like if you had thumbnails leading to a larger modal view of that image for example... And because the image was already loaded it would be instant too - neat huh?

eg: <img src="myresponsiveimage.img"  size="2" />

An added benefit would also be that each version inside the .img file needn't be the same image. So dependent on how your layout worked, you could have different aspect ratios, for landscape/portrait, or a different crop, or even a completely different image if that was useful.

Some issues

Ok, so a new image format is a little out there. But as Elliot pointed out, the WOFF font format was created and embraced pretty quickly so it's not beyond the realms of possibility. WOIF? Looks a bit like wolf too which is pretty rad eh? ;)

Secondly, you might think that wrapping 5 versions of a file and loading it could be a little heavy. That's possible for sure but take a look at this typical ICNS file. The component parts are huge but as a package the whole things weighs just 225kb which includes a 671kb 1024x1024 image too. There's also potential for a kind of multipart download of parts of the file if required... 

Of course we'd need to develop plugins or dedicated tools to wrap the files up, but really that's pretty trivial - even on the server side if you needed to build creation of these files into a CMS.

So what next?