Well in late November, we pushed a new responsive design out to the Shropshire Council Newsroom.

Scaling the existing design down

When I worked on the first version of a responsive design for the newsroom, I took the original fixed-width ‘desktop’ design and scaled it down. At the time it was the quickest and easiest method as there were no design changes planned, but it didn’t give the cleanest results. As soon as a device browser hit a media query threshold, there was a large ‘jump’ in the available space which resulted in a lot of side margin space at certain screen sizes. So this approach, although worked, didn’t really make best use of all mobile devices’ screen width.

Scaling a new design up

Following our initial responsive design, we started preparing for ‘version 2′ of the newsroom which included a redesign of current sections of the homepage as well as adding some additional features. We therefore decided to take the opportunity to completely re-code the newsroom from scratch. This allowed us to take the approach of scaling-up a mobile design to a desktop design.

I found this approach to make a lot more sense. Instead of battling the confinements of the desktop design from ‘version 1′, which usually required a lot of new CSS overriding old CSS, I was able to write a single CSS rule that would be valid for all screen resolutions. So in effect the CSS was a lot less bloated, as the scale-up method is a progressive method instead of a overriding method.

A new way of thinking

Doing a scale-up responsive design is quite a different approach to the way a website is coded and can take a bit of time to get your head around.

Scaling down fixed-width elements is fairly restrictive especially if multiple elements contained within the main columns of the design are also set to a fixed width. We have to in turn change all the fixed values for each size of device we want to support, and as already mentioned will probably result in a lot of side margin space at certain mobile device screen sizes, a jumpy response at media query thresholds and plenty of CSS overrides.

Instead, we are now using percentage based column widths which allows us to take full use of a devices’ screen width at a smooth response. Content within these columns are now set as a percentage of their parent (usually 100% to maximise the available space).

So to paint a picture of how the CSS appears between the two, instead of changing multiple fixed widths in multiple instances for each media query, we now just change our main columns percentage widths. The content in these columns is set in our main CSS just to fill the column space so we don’t need to worry about this.

The numbers never lie

In ‘version 1′, our main CSS file had 1218 lines of code and 567 lines in the responsive CSS file. Compare that with ‘version 2′ where we have just 707 lines in the main CSS file and 140 lines in the responsive CSS file. Now isn’t that a much more efficient and manageable sounding design?

Our Ordnance Survey background mapping has been cached in an image format that speeds up various requests to the server to produce the image tiles the application requests. This improves loading time, panning and moving around the map as each tile is already available, removing the request for tiles to be created by the server. We have various cache setups depending on the requirements of the application. All our applications use a single background cache, in the good old days you had to have this as dynamic data…..this is what used to make mapping applications so slow as each tile in its native format is very large!

We then create a web service from the data and allow it to be consumed in various formats. WMS, KML, REST are some of the formats that we can offer for applications to use.

The ADSL data is different. This is dynamic data in a GIS format that the server can consume. We could also cache this data but usually it is subject to change or update so we set it to be requested and drawn by the server each time new data is being requested (opposite to the cache service above). We create the design or “symbology” of the data in a desktop application. The server replicates the layout we create, however this can be overridden by the application.

Once we are happy with the services we then go into development mode! Using a javascript API specific to our mapping application, we then consume the services and code the functions needed for the application. The application then gets embedded into the page.

We have a few of these applications across the Shropshire Council website and we are providing more and more each week! If you have any suggestions or feedback about the mapping applications we would like to hear from you!

First things first, thank you to everybody who took time to test the system over the past few weeks, this was the first time we have run a public test and it has resulted in a much more useful system. If you want to be involved in future tests make sure you’re signed up and you’ll be first in line.

Although we have designed the system to work for a wide range of devices we took a chance with this project to try out some new technologies which I wanted to talk about briefly here.

Although the system is ‘complete’ we will continue to take suggestions and feedback from you.

Responsive design

We learnt from the testing stages that the utility of the system wouldn’t be truly realised unless we could make it work elegantly on a mobile phone. To do this we used a technique called responsive design (although technically, it’s an adaptive design) which uses new functionality in modern web browsers to make an website look and behave differently depending on the screen size of the user’s device.

We used this to turn a large bus timetable into a format that would work on a mobile phone (pictured)

Left: How a time table looks on a desktop or laptop. Right: on a mobile device

HTML5 Geolocation API

Requiring a postcode to get a location from the user doesn’t always work, so we used the HTML5 geolocation API to access location information about the user’s device to estimate their position. This makes finding your nearest bus stop while out and about much faster.

Progressive enhancement

Despite using bleeding edge technology we also made sure that users on older technology don’t miss out on core functionality (known as progressive enhancement).

Development API

A tentative first for us. Everything you can do through the front-end is accessible through a development API.

We have now calculated that we are directly saving the council £204k over an initial 5 year period and are going to save a further £228,905 every five years thereafter.

How are we saving this money?

We built a search engine framework to replace two third-party products. A website search engine and an address search system. These systems were costly and becoming more expensive as additional functionality was required.

So we decided that we’d build our own search engine to cover the needs of these two products as well as providing additional features for other products.

Our search framework consists of a set of J2EE applications written in-house and running under a clustered pair of Apache Tomcat application servers. The search indexes are all stored on a pair of load balanced and clustered PostgreSQL servers, and all these servers are running Linux as their operating system.

Quick cost breakdown

The costs of the existing search systems added up to a total of £228,905 over a five year period.

We spent £24,635.92 on hardware to allows us to get the maximum performance and stability, and this hardware is also being used to power quite a number of other systems too. So after our initial outlay of hardware, we were left with £204,269.08 for our first five years.

Conclusion

The system that we built and delivered is saving us much more than the amount we’ve calculated above, but working out those true costs would be time-consuming and offer no real benefit.

Open Source works for us and it works for us well, and we have proven that you can significantly reduce costs when using it with no feature or performance degradation.

We’ve had bucket loads of feedback and I’d love to be able to address every one individually but there were just too many, instead I have tried to summarise the general themes below.

Will there be a print button?

Certainly – we couldn’t get this working satisfactorily before the testing began so we pulled it. The final version will have a print button.

Will there be a mobile version?

Yes – we are discussing early ideas for a mobile version of the system, with tools like the HTML5 geolocation API and media queries available to us we will create an excellent mobile version of the system.

The use-cases change as does the context (finding a bus based on location is much more important with mobile) so it might turn out to be a lot of work. For this reason we won’t be trying to squeeze the mobile version in before the launch but it will follow shortly after.

My bus stop is missing

Thanks for spotting that – we discovered some gaps in our data which we are fixing.

I don’t know my postcode – the nearest bus stop search is useless

We are changing the design of the search so that you can search by street and town or use browser based location tracking so you won’t need to know your postcode.

Could you add bus fare information?

This was something we wanted to add early on in the project but we couldn’t get sufficient data. Bus fares are a very complex problem but it would be useful. We have added this to our feature list for an upcoming version.

Will there be a developer API or open data file?

Watch this space

Welcome to the 21st century! / It’s about time you did something like this…

Have you seen some of the other things we’ve been up to?

Although testing has ‘finished’ we will leave the system up and available for the near future and continue to update it with new developments. Development is ongoing and we’re expecting to go live with the system mid-September. If you have any more feedback please feel free to let us know.

If you do then let us know – feedback from our customers is really useful, helping us to see what we’re doing right and where things need to be improved. Giving us feedback is really quick and easy, there are several ways to let us know about your experience.

The quickest and simplest way to let us know if your visit to shropshire.gov.uk has answered your query or provided the information you wanted is to click on the little faces under ‘rate this page’ on whatever webpage you’re visiting. There is a smiley face if you rate it as good, a neutral face for average and a frowny face for poor, you can select a reason for your rating and leave a short comment (please note, these are anonymous).

There is also a contact on all shropshire.gov.uk pages containing an email address, either in the webpage or the footer, for example,

or

Simply click on the email address and you can provide detailed feedback via our online form. You can fill this in anonymously or leave your details if you would like a response. You can also get in touch with us here on Project WIP or comment using twitter and facebook (some services areas have their own  facebook and twitter accounts, you can check them all out here).

One of the primary purposes of Project WIP itself is to communicate with you, and we want this to be a two way process. This isn’t about us talking at you – we want to have a conversation so please comment on the blog posts, have a look at the ‘how you can help‘ section, give us feedback and share your ideas or even volunteer to become a tester and try out the first versions of our creations, helping us to perfect them before they go live for everyone to use.

If you’re wondering what we’ll do with the feedback we receive; all of it is analysed, then some is sent to web editors to help them improve the content or layout of their pages and make them easier and more useful. Other feedback may be accepted and prioritised to be added / fixed / made, at some point in the future.

We may also publish your idea or feedback; either here or on shropshire.gov.uk, possibly editing it a bit if there is a spelling mistake (or anything inappropriate so please keep it clean!). We can’t provide status updates on all feedback we receive but don’t let that stop you – we’re waiting to hear from you!

