Stuff in my head

The accessibility of media queries and user choice

Thu, 07 Mar 2013 06:08:00 -0500

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

Fri, 22 Feb 2013 07:55:00 -0500

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

Thu, 18 Oct 2012 07:47:42 -0400

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

Tue, 11 Sep 2012 05:47:00 -0400

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.

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

Wed, 25 Jul 2012 12:57:00 -0400

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

Thu, 28 Jun 2012 05:55:00 -0400

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

Tue, 19 Jun 2012 05:45:00 -0400

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?

Sometimes

Mon, 16 Apr 2012 09:23:00 -0400

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

Mon, 16 Apr 2012 08:09:57 -0400

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

Tue, 27 Mar 2012 04:47:00 -0400

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

Mon, 26 Mar 2012 07:36:00 -0400

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

Sun, 25 Mar 2012 06:03:00 -0400

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

Fri, 23 Mar 2012 08:40:00 -0400

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

Wed, 21 Mar 2012 10:33:00 -0400

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

Wed, 14 Mar 2012 06:43:00 -0400

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?

Tue, 28 Feb 2012 11:59:46 -0500

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

Sat, 25 Feb 2012 17:01:00 -0500

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.

Responsive Summit

Fri, 24 Feb 2012 07:12:00 -0500

So the dust has settled on the first Responsive Summit.

The day was really good - a really positive discussion around a topic that lots of us are figuring out as we go.

Bizarrely the whole thing seemed to get a little blown out of proportion which is a little odd. To clarify, this was not intended as an official event, the outcomes of which were never intended to inform any form of dogma around the subject. It was merely a bunch of people who kinda sorta know of each other via twitter getting together and having a good old natter about the problems we faced.

We figured that given that we’re all just making this stuff up, it’s better to share some of the ideas, techniques and problems we have in getting RWD to work and then put a summary up - in one place - for those conversations and any potential solutions for the problems discussed.

Half the battle with a distributed community like ours is that there are answers to a lot of these things out there. The trouble is they exist on random blogs, forums and personal sites. Finding it is a nightmare.

So one really positive thing that came out of yesterday is that one of us will stick together a site where we can pull all of that stuff together - owned by no-one in particular (other than to maintain it) but a place for the community to post “stuff” like snippets of CSS, JS, longform techniques etc… Then its up to all us to field test those bits and let the good stuff naturally float to the top through voting or whatever. I know personally I have folders full of little experiments and I know plenty of others who do too.

I don’t want to get into the whole backlash thing - that’s just a little sad. Sure the name was a bit dumb. That was my bad but was meant to be silly and entirely tongue in cheek. Hey ho, you live and learn…

What I do want to mention though is how the whole thing came together over a couple of hours over twitter (here’s the whole thread for those who can be arsed) which in itself is a pretty amazing thing by itself and surely a good precedent for anyone else that wants to do something similar (hint).

So there we are. Wanted to get that down while it was fresh but we’ll be posting up a fuller summary of what went down later next week.

Iamburley's Blog: What's with all the Sharing?

Sun, 11 Dec 2011 06:17:40 -0500

Iamburley's Blog: What's with all the Sharing?:

iamburley:

I have been in Twitter’s company for about a year - a veritable beginner by lots of my colleagues standards. I properly struggled at first. Why tweet? I thought. Who cares what I have to say, about anything? Especially the mundane - but actually time has shown me that is exactly the beauty of…

Tomayto Tomahto

Mon, 14 Nov 2011 06:00:00 -0500

I Guess it just boils down to Semantics…

How many times has that been the bewildering footnote to an epic duel between two empassioned geeks on the Twitter?

You often hear stuff like that after the realisation dawns three hours and countless 140 character bile nuggets later:

“…we mean kinda the same thing but we’re describing it differently”.

That’s the nature of semantics in a nutshell. With all the best will in the world they are still inherently arbitrary, and prone to ambiguity in the same way any subjective thing is. Even more so when the communication of that meaning is written or indirect. We try to apply rules and contextual hooks to help lean towards a certain semantic wrapper or definition, but humans are notoriously crap at agreeing on things.

If you’ve been working on the web for a while you’ll no doubt have been involved in a rather extended debate about what particular tag to wrap your content in. Should this be a <section> or an <article>? Is this really a list? At some point someone has to make a call. And that call is based on personal choice. And it’s that moment where the true value of semanticity comes into question. If something means something to you and something else to someone else, then who is right?

We can’t police semantics, it’s impossible to validate against free will. We can only try to get to a point where meaning is close enough to be of some value to us or the machines that need to work with it. And we have that with the new semantic wrappers in HTML5 which are a big step in the right direction - structurally helpful but still baggy enough to allow ambiguity to slip in. As a set of best practices they work well and certainly aid the readability of markup by removing a lot of the need for extra class names etc.

However, the point I’m building up to is really who are semantics for these days? Molly Holzschlag gave a great précis of the rationale for the initial drive for semantics over the weekend on Twitter. Primarily because assistive technologies were so cacky, the web community basically said screw you we’ll try and fix this from the inside. It dovetailed nicely with the standards movement too, and us lot who built the web, did our bestest to make sure the stuff we made conveyed as much meaning as possible. The problem was it was our meaning, which could be spot on, or could be complete nonsense.

We’re in a very different place now technologically. Having our markup machine readable through semantic markup is no longer a necessity. Look at Apple’s Reader technology in Safari. It happily sifts through the shittiest of markup and manages to deliver a pristine version of an article sans clutter. Similarly for events inside Mail app, without any markup whatsoever it figures out things that look like dates or events and provides calendaring functionality off the back of it. Search engines are pretty clever too these days - and they couldn’t give a flying fuck about what your content is wrapped in.

So what i’m getting at is this.

Machines are smart and getting smarter daily. They’re also impartial and use hard data instead of opinion to inform their choices. We already trust them with categorising and contextualising so much of our content already, and yet somehow we still have that distrust and slightly holier than thou attitude about controlling stuff that - dare I say it -perhaps isn’t that important any more.