Before I go any further, I should probably point out that I’m a designer Jim, not a developer. I can code HTML and CSS and just about get away with it, but I don’t here. I’m more interested in design and content implications of responsive websites.

So what’s the big deal?

Multiple platforms

When it comes to designing for ‘tinternet’ it’s easy to think of it as just a whole bunch of different desktop computers or fancy phones. Well, sadly it’s not so straight forward anymore. It seems that almost all devices these days are being built to access the web. From mobile phones, tablets, TVs, cars, fridges and washing machines to cereal boxes* and it’s only going to diversify further.

And yes, apple could be about to shake the tree again this year with a new Apple TV, whilst most of us are still contemplating the implications of the iPad’s new retina display. So, with so many different sized displays, herein lies the problem. How do I optimise my design and content? Go for the 2048px or 960px grid system?

*Maybe not cereal boxes, but we’ve all seen minority report by now.

The perfect solution

This is why responsive design is seen by many as the silver bullet. The easiest, most cost effective way to design and implement one solid entity that will work on anything you throw at it. Job done.

As all the figures show, web traffic on mobile devices is rocketing. Hence the growing argument for designing for mobile first, then embellish for tablet, desktop and TV later. It’s a design approach that fits in nicely with the progressive enhancement model. There are even some CMS modules that can handle it all for you.

The end result is lean, well considered and full of fancy CSS and media-queries that make it look and feel rather sexy. Throw in technologies like SVG and Typekit and you could even scale for retina displays without any sweat, (let’s forget about images and IE for a moment and humour me).

OK, so it might take a bit longer to work out the design, content (less please) and structure, and you probably need to build a good HTML prototype first. But what’s not to like? The client gets great value in the long term, you just need to get them onside.

Or maybe not

But is it actually feasible to stretch or re-jig a design optimised for 300px to 2048px wide on the fly and still retain some design coherence? And what if your website has specific calls to actions, complex forms, or huge amounts of corporate information that a CMS is constantly feeding, what happens then? You can’t always maintain clean and lean.

This is where it all starts to get murky. Even though smart phones and tablets can handle complex HTML well, it’s not always a nice experience, responsive or not. Then there’s TV browsing, it can make you feel like Mr Magoo. User goals and interactions are going to be different depending on the platform. So maybe going bespoke for mobile and TV isn’t such a terrible idea after all?

So where does that leave me?

Before we all dive straight into responsive projects, I suggest we take a leaf out of the techies’ book and begin our response to the responsive question with… Well the thing is, it’s actually not that simple.

Yes it can work brilliantly in some instances, but not all. We still need to weigh up the pros and cons and as always make ROI and user needs central to the outcome.

There are plenty more articles to be found and the debate goes on, but here’s my pick of the pro responsive bunch if you want to know more.

X Booth
A list apart
Think Vitamin
Smashing Magazine
.net magazine
Golden grid system
Less Framework

Back in 2008 we were tasked with creating the brochure for the Edinburgh Comedy Festival. As part of that project, we decided that we needed a way to automatically generate the brochure in Adobe InDesign (to prevent designers from wearing their mouse clicking fingers down to little stumps).

Because each page in the brochure could potentially have a different layout (each page is comprised of a series of blocks, each of which contain a show listing of variable size), this meant that a master template could not be created that would cover every page.

The solution

After some research into InDesign and XML, it became apparent that the primary use for XML was to import data and insert it into a pre-created page template which would be repeated throughout the book, rather than down to the block level as was required for the brochure. So we had to learn how to write a script for InDesign which could be used to read our data in and lay out each page as required.

As it turned out, InDesign uses JavaScript as its scripting language (although on a Mac you can use applescript), being a web developer from before the turn of the century (does that make me sound old?), I had a great deal of experience with writing “pure” JavaScript (no jQuery, YUI nor any other JavaScript framework) which made the whole experience a lot less daunting than it otherwise might have been.