I won’t bore you with the CMS changes (but I will say that what we have received the comment “Love it , Love it, Love it!!” during the testing phase), so for this post we will focus on the improvements to the website itself.

What’s new?

Following feedback about content that appears to be out of date, we’ve added a new notification that will appear on pages that are currently being reviewed. This alert will also allow you to give feedback to our Web Manager to help our editors update the content with the information you require.

Our online payments system has recently been updated, and we are now able to provide direct links to certain payment types. As such, the list of payment options on our “Pay for it” page has been reviewed, and direct links provided where applicable. Unfortunately some of our services require further information in order to take payments, and so we are not able to provide direct links to all of our online payment types at this time.

We’ve had some people voice their concern over the use of 0345 numbers for the main Shropshire Council contact lines, and so we have set up a new page detailing the reason for this choice along with the costs to you for using them. To make this easy to find we have added a “(How much does this cost?)” link to the footer next to the main telephone number.

To keep our website accessible for everyone, we have changed some of our code to help make our in-page content shortcuts easier to use for those relying on keyboard navigation with screen readers/magnifiers.

To touch slightly upon our CMS changes, we are now able to schedule newsflashes (meaning one of our skilled editors will not have to stay up late to add and then remove a newsflash for a planned overnight service outage), and can now provide a more varied range of links for our main homepage feature.

We release updates to our website regularly and take bug reports and change requests from our internal staff, partners and the public. If you’ve got an idea for an improvement you would like to see in our next website update, please let us know.

Instead of writing a post solely to justify our choices, I thought it would be more useful to share the principles and practices that led us to arrive there. Let’s begin with some common myths: you accidently eat spiders in your sleep, chewing gum takes 7 years to digest and people don’t read on the web.

The truth is that despite the generally horrible reading environment the web provides users have become very good at telling the difference between useless and useful information. They scan through pages disregarding the content that doesn’t interest them, and reading the content that does.

Although we can’t ensure that what is written is engaging and captivating enough to keep the reader’s attention, we should ensure that our design makes it possible, by creating a comfortable environment that makes reading easy.

User experience

When we design a website we think about the user experience on a site wide level, we should apply the same techniques to a single page.

Consider the experience of reading – being drawn in with the first few lines, followed by a period of solid reading, before the conclusion where there is opportunity for suggestion and further information.

Fonts & Typography

You can’t build a house on sand and you shouldn’t build a design on poor typography. Font choice is important; not all of us have the luxury of choosing our font, so where style guides dictate your fonts, get to know them inside out – play to their strengths and deal with their weaknesses. It’s not unusual for corporate style guides to be written without the web in mind, if this is the case then point it out and ensure you arrive at a web-friendly conclusion.

By complying with rules and best practices of measure (line length), leading (line height) and baselines (the vertical space between lines and paragraphs), it is easy to create a readable body of text, but that isn’t the whole story.

Content first

Let your typographical design inform the rest of your design. Resist the temptation to start with the homepage or the branding when you begin your design. Start with a content page and let that dictate your grid.  Use existing elements if you have any (photos etc) as a basis for unit size and move on from there. This will give you a grid that supports your content and you will arrive at a design that feels more organic.

Now you have a beautifully crafted  design, and your users are reading make sure you protect the content – resist pressure to place ads or distracting content within the article. Save these for the top and bottom of the page (if at all).

Write this stuff down

Use style guides and standards to share this amongst your designers, a lot of these standards and practices are subjective and can take a long time to figure out from scratch. Documenting the reasons for your design decisions can help maintain them throughout the life of a design.

Want to know more?

Read the following articles and blog posts:

• The 100% Easy-2-Read Standard – Information Architects Japan
• Relative readability – Wilson Miner
• In Defense of Readers – Mandy Brown
• 10 Principles for readable web typography - Smashing Magazine
• Five simple steps to better typography - Mark Boulton

“We’re trying to expose the brilliant work that our IT development teams do, previously shrouded in mystery like some military Black Ops team.”

It’s been nearly 3 months since Project WIP launched and we have blogged about open source, site releases and accessibility. But you may be wondering about the actual products we’ve been busy conceiving, designing and building.

Well to put your minds at rest I will give you a little taster of some of the products that the IT Development teams have made in-house; taking into account all those other things that we have been banging on about.

Shropshire Newsroom

The newsroom was created to separate news from the website and provide a ‘one stop’ shop for all news. It is powered by WordPress and links into Flickr, YouTube, Twitter and Facebook.

Since the newsroom went live back in March we have had over 9,900 visits, over 39,000 page views and over 7,800 unique visitors. With good old Twitter sending over 5% of visitors our way.

