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)

Advertisements

Ten guidelines for university websites from the Nielsen Norman Group

University Websites: Top 10 Design Guidelines by Katie Sherwin on NNG

University Websites: Top 10 Design Guidelines by Katie Sherwin on NN/g

Last week (Sunday 19 January) the Nielsen Norman Group published an incredibly helpful article offering ten design guidelines for university websites: University Websites: Top 10 Design Guidelines.

Their summary:

Effective university websites can increase conversions, strengthen institutional credibility and brand, improve user satisfaction, and save time and money.

The web team are currently writing a business case and strategy detailing how we propose to take the University website forward over the next few years, particularly as access to the web using mobile devices is predicted by some to overtake desktop/laptop use this year.

Our focus will be on three activities:

  1. Standardise
  2. Simplify
  3. Consolidate

Publication of his article has come at just the right time for us, and is a good companion to this oft-referenced cartoon on xkcd: university website.

Updating the University shield

Move and replace dialog box

Updating the University shield in my SVN working copy.

Here’s a minor update that I made to the University website this afternoon: I updated the University shield across most of the central website.

As you can see from the screenshot above, the problem with the old one was that, while it looked fine on a blue background, when it was embedded on a white background (for example, if someone linked to a University page from within Facebook, or was printed) then it looked awful!

So I created a new one, at the same dimensions (42 x 52 pixels) and for the first time it now adheres to the new corporate identity guidelines…

Dimensions for University shield on a webpage

Dimensions for University shield on a webpage

It the little things that make me happy!

Update

A couple of people have asked me on Windows Live Messenger and on Twitter why it was like that in the first place.

Well, it was to do with a slight colour mismatch between the graphic files we got from the designers (who were using CMYK values) and the web team (who were using RGB values). So we made the shield’s inner blue colour transparent so that it could pick up the RGB colour in the header behind it.

It seemed like a good idea at the time.

I’ve been meaning to change it for some time, since receiving the new batch of updated University crests months ago (in which those who pay attention will notice that the lion has lost his genitals). And with today being Fix-it Friday… I fixed it.

The next time we do a major refresh of the University website’s design I expect we’ll use a PNG and some tasty alpha transparency for that even smoother finish.

Keeping a collection of screenshots for inspiration

Collage of website screenshots that I use for design inspiration.

Example collage of website screenshots that I use for design inspiration.

Back in late 2008 I read an interview with a Web designer who advocated keeping a scrapbook of cool designs that you’ve seen so that when the time came for Needing Inspiration™ you already had a volume of stuff to look through and be wowed by. It was a discipline that he’d picked up from art college, seemingly.

What a brilliant idea I thought and promptly started my own collection.

I keep two collections:

  1. One is for stuff that I cut out of newspapers and magazines that I glue into an A4 Black n’ Red spiral-bound notebook (simply because that’s what I had to hand).
  2. The other is for screenshots that I store in Dropbox in a directory called ‘Cool designs (inspiration)’.

I started to use Flickr for storing the screenshots but Flickr requires that you own the images, and technically I don’t as they often contain copyrighted designs. Also Flickr requires online access (which I can’t always guarantee) and it’s relatively slow for this process. I’m currently using the image viewer in Google Picasa to quickly navigate through the screenshots.

To grab the screenshots themselves I generally use SnagIt —it’s especially useful for long screens that require scrolling, SnagIt captures it automatically—but occasionally I resort to the good old Windows shortcut Alt+PrtScn.

These collections of screenshots and my scrapbook I find really, really useful. At the moment I’m working on a redesign of the University’s sport website and this has been a great resource to give me ideas and suggest alternative ways of laying out information. I recommend it highly.

Developing a new theme for Moodle 2.0

At the start of the current academic session (2010-2011) the University introduced Moodle as its preferred learning management system (LMS), also called a ‘virtual learning environment’ (VLE) and began the move away from WebCT (which is now owned by former rival Blackboard).

Moodle (which I discovered is an acronym for Modular Object-Oriented Dynamic Learning Environment) is an open-source application which of course means that it’s free… up to a point: you still need to install it, configure it and create a new visual theme for it should you require. And that’s exactly what I’ve been doing this week.

screenshot

A dream to work with

Over the last few years I’ve worked on the redesign of quite a few third-party Web applications. Some have been easier than others. One quite literally drove me to tears with frustration. Moodle 2.0, though, has been an absolute dream to work with.

Moodle 2.0 is written in PHP which I have quite a bit of experience with, so that greatly helped. Having the right mental model of how something works really helps when you’re only working with one aspect of an application.

It also helped that we have a very helpful and responsive Moodle development team located within the School of Computer Science who have been great to work alongside.

Great documentation

