1. Making better information requests in Hackney – Part II

    This is part II in a series of blog posts about our work with Hackney Council to conduct a discovery and prototyping project to improve the public-facing parts of information request processes. Read the first part here.

    With our experience of running WhatDoTheyKnow and Alaveteli, we’re big believers in the importance of information transparency laws in our democratic system. But at the same time, we understand the operational challenges of meeting the statutory requirements of these laws for public bodies.

    The challenges of dealing with information requests

    While many local authorities have dedicated information governance staff whose job it is to manage requests, finding and compiling the information is often done by hard-pressed staff within services, fitting in information-related work around their core responsibilities.

    Requesters sometimes have the expectation that information is all carefully organised in a few databases, ready to be aggregated and extracted at the click of a button. In reality, the degree to which information is well-organised varies a lot between services in a council and between different councils, often because of procurement decisions and departmental priorities stretching back many years.

    Working with Hackney Council

    We’re part way through our project with Hackney Council that Mark wrote about a few weeks ago, helping them redesign the public-facing parts of their FOI and Subject Access Request (SAR) services, so we’ve seen these challenges up close. We’ve also seen how they can be made even trickier by legacy IT systems that are no longer fit for purpose.

    At our ‘show and tell’ last week with Hackney, we shared findings from some of the research we’ve done, along with early prototypes of potential new FOI and SAR submission forms, both created collaboratively with Hackney Council staff.

    Prototyping with the GDS toolkit

    We decided to go straight from sketches to HTML-based prototypes for this project. We thought that moving in-browser with real interactive elements would make it easier to test out some of the more complicated interactions and conditional workflow of the SAR process in particular.

    Prototyping is about quickly testing hypotheses, and not getting bogged down in implementation details. So it was a pleasure to use the GDS frontend toolkit to build our prototypes. Not only did the GOV.UK toolkit help us build something relatively rich in just a few days, but it also meant we benefited from GDS’s previous work on design patterns developed for exactly this kind of context.

    Using public information to reduce FOI requests

    When submitting a request via WhatDoTheyKnow, users are automatically shown previously submitted requests that might answer their question, and we know that almost 10% of requesters have a look at these suggestions in more detail.

    As you can see here, we took this pattern from WhatDoTheyKnow, and enhanced it further in our FOI prototype.

    Now, as well as prompting with previous FOI responses from a disclosure log that we’re hoping to build, we also want to include relevant links to other topical or frequently requested information, drawn from other data sources within the council.

    If we can get this to work well, we think it could have a number of benefits:

    • Helping the person submitting the FOI get their answer more quickly
    • Reducing the number of requests that would otherwise have been sent to the council
    • Encouraging more proactive, structured publishing of data by the council.

    It’s this last point which we’re really interested in, longer term. We think using a common sense technology approach to highlight possible answers to FOI requests before they are made will get people answers more quickly, reduce the burden on responders, and reinforce efforts to proactively release commonly requested data leading to real transparency benefits.

    We’ve been doing usability testing of these prototypes over the last few days, and will be looking very closely at whether our assumptions here stand up to scrutiny.

    Reducing back and forth around SARs

    Given our background, we’re inevitably very interested in the FOI component of this project, but the Subject Access Request component is no less important. And while there’s none of the same opportunity for pre-emptively answering people’s requests, there’s plenty of scope for making the submission process a lot smoother.

    A valid FOI is just a written request and some contact details, but the information needed for a SAR to be valid is much greater and more complicated. For example, along with the specifics of the request, a solicitor asking for personal information on behalf of a parent and their 16-year old child would have to provide proof of ID and address for both family members, a letter of consent from the child, and a letter of authority from the parent, confirming that the solicitor is acting for them. Even the most straightforward SAR calls for the handling of personal data and confirmation of the requestor’s identity and address.

    Given all this complexity, it’s easy for there to be a lot of back and forth at the start of a SAR: clarifying a request, asking for documents, arranging receipt of documents, and so on.

    We’re hoping to build something that makes it much clearer to the person making the request what they’ll need to do, thereby taking some of that responsibility off the shoulders of the team managing the requests.

    process sketch showing first thoughts about SARs

    The sketch above was our first crack at something that could handle (most of) this complexity, and we’ve made a number of changes since then as our understanding of it all has increased.

    Recruiting representative users to test SAR submission has proved challenging and wasn’t helped by the Beast from the East rearing its snow-covered head. But we changed tack and successfully ran some guerilla testing in Hackney’s service centre last week, and we’re hoping to do further testing later in the project that has more chance of benefiting from contacts cultivated by individual services.

    Changing the conversation

    The conversation around information requests often focuses on the burden of responding. And although the number of information requests local authorities receive is unlikely to decrease any time soon, we’re hoping that through our collaboration with Hackney, we can make handling them a whole lot easier.

    If we do it well, we think we could eliminate a lot of the process issues created by poorly-designed legacy systems, while baking in a fundamentally more open and transparent way of operating that has the potential to benefit both citizen and state alike.

    Get involved

    If you’re responsible for managing FOI requests or data protection in your own public sector body and you’d like to follow this project in more detail—or if you’d like to participate in some of the discovery work—then please get in touch at hello@mysociety.org.

     

    Image: Sarah Palmer-Edwards

  2. Hello, is it me you’re searching for?

    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 facebook
    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

  3. Talking about the mySociety design process

    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!

    Header photo © Hewitt & Walker

  4. Designing for wordy languages at mySociety

    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:

    messy-alaveteli-headerIt 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?

    romg

    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.

    pseudolocalization-code-snippet

    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…

    before

    …into this!

    after

    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')
    psuedolocalized

    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 WillisCC BY-SA 2.0