Designing in the browser

Cover of Implementing Responsive Design by Tim Kadlec

Implementing Responsive Design by Tim Kadlec (New Riders, 2013) ISBN 978-0-321-82168-3

As we begin to transition towards a mobile-friendly design and workflow, I’m thankful that for the last five or six years we’ve been designing primarily in the browser, rather than in graphic editing applications such as Adove Photoshop or Corel PaintShop Pro.

I’m one of these people that usually has numerous books on the go at the same time. One of my current books is this excellent book by Tim Kadlec called Implementing Responsive Design—Building sites for an anywhere, everywhere web (New Riders, 2013) ISBN 978-0-321-82168-3.

The world is changing. We now have more networked devices on the planet than human beings. In the UK people now spend around 16 hours online every week, on a variety of devices (desktop computers, laptops, tablets, smartphones, game consoles, etc.). Very shortly there will be more mobile devices accessing the web than desktop and laptop machines.

Therefore, we need to change too. One of the things the web team is currently looking at is our strategy for designing for mobile devices. We’re very much in the early stages.

What is immediately clear, however, is that this will have a profound effect on how we work as a team. Designing for today’s devices and users requires a different kind of workflow than we’ve previously enjoyed/endured (delete as applicable).

Old workflow

When I began in the web team in 2006 we would typically design a website as though it was a brochure. We started with a fixed width (around 950 pixels), and we used desktop publishing, image manipulation, and occasionally presentation software to design our sites.

It was a terribly inefficient way to work. We would first design it as though it was a document, and then have to interpret it for real in HTML and CSS to view in a web browser. It certainly wasn’t a DRY (don’t repeat yourself) process.

And it also gave our clients completely the wrong impressions. Once they had signed off on a design they expected the website to look exactly like the image we’d promised them on paper. In every browser. On all screen resolutions. And of course we couldn’t deliver it. Does anyone else remember, for example, trying to provide smoked-glass effect backgrounds on IE6, which doesn’t support alpha transparent PNG files, and modern browsers, that did?

On one website build we were brought in quite late on in the project to take receipt of a number of site designs and code them up for our content management system. It was one of the most frustrating projects I’ve worked on. We had no say in the design; we were effectively handed a photograph of a website and told “build that!”

As you might expect much of the interactive nature of the web had been ignored and we kept returning to the designers asking them “How did you envision this to work?” “This bit says ‘slider’ but where does the text go? What happens when the image reaches this part, does it slide underneath, over the top?” A lot of these things hadn’t been thought through because the designers had been used to designing for print, which is static.

A different workflow

When we worked on the current incarnation of the website in 2007–2008 I realised that we needed a more efficient workflow, and because I was more familiar with HTML and CSS than I was with the nuances of Adobe Photoshop I started designing everything in the browser.

The reasoning I gave people was very simple: nothing looks more like a website than a website. People understood that.

I found it liberating. It meant that we didn’t need to rework things: we didn’t need to sketch it in a graphics package and then code it later. It meant that we were given immediate feedback, and could see what it looked like in IE6 and deal with it there and then.

And it meant too that clients could get a very real idea of the effort and issues that go into designing a site, the issues with cross-browser compatibility (now that’s not so much of an issue), and they began to realise that not everything needed to be pixel-perfect in every browser.

To be honest, it was a little intimidating at first. If you’ve never sat in front of a client and written code (whether HTML or CSS) you can feel very self-conscious. What if you get it wrong and they lose confidence in you?

The truth is that not every designer or coder gets it right the first time. But that’s the truth whether there is someone sitting with you or not. And I found it helpful for the client to see that. “Oh! That didn’t work,” I’d say. Then I’d sit and talk through the issue out loud until I found a solution. It was helpful for the client to effectively see the working out of these issues, to see the scribbles and the code syntax look ups.

I would often explain that I would sketch it out in code, to make sure the idea worked, then I’d clean up the code later.

While I felt self-conscious, I often found the client was delighted. They could see their ideas taking shape on an actual website in front of their eyes. They could then immediately see what worked and what didn’t. It was a really effective way to work.

A responsive workflow

Now things are changing again. We’re not designing for a best-guess fixed-width site, we now have thousands of mobile devices to take into account.

We do have a lot to learn still, but we are on the right road, and already having a workflow revolves around designing in the browser is a tremendous help.

As Tim Kadlec says:

Until the wonder-tool comes along, it’s important to work toward loosening the grip of your favourite graphic editing program. Don’t remove it entirely, but start moving toward an more agile approach. Create the visuals as you code. Tackle the two hand-in-hand and you’ll be much better equipped to work on the Web. (ibid., p. 173)