The way that Moodle have organised how their themes work is logical and pretty clean, and the documentation on developing Moodle 2.0 themes is really good.

And I mean really good: it’s usable. I spent an hour or so carefully reading through the documentation and then got stuck in.

I did what many advise and started with an existing core theme and adapted it for our use, which took me about half a day. The rest of my time was spent working on icons.

Icons

I didn’t really like the default icons in Moodle, they looked quite pre-Windows 3.1. So I decided that I’d try to replace them using the excellent Silk icons set by FamFamFam.

Well, lo and behold if Moodle doesn’t also have an excellent document on how to use images within your theme as well as an example silk icons theme! Someone has already done the work for me!

I discovered that the example theme doesn’t contain all the icons we’re using and it didn’t customize the smilies so I complimented Silk with two other 16 x 16 pixels sets:

All-in-all that gave me over 4,500 icons from which to choose.

Moodle logic for icons, example 1

Something that really helped me was understanding the logic that Moodle uses to determine which icon to use. I was helped by this thread on the Moodle forum.

I discovered pretty early on that if your theme doesn’t provide a particular icon then Moodle will just use its own default icon. You include your own icons within three sub-directories within your theme folder:

  • /pix
  • /pix_core
  • /pix_plugins

Using Firebug or Chrome’s Web developer tools look at the URL of the icon you want to replace.  You’ll see that it looks something like this:

http://example.com/moodle/theme/image.php?theme=newtheme&image=icon&component=qtype_multianswer

The important bits are in bold which are, in order of appearance:

  • newtheme is the name of your theme.
  • icon is the filename of the icon file without the filetype suffix, e.g. icon.gif, icon.jpg or icon.png.
  • qtype is the name of the sub-directory. In this case (I think!) because it’s a ‘&component=’ it is a sub-directory within the pix_plugins directory.
  • multianswer is the name of the sub-directory within the above sub-directory!

In other words, that URL is for an image within this directory:

/theme/newtheme/pix_plugins/qtype/multianswer/icon.png

Moodle logic for icons, example 2

Similarly, the following code

<img alt=”” class=”smallicon navicon” title=”” src=”http://turret-new.cs.st-andrews.ac.uk/moodle-2/theme/image.php?theme=newtheme&amp;image=i%2Fsettings&amp;rev=235″&gt;

will look for a replacement icon in this directory:

/theme/newtheme/pix_core/i/settings.png

You can glean that from ‘i%2Fsettings’, as ‘%2F’ is the URL encoding (also called percent-encoding) for a forward-slash (‘/’), and the word that appears beyond that is the filename of the icon, in this case ‘settings’. As far as I can tell you can use any format you like from GIF, JPG and PNG.

Clearing the cache

The way that our installation is set up, every time I made an HTML or CSS change I had to clear the theme cache which was as simple as logging into Moodle 2.0 and navigating to Administration > Appearance > Themes > Theme selector then clicking on the button at the top of the page: “Clear theme cache”.

Later on in the development I discovered that Moodle was also caching the information about the themes, such as the theme name and any information that appears once you’ve activated a particular theme. I needed to get the Moodle administrator to clear that for me.

Conclusion

This has been a surprisingly fun project to work on. Surprising only because of my experience with other less-well designed systems. I wish all Web applications were this fun and this easy to edit.

Download

A number of people have emailed me asking for the theme and icon set that I developed/extended. Feel free to download the file below, on the understanding that I can offer no technical support on it.

This theme is released under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

About

University of St Andrews is a fluid-width, three-column theme for Moodle 2.0 that was adapted by the University of St Andrews web team, based on a theme called Leatherbound created by Patrick Malley.

Tweaks

This theme is built upon both Base and Canvas, two parent themes included in the Moodle core. If you want to modify this theme, we recommend that you first duplicate it then rename it before making your changes. This will prevent your customized theme from being overwritten by future Moodle upgrades, and you\’ll still have the original files if you make a mess. More information on modifying themes can be found in the MoodleDocs.

Icons

License

This, and all other themes included in the Moodle core, are licensed under the GNU General Public License.

The following zip file is hosted at Let’s Crate.

Download moodle-2.zip (190 KB)

Making the Student Handbook mobile-friendly

Yesterday I wrote a post about our first steps into the mobile web. Today I will look at what I had to do to make it happen.

Learning about the principles

The first step was to think about the principles behind mobile web design. I am well versed in the principles behind desktop web design, but mobile is a different ball game. The focus is even more strongly centred on a streamlined approach — less is more.

The only other thing I really knew is that there are no easy answers. I had to do my research.

