We’re longstanding supporters of LocalGovCamp, the conference where innovators in Local Government come together to share knowledge on how to improve services.
This year we’re both sponsoring it and running a couple of hands-on, interactive sessions. All online, of course, given the way things are these days.
On Tuesday 6 October, join a mySociety-led discussion with Mark and Zarino, on how consistent data standards across councils could open the doors to much better innovation.
We’ll be looking at our own Keep It In The Community project, nodding to our Council Climate Action Plans database, and inviting attendees to join a wider discussion on how we can encourage better joined-up data across councils.
And on Weds 7 October, our designer Martin will be running a mock ‘consequence scanning’ exercise. He’ll take participants through a new and useful way of assessing and mitigating risks in new government services, as conceived by Dot Everyone, recently taken up by Future Cities Catapult, and now used successfully in service design workshops by SocietyWorks.
We hope you’ll come along and enjoy some good discussion and deep dives into local government service improvement: find out more and book your place here.
When something’s not right on your street, and you’ve gone out of your way to report it to the local council, the last thing you want is to get bogged down in a complex log-in procedure.
That’s why FixMyStreet has always put the log-in step after the reporting step, and has always allowed you to report a problem without needing an account or password at all.
But we know we can always do better, and in the 11 years that FixMyStreet has been around, new design patterns have emerged across the web, shifting user expectations around how we prove our identities and manage our data on websites and online services.
Over the years, we’d made small changes, informed by user feedback and A/B testing. But earlier this year, we decided to take a more holistic look at the entire log-in/sign-up process on FixMyStreet, and see whether some more fundamental changes could not only reduce the friction our users were experiencing, but help FixMyStreet actively exceed the average 2018 web user’s expectations and experiences around logging in and signing up to websites.
One thing at a time
Previously, FixMyStreet tried to do clever things with multi-purpose forms that could either log you in or create an account or change your password. This was a smart way to reduce the number of pages a user had to load. But now, with the vast majority of our UK users accessing FixMyStreet over high speed internet connections, our unusual combined log-in/sign-up forms simply served to break established web conventions and make parts of FixMyStreet feel strange and unfamiliar.
In 2014 we added dedicated links to a “My account” page, and the “Change your password” form, but it still didn’t prevent a steady trickle of support emails from users understandably confused over whether they needed an account, whether they were already logged in, and how they could sign up.
So this year, we took some of the advice we usually give to our partners and clients: do one thing per screen, and do it well. In early November, we launched dramatically simplified login and signup pages across the entire FixMyStreet network – including all of the sites we run for councils and public authorities who use FixMyStreet Pro.
Along the way, we took careful steps—as we always do—to ensure that assistive devices are treated as first class citizens. That means everything from maintaining a sensible tab order for keyboard users, and following best practices for accessible, semantic markup for visually impaired users, to also making sure our login forms work with all the top password managers.
Keeping you in control
The simplified log-in page was a great step forward, but we knew the majority of FixMyStreet users never used it. Instead, they would sign up or log in during the process of reporting their problem.
So, we needed to take some of the simplicity of our new log-in pages, and apply it to the reporting form itself.
For a few years now, the FixMyStreet reporting form has been split into two sections – “Public details” about the problem (which are published online for all to see) followed by “Private details” about you, the reporter (which aren’t published, but are sent to the authority along with your report, so they can respond to you). This year, we decided to make the split much clearer, by dividing the form across two screens.
Now the private details section has space to shine. Reorganised, with the email and password inputs next to each other (another convention that’s become solidified over the last five or ten years), and the “privacy level” of the inputs increasing as you proceed further down the page, the form makes much more sense.
But to make sure you don’t feel like your report has been thrown away when it disappears off-screen, we use subtle animation, and a small “summary” of the report title and description near the top of the log-in form, to reassure you of your progress through the reporting process. The summary also acts as a logical place to return to your report’s public details, in case you want to add or amend them before you send.
Better for everyone
As I’ve mentioned, because FixMyStreet is an open source project, these improvements will soon be available for other FixMyStreet sites all over the UK and indeed the world. We’ve already updated FixMyStreet.com and our council partners’ sites to benefit from them, and we’ll soon be officially releasing the changes as part of FixMyStreet version 2.5, before the end of the year.
I want to take a moment to thank everyone at mySociety who’s contributed to these improvements – including Martin, Louise C, Louise H, Matthew, Dave, and Struan – as well as the helpful feedback we’ve had from our council partners, and our users.
We’re not finished yet though! We’re always working on improving FixMyStreet, and we’ll be keeping a keen eye on user feedback after these changes, so we can inform future improvements to FixMyStreet.com and the FixMyStreet Platform.
Your donations keep our sites running.Donate now
WhatDoTheyKnow Pro is our Freedom of Information service for journalists, and campaigners, and we’ve recently rolled out some major changes to the request sidebar to make reading, navigating, and classifying Pro requests a lot easier.
Since the very first Alpha version of WhatDoTheyKnow Pro we’ve been receiving feedback from our users, which we have been feeding directly into our future development plans. The sidebar changes are the first round of changes that have come as result of direct Pro user feedback, and there will be more to follow.
In WhatDoTheyKnow a member of the public can send a Freedom of Information request to an authority, which they receive in the form of an email. The request, as well as any replies or follow up from the requester, or the authority, are published on WhatDoTheyKnow. If the request is made by a Pro user, they have the added option of making a request private for a limited time.
In the request process we observed the following:
- A new response from an authority goes to the bottom of the thread (the bottom of the page)
- The user interface for updating the status of a request is located at the top of the page (a request’s’ status is a way of keeping track of where it is in the request process – for example ‘awaiting response’, ‘needs clarification’, or ‘refused’)
- A longstanding or complicated request will often consist of many, many messages. So scrolling to the bottom of the page to read the most recent response, then back to the top to update its status involves a lot of interaction that we can remove.
We can’t say for sure that a user will always be at the bottom of the request thread when updating the status of a request, but we can safely assume they are sometimes.
For these changes we set ourselves the following goals:
- Speed up the process of updating the status of requests
- Improve the experience of navigating requests with a long history.
In previous research we established that a typical workflow for dealing with request responses is:
Get reply → Read reply → Take action (typically reply, or update the status of the request)
It’s a short, three step process, but a busy user catching up with a backlog may do this hundreds of times a day, so if we can optimise this workflow we can save a lot of time and frustration.
So what have we done?
For desktop users we’ve made the sidebar controls (where the ‘update status’ button is) “sticky”, so it will follow you as you scroll up and down the page, meaning you can update the request status from any position on the page. This really helps as requests get longer, as you no longer need to scroll back to the top to classify the latest response.
We’ve added new message navigation buttons. This is to enable you to move through a request thread message-by-message by clicking the up and down arrow buttons, or using the arrow keys on your keyboard. We’ve also added a counter so that it’s easier to see where you are in the list, and to go back and forth to specific messages.
We’ve also taken this opportunity to make some key information about the privacy of your request visible at all times (this was previously hidden behind a click), and to tweak the design of the sidebar – making it easier to read and removing some visual noise.
More to do
We’re looking at a way to add similar functionality to mobiles and other small screen devices. As screen space is limited it will require a separate design process.
We’re aware that the problems we’re trying to solve aren’t unique to our Pro customers, so if the features work, and are well received, we’ll be making a similar feature available to all WhatDoTheyKnow users in the future.
Keeping in mind that as our public users have different needs to our Pro users there are some design challenges to overcome beforehand. For example – the public request page has more features to help less-frequent users, because we’re keen to ensure that everyone can participate in the FOI process, not just experts. Conversely, Pro users are by their very nature more likely to require less guidance. We’re going to need to do more research on this shortly.
Got some feedback?
Whether you’re a WhatDoTheyKnow Pro customer or not, we’d love feedback on this feature — or any other. Drop us an email to firstname.lastname@example.org.
There’s a common theme to a lot of mySociety sites: enter your postcode, see something that relates to you.
From FaxYourMP—the mySociety project so old it predates mySociety itself (paradox!)—through to TheyWorkForYou, FixMyStreet, and WriteToThem, as well as a few of our commercial projects like Mapumental and Better Care, we’ve discovered that asking for a visitor’s location is a super effective way of unlocking clear, relevant information for them to act on.
So perhaps it shouldn’t have come as a surprise that, while doing some regular monitoring of traffic on this website, we noticed a fairly significant number of people attempting to search for things like postcodes, MP names, and the topics of recent debates.
Random sample of search terms, July–December 2017 animal sentience corbyn germany CR0 2RH theresa may EN3 5PB fire ruth davidson HG5 0UH eu withdrawal bill diane abbott
By default, the search box on this site delivered results from our blog post archive (it goes all the way back to 2004 don’t you know!)… which is pretty much what you’d expect if you know how we do things here at mySociety. We have this centralised website to talk about ourselves as an organisation; then each of our projects such as TheyWorkForYou or FixMyStreet is its own separate site.
But, looking at these search terms, it was pretty clear that an awful lot of people don’t know that… and, when you think about it, why should they?
The most obvious solution would just have been to direct visitors towards the individual sites, so they could repeat their searches there. Job done.
But we figured, why inconvenience you? If you’ve made it this far, we owe it to you to get you the information you need as quickly as possible.
Handily, we’ve got rather good at detecting valid postcodes when our users enter them, so programmatically noticing when a user was searching for a location wasn’t hard. And equally handily, TheyWorkForYou offers a powerful API that lets developers exchange a user’s postcode for detailed data about the boundaries and representatives at that location.
What do you get when you combine the two? Automatic search suggestions for TheyWorkForYou, FixMyStreet, and WriteToThem, when you enter your postcode on www.mysociety.org.
The search page is also aware of the most frequently searched-for MPs on our site, and will offer a direct link to their TheyWorkForYou profile if you search for their names.
And finally, if you search for something other than a postcode, we give you a single-click way to repeat your search, automatically, on TheyWorkForYou, opening up decades of parliamentary transcripts to you, with a single tap of your finger.
It’s not a big, glamorous feature. But it’s something we know will come in useful for the few hundred people who search our site every week—possibly without their ever noticing this little bit of hand-holding as we steer them across to the site they didn’t even know they wanted. And most importantly, it should introduce a few more people to the wealth of data we hold about the decision-makers in their lives.
Header image, Flickr user Plenuntje, CC BY-SA 2.0
Last month, I gave a talk at DotYork—a digital conference in the North of England—about the way mySociety designs and builds websites for different countries and cultures all around the world.
If you’re into web technologies, or user research, or just generally the sort of work mySociety does, then it’s a fun 15 minute watch!
You can download the slides from my talk here, or watch videos of all the other DotYork 2017 talks here.
At the end of the Q&A session, I said I should write a blog post with links to some of the stuff I couldn’t fit into my talk. So here is that blog post!
- Working with the mySociety design team – a primer we often share with new international partners, before starting on a joint project.
- The Facebook-Loving Farmers of Myanmar – a fascinating exposé into how people outside the Europe and the US have very different relationships with online technologies.
- User Research When You Can’t Talk To Your Users – some great ideas on where to get user feedback on your products, even when you can’t talk to them in person.
- A really excellent post from Karolina Szczur on improving front-end performance for websites, including optimising images, fonts, and scripts, and continuously montoring performance.
- A guide to Analysing Network Performance in Chrome DevTools – a great introduction for anyone trying to track down why their website isn’t loading quickly.
Header photo © Hewitt & Walker
We recently made some changes to our Freedom of Information software, Alaveteli, that makes it twice as easy for partners to change the look and feel of their site. This post goes quite in-depth, so it’s probably best suited for designers, developers and other technically-minded readers
This year we embarked on a ground-up redesign of Alaveteli’s theming capabilities to make customising Alaveteli easier and faster. We used a mixture of techniques to try to achieve this and since releasing the update we’re happy to have seen a decrease in the complexity of our themes, and the time we spend making them.
Alaveteli, our Freedom of Information platform is one of our most deployed software packages and each deployment requires some customisation, from simple branding changes to complex functionality to support a country’s FOI process. This is either done internally by our own developers, or our partners take this on themselves.
An Alaveteli deployment consists of two things, the core: the guts of Alaveteli with no customisations, and the theme: the aesthetic and functional customisations made to each site. We ship Alaveteli with a fully-featured base theme that gives partners a good starting point to work from, but they can also start their own theme from scratch.
After talking to our partners and the Alaveteli team we felt that the process of theming was too complicated and involved. It required a lot of knowledge of Alaveteli’s inner workings, was coded in a way that made it hard to understand, and almost always required the intervention of a front-end expert, even to make trivial changes.
Our vision for how Alaveteli’s theming should work was:
- Intuitive Front-end developers and designers should be able to follow and understand the templates without needing expert knowledge about Alaveteli’s inner-workings.
- Flexible Overriding Alaveteli’s core code should be easy, so a theme should use low-specificity, componentised code to enable this.
- Supportive Should a partner decide to only change a few colours, or embark on a large-scale redesign Alaveteli, the theming process should never get in the way.
How we did it
Using the tools we have
Alaveteli is built on Ruby on Rails, so our first goal was to make better use of Ruby on Rail’s template inheritance.
Firstly, we split all of the Sass files into logical components.
Each component has two associated Sass files, a layout.scss and a style.scss. layout.scss describes only layout of a component, e.g. the physical dimensions and position on a page. style.scss describes the styles, for example typefaces, colours, borders and other presentational properties.
Should a partner wish to totally redesign or replace a component, they can replace both files with their own. Alternatively they can just choose to replace one part of the component, for example keeping the layout, but replacing the styles.
Ensuring the lowest possible specificity
When customising Alaveteli we want to be sure that a partner never has to fight with the base theme to achieve their goals. The most important part of this is to ensure CSS styles are easy to override.
Firstly we removed all ID selector’s from Alaveteli’s stylesheets and replaced them with class selectors, giving us a good jumping off point as class selectors have much lower specificity than IDs. We then rewrote and refactored Alaveteli’s CSS using the Block Element Modifier methodology (BEM).
BEM helped us in two ways: it’s written in a way that makes CSS self-describing, for example the code snippet
.header__navigation__listtells us that this list is a child of the navigation element and a grandchild of the header element.
As well as this, using a single class to define the styles for this element means that using BEM gives our styles the lowest possible specificity, so partners can override them with little resistance.
Using a settings partial
All of our theme’s styles use the variables defined in _settings.scss when referencing colours, typefaces, spacing, and even logo files so the bulk of Alaveteli’s customisation can be done in our base theme’s settings partial _settings.scss.
This allows partners to make simple changes which have a huge impact on the look and feel of the site. We’ve found that the large majority of our theme customisation can be done by just changing the variables in this file and it has sped up the theming process markedly.
We’ve quietly rolled out these updates to Alaveteli over the past 12 months and the impact of the changes has been encouraging.
Internally, we’ve found our theming projects are faster and more efficient. We conservatively estimate that it takes half the time to make a new theme than it used to.
Thanks to the self-documenting nature of BEM and the styles encapsulated in our settings partial, Alaveteli theming requires a lot less understanding of the platform’s inner workings. Our partners are able to be more self-sufficient and rarely require our intervention to assist with simple customisations.
Maintenance and support of our themes is greatly simplified, as the structure is consistent across projects, we’re able to roll out further changes and fixes in a more predictable way.
Overall, we’re really happy with how the changes worked out and the things we’ve learnt from this project we’ll be carrying into our others too, so look out for changes like across our work in the future.
Last year, we blogged about the work we did for Médecins Sans Frontiers, suggesting improvements for their Patents Oppositions Database.
Need a quick recap? Two things you should know:
- When medicines are re-patented, it prevents the development of generic versions. One company retains the monopoly, and costs remain high, where otherwise the generics would have provided a cheaper option.
- Médecins Sans Frontiers support those who challenge patents in court by providing resources, such as arguments which have previously succeeded in similar cases, via their Patents Oppositions Database site.
As we explained in our last post, it was clear to MSF that while the idea of the Patents Opposition Database was sound, it relied on active take-up from community members — members who were often too busy to engage in a site that was anything less than simple and inviting.
That’s when they came to us, first for consultation, and then to put our suggestions into action. It’s exactly the sort of work we enjoy: it potentially changes lives, and it involves using good design and coding to do so.
Getting to the bottom of things
MSF had a good idea of why their site wasn’t enjoying the kind of take-up they’d hoped for, and in that initial phase we were able to confirm this through research.
As we talked directly to a number of the site’s users, and gave the site a rigorous analysis ourselves, we found some recurring frustrations:
- It was difficult to find content
- While there was patent information from a variety of sources, linking it together was a chore
- People weren’t contributing to the site because it took too long to do so
- There was no feeling of community, so users didn’t feel a strong compulsion to help one another
And that pretty much brings you up to speed with where we were last time we blogged this project. Since then, we’ve been beavering away on making improvements.
How do you encourage community?
People tend to look at community as a nebulous concept: all the more so with online communities, where success is often seen as a coincidental factor rather than one that you can foster.
But for this project, it was clear what to do. And the site has the odds stacked in its favour: visitors have a very strong motivation to contribute, so we just needed to make that as simple as possible.
We worked on two broad areas: the site’s design, and some new core functionality.
New design that removes barriers
- The first thing to do was to ensure the site met modern standards, breaking down any impediments to participation. It’s now responsive (ie it displays well on any size of screen), clear, and accessible.
- Then we made sure that, when visiting the homepage, it was obvious what to do next. This was achieved with a prominent search function, and some clearly signposted ‘next steps’.
- We wanted to reward people and organisations for playing an active part, so we created profile pages which highlight their activity.
- Documents are the mainstay of the site, so they’re now highlighted as the main resource on any pages where they’re relevant. We also tidied up the way they were being stored, so they’re consistent across the board.
- We tackled that user frustration and made sure that patent data from sources such as WIPO and EPO were cross-referenced and brought together.
New functionality that fosters participation
- Users can now view and mark up documents right on the site, and then share what they’ve discovered with other users, thanks to the ‘add an annotation’ function.
- We created an email alerts service, drawing on our experience running TheyWorkForYou, which sends out thousands of alerts to people tracking topics in Parliament. This kind of alerting system is great for bringing people back to the site at their own convenience. So now, when there’s a new case concerning a specific drug, anyone with an interest in that drug will receive an email. If someone leaves a note on one of your annotations, you’ll know about it too.
- Search is absolutely crucial to the site, so we implemented a powerful new search facility which can look through not just the site’s own pages, but the documents it hosts, too. We added filtering tools to give the user more control over what they see.
- Advanced users can also obtain search results in a standardised csv format for download, so they can be used for their own reporting, or even as a data source for other sites.
- We created a new ‘call for help’ service, so users can ask the community to contribute to a patent opposition. These become touchpoints across the site, where users are urged to help if they can.
Our improvements were presented at the AIPPI (International Association for the Protection of Intellectual Property) World Congress, and the new site is now live at www.patentoppositions.org.
Of course, we’ll be keeping an eye on its performance, and until April we’ll be refining and tweaking until we know that the much-needed community is up and running happily.
Image: Taiyo Fujii (CC)
When someone uses mySociety software to report a street problem, or make a Freedom of Information request, it’s often in a language other than English, because our code is used to power sites all over the world.
That’s fine: we include a facility for people to add translations to the sites they deploy, so, job done, right?
Except, unfortunately, there’s more to it than that. However much we complain about the idiosyncrasies of our language, there’s one thing English has got going for it, and that’s conciseness. And that means that words and phrases which fit quite nicely into our designs suddenly become problematic.
A recent front-end design ticket in Alaveteli, our Freedom of Information platform, centred around improving the display of various standard elements (the navigation bar, language switcher, logged-in user links) when the Alaveteli site in question is displaying in a language other than English.
Here’s a picture which shows exactly why that was an issue:
It was enough to make a designer sob.
To put it bluntly: As soon as those carefully-crafted navigation bar links get translated, all bets are off as to whether they’ll continue to fit in the space provided. It’s an issue that’s faced by anyone creating software designed for international reuse.
So I figured I’d share a few things the mySociety design team has learned about internationalisation, and one quick trick that I recently started using to test international language lengths on our own websites.
Not only are some languages more verbose than others (ie: they use more words to convey the same concept), but many use more characters per word.
Then there are other languages which use fewer—but more complex—characters that need to be displayed larger to still remain legible.
The W3C (which sets standards for the web) suggests that front-end developers can expect the following ratio of increase/decrease in visual text width when translating from English into this handful of common languages:
Language Translation Ratio Korean 조회 0.8 English views 1 Chinese 次檢視 1.2 Portuguese visualizações 2.6 French consultations 2.6 German -mal angesehen 2.8 Italian visualizzazioni 3
That’s a 150–200% increase in space required to display words in the European / South American languages that we deal with quite a lot here at mySociety.
Often, you’re lucky, and the layout includes enough space to absorb the extra words. Headings and paragraphs of text are really good at this. Indeed, as the amount of text to be translated gets bigger, you notice that the translation has less effect on space, as the W3C, again, notes:
No. of characters in English source Average expansion Up to 10 characters 200–300% 11–20 characters 180–200% 21–30 characters 160–180% 31–50 characters 140–160% 51–70 characters 151-170% Over 70 characters 130%
So—no need to worry—it’s just short little bits of text that hurt the most. Phew.
Hang on, short little bits of text… like all those buttons and links all over every single website mySociety makes?
That’s what mySociety has designers for 🙂
There are lots of tricks we can use to reinforce our layouts to better handle long strings. For instance, where possible, we avoid creating horizontally-constrained navigation bars.
And in some cases, we can use modern styling techniques like Flexbox to better handle overflowing text without harming legibility or the overall layout of the page.
But testing the effectiveness of these techniques can take time and, while we have a fantastic network of volunteers and international partners who translate our open source projects, we’re often working on the initial layout and styling before that has a chance to happen.
While I was working out fixes for the Alaveteli user links and language picker dropdown, I threw together a quick “pseudolocalize” function that temporarily makes the text longer, so we could preview how it’ll look once it gets translated.
Only later did I discover that “Pseudolocalization” is, apparently, a real thing, originating from the Windows developer community.
Typically existing Pseudolocalization functions would do all sorts of orthographic substitutions to test how weird characters are displayed, as well as padding the strings to make them longer. So, something like Account Settings would be transformed into [!!! Àççôûñţ Šéţţîñĝš !!!].
My little function skips the weird character substitutions, and instead just doubles the text content of any elements you tell it to.
So you can run…
…in your browser console, to turn this…
Yep, it’s useful and it’s ridiculous — our favourite combination.
Plus, it’s super fast, and it works with nested elements, so if you were totally crazy, you could just run it on the entire
'body'and be done with it!
Now, we’re not saying we’ll be able to cope with, say, the longest word in Sanskrit, which is 431 letters long, but this approach does make us pretty confident that we’ve got a great basis for whatever most languages can throw at us.
If you’re a web developer with similarly ingenious tricks for improving the internationalization of your sites, share them in the comments box!
Photo of Nepalese prayer wheels by Greg Willis – CC BY-SA 2.0
You’ve probably seen the recent news story about the guy who bought, then vastly increased the price of a vital drug: it’s been widely shared on social media in the last couple of days.
Not long ago, we blogged about the work we’d done on the Patent Oppositions Database.
You may have found the concepts involved somewhat abstract. If so, now’s a great time to go and read it again, with this news story in mind. It’s an excellent example of what that project is hoping to prevent.
Image: David Goehring (CC)
International emergency aid charity Médecins Sans Frontiers are one of the biggest purchasers of medicine worldwide, and naturally it’s important that the drugs they buy are cost-effective. Where possible, they choose generics—white label medicines that contain the same ingredients even if they don’t carry the well-known brand names: think ‘ibuprofen’ or ‘aspirin’ rather than ‘Nurofen’ or ‘Anadin’.
But when a specific medicine is only available as a patented product from a big drugs company and with an equally big price tag attached, MSF, like everyone else, has little choice but to pay.
Curiously, this turned out to be a problem that can be solved, in part, through good web design. Here’s the story.
Obviously, drugs companies have an interest in keeping their medicines under patent. As MSF explained, patents, and in particular the practice of ‘evergreening’ them (extending their life indefinitely by making slight modifications to the medicine’s make-up), give pharmaceutical companies a monopoly on pricing, and can impede access to patients who would benefit from them.
MSF’s online project, the Patent Oppositions Database (PODB) is a resource for helping people challenge medicine patents. PODB helps groups around the world to find each other and work on cases together, and to share previous examples of art and arguments used in lawsuits which may help others in future oppositions.
The site was already up, running and functional, and the concept was sound. But it wasn’t attracting much take-up. On analysis, it became clear that this was because there was no focused experience on the site, encouraging users towards the core interactions which would power the whole concept of collaborating and sharing knowledge.
Where design came in
MSF asked us to suggest improvements that would enable groups to communicate about specific cases, and to improve the sense of community. Our solutions will add intuitive user paths that lead people to existing opposition cases and the information they need, then encourage them to join in by placing discussions and information about contributors on the page.
It’s crucial for MSF that the project reaches its full potential, and with the in-depth design changes we’ve suggested, and have now been asked to implement, we know it will.
You can read more about how we approached this project in our latest case study, over at the mySociety Services website.
Image: Procsilas Moscas (cc)