If you’ve been building websites during the past two years you must know that the web doesn’t live on a desk anymore. The reality is that we now need to test our work on multiple devices, instead of just few desktop browsers. All this is easier said than done. It’s easy when you have a dozen devices laying on the desk in front of you, but what about the rest of us? Devices are expensive and the landscape is ever expanding.
The reality is that we now need to test our work on multiple devices, instead of just few desktop browsers.
That is the reason why we decided to set up an open device lab to Kisko’s office. ‘Open’ meaning that anyone can pop round, use the devices freely and contribute by lending their old devices to us. The list isn’t very long yet, but it will grow over time. I am also planning to contact few device manufacturers to help us out here.
Joni Korpi and I are leaving our spare devices at the office for testing purposes and we are hoping to see others to contribute too. Kisko Labs is also—in addition to the space—giving four devices for testing purposes. If you’ve got an old mobile device which you aren’t using anymore and it’s just gathering dust, then why not lend it to our lab. The device will of course remain yours all the time, and you can take it back whenever you want.
I will post more info about the project either here or on Twitter once we get everything up and running. I also made a site for the lab which can be found at devicelab.fi. Shout outs also to Jeremy Keith who started this whole ‘open device lab’ thing in the first place.
How things are looking at the moment:
Kisko Labs is located downtown Helsinki, next to Katri Valas park. Our address is Vilhovuorenkatu 11D, 00500 Helsinki, FI. Before coming make sure we’re at the office by sending message to @kiskolabs at least few days beforehand.
During the last week I was at the Webshaped conference listening Stephen Hay’s talk about responsive design workflow. This post isn’t going to be strictly about that, but as Stephen’s way reminded somewhat the way I work myself, it made me want to write down some thoughts about my workflow and how it has evolved during the past two or three years and how it might still evolve in the future.
About three or four years ago—when I mostly did just static width sites—my projects went through the different phases in the order illustrated below, which looks like a typical waterfall process. Back then there wasn’t much room for revisions, and what clients saw were either the wireframes or almost finished Photoshop designs.
That model kind of used to work back then, but now there’s just one problem. Waterfall model doesn’t make that much sense when combined with responsive design. Actually it wasn’t ever very optimal way to do web design, but as I and everyone around me were so used to delivering things in that specific order we never really tried to challenge that.
The new way
This is the process I use today when doing responsive web design (illustrated below). I used Mark Boulton’s workflow article and Stephen Hay’s presentation as resources while writing this. My new process reminds more agile than waterfall model and I’m going to explain each step in more detail further on.
Workflow in short: Starts from the content out and encourages to spend time to really think it through. After the first content drafts are done I convert them to HTML prototypes, open them up in a mobile browser, and look how the order of the content works there. I do sketching and visual design mostly before and after prototyping. After first sketches I usually go pretty fast back to the HTML prototype and start adding some CSS to see how my ideas actually work. The whole process happens in iterations which usually go somewhat like this: sketch → prototype → design → test → discuss until it works. The order might not be this linear in reality, but I wanted to simplify my diagram for this article.
The first stage is about information gathering, getting to know the client and research work. The goal here is to gain better understanding of the client’s business, competitors and main goals of the project. Without proper knowledge it’s almost impossible to know what the client actually needs/wants.
During this stage I ask a lot of questions like: “Why people would come to your site?”, “What is the main goal you are trying to achieve?”, “Who are your main competitors?” …and so on. You can get ideas on what to ask by browsing through project sheets of other design firms:
Planning is done based on the knowledge that is gathered during the first stage. In this stage I usually start by refining the concept and move on to work on the user stories and the information architecture. I also work on establishing and describing content elements, which can then be rated with a level of importance. Based on that importance we can then do rough HTML wireframes of the views. These last two steps are quite identical to Stephen’s workflow steps ‘Content inventory’ and ‘Content reference wireframes.’
“Text design” here means that we write (design) all the contents of the website down in textual form. This is one of the most important stages in the whole process, and yet it’s probably also the most underrated step. I say this because in my opinion it doesn’t make much sense to go any further if we don’t have the actual content at hand. Content is the reason why people come to the website and the whole process should start from that.
I often do this step in HTML without styles, as then we can instantly see how the content appears in a narrow single column layout and if the order is correct. This is also basically the way the site will be shown to users using screen readers.
Keep in mind that it doesn’t have to be the final draft yet, as we can refine it during the prototyping. This step is also possible to accomplish using text documents which works almost equally well.
Sketching ideas down is usually something which happens all the time, but it’s especially important before jumping to browser. I often test my sketches using the HTML text designs I did in the previous step (which basically mean that I add a few CSS rules on top of them).
By spending a short time sketching you can save yourself hours on the computer. Not only will you save yourself hours, you may even afford yourself some peace of mind. (…) I challenge you to start employing sketching as a part of your process and you will see a dramatic decrease in the amount of times you hit that virtual wall of nothingness.”
– Tara Roskell
Prototyping early in HTML/CSS is necessary as that’s the only way to truly see how the layout will respond to different viewport sizes. This also allows me to show the actual site much sooner to the client and react early to problems which the design might have.
Unlike Stephen, I don’t really work on “breakpoint graphs” before the actual prototyping or design. It’s good to be aware of the various breakpoints and what works for different viewport sizes—or doesn’t, and it’s probably also a good idea to let the client know what the landscape is like, but I let the actual content in the browser to be the judge when making decisions.
Below is a device breakpoint diagram which I did based on the Pragmatic responsive design by Stephanie Rieger and Metal Toad’s Simple Device Diagram. I did it because I felt that the other one was too old and the other one was just completely missing Symbian devices which are quite popular around here (click the image to view a bigger PDF version):
This step happens in iterations before and after prototyping. I still use Photoshop to do most of the design, but I’m moving more and more towards design in a browser. Especially typography seems to be something which is really hard to get working anywhere else than inside the browser (Although at the same time I have noticed that if I do the jump too early, everything will end up looking flat, uninspiring and somehow cluttered).
The most important part here is to use a tool which doesn’t restrain your creativity. It can be the browser, Photoshop, Fireworks, InDesign or anything else that feels right.
Introducing testing as a part of your process early will save you from having bigger problems later on. Just look at the device breakpoint diagram I did and add all the browser quirks on top of that, and you should start to understand why it’s almost impossible to build responsive sites without testing them on a number of actual devices. Testing should also include user testing as that’s really the easiest way to see how the prototype actually works in terms of usability and which parts of it might still need work.
I mostly do all the testing with the devices I already have, but sometimes there’s a real need to bring in new devices or even go to a store and do some field testing there. That doesn’t cost anything, at least not yet…
Discuss with the client during all iterations. Present the actual HTML prototypes to the client and show how they work on actual devices. Avoid ‘The Big Reveal’ like Mark Boulton said.
Sketch → prototype → design → test → discuss until it works.
There is no perfect workflow. What works for me, might not work for everyone, and I have a feeling that the changes in my workflow are just the start of the transition. What I described here works best when designing websites (large or small) but it might need some adjustments to work well with web application design which is somewhat different (depending, of course, what kind of application it is). ❦
Couple months ago while I were designing a website I remembered a technique I had long forgotten. I used to use this technique before I moved from print design to web design about eight years ago and it was, for me, an essential way to utilize modular grids better. Grids in design are kind of like the scales in music. They give you a way to anchor your layout elements and typography to a certain rhythm.
What is a modular grid
A modular grid is a grid which has consistent horizontal divisions from top to bottom in addition to vertical divisions from left to right. Modular grids are created by positioning horizontal guidelines in relation to a baseline grid that governs the whole document. Baseline grids serve to anchor all (or nearly all) layout elements to a common rhythm. 
The thing is, I don’t actually even know the reason why I abandoned this good practice when I moved forward on my career. I might have though that the same practices won’t work in the digital world, but oh boy, I was so wrong back then.
This technique is also so bloody simple that I wouldn’t be surprised to hear if most of you are already doing something similar.
My method is this: While you are aligning elements to a grid, zoom out the layout (in browser or Photoshop) so much that the size of the layout is around 30-40% of the original and about the size of the iPhone’s screen in landscape orientation.
This way it’s much easier to see the balance of the whole layout—if it works or not. I also promise that it will make you much faster (and hopefully better) designer. At least that is how I feel it transformed my own process. Of course, after you have zoomed back in to see the layout in its real size, you have to then fine-tune elements and typography and start working on the smaller details.
Remember though that not all layouts work the same way and because of that you shouldn’t always force elements to a grid.
Tools to get you started
There is this tool called Modular Grid Pattern which has a Photoshop extension which allows you to create modular grids directly inside Photoshop. Then there’s also this interesting experiment which uses a fluid modular grid framework. There are also a number of tools that allow you to create and use responsive grids, but they are mostly multicolumn grids (with or without baseline grid) and not modular.
Tools are just tools though and the best way to actually start learning is to pick or make a grid yourself and start using it. Check also my resources below, thegridsystem.org for example has a lot of interesting articles and templates if you want to dive deeper.
CSS is designed primarily to enable the separation of content from presentation, including elements such as the layout, colors, and fonts. This separation improves content accessibility and provides more flexibility and control over the presentation. CSS is quite flexible language on its own, but as websites become more and more complex we sometimes need to have more control.
I’m using Sass to extend the basic behavior of CSS and this post is mostly about some basic things I’m using. I’ll also assume that you know something about Sass already and that’s why I won’t dive deep into what it actually is. If you are running OS X, you can get Sass up and running using these two commands below. The first one installs Sass Ruby gem and the second one translates your .scss file into a .css file.
Using Sass’s @import you can organize your styles into a smaller partials. @import in Sass works a bit differently if compared to CSS @import statement. The difference is that when Sass is processed all the partials will be combined into a single CSS file which reduces unnecessary HTTP requests and speeds up the loading time. I usually have one “main” Sass file where I have all my variables, mixins, etc. and where I do the importing.
This way you can separate different sections/features.
Variables are good when you need to, for example, use the same colors again and again. They allow you to specify widely used values in a single place and I usually specify them as the first thing in my main stylesheet.
The benefit of this is that when you need to later adjust or change that shade of blue, you only need to change it to one place.
Converting Pixels to EMs
One of the most useful features for me has been the ability to convert pixels to EMs without the need to use calculator. This function below does that and it works by taking two arguments, pixels and context. You can either use the default context and specify only the pixels you want to convert – or you can specify pixels and a custom context for the conversion.
Making your own grid system is also pretty straightforward in Sass. The following example is a Sass @mixin from David Demaree’s article on A List Apart which takes one argument—$span—which will be passed into our @mixin as a variable: