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)

Mobile users, tablet usability and form usability

What is a mobile web user anyway? Top 5 assumptions to avoid

We know mobile traffic is increasing, but it is important to understand what that really means and what we should do about it.

Many mobile websites make the classic mistake of assuming their users must be out and about. This is not true – huge amounts of mobile use is in the home. Other mobile websites have reduced content and functionality compared to the desktop experience, but this only serves to frustrate users.

I enjoyed this article by James Coltham, which highlights five key assumptions that we should avoid when thinking about mobile.

The key message is that although we know that different devices have different capabilities, we cannot automatically assume that this will affect what the user wants from the website.

Tablet usability

In a similar vein, Jakob Nielsen has been looking at usability on tablets, and has concluded that most websites do not need special designs for tablets.

We found that most websites are fairly usable on tablets and need only limited adjustments to suit this environment. (In contrast, using websites on mobile phones requires many more design changes to accommodate the smaller screens.)

Not surprisingly, when we asked people how they use their tablets, web browsing was universally mentioned as a top activity.

Although tablet-specific applications have plenty of usability flaws, the problems are mainly the same as those that plague traditional application design: difficult features, a mismatch with user workflow, and poor instructions that people don’t read.

How to improve the usability (and conversion rate) of your forms

I recently came across this interesting article about how to make forms more usable. Forms are often tricky to get right. This article looks like a very useful overview of tips.

How students use smartphones, and when an app is (not) appropriate

This is how students actually use smartphones

Gareth sent me this interesting infographic about how students use phones. A few interesting stats stood out for me:

  • 29% of students say they use their phone for learning.
  • 88% say they use it for surfing the web.
  • 78% say they access an academic service using their phone.

Mobile app vs mobile website design: your four options

Once you decide you want to reach users of mobile devices, the temptation may be to create a smartphone app. But often that is the wrong approach.

Here, Paul Boag outlines the four options you may take to reach mobile users. He concludes that when users are trying to access information, a responsive web design – rather than an app – is the way to go.

We’re not ’appy. Not ’appy at all.

The Government Digital Service explains why they are focusing on the mobile web, not native mobile apps, to deliver digital services. The comments section also contains an interesting discussion:

Interesting that you don’t mention what seems to me the most obvious reason not to have gov.uk apps – I don’t spend most of my time interacting with the government. I’m not going to install your app and have it clutter up my phone, demand updates, etc, just to book my driving test (once or twice in a lifetime) or pay my VAT (once a year). This is exactly the kind of occasional use the Web is good for.

Multiscreen; writing for the web

Windows on the web

This article is about multiscreen, the increasingly common phenomenon whereby web users begin a task on one device and complete it on another. It is interesting to note that the most common device to start a task on is now a smartphone. This is a big reminder of how important mobile is today.

90 percent of people start a task using one device, then pick it up later on another device—most commonly, people start a task on smartphone, and then complete it on the desktop…

When people start a task on one device and then complete it on another, they don’t want different content or less content, tailored for the device. They want the same content, presented so they can find it, navigate it, and read it. They imagine that their devices are different-sized windows on the same content, not entirely different containers.

It is important for us to bear in mind that different people use different devices. But it is increasingly common for one person to use multiple devices. We need to ensure that people have a consistent experience across multiple devices.

The new multi-screen world: understanding cross-platform consumer behaviour

Google’s highly interesting and digestible report on multiscreen. There are also some interesting findings on how people shop online. I wonder if this also applies to shopping for university courses online.

Please note that this report is now almost a year old, so there have probably been a lot of changes since then too.

Smartphones are the backbone of our daily media use. They are the devices used most throughout the day and serve as the most common starting point for activities across multiple screens. Going mobile has become a business imperative.

Writing for the web — highlights from the Nielsen Norman Group Conference

A web editor reports back from a writing for the web class put on by one of the most influential usability experts. There are some great tips here. This is a must-read for anyone creating content for the web.

Written content is key. Despite what your graphic designer might tell you (and I love the ones I work with), it’s the words on the page that have the most impact on users – not color, not format, not layout. Not blinking boxes or popups or videos. Words are the quickest, simplest way to communicate clearly with users. And they are by far the most effective element on a website for building trust and credibility.

Printing out webpages

Did you know that all University webpages print out in a print-friendly format automatically? From time to time we are asked if we can add ‘print-friendly’ pages to the website. But this functionality has always been on the website, using a technique that is over a decade old.

In modern web design, the visual look and feel of a webpage (determined by cascading style sheets or CSS) is kept separate from the structure and the content (built using HTML). This provides a great deal of flexibility, allowing us to present the same document in different formats without the need to maintain multiple separate webpages.

When you view a webpage in your web browser on a desktop computer (and, increasingly, a mobile phone), you will typically be presented with the webpage with a CSS style designed for screen media. This allows us to show off a bit and use the freedom of the screen to the full to create the rich, interactive webpages we are all familiar with.

A style sheet designed for print media can remove many of the elements of a webpage that just don’t make sense on a printout. So most colour is removed and all text is displayed as black on white, saving on ink. Navigation menus are removed because the clickable printout still hasn’t been invented yet. And in place of hyperlinks in the main content area, we display the URLs of all links so that you don’t have to refer back to the webpage to work out what the link is to.

What you have left is a clean, streamlined document that can be printed off perfectly — almost as though it was never a webpage in the first place. And we didn’t need to create a ‘print friendly’ version — it was generated automatically.

We are planning on publicising this feature more in the future, as it seems that many are still unaware of it, even though it has been a standard web technique for some time now.

mSaint – student portal for iPhone

Last month Duncan blogged about making the student handbook mobile friendly which was in preparation for mSaint – the new student portal for the iPhone, built on the campusM platform from oMbiel.

mSaint went live this week and can be found in the iTunes app store (search for mSaint).

Not being an Apple iPhone user I haven’t been able to get my hands on it, but from what I’ve seen on other users’ phones it looks pretty impressive.  Versions for BlackBerry and Android are promised for 2011.  I do hope there is going to be an HTML version too so that I can access it on my Windows Mobile smartphone, but that’s a whole other debate.

Screenshots

I thought you might like to see some shiny screenshots:

mSaint - Student version splash screen

mSaint - Student version splash screen

mSaint main menu

mSaint main menu

mSaint location map

mSaint location map

mSaint news feeds

mSaint news feeds

mSaint PC availability

mSaint PC availability

Window sizes and the fold

It can be difficult to design a webpage. Sure, there is a great deal of freedom. You are not limited by, say, the size of a piece of paper.

But there is, of course, a limit to what you can reasonably do with a webpage. One potential constraint is the size of a browser window. As monitors have increased in size over time, webpages have gradually become wider in order to fully use the available space.

Sometimes a web developer will be asked to optimise a webpage so that it looks perfect on a client’s setup, but not necessarily anyone else’s setup. While it may be common for something to be displayed at the bottom of a page on a physical publication, it is impossible to guess where the bottom of a monitor will be when designing a webpage.

Estimating browser sizes

There is not one set browser window size. While the vast majority of visitors use a display that is at least 1024 pixels wide, a handful are still using a display that is 800 pixels wide or smaller. Even then, there is nothing to say that the user has their browser window maximised! In essence, a user can be peering through a window as small or large as you can imagine.

Screenshot of the University of St Andrews website and browser sizes

To help us out, Google have a useful tool called Google Browser Size. This is probably familiar to those whose work focusses on the web. But it may be useful to other content creators and website maintainers to see this in action.

Google Browser Size shows you an estimate of the browser window sizes of web users. It displays this data like a map with contours, which is then overlayed onto your webpage. As you can see, 80-90% of users can comfortably view the full width of the University website.

What about the ‘fold’?

Where is the ‘fold’? Almost everyone has to scroll to view all of the content on a normal webpage. But when does this begin to matter? At the 80% mark, where horizontal scrolling stops? The 50% mark?

It is impossible to say. The truth is that web content should be accessible to all users. If the motivation is to stop people from having to scroll, arbitrarily selecting a percentage of people who must scroll is not good enough.

But we needn’t worry about squishing up our webpages so that no-one has to scroll. The fact is that scrolling is okay. We all do it. The fold is largely a myth.

Don’t worry about where the fold is. Of course, what appears at the top of a page is important. But cramming everything up there will overwhelm users. They would prefer to scroll. Just lay out your page so that it entices your users to read on.

Designing with all users in mind

The evolution of browser window sizes is one of those challenges that can make web design a tricky job. Just as developers have become accustomed to designing for monitors at least 1024px wide, the mobile web is ensuring that we must always keep smaller displays in mind too.

The beauty of the web is that there is great freedom. We really don’t have to worry about concepts like the fold. The trick is to embrace this freedom while exercising restraint.

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.

First steps into mobile

I thought I would try and take the advice of Brian Kelly who has suggested that web team members write a post a month about their work. It is particularly interesting that after coming back from IWMW I was struck by just how much focus there was on the mobile web. It felt like it was becoming something we would be getting stuck into sooner rather than later.

Sure enough, since my return I have spent around a week working on how web pages are displayed on mobile devices. It has been a tricky problem to solve, not just because of the complexity of developing a website for mobile devices, but also because of the nature of this particular project.

Integration with mobile applications

The part of the website in question is the new web version of the Student Handbook. In this past, the Student Handbook has been produced as a physical booklet. This year, for the first time, the handbook is being offered on the web — and not as a hard copy.

One of the drivers for this has been the development of mSaint, the new mobile application that is due to launch in time for the start of this coming academic session. The application is being designed to give students access to important information any time, any where. The Student Handbook will be one of the guides incorporated into mSaint.

