On upgrading to ‘responsive design’

Crispin – 16 April 2015

If you’ve no idea what a ‘responsive design’ is, take a look at this article.

Now that I’ve converted a number of websites to responsive design, I’m finding it easier to identify conversion issues and sticking points in the original website.

Some of the issues that need considering

Tap versus click

How many websites have Click here to … Fortunately the sense of the link text is not lost, so there is no need to change each and every one immediately. In the longer term, the website is going to look dated if these links are not rephrased.

Links have to be spaced apart sufficiently for fingers so that they don’t encroach on a neighbouring link. For the ‘small screen’ version this may mean making the overall font bigger or increasing the line spacing.

Hover style changes and titles

With a mouse, it’s possible to hover over a link and designers would frequently give a visual clue to the visitor that they are on link by adding an underline or changing the colour of the text or the containing box’s background colour.

Another technique that users encounter is that of a hover title. This gives a more fulsome explanation of what a link does when the mouse hovers over it.

Neither of these is going to work on a touchscreen, but they are still useful for the desktop rendition of the website.

Menu design

Older websites frequently use drop-down and fly-out menus. These may not work well on a small screen and so require a rethink.

Where a multiplicity of menu bars have been deployed to give the visitor no excuse for not being able to navigate, this can cause problems because of the real estate that they take up on a small screen. Rationalisation may be in order and given that visitors are more sophisticated than they used to be, lots of alternative means of navigation may be redundant.

Text in an image

In the old days (in web terms), designers wanting to use a particular font face would resort to creating images of the text that they needed, particularly for navigation items and menus, because there was no alternative. Even back in the day there were a number of issues with this approach, but now they all have to go. They should be replaced by real text with a web font if a special font is needed.

The reason they have to go is that they are not flexible in font size and width of the string of characters may cause problems too.

Table-based designs

In the old days (again), designers would use HTML tables as a means of constraining their wonderful designs into the creaky browsers of the day. If your existing website is more than five years old, it’s quite likely that this is the case.

If you feel up to a bit of technical stuff, you can check by browsing to your website and then viewing the source code (either via the menu bar or if you prefer the keyboard Ctrl-U or alt-⌘-U) and this should then bring up the page of HTML code for the page at which you are looking. Search for instances of <table – ie the table tag – in this page. If one or more exist and you have no tables of data on the web page you are viewing, then you have a table-based design.

Table-based page designs have to go.

Big tables of data

The legitimate use of the table HTML tag is to display tables of data.

Wide tables are going to present a problem on a small screen and it may be necessary to create a viewport for the table so that it can slide left and right. The example below shows a table that’s wide even on a desktop computer and, depending on the operating system, a scroll-bar will appear along the bottom. It may be necessary to have some indicator to slide the table left if it’s not obvious from the viewed data eg a column boundary falls at the table edge and there’s no reason to think that there is hidden data to the right.

Long tables and long and wide tables might also require additional thought. Hiding any information on a mobile device that will be present on the desktop version is not generally thought to be a good plan.

Web forms

Forms may need rearranging. Our own contact form has this as a desktop view:

that changes to this on a small device:

In the latter, the width of the text box is set to a percentage of the screen width to maximise the available space.

The smartphone effect

Both iPhone and Android phones will attempt to identify phone numbers in a website and, in the case of the iPhone, will change the colour of the font. You can tap on the number and you get the option to call it. This is a fabulous improvement in the user experience, but entirely ruined if your designer used text in an image for that bold, bright, imperious telephone number at the top of the page.


Portable Document Format files have their place but they are not usually good as a web page substitutes. On small-screen mobile devices there’s going to be a particular problem because it’s likely that the text will be illegible at the default size and if it’s a form that’s supposed to be filled in, there's going to be the issue of how to print it. Some people will have cracked the printing issue, but many won’t. I also suspect that many people won’t have any idea where to find the PDF they just downloaded.

The upshot is that you should try and eliminate PDFs from your website wherever humanly possible.


In the pre-broadband, always-on, internet days, the speed at which a website loaded really mattered. When broadband was introduced, web designers were early adopters and many soon forgot about latency – the time it takes for a page to load.

Latency now matters again on two counts: mobile connections can be a lot slower than broadband, particularly outside metropolitan areas; people may be paying for their traffic volumes.

To ensure good performance, time and effort have to be spent on creating ‘clean’, compact HTML code and optimising pictures. This will almost certainly come up against your budget constraints, so there will be a trade-off.

The home page name

You may have noticed that when you go to the home page on most websites, there is no page name ie the address bar shows:


In this case, the default page is being shown but this will still have a physical page name like index, index.htm, default.aspx or home.php, even though it’s not displayed.

Within the website, there will be links to the home page and these should be referenced by a forward slash (/) rather than the page name ie if there are internal references to /index.htm these should be changed to plain old / right now. Do not delay in this because physical page names can store up trouble for the future.

The veritable (technical) can of worms

Websites that have had a life can accrue all kinds of oddities as a result of early design decisions, shortcuts taken by a designer as a result of budget or time limitations, the need for an emergency change, content management systems that haven’t quite made it, etc, etc.

Although designers can get disdainful about the quality of code, if the website has been demonstrably earning its keep then the charges against it may not have stood up – until now that is, when there is pressure from Google to make all websites mobile-friendly.

A technically-challenged website may have to be rebuilt from scratch with all the essential content manually copied.

What does this mean for the owner?

Revamp the old or create a new website?

Some websites that I designed without particular regard to responsive design have passed the Google mobile-friendly test without alteration, though when I look at them, there are things that need fixing. A website like this can be revamped relatively quickly and at low cost.

With respect to a new website, one thing that scares website owners is losing their Google ranking if they have a new one built. This is a legitimate concern but one that can be mitigated by ensuring that you have all the correct redirections in place though no-one can warrant that there will not be a change in ranking.

A new website would provide the opportunity for a re-evaluation of its objectives.

What needs to be done?

What is undeniable is that it will require work by you even if you pay your design agency to do the heavy lifting.

Depending on the scale of changes required, there are a number of areas of work:

  • identify the number of pages in the website that need to be converted (a cull will obviously reduce the conversion work needed)
  • collect the content that you want to transfer from the old design to the new – this is going to be a manual process, particularly if you review the content as you go.
  • ensure that your website hosting provider or agency has the capability to redirect old pages to new – I reckon that most should be able to. If they can’t, then you should consider changing hosting providers if your Google ranking is important to you.
  • change the website design to make it responsive
  • test the responsive design on as many real devices as possible
  • create the redirections from the old page names to the new – a technology or platform change may require new page names and if so, favour clean URLs – ie page names without endings like .html, .aspx, .php.

Owner’s checklist

This applies if you want to retain some control over the redesign process.

Identify the page names in your website

Use a Google sitemap generator to find all the pages that are in your website right now. Download the plain text version of the results which will be an XML format file that can be opened in a text editor. It’s pretty easy to fathom even by a non-expert.

Note that this will only list pages that are correctly linked in the website. You may think you have other pages, but if they are not linked correctly, the search engines will not find them.

Collecting content from the old website

The difficulty of doing this will depend on the construction technique used in the original website. Essentially you will be copying and pasting from the existing pages and it may be helpful to use Microsoft Word to manage this process.

The new website technology

If your website is more than a few years old, then it’s likely that you will need to change technology and/or platform. This may involve a new content management system (CMS), coding in HTML5 or both.

From the owner’s point of view, the main change will be in the page naming. You should draw up a table of the old and new names eg:

Old name New name
index.htm index
contactus.htm contact-us
whoweare.htm who-we-are

Note that in the page redirections (mentioned in more detail below), the default page index.htm will be redirected to /.

Ensure that your provider has the capability to redirect pages

This should involve an email or call to your agency or provider to ensure that there are facilities within your hosting arrangements to be able to redirect the old names to the new names in the list above.

The default page is a special case and the target for this should always be / irrespective of the technology being used.

Change the website design

The main choice here is whether to hand the redesign over to an agency or do it yourself with a template design.

As an owner, you may want to have a preview website temporarily available on a different host name eg preview.yourdomain.co.uk as opposed to www.yourdomain.co.uk – the two host names are preview and www respectively. This gives you a chance to test the website with colleagues before going live. Incidentally, the robots.txt file should be set to block search engines on the preview version of the website.

Ensure that there is a ‘404’ page-not-found page so that in the event of a future bad inbound link, the visitor or search bot knows what is going on.


Emulators can be used – the Chrome browser has one and there are pay-for ones available. However, the only really valid tests are on hardware, so you may have to badger colleagues and friends to get a good spectrum of devices.

Create the redirections

This is only relevant to the main website, not any preview version. Once your website has gone live, be quick to get the redirections into place to reduce the number of page-not-found errors.

What’s it all going to cost?

From the experience I have had to date the price seems to be in the range of £25-35 + VAT per page for 20-50 page websites. Pricing per page is not necessarily the best way to do an estimate, but it gives an idea.

Larger websites would require an examination of the content management system before a figure could be given because pricing per page is unlikely to work well.