-
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.
What’s next?
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.
The problem
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?
Don’t panic!
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…
pseudolocalize('.navigation a')
…in your browser console, to turn this…
…into 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!pseudolocalize('body')
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
-
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.
These are the kind of insights that it’s now very easy to discover on the Passenger Focus website, thanks to the latest project by mySociety Services.
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!
-
FixMyStreet, our site for reporting things like potholes and broken street lights, has had something of a major redesign, kindly supported in part by Kasabi. With the help of Supercool, we have overhauled the look of the site, bringing it up to date and making the most of some lovely maps. And as with any mySociety project, we’d really appreciate your feedback on how we can make it ever more usable.
The biggest change to the new FixMyStreet is the use of responsive design, where the web site adapts to fit within the environment in which it’s being viewed. The main difference on FixMyStreet, besides the obvious navigation changes, is that in a small screen environment, the reporting process changes to have a full screen map and confirmation step, which we thought would be preferable on small touchscreens and other mobiles. There are some technical details at the end of this post.
Along with the design, we’ve made a number of other improvements along the way. For example, something that’s been requested for a long time, we now auto-rotate photos on upload, if we can, and we’re storing whatever is provided rather than only a shrunken version. It’s interesting that most photos include correct orientation information, but some clearly do not (e.g. the Blackberry 9800).
We have many things we’d still like to do, as a couple of items from our github repository show. Firstly, it would be good if the FixMyStreet alert page could have something similar to what we’ve done on Barnet’s planning alerts service, providing a configurable circle for the potential alert area. We also are going to be adding faceted search to the area pages, allowing you to see only reports in a particular category, or within a certain time period.
Regarding native phone apps – whilst the new design does hopefully work well on mobile phones, we understand that native apps are still useful for a number of reasons (not least, the fact photo upload is still not possible from a mobile web app on an iPhone). We have not had the time to update our apps, but will be doing so in the near future to bring them more in line with the redesign and hopefully improve them generally as well.
The redesign is not the only news about FixMyStreet today
As part of our new DIY mySociety project, we are today publishing an easy-to-read guide for people interested in using the FixMyStreet software to run versions of FixMyStreet outside of Britain. We are calling the newly upgraded, more re-usable open source code the FixMyStreet Platform.
This is the first milestone in a major effort to upgrade the FixMyStreet Platform code to make it easier and more flexible to run in other countries. This effort started last year, and today we are formally encouraging people to join our new mailing list at the new FixMyStreet Platform homepage.
Coming soon: a major upgrade to FixMyStreet for Councils
As part of our redesign work, we’ve spoken to a load of different councils about what they might want or need, too. We’re now taking that knowledge, combining it with this redesign, and preparing to relaunch a substantially upgraded FixMyStreet for Councils product. If you’re interested in that, drop us a line.
Kasabi: Our Data is now in the Datastore
Finally, we are also now pushing details of reports entered on FixMyStreet to Kasabi’s data store as open linked data; you can find details of this dataset on their site. Let us know if it’s useful to you, or if we can do anything differently to help you.
Technical details
For the web developers amongst you – we have a base stylesheet for everyone, and another stylesheet that is only included if your browser width is 48em or above (an em is a unit of measurement dependent on your font size), or if you’re running Internet Explorer 6-8 (as they don’t handle the modern CSS to do this properly, we assume they’ll want the larger styles) using a conditional comment. This second stylesheet has slight differences up to 61em and above 61em. Whilst everything should continue to work without JavaScript, as FixMyStreet has done with its map-based reporting since 2007, where it is enabled this allows us to provide the full screen map you can see at large screen sizes, and the adjusted process you see at smaller resolutions.
We originally used Modernizr.mq() in our JavaScript, but found that due to the way this works (adding content to the end of the document), this can cause issues with e.g. data() set on other elements, so we switched to detecting which CSS is being applied at the time.
On a mobile, you can see that the site navigation is at the end of the document, with a skip to navigation link at the top. On a desktop browser, you’ll note that visually the navigation is now at the top. In both cases, the HTML is the same, with the navigation placed after the main content, so that it hopefully loads and appears first. We are using display: table-caption and caption-side: top in the desktop stylesheet in order to rearrange the content visually (as explained by Jeremy Keith), a simple yet powerful technique.
From a performance point of view, on the front page of the site, we’re e.g. using yepnope (you can get it separately or as part of Modernizr) so that the map JavaScript is downloading in the background whilst you’re there, meaning the subsequent map page is hopefully quicker to load. I’m also adding a second tile server today – not because our current one isn’t coping, it is, but just in case something should happen to our main one – we already have redundancy in our postcode/area server MapIt and our population density service Gaze.
If you have any technical questions about the design, please do ask in the comments and I’ll do my best to answer.