Stuff in my head

Sometimes

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.

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. 

The simplest way to handle retina graphics for iPad and iPhone

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.

Of course this only works for background images for now but there’s not too many scenarios where a background image won’t suffice. We’re working on a fix for inline images which we hope to share soon.

Mounting NAS share on wake for macbook users

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.

Why wireframes are dead to me

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.

A Responsive Panacea

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

It’s an exciting time for the web, but don’t get carried away hammering a square peg into a round hole. There are 50 ways to skin a cat but remember responsive is just one of them. 

A Tool talking about Tools

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.

And Gridset is just the start. We have lots of cool stuff in the works too that will keep adding to our toolkits and hopefully making all of our lives a bit easier.

Where are the Androids?

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.

So where are the Androids? I have a theory which isn’t all that revolutionary but i’ll put it out there all the same. People in the main buy Androids because they don’t know any better. My Mum is pretty typical, she went to the phone shop, got sold a deal and probably doesn’t even know she has an Android, let alone that it can do all kinds of cool stuff she’d probably enjoy. That would certainly explain the disparity in numbers and conspicuity that seems to be the case not only on the street but also in our analytics too. 

A better responsive image format

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?

I literally have no clue. I’d like to punt the idea around a bit and see if it’s got any legs at all - so please feel free to spread the word and hopefully we can get the idea in front of some people who can either help it move forwards or help prove it’s not the right way to go. Also would love to hear your thoughts in the comments below.