Survey of university websites

Bar chart showing Scotland vs UK vs world university websites As part of our work around developing a solid strategy for the University website for next few years, over the last couple of days we’ve been doing a little ‘competitor analysis’ and have visited over 200 university websites; in all it took us around eight hours. We asked three questions of each site we visited:

  1. Responsive
    Is the homepage responsive? (In other words, does the site adapt depending on the size, orientation of the screen used to view the pages?)
  2. Log in
    Do you need to log in to view information for internal audiences (which we broadly defined as an intranet)?
  3. Standard design
    Do the academic schools’ websites have a standard design?

Similarly, we looked at three areas:

  1. Scottish universities.
  2. Top 100 UK universities (from the Guardian university guide 2014).
  3. Top 100 world universities (from Times Higher Education world University rankings 2014).

Results

The results were both fascinating and encouraging:

Scotland UK World
Responsive 21% 43% 36%
Log in 50% 59% 53%
Standard school sites 86% 91% 39%

Not as far behind as we feared

Working largely in isolation from other university web teams—apart from those few moments each year we gather at Scottish Web Folk, IWMW or T44U conferences—it is easy to convince yourself that you are lagging far behind our fellow universities in terms of adoption of the latest web browser features and standards. A recent meeting of web team members from Abertay, Dundee and St Andrews, however, showed us that we are facing largely the same issues in each institution. And these results show us, certainly in terms of adoption of a mobile-friendlier, responsive website design, we are still a part of the majority. I wish we’d carried out this exercise, say, a year ago so that we could see how quickly this is moving. Time to respond, though.

In or out?

There has been a question posed here about whether our ‘intranet’, our pages for internal audiences, should be available to the general public or whether they aught to be secured behind a login. From this limited sample of approximately 200 institutions, around half restrict access. I’m still trying to figure out what is the exact question that we’re asking here. Is it simply about making some information unfindable by the public, or is it more about providing a more focused experience for external audiences, particularly in the area of search. Currently when someone enters a search term into the search box on the homepage it returns results from the entire University website: over 250,000 pages. Should we be displaying results only from sites that are relevant to external audiences (e.g. information for prospective students, administration A-Z, about the University, school websites, etc.)?

Standard school sites

Finally, we were surprised—but encouraged—by the high percentage of sites that offered a standard look-and-feel for school websites. We would never have guessed, for example, that 9/10 of UK websites would offer this.

Conclusion

This has been a valuable exercise. It would be interesting to repeat this exercise in 12 months’ time to see how the landscape has changed, particularly in the area of responsive design.

Grid—a simple guide to responsive web design

Grid—a simple guide to responsive design by Adam Kaplan.

Grid—a simple guide to responsive design by Adam Kaplan.

It feels like the web is evolving at a frightening rate these days, and while we’re being encouraged to design for mobile first even the technical specifications (particularly HTML5, and CSS3) haven’t settled down yet and are still subject to change.

For example, there is currently a lot of energy being put into how to deal with responsive images: you don’t necessarily want mobile devices (possibly with smaller screens and slower bandwidth) to download images that would be more appropriate on desktop browsers, with larger screens and possibly fibre-optic broadband connections.

If you are feeling a little overwhelmed by it all and wondered where to start then I can recommend Grid, a simple guide to responsive design, created by Adam Kaplan, a designed from Chicago.

In seven simple steps he unpacks all the important stuff: why and how. And then he ends it with an encouraging, non-threatening challenge: practice makes perfect.

New framework for responsive HTML emails

Quickly create responsive HTML emails that work on any device & client. Even Outlook.

Quickly create responsive HTML emails that work on any device & client. Even Outlook.

Ink is a fairly new framework from Zurb, who brought us the Foundation CSS framework, for creating responsive HTML emails.

It’s been a while since I’ve been asked to help put together an HTML email but as news of this new HTML email framework dropped into my inbox this morning I thought it would be useful to share it.

As anyone who has been charged with creating HTML emails, and told that they must look equally good in Google Mail, Outlook and any other client, will attest it’s not entirely straight-forward. Not least because, well, who wants to go back to using tables for layout?!

Newer versions of Outlook (2007 and 2010, I’m looking at you) don’t help either as they use… wait for it… Microsoft Word to render the HTML!?

I don’t have any need for creating HTML email at the moment, but this really looks interesting. I may just have a play with it one lunchtime.

Download Ink from Zurb