Geoff Coleman; Birmingham Journalist had this to say about it:

“@shropcouncil Just had a look at your newsroom-great stuff.”

Waste Collection Finder

This service allows our customers to look up when their bin days are. It uses data from the national land and property gazetteer (NLPG) and our waste supplier Veolia’s collection schedules.

On average the Waste Collection Finder recieves 60 pageviews a day however, on Wednesday 27^th April 2012 before the bank holiday we had over 1350 page views  and on Thursday 28^th April 2011 we had over 1200 page views.

Since the launch we have had nearly 2000 calendar searches performed (excluding staff).

Martin Taylor-Smith, Shropshire Council cabinet member for Service Transformation and Organisational Development, said:

“The online waste collection day finder demonstrates our commitment to using IT to deliver essential public services more cost-effectively and intelligently. I‘d like to congratulate the in-house web development team who have done a fantastic job on this and encourage the public to use the new collection day finder.”

Project WIP

Of course our beloved Project WIP website.

The aim is to

• Engage with our customers
• Offer ways for our customers to submit feedback, share ideas and to get involved with the project
• Document our progress and share our ideas and findings throughout the multitude of projects that contribute to our website
• Promote the work of the many project teams involved in our website

Project WIP was designed and built by Shropshire Council ICT Development Services. It is maintained by a group of people who work on Shropshire.gov.uk in varying roles.

From the 1st March 2011 we have had over 900 visits over 2900 page views and over 500 unique visitors.

We have over 150 followers on Twitter and we have had plenty of positive and useful feedback (Thanks to everyone so far!).

Paul Annett (@Nicepaul) from Alpha Gov says:

“The clean, modern, uncluttered layout of http://shropshire.gov.uk/ should be an example to all local government websites.”

@AndyWoodall says:

“Got to compliment your web team, your site is very clear, uncluttered and easy to read, other authorities could learn from it!”

@tomskitomski says:

Loving @ProjectWIP , specially the autocompletegoodness on shropshire.gov.uk Simple win. http://tinyurl.com/6ybdxsn

New Projects

Connecting Shropshire

We know how frustrating it can be to have a slow or non-existent internet connection, so we are looking at ways we can work with our communities, businesses and internet service providers to get Shropshire connected. To help the campaign we are trying to gain interest through twitter and facebook to support the rural broadband project.

Coming Soon

Online Bus Timetables

We are currently working on a system to simplify the way you find bus time within Shropshire online.

Events Portal

Have you ever wondered “What shall we do this weekend?”. Well with the help of our events portal we hope that you will be able to find a list of events that are happening all over Shropshire from festivals to book reading clubs. Watch this space!

Automated tests are useful but limited and should only be used as part of a wider range of tests incorporating a number of different tools and methods – including user testing.

However, in some circumstances you may not have the time or resources for such in-depth user testing, or have been brought in at last-minute only to find that the site is “almost live”. In those cases you are going to have to get stuck in and test it yourself… but where do you start?

In this post, I will go through the methods and tools we use to test the various sites that come under the responsibility of Shropshire Council.

The method…

The best thing you can use to test a website is a human being. You will find that a reasonably short run-through of the main features of a website will immediately give you an idea of the quality and consistency of the underlying design and user experience.

If something seems odd, hard to understand or awkward to use, chances are that the same thing may be even more confusing or harder to use for others, and so is something to investigate further using other tools and methods.

That being said, some issues may not be readily apparent by just browsing through a website, and so I do rely heavily on some Firefox add-ons and web-based tools to assist me, which I will mention as we go along. (Some of these are also available for Google Chrome)

The tools for…

Keyboard navigation

Before breaking out any specific tools, the first thing I try out when testing a website is non-mouse navigation – can I get to what I want using standard keyboard shortcuts?

You can try this yourself, just visit one of your favourite websites, then make a mental note of a link somewhere in the middle of the content. Now try getting to that link just by using the Tab key.

How did that go? Were you lucky enough to find a site that allowed you to easily keep track of where you are on the page?

On an accessible site you should be able to follow your own progress through all the links on the page, usually by looking out for visual effects similar or identical to those that would occur if you hover your mouse cursor over them.

Sadly, chances are you are looking at a website that hasn’t put any thought into accessibility and you are still struggling to pick up where you are. In those cases, you may have had to figure out which element had the default dotted outline that most browsers use as a fall-back for focus, or were keeping an eye on the status bar for the changes to the URL preview.

The frustrating thing about all of this is how simple the fix can be.

For standard (X)HTML websites using CSS, the way a link behaves is normally determined by the “:hover” pseudo-class. For example:

a {
color: blue;
}

a:hover {
color: darkblue;
text-decoration: underline;
}

For those not clued up on CSS, this will underline the link and turn the text a darker shade of blue when you hover over it.

To allow the exact same links to react the same way for keyboard navigation, all you need is the :focus pseudo-class, like so:

a:hover,
a:focus {
color: darkblue;
text-decoration: underline;
}

Simple, eh?

Properly structured source code & content

Like most web developers, I use a number of add-ons to test and evaluate websites. I tend to do most of my testing in Firefox, taking advantage of the large amount of add-ons available for it. For accessibility testing I use HTML Validator, the Web Developer toolbar, the WAVE Toolbar (still marked as an “experimental” add-on) and Firebug to evaluate the source code and stylesheets on a page.

HTML Validator

The HTML Validator tool is simple to use, as the icon in the status/add-on bar will change to give a visual status of the page validity as soon as it has finished loading. Double-clicking on the icon will launch a new window containing the page source code and detailed results of any warnings or errors. By selecting one of the warnings/errors in the list it will show you where it occurs within the source code itself by scrolling to and highlighting the offending line. The beauty is that you can configure it to check for a particular level of accessibility (as defined by WAI WCAG1.0), which will identify elements that either fail outright, or will require manual checking.

Web Developer toolbar

The Web Developer toolbar has an array of useful features, but for accessibility testing there are a couple of them that stand out. For graphics-heavy pages, the ability to display the alt attributes on all images is a massive time saver, making it easy to see where images are missing the attribute or when it is not used properly.

Similarly, being able to view a page outline that has been constructed from the header tags within the markup gives a quick preview of how a page might be interpreted by a screen reader. As the outline properly nests the headers hierarchically based on their tags, it shows where headers have been missed out or used in the wrong order, for instance, when someone has used a H3 following a H1 when they should have used a H2.

WAVE Toolbar

The WAVE Toolbar combines most of the elements of the HTML Validator and the Web Developer toolbar that I’ve previously mentioned, albeit with a visual overlay of validation warnings/errors on the page itself rather than its source. It’s a nice user-friendly way of showing people why a page fails, handy if you need to explain your work to someone who isn’t well-versed in HTML.

Firebug

Last, but not least, the Firebug add-on. This has become one of my most heavily relied upon tools in recent years, and is normally the first add-on I advise any budding web developer to install. The ability to view and edit HTML and CSS in the browser is amazingly useful for identifying solutions to any accessibility issues that are identified by the other tools, especially when combined with the ability to add your own custom style sheets via the Web Developer toolbar.

Using colours properly

Much like when it comes to picking out what clothes you are going to wear, there are certain colours and styles that go together well in website design. The combination of these factors can help or hinder visually impaired users when it comes to reading your content, but can also influence how everyone uses your site.

I usually start by getting an overview of the homepage and a standard content page using an automated contrast checker (such as the the Juicy Studio Accessibility Toolbar or WCAG Contrast Checker add-ons for Firefox, or www.checkmycolours.com).

As I’ve said before, automated tools are good, but they aren’t 100% accurate. With contrast checkers the results are based on an evaluation of your CSS and (X)HTML code, but these can often misinterpret how some rules should be applied, and more importantly, don’t take into account pseudo-classes or scripting influences. This means that you may be getting a mixture of false positive and negative results on the test, and are ignoring some potential UI issues.

Because of these limitations, it is still necessary to manually check certain aspects of the design, for instance, the :hover/:focus effects on links and form elements.

In these situations you will have to identify the colour values used for these events, and use the manual colour comparison tools available in the WCAG Contrast Checker. I use Firebug to identify a link/button and use the options in the Style menu to get to the :hover & :focus rules, and the Computed tab to see the actual values of an element, as sometimes contrast is only an issue if the font-size is below a certain pixel value (normally about 18px).

If you are looking to tweak a colour a bit in order to make it compliant, take a look at http://snook.ca/technical/colour_contrast/colour.html. Just enter your foreground and background colours and use the sliders to find the best match for your level of accessibility.

Summary

Because of the complexity of modern web designs and the underlying technologies that they are based on, there is no “magic bullet” for accessibility testing. It is only by combining a number of different tools and resources, coupled with good old human ingenuity and common sense that a website can be properly evaluated.

If you want to properly plan for and test for accessibility, remember to ask the people who rely most on accessible websites, and be sure to listen to any suggestions they may have.

The development of shropshire.gov.uk website was aided by the involvement of a local centre that provides training and advice for disabled people, whose input greatly influenced the finished product as well as all the versions we have released since.