Processing XML in InDesign is relatively easy, what you do with it after that is the harder part. I found a simple but useful XML glue script written by Stephen Studley at Adobe which allows you to create an XML rules processor (located in your “Adobe InDesign CSx\Scripts\XML Rules” directory), this processor will iterate through a set of predefined rules and match the xpath you have defined with the corresponding XML elements, it then fires the associated rule’s apply method.

The general principle is:

1. Define an xmlRuleSet (an array of xmlRules)
2. Load the XML
3. Pass your ruleSet through the glue code rules processor
4. Sit back and relax as all your worries drift away (okay, maybe not this one)

A sample XML rule set using the glue code:

var myXMLRuleset = [
	new processTime()
];

/**
* get the time (as a string)
*************************/
function processTime(){
	this.name = "processTime";
	this.xpath = "/pages/page/listing/time";
	this.apply = function(srcElement, ruleProcessor){
		result = true;
			currentSettings.currentListing.time = srcElement.contents;
		return result;
	}
} //end processTime

//start processing the XML
 __processRuleSet(elements.item(0), myXMLRuleSet);//elements = document's xmlElements

In the first iteration of the brochure, each page was a 3×3 grid and each listing within the page could cover a single column, two columns or full page. The layout changed in later years to being a 2×4 layout and the size of the listings can be either single, double (1×2 vertical) or quad (2×2), because I had written the script with this in mind, it was relatively straightforward to adapt it to the new layout.

Some logic needed to be created that defined where a listing could sit on the page, to minimize complexity of the JavaScript (and maximize speed of brochure generation), the javascript code does only a cursory validation of each page’s listings, to verify that the correct number of listings are on each page and that the listing doesn’t sit outside the document boundaries.

Prior to importing into InDesign, the XML is validated via a PHP script to ensure that the correct layout has been defined (better to know before you leave your computer processing for 2 hours). The XML consists of a series of pages which can contain one or more listings which have their size defined as an attribute of the listing.

The PHP iterates through each page and counts up the total score for the page, if the score does not equal exactly the number of columns multiplied by the number of rows, then the page is invalid. It also does a little look-ahead checking to ensure that the listing would not overlap another listing on the same page (or go outside the bounds of the page).

Once the JavaScript has processed a single listing item’s XML, it creates an internal listing object (a javascript object with all the properties the listing can have), it then passes this object over to a handling function that pulls the correct listing template (based upon the attributes in the listing XML tag) out and inserts it on the page, then iterates through the placed item’s elements and sets their values to the appropriate value in the internal object.

The Templates

The listing templates could not be stored as separate InDesign files which could then be loaded in and then placed into the document, after a bit of digging however, I discovered libraries.

Libraries are collections of InDesign objects that can be stored together for easy organisation, they also have the added advantage of being relatively simple to access via a script (use app.open to open the file and then brochureLib.assets.item( itemName ) to access an item in the library).

Each library item was created in a normal InDesign document, then every element that needed to be dynamic was tagged with the same name as it’s corresponding XML rule. This tagging allowed me to write code that iterated over all the elements of the newly placed object and insert their content from the previously generated listing object.

The result

1. Reduced number of errors – since the brochure pagination is pre-determined, the only place for pagination errors is at the initial layout stage
2. An improved build time – it would have taken weeks to manually lay out (excluding the slew of inevitable content changes), it now takes hours
3. Designers are able retain their finger tips, allowing them to make those inevitable content changes and all the other tweaks that can’t be easily automated

Some tips if you want to do this yourself

1. Go metric (use mm for dimensions, it makes calculations much easier)
2. Standardise your naming conventions (including case) across everything (JavaScript variables, tags, XML), it may seem obvious to you, but it won’t be to everyone involved
3. Optimizing the javascript is very important
4. Don’t minimize the window whilst processing, if you do this then InDesign’s coordinates origin changes and the layout messes up
5. Don’t write debug messages out straight away (causes slow down), write a wrapper function and flush debug messages to the console every so often
6. Split the XML into smaller files and do them in batches (the time taken to process and layout increases exponentially).

