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.
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:
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!
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.
Our FOI site WhatDoTheyKnow has a fancy new frontage.
Coming hot on the heels of TheyWorkforYou’s new homepage, the fresh look is part of our rolling process of design improvements. Out goes the rather sober grey and burgundy colour scheme, and in comes a fetching cobalt blue paired with banana yellow.
As you might have guessed, though, there’s more to this than a new palette. Yes, in the fast-changing world of web design, fashions change and dated sites can run the risk of looking irrelevant—but we are also keen to ensure that any new design works for its keep.
Not just a pretty face
It’s important, when we invest time and resources into a redesign, that there are tangible improvements. So, like almost everything we do these days, the changes will be subjected to scrutiny from our Research team.
They’ll be checking that we’ve:
- Improved the site’s usability, making it more obvious how to browse or file FOI requests;
- Encouraged users to take the step of making an FOI request, even if the concept is a new one for them;
- Enabled people to understand what the FOI Act is, and what rights it confers.
That’s a lot to expect from a simple redesign, so let’s take a look at how we hope to achieve it.
Of course, the first thing visitors see is the title text. It may seem pretty simple, but, as anyone who writes will know, the shorter the sentence, the harder it is to get right.
Take it from us, this deceptively simple piece of copy represents quite a bit of anguished brainstorming:
It tries to distill a complex idea into something that absolutely everyone can understand, even if they’ve never heard of FOI before. Meanwhile, the subtitle highlights your legal right to information.
Alaveteli, the software this and many other FOI sites around the world are built on, has always included two figures on its sites’ homepages: the number of requests that have been made through the site, and how many public authorities it has contact details for. The image below displays WhatDoTheyKnow’s stats at the time of writing:
It’s a nice way of showing that the site is both useful and used, but there’s something else, too: when users see that other people have taken an action online, they’re more likely to take the plunge themselves. It’s the same thinking that informed our byline on WriteToThem: “Over 200,000 messages sent last year.”
How it works
The homepage now includes a simple graphic to show the path you can expect to take if you go ahead and file an FOI request on the site:
Breaking the process down into just three steps makes it look manageable, and there’s a link deeper into our help pages for people who want to understand the FOI Act better.
For those who prefer to browse
Some content remains the same. We’ve still included links to the latest successful requests—albeit lower down the page, so as not to distract from the page’s main message, that you can make a request. These show, more graphically than any piece of copy could, that you can get results:
They’re also a great way into the site for people who just want to browse: they are a random assortment of requests that have recently been marked as successful, and can often throw up some surprising and interesting subject matter.
Sharing the benefits
Provided that we discover that the design has been effective in the areas mentioned above, we hope to roll it out as an option on the wider Alaveteli codebase, so it can be implemented by anyone running an Alaveteli site.
Meanwhile, the open source code can be accessed on Github by anyone who would like to use it.
Visit TheyWorkForYou’s homepage today, and you’ll see big changes.
These pages being the most visited, it made sense – but it did leave us with a shop window that did no justice to the goods within.
High time for a new front page
TheyWorkForYou’s homepage had not changed all that much since the site began in 2004: as new content such as committees or the devolved parliaments were added in, they simply got squeezed in wherever they would fit.
This is the first time in a good few years that we’ve taken a step back, started again with a blank canvas and prioritised what’s important.
Simpler, leaner, better-looking
It tells you what the site is for
Consistently, a good 60% of our users are first-time visitors to the site, so we need to make it very clear exactly what we do, and why they should care.
It helps you find your MP’s information
78% of the UK population don’t know the name of their MP (presumably that’ll be even higher for a while, post-election!). That’s why a postcode box, which matches you to your MP—and not a search box—is the most prominent input on the page.
It highlights current affairs
We know from experience that a large proportion of our users’ searches are based around issues that have just hit the headlines, whether that’s the latest budget, a ding-dong at Prime Minister’s questions, or a big news story.
It’s not always obvious to a casual observer where to find the relevant debates: for example, in Hansard (the official record of Parliament, which is where our content comes from) the budget is called the ‘Autumn Statement’, while Prime Minister’s Questions is labelled ‘Engagements’.
So now we have space to signpost the content that most visitors are likely to be looking for.
It encourages you to subscribe to activity
In a secondary but still prominent position, we signal that you can sign up for email alerts whenever your chosen MP speaks or your chosen keyword is mentioned. We hope that this will encourage still more people to engage on the things that matter to them.
It offers other paths in to content
If you’re just browsing, there’s still plenty of chance to see what’s new. Recent activity from Parliament is showcased on the lower half of the page, or you can riffle through all the different parliaments and types of debate in the top menu.
A fitting gateway
TheyWorkForYou still has all the same content, but now it has a homepage to be proud of, too.
That homepage is still a gateway into rich data: an archive of searchable, shareable, readable debates going back to the 1930s, profiles and voting records for MPs and Lords both current and historic, and the calendar of upcoming events.
With this new design, though, it should all be much easier to find. We hope you like it.
Users of Lothian Buses are more satisfied with the value for money of their bus journeys than anyone else in the country.
Passengers on the Oxford Park and Ride service find the seats the most comfortable. And the drivers of Trent Barton in Nottinghamshire give a friendly enough greeting, according to 95% of passengers.
It’s an extension of the work we did last year to help the transport watchdog display their train satisfaction data. We’ve introduced a new design which, we hope, makes it much easier to explore the results of Passenger Focus’ annual passenger satisfaction survey.
We’ve used a new visual approach that is appropriate for the bus data: it makes it really easy to browse through 32 different survey categories, from cleanliness to safe driving.
When you have that many categories, drop-downs aren’t really an option, and we’re pleased with what we came up with to make it easy to make the most important categories prominent, while still allowing easy and intuitive access to the others.
We’ve also used responsive design, which means it performs beautifully whether viewed on mobile or at the desktop. Check it out for yourself here – be sure to resize your browser to see the mobile version kick in!
Simply Secure is a new organisation, dedicated to finding ways to improve online security – in ways so accessible and useful that there will be no barrier to their use.
It will bring together developers, UX experts, researchers, designers and, crucially, end users. The plan is to ensure the availability of security and privacy tools that aren’t just robust – they’ll be actively pleasing to use.
Now, you may be thinking that online privacy and security aren’t the most fascinating subject – but this month, the chances are that you’ve actually been discussing it down the pub or with your Facebook friends.
Remember the iCloud story, where celebrities’ personal photographs were taken from supposedly secure cloud storage and put online? Yes, that. If you uttered an opinion about how those celebrities could have kept their images more safely, you’ve been nattering about online security.
Simply Secure is founded on the belief that we’d all like privacy and security online, but that up until now, solutions have been too cumbersome and not user-centred enough. When implementing them becomes a hassle, even technically-literate people will choose usability over security.
How we helped
Simply Secure knew what their proposition was: now we needed to package this up into a brand for them. Crucially, it needed to transmit a playful yet serious message to launch the organisation to the world – within just four weeks.
Our designer Martin developed all the necessary branding and illustration. He created a look and feel that would be carried across not just Simply Secure’s website, but into the real world, on stickers and decoration for the launch event.
Meanwhile, mySociety Senior Consultant Mike helped with content, page layout and structure, all optimised to speak directly to key audience groups.
Down at the coding end of things, our developer Liz ensured that we handed over a project that could be maintained with little to no cost or effort, and extended as the organisation’s purpose evolves.
“mySociety are brilliant to work with. They did in a month what I’ve seen others do in six, and they did it better” – Sara “Scout” Sinclair Brody, Simply Secure
What did the client think? In their own words: “We approached [mySociety] with a rush job to build a site for a complex and new effort.
“They were able to distill meaning from our shaky and stippled examples, and create something that demonstrated skill not only as designers and web architects, but as people able to grasp nuanced and complicated concepts and turn those into workable, representative interfaces”.
Always good to hear!
People who know mySociety’s work might have noticed that we don’t typically work on purely content-driven sites. Generally we opt to focus on making interactions simple, and data engaging, so why did we go ahead with the Simply Secure project?
Well, there were a couple of factors. Firstly, we genuinely think that this will become an invaluable service for every user of the internet, and as an organisation which puts usability above all else, we wanted to be involved.
Second, we believe in the people behind the project. Some of them are friends of mySociety’s, going back some time, and we feel pretty confident that any project they’re involved in will do good things, resulting in a more secure internet for everyone.
Take a look
Simply Secure launches today. We’ll be checking back in a couple of months to report on how it’s going.
So we wanted to build an app for FixMyStreet. Easy: we just had to make a cut-down version of the website, right?
Hmm, not quite.
Now he explains a little more about what informed the decisions he made during the apps’ development.
Moving the map, not the pin
When you use the desktop version of FixMyStreet, the first thing it asks for is your location, and there’s a good reason for that. It’s such a good reason that it needed to apply to the app as well.
On the desktop site we ask you to input your postcode or street name. With a mobile app, it’s much more likely that you’ll be reporting a problem that’s right in front of you, so we can usually skip that step and show you a map of your current location.
However, while the accuracy of geolocation technology is pretty good, it’s not perfect, so we wanted to let users fine-tune the location.
On the website you click on the map to drop a pin where the problem is, but we’ve found this isn’t the best solution on a small screen. Fingers are big and the end of a pin is small so it can take several clicks to correctly position the pin.
We quickly realised that having a central static crosshair, and moving the map to the location was a much easier and more accurate way to set a location.
Sending reports made offline
As we explained in the previous post, one of the benefits of the apps over the mobile site is that you can make reports even if you have no phone coverage. The app stores all the details until you get back within range and you’re ready to send it off.
One decision we made, which might seem initially puzzling, is that these offline reports don’t automatically get sent off to the council once you’re back within range of a phone or wifi signal.
There are two linked reasons for this, and they’re both related to the fact that FixMyStreet lets you report a problem even if you don’t know who to send it to.
Simply, before we can work out who to send the report to, we need to know exactly where you are – and that you are within FixMyStreet’s area of coverage (ie, within the UK).
Your location also dictates the categories that we show you. Each council has its own categories, and in areas covered by two tiers of government, each council will deal with different types of report. So for example, your county council might deal with potholes, while your district council handles dog fouling.
Once you’re back online we can check that the location is one we can accept a report about, and then fetch the list of categories for you to pick from.
In effect, this delay is also a second chance for you to check your report before you send it off, although that was never the reason for the decision!
The constant map
We initially designed it with the map only appearing when you needed it, but having the map underlying the reporting process provides a nice bit of continuity with the website, and seemed to make the app cohere better too. So, while there’s no particular reason for it to be there, we made the decision to keep things uniform.
If anything else about the app has got you wondering, do feel free to leave a comment below!