The first question to ask myself was, is a three year old book about mobile web design still relevant? Gareth let me borrow this book, and while parts of it feel out of date, there is still plenty of insight to chew over. It is particularly useful when thinking about older or non-‘smart’ mobile devices. There is a tendency nowadays for articles about mobile to be heavily focussed on iPhone and Android. While this book does feature the iPhone, it is much more about the wider principles of mobile web design.

I also found it useful to take a look at Patrick Lauke’s slides about the mobile web, which he delivered at IWMW. These are more up-to-date, and it was useful to refresh my memory about what I had learnt.

There are three major approaches to tackling mobile:

  1. Do nothing and hope for the best.
  2. Create a separate mobile site.
  3. Adapt what already exists.

Option 3 was the only one really open to us. This option requires compromises to be made. It probably also leads to the largest file sizes. But it is easier, and if you use web standards and code your website well, it should work well enough on a mobile device.

The stylesheet

The first step was to create a stylesheet optimised for mobile devices. A decision was taken early on to focus on the current generation of browsers, as mSaint is designed primarily for smartphones. Mobile Safari, Android and Opera Mini and Mobile all ignore stylesheets with the attribute media="handheld". Modern mobile browsers like to think of themselves as a cut above that sort of thing. They try to render a webpage more or less as you would expect it to on a desktop.

(Handheld stylesheets have always been shakily supported anyway. I have created one nonetheless as a fallback for any mobile browsers that prefer to deliver a webpage in this way.)

But accepting that modern mobile browsers will render the desktop version was not an option in this case. The technique around this is to use CSS3 media queries, which allow us to dictate which stylesheet is used based on the width of the device or browser window. Perfect for adapting content for mobile!

There is a good tutorial on how to use media queries. Guess which browser doesn’t quite like it? Internet Explorer’s issues were the source of some of the biggest puzzles I faced. But since I figured out how to make IE play nicely, it has worked well.

Design

So that it integrates well with mSaint, we have removed a lot of the devices that you find on a standard University webpage. The header, main navigation, left hand navigation and footer have all gone. Basically, everything except the content has gone. Thank goodness for display: none;!

Much of the rest of the stylesheet has been lifted straight from the existing stylesheets. So it should look and feel pretty familiar to regular users of the University website. The other major change I made was to lay out all of the content so that it sits in one mobile-sized column. So any items that appear in the right hand sidebar on the desktop version of the Student Handbook will appear beneath the main content on the mobile version.

When deciding on the ideal width of the column, I settled on a maximum width of 480px. This is the width of an iPhone in landscape mode. But I did not just make this decision with iPhone goggles on. Looking at standard screen resolutions for mobile devices (QVGA, HVGA, VGA and WVGA), 480px is the dimension that comes up the most.

Viewport

The main thing that I have learnt that I was not aware of before is to do with the viewport. The iPhone automatically displays every webpage as though it were 980px wide, and this becomes the scrollable area of the webpage. But if you have optimised the content specifically for mobile display, this is no good. The text is zoomed out and unreadable. The user must manually zoom in, even though there is absolutely nothing on the rest of the page.

The answer is to use the viewport meta tag:

<meta name="viewport" content="width=device-width" />

This tells your mobile browser to automatically zoom in as though the web page were as wide as the mobile device. You can also set a specific width, as well as setting an initial scale and control how far the user can zoom in and out. Originally introduced by Apple for Safari, it seems as though most modern mobile browsers recognise and support this — though this hasn’t been without its problems.

I have been a bit iffy about including the viewport meta tag on these standard web pages. From what I gather, its presence is supposed to indicate that the webpage has been optimised for mobile, which ours hasn’t. It also appears to alter the behaviour of Opera Mobile (by disabling the mobile view option). However, it appears to have no effect on the way desktop browsers display the page, while making it look much better on mobile devices. So we are sticking with it for the time being.

But just when I had got my head around how to control the viewport, imagine my shock when I discovered that a pixel is not a pixel. That is to say, the number of pixels on your device is not the same as the number of pixels that appear to be displayed. Accommodating different screen sizes and resolutions seem complicated at first, and unfortunately it only becomes more complicated as you learn more!

Apple have a very useful guide for developers called Safari Reference Library. It was hugely useful in helping me understand about the viewport and a lot of the other quirks of Safari for iOS, such as automatic text resizing. I think Safari tries to be too clever for its own good sometimes. This makes it a brilliant mobile browser overall, but it is quite frustrating as a developer to try and work out precisely what it is doing.

Incidentally, Opera also have a good mobile web optimisation guide.

Testing

Testing for mobile is notoriously difficult. There are hundreds of different devices, operating systems and browsers out there, with radically differing capabilities. Testing every possible combination is even more impossible for mobile. It makes designing for desktops look like a piece of cake.