What’s all this then?

HTML 5 video. It’s the latest buzz word filtering down from the lips of techie types. You should use it they say, it’s the future they say. Well, in all honesty, it probably is. But what the hell is it and why should it concern you? Well I’m no programmer; I like cameras rather than keyboards, so I’m going to explain this to you in the way that I understand it.

The big 5

HTML is the language that is used to build the pages of the web. HTML 5 is the fifth incarnation of this language and it includes some great developments in the way we can use online video. It’s just as easy to encode as other web video formats, such as Flash, but unlike Flash it can run video of exceptionally high quality fairly easily (meaning little or no buffering). HTML 5 is not just great for video, its graphics capabilities are awesome too. Check out various examples on the Apple website.

Cross platform

The main reason why we should all be excited about HTML 5 video is that it is intended to work across all modern platforms and browsers. If you’ve just tried to watch a flash video on your new iPad 3 you’ll know that this is awesome news! The HTML 5 <video> element is open standards, meaning it’s not controlled by one company, you can put a custom skin on it and it still works everywhere. This also means that if your browser supports it, you don’t have to download any third party plug-ins and because it’s supported natively by the browser, video playback performance is better. All good stuff. But…

The Open Standards Reality

Although HTML5 is an open standard, not all of the video codecs (the software that decodes the video) used by browsers are.

The current codec that is most widely used is called H.264, this codec is controlled by a patent and is subject to royalties for companies that create software that use it.  Although the patent holder has stated that end users will not be charged a royalty for using this codec, the creators of the software that is used to encode the video will be (which means that the software creators are likely to pass on this cost to the end user anyway).

Two open video formats (ones unrestricted by patents) which are intended to be used with HTML5 video are OGG Theora, also sometimes referred to as ‘Vorbis’, and WebM which was created by Google.  Support for these formats however is not absolute.  As of March 2012, according to longtailvideo.com, half of the major browsers (Chrome, Firefox, IE9+ and Opera) support WebM and only three of those browsers support OGG Theora (the odd one out being Internet Explorer).

Who’s using it?

Well not everyone is delivering videos in the format  yet, it’s relatively new to the crowd, but these guys are all running at least some HTML 5 video. You might have heard of them; Google, /YouTube, Vimeo, Facebook, Twitter, LinkedIn, Flickr, Wikipedia to name a few. The world has gone mobile in a big way, and companies need to adapt to their customers trends. The biggest trend right now is mobile video, and it’s only going to get bigger. HTML 5 is the platform that truly brings everyone together. If you’re looking at video on your iphone or iPad, it’s HTML5.

Future stuff

The developments in the HTML language now allow for a developer to place video in the same way that they embed images. This gives much greater flexibility in dictating when and where video will appear on a site, and going forward, this is going to mean you’ll see some really interesting video projects springing up. A great example you can play with right now is ‘The Wilderness Downtown’ by Chris Milk and Arcade Fire. It demonstrates personalised interactivity (subtly referencing Google Maps and Street View), the capabilities of HTML 5 in generating 3D graphics, and how video can be displayed across windows and at different times (best use Chrome for this one by the way).

So the scene has been set both for universal video compatibility and increased interactivity. It’s great to finally be able to put a video on a website and know that it’ll play everywhere on anything, and the possibilities for interactive online video projects are mind boggling. If you have video on your website, but you use flash and so can’t watch it on your iphone, give us a shout and we’ll hook you up to the big 5.

What Facebook Say

Facebook’s Paul McDonald describes Timeline as, “a new kind of profile that lets you highlight the photos, posts and life events that help you tell your story.”

As an individual there are probably lots of chapters that you might happily forget, and happily, there is a button for that. As a company, Timeline can be utilized to interact and promote your business to followers both old and new and draw visitors back to the founding of your company, highlighting all the great milestones along the way.