The challenge has been to make the new Student Handbook webpages integrate well with mSaint without compromising the standard version of the webpages. The mSaint application works by linking to the individual webpages, opening up in a new browser window on the mobile device. As such, these pages need to be displayed without the website’s normal navigation, as this is different to the navigational structure of mSaint.

This has provided us with the ideal opportunity to take our first steps into designing for mobile devices. But it has also posed a tricky problem. We need to optimise these webpages for mSaint without it having an adverse effect on the experience of other users.

Foremost in my mind has been the experience of those who are navigating through the website on a mobile browser, rather than accessing these pages through mSaint. It is (relatively) trivial to create a separate stylesheet for mobile devices. But creating an mSaint-specific stylesheet or section that does not impact on other mobile users has been an impossibility so far.

It looks like for the time being we will have to make do with offering a stripped-down version of the Student Handbook to all mobile users. Perhaps we will put a disclaimer about how the Student Handbook should be viewed on a mobile device via mSaint  — but this is far from ideal. Thankfully, the regular ‘desktop version’ (if that is what you can call it) of the Student Handbook will be unaffected.

In a separate post tomorrow I will write about what I had to do to make these webpages more mobile-friendly.

Next steps

This has been a steep learning curve. There is a lot still to learn. Just as you always learn while developing for a desktop environment, there is more than this to keep on top of for mobile.

The mSaint project has brought mobile into focus a bit more quickly than I was perhaps expecting. We are anticipating that a good mobile experience will come to be expected across the University website, and it will become a larger part of our work over time.

Horizon scanning at IWMW10

Earlier this month Gareth and I attended the Institutional Web Management Workshop 2010 (IWMW10), held at the University of Sheffield. It was my first time at IWMW, and since I still feel slightly new to the Web in a higher education environment, it was a good opportunity for me to take in the sorts of issues that are commonly faced by institutional web teams.

Turbulece (sky before a thunderstorm)

Turbulent times - we certainly experienced that in Sheffield's weather

It turns out that, right now, the main issue is the effect of the economy. The theme for this year’s IWMW was ‘the web in turbulent times’. Many of the presentations focussed on the doom and gloom. This, coupled with the horrendous weather we experienced while in Sheffield, did little to dispel the stereotype that it’s grim up north (or, in our case, a couple of hundred miles down south).

Luckily, there was plenty of techy chit-chat too. It still fits in with the theme. The web is permanently turbulent. (I think it was designed like that because turbulence creates bigger waves, leading to a more enjoyable surfing experience.)

One of the key characteristics of the web for me is the fact that it is always changing, always developing. Once you’ve got on top of it, something else comes along for you to learn. That is what makes working in the web such an interesting challenge.

An update to the language of the web

Two of the biggest developments on the horizon were covered by one speaker, Patrick H Lauke from Opera Software. The first was HTML5 (and friends), the upcoming update to the language of the web.

The headline is that HTML5 does not replace the existing version of HTML. It is the same but with “more bling”. By the looks of it, it will be much easier and more intuitive to code as well. But the specification is not yet complete, and there are hurdles still to leap in the form of compatibility, accessibility and a question mark over video formats.

We were given a demonstration of some HTML5 functionality in the Opera browser. A lot of what HTML5 adds is exciting and sensible. But I think there will be a rough period while the creases are ironed out. The demonstration was promising, but it is clearly not yet the finished product.

Nonetheless, I read an interesting article recently outlining five reasons why you can use HTML5 today. It’s definitely something we should be turning our attention to sooner rather than later.

Mobile web

Later, in a smaller breakout session, Patrick H Lauke spoke about the mobile web and how to make your website mobile-friendly. Phones are becoming ‘smarter’ and connectivity is advancing. People will increasingly come to expect to be able to browse the web while out and about just as efficiently as they can on a desktop machine.

But the mobile web throws up a whole extra set of issues, adding to the already-complex set of challenges we have been accustomed to facing for years. There is a huge range of screen sizes and browsers in use, and mobile web designs must try to accommodate them all. Then there is the question of how to streamline the website for mobiles without ‘dumbing down’ the content.

Like HTML5, the mobile web still has a bit to go. As we found out in Sheffield, the mobile web cannot yet be fully relied upon in the same way we can rely upon the web on a PC. But that is why HTML5 and the mobile web are for the future, even though we need to start thinking about them now.

Reflections on my first IWMW

Overall, I found my first IWMW to be a great learning experience. It has given me plenty to think about. Although I was of course aware of the issues surrounding HTML5 and the mobile web, what I learnt at IWMW has helped me focus on the key aspects to look towards.

In addition, there were plenty of other interesting talks. Particular standouts included Jeremy Speller’s about disaster communication in a crisis and Paul Boag’s persuasive presentation about cutting down the amount of content on an unwieldy website.

Due to the anticipated sector-wide cutbacks, there is uncertainty about whether IWMW will take place next year. I think it would be a real shame if it was not held in 2011, because at my first IWMW it was clear that the event is a hugely useful way to discuss ideas and meet people facing similar issues.