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.
When you consider that FixMyStreet has been running for over a decade, it’s not really surprising that the maps in some areas are a little over-crowded with pins.
That can be a problem for anyone trying to make a new report — even when you zoom right in, we were beginning to find that in some very congested areas, it was difficult to place a new pin without clicking on an existing one.
We’ve tried to remedy this in various ways in the past. For a while we only displayed newer reports by default, a decision which we discarded when we brought in pagination, allowing users to click through batches of reports rather than seeing them all in one long list on a single page.
For some time now we’ve also provided the option to hide the pins completely, via this button both on the desktop and app versions:
And there’s also a ‘hide pins’ option at the foot of the map:
But even so, arriving at a map absolutely covered in pins and having to look around for that button doesn’t exactly seem like a nice, smooth user journey, so we’ve revisited the matter.
Why not just delete the old reports?
We’ve always had a policy of keeping every report live on FixMyStreet (unless it’s reported to us as abusive, or its maker contacts us to ask us to remove it — and even in this latter case we’d prefer to retain the content of the report while anonymising it).
This is because the reports made to councils build up to create an invaluable archive of the issues that various regions of the country face, through time.
The historic collection of reports allows planners to understand recurring or seasonal problems; and researchers use this data as well, to get insights into all sorts of issues. For examples, see Réka Solymosi’s presentation at TICTeC on using FixMyStreet data to understand what counts as ‘disorder’ in the environment, or mySociety’s own research on why some areas of the country report on FixMyStreet more than others.
And so here’s what we’ve done
- When you visit a map page on the main FixMyStreet site, by default, you’ll again only see reports that are less than six months old, and that are still open.
A report remains ‘open’ until the council marks it as ‘closed’, or a user or the council marks it as ‘fixed’. ‘Closed’ means that the council doesn’t intend to do further work on the issue, which can be for reasons such as the issue not falling within their responsibilities or because it is part of their regular maintenance schedule and will be seen to in time.
- You can still opt to see closed and fixed reports by selecting from the dropdown at the top of the list:
- And you can also still see reports older than six months by clicking the checkbox:
- The two filters work together, giving you the options of displaying:
- Open reports less than six months old (the default)
- Open reports of any age
- All reports less than six months old
- All reports of any age
- Any combination of open/closed/fixed reports less than six months old
- Any combination of open/closed/fixed reports of any age
To keep things simpler for app users, the display there is set to only show newer, open reports, so if you want the full range of options, you’ll need to switch to viewing the site on a desktop.
Additionally, reports that have been closed for six months without any update being made will now no longer allow updates. If you need to update an issue that falls into this category, we recommend starting a new report (possibly linking to the old one for reference if it provides useful information for the council).
But you might not see this everywhere
Some councils use FixMyStreet Pro as their own fault-reporting software. These councils can opt whether or not to adopt these defaults, so your experience may be slightly different when visiting FixMyStreet via your local council’s own site.
We think that we’ve arrived at a more intuitive solution than those we tried before — and we hope that these options will suit everyone, whether you’re a user in a hurry coming to make a quick report, or someone who’d like to see a more in-depth history of the area. Give it a go, and then let us know your thoughts.
You might already be enjoying one of the usability improvements that FixMyStreet version 2.0 has brought, though it’s possible that you haven’t given it much thought.
But for FixMyStreet, we hadn’t given much thought to letting you filter reports by more than one dimension, until Oxfordshire County Council suggested that it would be a useful feature.
For quite some time, you’d been able to filter by category and status (“Show me all pothole reports” or “Show me all ‘unfixed’ reports”), but this new functionality is more flexible.
You can now select multiple categories and multiple statuses simultaneously (“show me all pothole and graffiti reports that are unfixed or in progress”) — and all through the power of tickboxes.
If you’re a non-technical person, that’s all you need to know: just enjoy the additional flexibility next time you visit FixMyStreet. But if you are a coder, you might like to read more about how we achieved this feature: for you, Matthew has written about it over on the FixMyStreet Platform blog.
If you’ve used FixMyStreet recently — either to make a report, or as a member of a council who receives the reports — you might have noticed that the site’s automated emails are looking a lot more swish.
Where previously those emails were plain text, we’ve now upgraded to HTML, with all the design possibilities that this implies.
It’s all part of the improvements ushered in by FixMyStreet Version 2.0, which we listed, in full, in our recent blog post. If you’d like a little more technical detail about some of the thought and solutions that went into this switch to HTML, Matthew has obliged with in a blog post over on FixMyStreet.org.
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.