What we’ve been up to

We have created a new look and feel for Shropshire.gov.uk which you will hopefully see works just as well on mobile devices and tablets as it does on a traditional desktop PC.

We have changed and developed the way we write content, adopting a much more task-orientated approach, and will continue to do so.

We have implemented Umbraco as a basis for a new content management system (CMS) to create a more flexible environment for our developers, designers and editors, as well as scrapping the aging search engine and replacing it with Google Search.

What’s next?

We will continue to run this as a working prototype alongside the current library web pages until we are happy for those pages to be replaced.

We need to get as much feedback as possible, so we’re going on tour to test the site with real customers at libraries across the county.

We’ve got a stack of work to do before we’re confident this new approach works and can be used to replace the current Shropshire.gov.uk website.

At the moment the prototype is limited to Libraries, but we will be announcing another service area for the prototype shortly.

Feedback

We really want to know what you think about what we’ve got so far, whether it is good, bad or indifferent. Nothing is final and we will use the feedback we are given to keep improving.

If you would like to give us feedback, we would prefer you to use Get Satisfaction so that other people can see what you’ve written and our response, but we know that this may not be everyone’s preference, so you can also send us an email, tweet us @projectwip or use our contact form.

I’d like to finish by thanking everyone who’s helped out with this project over the past few weeks, with a special thanks to the staff at Shropshire Libraries who have approached this project with real enthusiasm and been open to changing not only their website but the way in which they work.

Our approach

It’s best not to make a large graphic and scale it down (or vice-versa), as we’ve found it can produce irregular results. Instead we make every graphic twice, once at the regular size and once at double size.  We then use pixel hinting (aligning the graphic to the pixel grid) to make the edges as sharp as we can.

We save a copy of each graphic for web use at 72 dots-per-inch and put ‘@2′ at the end of the filename of the high resolution version (for example our logo files are named logo.png and logo@2.png, this isn’t necessary but it makes file management simpler).

The Shropshire Council logo at normal (top) and high resolution (bottom) for comparison

We specify the normal sized graphic in our main CSS file and use a CSS3 property called ‘background-size‘ to tell the browser what size to render the graphic.

header h1 a {
 background: transparent url(img/logo.png) top left no-repeat;
 height: 24px;
 width: 100px;
 background-size: 100px 24px;
}

Using a media query we serve a CSS file only to devices with a high-DPI display.

<link rel="stylesheet" href="highdpi.css" type="text/css" media="only screen and (-webkit-min-device-pixel-ratio: 2)">

In this CSS file we use the cascade to override the statement in our main CSS file, replacing the standard sized logo with our high resolution version.

header h1 a {
 background-image: url(img/logo@2.png);
}

…and there we have it, a super crisp looking logo! Because we have specified background-size the high resolution graphic is squeezed into 50% of the space, rendering fine detail you can only see on high-DPI displays.

Comparison of the Shropshire Council logo on a normal screen and an iPad 3 (running on an iOS simulator)

Problems with this approach

The way we are doing this isn’t perfect, before we go live with the site we’re looking for solutions to the following:

Background images only

We’re still looking for a clean solution for inline images (<img>), particularly in situations where these are added through our content management system.

Limited browser support

This approach will only work with webkit and mozilla browsers at the moment (with vendor prefixes), until we see more browser vendors adopt the ‘min-device-pixel-ratio’ media query we can’t rely on it and will use progressive enhancement to make sure older browsers still work fine.

Downloading two images

Unfortunately we send devices with high-DPI displays both versions of the image and this is terribly inefficient. We could target devices with standard resolution displays with their own CSS file to prevent this, which we’ll look at implementing soon, once we can find a clean solution for legacy browsers.

<link rel="stylesheet" href="standard-res-graphics.css" type="text/css" media="only screen and (-webkit-min-device-pixel-ratio: 1)">

 Maintenance and workload

We have to create our graphics twice, and maintain two graphics when we’re updating the site. This could be avoiding by using a different image format such as SVGs (scalable vector graphics), which we’re looking into in the future.

As mentioned in previous posts we are completely redeveloping shropshire.gov.uk, starting with Libraries. Part of this overhaul is to look at the user experience (UX). UX (from wikipedia) is:

the way a person feels about using a product, system or service

Our aim is to provide the user with best experience we can possibly give them allowing them to do what they want quickly and easily. The new design should be forgiving if they make a wrong turn and be intuitive enough so they should be able to figure it out for themselves.

Carrying out the UX work

The first thing we looked at was the website statistics for library pages over the past 12 months. We paid particular attention to customer journeys; where they land on the site, where they go and where they leave. For example: we found that the majority of users access the library catalogue to renew books.

We have decided, based on our observations that tasks and services are more important to our customers than general information. So we are going to organise the website around the most popular tasks.