The book Mobile Web Design by Cameron Moll contains a highly interesting section about Yahoo!’s procedure for testing their 2006 FIFA World Cup mobile site. By selecting a range of 5-10 devices from top- to bottom-end to test on, they felt that they had covered a wide enough range for the website to work on most mobile browsers. The technique paid off for them as it was a hugely successful website, attracting a peak of 290 million page views in one day. And that was four years ago. Incredible!

We are not aiming for that sort of audience, so our testing has been an even more modest affair. I used my own iPhone to test it in Safari and Opera Mini. But this has been quite frustrating as it is very difficult to get a signal in my office. Upstairs, my colleague has also been testing on an Android emulator.

The Opera Mobile emulator has also been hugely useful, particularly for comparing different screen sizes. How important Opera Mobile actually is, I am not sure. At the end of last semester, around 1% of visits to the University website were on a mobile device. Among those users, Opera does not appear to figure as highly as I had expected.

There is more information about mobile emulators here. These are highly useful tools for finding out how a mobile browser will render a page. But unfortunately they tell us little about how it genuinely feels to use a website on a particular type of device.

Launch of new website design

Screenshot of new website design

Screenshot of new website design

Following consultation with staff and students, and nearly nine months of work we launched the new website design for the University of St Andrews during the early evening of Monday (8 September).

Unlike the website launch in May 2007, which combined for the first time all 27 of the support unit websites into one enterprise-wide site, this re-launch was more of a design update than a radical restructuring of information.

Feedback sessions

Back in February 2008 we meet over the course of three lunchtimes with both staff and students to elicit feedback on what people

  • liked
  • disliked
  • thought was missing (both information and features)

Those sessions were very helpful, and feedback from those were thrown into a melting pot of ideas that had also been compiled from Helpdesk calls received since the launch of the new site in May 2007, as well as our own thoughts and observations from using the site for nearly a year (remember, we had access to it for a few before it went public).

Re-design goals

Our redesign goals were quite clear:

  • Make the site easier to read
  • Offer more variety/flexibility in terms of layout, e.g. 2, 3 and 4 column
  • Ensure that it works in more browsers
  • Add new functionality

On the whole we’ve managed to achieve this, and the feedback during the last month when the site was quietly released to staff and students within a closed preview has been very positive.

The techie bit

When designing and building a new site you have to decide from the start which technologies you will definitely support and which you will try to break as least as possible.

We’ve built the site around a grid-based CSS framework called Blueprint CSS, which offers us a number of advantages such as ensuring that the site is built using accepted Web standards, a well-designed and attractive typography. It also makes it painlessly simple to develop new site designs and layouts.

Much of the new functionality (such as the carousel of images on the homepage, and the tabs on the Current Staff and Students’ pages) is largely provided using the jQuery JavaScript library.

While writing new features using JavaScript can be a long and arduous process the jQuery library allows you to do it in a fraction of the time — some of the functionality added to the site took less than a minute to write! It also works with a lot of modern browsers (Firefox 1.5+, IE6+, Safari 2.0.2+, Opera 9+).

Browsers

Speaking of browsers, based on statistics gathered by our Google Analytics account as well as Yahoo!’s guidelines for Graded Browser Support we settled on ensuring that the latest browsers received the best experience possible.  This included:

  • Firefox 2.0
  • Firefox 3.0
  • Internet Explorer 6
  • Internet Explorer 7
  • Opera 9.x
  • Safari 3.x

We tested the site back to Firefox 1.0, Internet Explorer 5.0, OPera 7.5 and Netscape Navigator 7.0, with varying degrees of success.  On the whole though the site is still usable in these older browsers, even if it doesn’t look exactly as it does in a modern, standards-compliant browser.

One major issue that we have become aware of is that the site crashes when viewed in Safari 2.0.4 (419.3) on a Mac. The issue it would appear is to do with how Safari handles JavaScript.  According to JavaScript expert, and jQuery author John Resig:

“Safari 2 has serious memory issues that are impossible to work around – simply loading and executing too much JavaScript will cause it to crash.” (J Resig, jQuery discussion group)

Our advice, following the graded browser support guideliness, would be to either disable JavaScript or upgrade to a more modern browser, such as Mozilla Firefox (the site works in everything back to Firefox 1.5).

Going live

Going live with a site is a strange experience of mixed emotions. There’s a combination of both elation that the site is going live, mixed with a little anti-climax and the nervousness of waiting for support calls to come in, hoping that we haven’t missed anything obvious.

On the whole, as a Web Team we’re really pleased with the results and the encouraging feedback that we’ve had from users, but we won’t stop there … there’s much still to be done, content to be improved on, sections to be reorganised and even more features to be added.