Covers and the Rules

Timeline introduces you and your business with a new ‘cover’ image.

The cover image is a roomy 851pixels wide giving your visitors a huge visual hit when they land on your new page. This space should communicate who you are, what you do, apply a creative and stand out from the crowd of billions.

But, there are a nice raft of rules as to what can and cannot be displayed here:

• Cover designs cannot include discounts or purchase messages
• You can explain what you do, but you cannot use it to display contact information such as web or email addresses, office address or contact numbers – basically no information that should go in the ‘About’ section of your page, and;
• It must not reference Facebook features or actions, such as “Like” or “Share” – gone are our arrows pointing to the ‘Like’ button

The last bullet is a crucial change to the way your business Facebook page works for you, as the introduction of Timeline has killed off the landing page.

One Landing Page

Gone are encouraging graphics which point visitors – whether discretely or not so – to the ‘Like’ button to encourage a click. Timeline will become your default landing page, giving the cover image even greater credence. The loss of the landing page is possibly the most contentious of all of the new changes and it has been lamented in the blogosphere. However, the new full width page layout is the reward, giving you much greater space to create information pages and apps for your Facebook business account.

iFrames

Owing to the switch to a full-width page to accommodate the cover image, the size of an iframe has increased from 520 pixels wide to 810px. This is a great opportunity for the design of new apps but a tad frustrating if you have a raft of iframes sitting on your current page. Frames of 520px look a little lost swimming in the centre of the new full width layout.

Apps and Navigation

Navigation tabs have dropped down into a horizontal list of ‘apps’ in below the cover image. You can add 12 in total but get ready to prioritize because only 4 will display at once, and the standard ‘photos’ app will always retain first place. The fixed location of ‘photos’ reiterates the new, visual sharing theory pushing the new Facebook re-design.

Mobile

Supported by iOS4 for iPhone and iTouch, and Android v1.8.1, Timeline brings greater flexibility and interest to Facebook on a mobile device. On your phone, photo albums are horizontally scrollable filling almost the full screen, and a thumbnail view is also available. The new visual layout prioritizes the display of images and displays all ‘check-ins’ on a clear map.

For help re-branding your Facebook business page or the creation of a Facebook app, contact us edinburgh@heehaw.co.uk.

But maybe there’s something other than just a misinterpreted design brief here?

When you’re buying design, we think it’s worth getting involved in the questions designers ask themselves when starting a project. It’s not often as simple as “make it look as good as it can”, or “follow the brand guidelines”.

Sometimes the design outcome can seem counter intuitive to those not privy to the brief. It might be that the most effective piece of design is wilfully disruptive. The designer may purposely design ‘some bad’ into it, to shock, or create an emotional reaction, or to grab attention (or more precisely, to manipulate the user’s attention around the piece). It might be that those things are more important than creating a lovely piece of design in and of itself.

We recently had a client who asked us to “make it look cheap”. That was the right solution for that product – and a lovely sophisticated design on beautiful materials would have been completely wrong. The client’s brief demonstrated a sophisticated understanding of their target market – and was a big factor in allowing us to deliver a very effective set of materials.

So maybe David Fincher’s design team are cleverer than we think – maybe there’s something tonal they’re aiming for – and they’ve got it just right? Maybe Bootleg Chic is the new Tiny people on a beach with giant heads in the clouds?

Nah – sometimes you just get it wrong.

If you observed our design team marvelling at websites fed to us through the likes of Site inspire, Abduzeedo and Smashing Magazine, the phrase you’d hear muttered most is ‘wonder how long that took”. Wouldn’t it be great to know. Exactly.

Imagine if sites by the ‘beeb’ or Nike were labelled like food in supermarkets – showing the real development time spent – maybe it would help us all set expectations accordingly. Likewise those that are heavy on ingredients, but just don’t deliver on flavour. What a leveller it could be.

Food for thought.