We have also taken it a step further by looking into the number of transactions that have been completed on the website, how many phone calls our Customer Service Center have taken and how many of those were things the customer could have done themselves on the website.

Going Undercover

After scrutinising the statistics and customer service enquiries we decided we needed to get a better understanding of what the library service actually do by getting closer to the customers.  I was surprised to learn that not only could you borrow books but you could use the computers, scan items, print documents, read the paper and even attend the many events libraries host all over the county.

So like undercover detectives we posed as librarians for the afternoon at Shrewsbury Library. We asked the staff everything you could think off “What did the customer phone for?” “Is the information available online?, “Do you recommend that people reserve books online?”, “Do you give new members information about what they can do on the website?”.

Now we understood the library service and it’s customers better we were able to create personas that described typical users.  We generalised the customers into around 6 groups and created a fictional person to represent the group. For example; ‘Mother and Baby’ – Sarah is looking for free baby groups to join, as she would like to meet new mums and borrow children’s books. She buys her groceries online and has a smart phone.

Using these personas this would allow all the library service, the content team and the web team to share a genuine view of the customers. So that under any situation when testing the website we could pull out one of the personas to ensure it met their needs.  We’ll go into our Personas in more detail in a future blog post.

Creating a Draft Information Architecture

Using our findings we created a draft information architecture (IA) that would allow the customer to perform any of the tasks the library currently has to offer online without a tiresome navigation. Trying to ensure that the journey never broke and allowed them to navigate to the most popular tasks from any page with ease. This also took into consideration the fact that people might make mistakes (we’re only human after all) they needed to be able to find the way back.

To put our theory to the test we decided try it out on a few unsuspecting colleagues around the office. We threw together a quick HTML prototype and stalked the corridors of Shirehall with an iPad and a smile, asking people to navigate around watching how they got to their destination page and looking out for common trends and mistakes. This allowed us to figure out what worked well and what didn’t work so well. This allowed us to start with a rough idea and test it early, and iterate on it to improve it quickly.

With a draft IA in place we created some draft wireframes taking into consideration everything we had already collected and observed. We had discussions on what should feature as a priority on each page, what needed to catch the customer’s eye and came up with several different ways to display the information on the screen. We worked through problems such as where should the phone number go? Should we include a map? How will users find their nearest library?

The next step is for our content team to start looking at each pages in more detail, using content plans and page tables, and for our designers to take the draft wireframes and flesh them out into HTML mockups.

We are still working hard on the project and hope to get something for you to see in April so don’t forget to signup for updates about the project at new.shropshire.gov.uk.

Come and say hi!

The minute we started working with the Web Team, their passion for improving the look and feel of our webpages and the content made it clear that it was not going to be just a matter of shoe-horning the old into the new, but would rather represent a new way of thinking and presenting the service to our customers.

It was explained at the outset that this was not a process which would require changes to the service, but that it could potentially highlight elements of the way we work which could be reviewed in order for us to enhance the service that we offer.

And indeed, it has proved to be a great opportunity to look at systems through the eye of both a user and a web designer. Staff continually re-evaluate systems and look at ways of streamlining them, but this process has been a very effective catalyst. Some of the systems highlighted in this process are internal procedures, some are interfaces between the internal system and those of our partners, some may be fairly easily changed, some may not and might require expenditure, some may happen quite quickly and be in place for the beta launch, and some may form part of a longer process of development; however the outcome will definitely be an improved service.

The Libraries Team are pleased to be the guinea pigs for the new user-friendly Shropshire Council website and as we move through the research and planning process prior to the launch in April, the level of anticipation and excitement is growing.

For several years now, our team of web editors have done a magnificent job of keeping the council’s website up-to-date, telling us when pages need to be deleted or amended, or when attachments are obsolete. This has resulted in our website being commended externally as being dynamic relative to those of other authorities.

However, given that we have over 300 editors across the organisation there are inevitably differences in approaches and contrasting levels of interest in the role. It is a time-consuming commitment, which can be difficult to balance with the demands of their day job.

With the arrival of the new website, our intention is to slim down our team of editors to one per service, to ensure that we deliver improvements by:

• Giving each service editor a sense of real ownership of the pages he or she is responsible for
• Turning the role of ‘web editor’ into a more specialised one, letting our smaller group become experts
• Allowing the web team to spend much more time with each editor on training, development, support and the exchange of ideas
• Allowing this smaller group of editors the chance to get together for regular group meetings, something which is impossible with our current number
• Ensuring that content across each service has a consistent look and feel, enhancing the overall user experience of our website

The intention is to have a tight-knit group of web super users, offering a professional and knowledgeable presence locally within each service, with the overall effect of delivering a joined-up feel to our website.

Must have varied content and transactions

We’re trying out some new technology and we want to give it a proper test drive so the service must contain a variety of content types and some transactions.

