Hello everyone and thanks for having me here. My name is Alexander Baxevanis, and I’m a Senior Consultant at Webcredible. 

No content

No content

The motivation for what I’ll be talking about today came from one of my recent projects, which was a very data-intensive website. I can’t say more about the kind of data we were dealing with, but what I can say was that one of the design goals was to fit as much data in the screen as possible, and avoid unnecessary whitespace. In fact you can imagine this being the goal in many different websites – for example if you have a shopping site you want to showcase your products, not whitespace, right? 

So this design problem was what initially got me to try and learn more about responsive web design. Who here has heard this term? For those of you who haven’t I’ll go into a short introduction 

A lot of the times, what we deliver as the output of a design process, is a wireframe like this, hopefully designed to a grid. The is often fixed to a commonly acceptable minimum width (960px, fits quite nicely on a 1024x768 monitor) and much less frequently fluid, which means it allows a bit of flexibility for different screen widths. You may have noticed I said a bit of flexibility – this worked fine for a while, but we now live in a world where people’s screens look more like this  

I’m really curious who out there has got a WQXGA screen … but if you forget about the crazy acronyms, this isn’t just theory – if you design a website, chances are it’s going to be displayed in many of these resolutions. If you don’t believe me, take a look at our analytics from the Webcredible website. 

Over the last month, we’ve seen at least 9 different screen resolutions with a share that’s large enough to see in this pie chart, ranging from around 5% to around 15%. And here’s close to 3000 people having this weird WQXGA resolution. I actually looked up how much monitors with such resolution cost, they’re over 400 pounds. These might well be some of your most tech-savvy, early adopter customers. On the project I started talking about, I also ran some remote usability testing sessions, using screen sharing software, and I was able to see the variety in the sizes of screens that people use. So you can see that building websites for a fixed canvas isn’t cutting it any more. The technology to address this is getting there  

Technologies like CSS3 Media Queries – which allow web developers to specify very precise rules about the way a page should be laid out in different screen sizes … And there’s a lot of smart people out there trying to get things like that to work in a variety of web browsers, and solve all sorts of practical problems, such as how to get small screen devices to download low-resolution images that fit their screens, instead of high-resolution images that are just a waste of bandwidth. 

You’ve probably already used a lot of sites out there that follow a responsive design – you probably just haven’t noticed as you don’t really go around resizing your screen, so here’s a quick demo. [2011 dConstruct website, 10K apart] So, all fine with the finished site, but what happens before we reach this stage? 

There’s usually a design phase before this – starting from sketches all the way down to wireframes. And a lot of the tools that we currently use in these early stages aren’t really suited to responsive design. Sketching on paper - you can't easily stretch or reposition things  

Tools like Axure (or Omnigraffle, or inDesign, or your favourite wireframing tool) – they all work to a fixed canvas. I love Axure, I even created an Axure training course that I teach at Webcredible, but I'm now starting to see it's limits. 

As you’ve seen in the demo, there’s multiple things you can do to adapt content to different resolutions. This is something that needs to be designed, rather than determined by chance. You can't just continue designing to a fixed grid and hope that whoever builds the site comes up with a good way to make it responsive. So what can we do? There's a few solutions - I'll start from the ones that I’ve seen people proposing around the internet, and then I’ll move to a couple of things that I’m coming up with as I’m trying to integrate responsive design in my workflow. 

The first solution is probably the most obvious one - if there's a technology that will be used for building the finished site, why not use it from the start to make your wireframes? Let’s see a demo of what it could look like: Demo: http://blog.stormid.com/files/responsive-wireframes/tramway/home.html 

So what are the pros & cons here? … – solving technical issues can be a barrier on creative thinking 

So, if we can’t build it in code, another solution is to create distinct wireframes for key screen widths. 

So what are the pros & cons here? … Demo: http://dropbox.headscapedev.com/projects/wireframes/demo.htm This is close to what we want and how we build it but I think the real trouble, especially on a content/data heavy website won't show up in the templates. 

This is very much an uncharted territory - I don't think we’ve found the best solution yet, but I've got a couple of ideas that I’d like to share with you today Going back to thinking responsively from the beginning of the design process. We often start from sketching on paper, and I love sketching because you put in the minimum possible effort in everything you try, there’s very little friction, and it you can easily tear it up and start again. Remember when I said paper isn't really a responsive medium - well that's not really true. 

My solution, which is often the solution in many UX problems, is to use the power of post-it notes. To experiment with layouts for different screen sizes, instead of sketching on a blank piece of paper, use a separate post-it note for each part of your sketch. And there's a lot of different sizes of post-it notes you can use 

By using different colour post-its, you can keep track of different major sections of your content Obviously you still can't stretch or shrink a post-it note, but you can do things like folding it, cutting it in half, or sticking a second one next to it to expand it By doing it this way you can get a general feel about what happens to your content, and also make sure that you don't miss anything important as you transition between different sizes. OK, so how does this work in practice? I’ve got these post-it notes with me so let’s try a little demo… … So, that’s a quick way of coming up with the overall layout in different resolutions, but what about the details of your wireframe? 

As I said before, it's probably impractical to create alternative versions of each page for different screen sizes. But it should be more easy and practical to consider and specify how parts of the page will behave as the page resizes. This requires extending the language that we currently use to create wireframes with some new notation. I’m not the first person to suggest adding a custom notation on top of sketches & wireframes.  

For example, a guy called Matt Gemmell who designs and builds mobile apps, has come up with this notation for documenting how an app responds to various different gestures. 

So, if we wanted to document, in a wireframe, how a design adapts to different screen sizes, what could this look like? Let’s say we’ve got this typical box of content that appears somewhere in a wireframe. We could show that it’s got a flexible width… … but maybe with some minimum … and some maximum width … We could say that this button has got a fixed width … And that this image should be hidden when it becomes too small, for example under 150 pixels 

You may also want to visualise that the two ‘columns’ in this box will collapse into one. This is very much work in progress – I haven’t used it in projects yet, but I’m getting close to the point where I’ll have to. There’s probably a few more things you could visualise like that (and a few that you couldn’t), but I hope you get the general point: With a layer of such symbols over your wireframes it’s easier to communicate with the rest of your design team, and with whoever builds the finished site, what you expect to happen at different widths, without having to create distinct wireframes for each state. In the end, however, there’s more than the final deliverable – you need to start working to different principles. 

No content

No content

No content

No content