The content types of a library cover things like events and venues; with venues typically broken down into information like opening times, locations, facilities etc. and transactions; where we ask some information from the customer to complete a service, such as apply for a library card.

Must be low risk

If the prototype doesn’t work as expected no one should come to any harm and there should be minimal impact on service delivery. This immediately rules out things like adult social care, crime and reporting problems.

Must be prepared to fail

The service area managers have to accept some risks – this is a prototype which means it could fail or we can make some mistakes and end up throwing the whole thing out at the end. This is obviously a worst-case scenario but it would be unrealistic to not consider this as a possibility.

Could do with some TLC

We believe this prototype will, if successful, make a huge impact on the way we deliver services, so the service we choose to prototype will be the first to feel the benefit. A service like libraries, which is always under threat during times of recession could really benefit from the help. Customers will also benefit from the services that libraries provide in a nice way – free books, frequent leisure activities and a better community resource.

Can provide the resource

Creating a website is a partnership, and requires as much work from the client as it does from the technical people, the content people and the designers. Libraries were more than willing to lend us some help from their digital librarians who have given up a lot of their time to be part of the project.

Must be a neutral or positive customer experience

We wanted a service that wasn’t associated with something negative, like paying a parking fine or objecting to a planning application (not that these services wouldn’t benefit). These events trigger a contact that starts with a negative event, which could mean customer feedback could be negatively biased .

This is something we’ve observed on our current website with the GovMetric service (three smiley faces at the bottom of the page) – services that customers have no choice but to interact with always get more negative feedback than others.

We can confirm that we made the right choice. Working with the library staff has been an absolute pleasure so far, they are group of very knowledgable people who have a real passion for their service, and care for their customer’s needs. Do yourself a favour a go to your local library to appreciate this first hand.

More updates as they come, we’ve created a new category on the blog to help you keep track, and if you haven’t already make sure you sign up to find out when we launch!

Starting a new website from scratch is a massive task so we’re breaking it down into distinct stages. We’re working our way through the council, service by service, treating each one as a separate website project.

Over the coming months we plan to visit each of these stages in more detail in a series of blog posts to share our  processes, methods and findings. Here’s an overview of the steps we go through for each service, in order:

Plan

1. Choose a service area
2. Audit and review existing web content
3. Investigate and research the service (work out customer objectives, business objectives and key tasks)
4. Planning and workshops (things like creating personas and card sorting)
5. Create site wireframes and content plans (user experience design, information architecture and page tables)
6. Testing (on paper, as a result refine wireframes and content plans)

Implement

1. Design (create final designs in browser)
2. Test (cross-device and cross-browser)
3. Implement in CMS (turn the designs into fully working, dynamic pages that can be managed by content editors)
4. Add content (This should be the simplest part, as we should have written most of it already in the planning stages)
5. Test (test with real users – observe and record stats)

Maintain

1. Monitor, analyse and refine

So, I’ve missed the bulk of the last few year’s hard work investigating other systems, but without worrying too much about that (guilt is an unnecessary and time-consuming distraction right?), I am now jumping right in as we embark on a new and exciting chapter in the tale of the Shropshire Council website.

Over the next couple of months we will create a new ‘prototype’ version of Shropshire.gov.uk’s library pages that will focus on customer needs rather than the organisation’s to make it quick and easy for our customers to find what they are looking for.

This work will give us the perfect opportunity to evaluate Umbraco as a replacement for our current bespoke content management system (CMS). We will review the prototype after four weeks by looking at our visitor statistics, feedback gathered and usability testing with customers in a number of libraries across the county. If we’re happy with the prototype we will roll it out across the whole of shropshire.gov.uk.

You may be asking yourself ‘why would Shropshire Council want to do this?’ To be honest there are so many reasons, some technical and some not. For me, the main reason is because it gives us a unique opportunity to start from scratch; to remove all of the content and structure that has built up over the years and to rethink it all.

It also gives us a rare opportunity to rationalise our current web-editor structure (300+), and turn the culture of ‘the more editors the better’ on its head as we have proved that it is not an efficient way of delivering online services.

We will work in partnership with the library service who have agreed to be our guinea pigs and we have already started some undercover research; lurking in the corners of Shrewsbury library watching what customers do and how they do it.

In 2011 there were several high-profile web projects that began as publicly available prototypes (commonly known as open betas), such as the single government domain project (http://gov.uk/), Direct Scot (http://www.directscot.org/)   and Herefordshire Council’s own website (http://beta.herefordshire.gov.uk/), so we are in good company.

The team at Shropshire.gov.uk is working tirelessly to get something out to you in April, and I promise that you won’t want to miss this opportunity to see what all the hype is about – it looks fab already!

Visit our holding page to sign up and be the first to find out when we turn the new site on: http://new.shropshire.gov.uk.

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?