One service we offer on TheyWorkForYou is an email alert: this lets you know when there is new data published on the site that either contains a word/phrase that you’ve subscribed to, or that indicates new activity from your selected Member/s of Parliament.
(Didn’t know this? Go and sign up now!)
We send around 400,000 of these emails a month. For many years, the look has remained exactly as it was when we first developed them: plain text, which has the benefit of being lightweight and unlikely to get scrambled by email clients. The downsides are that it doesn’t exactly make for a compelling email, visually speaking, and that some find it hard to identify which sections are of interest in a uniform block of unformatted text.
We’ve now finally transformed alert emails into a much more polished HTML format, and at the same time we’ve also improved the look and feel of four other vital elements of TWFY: profile images, the API, the sign-up page, and the Contact page.
As usual, before starting work, we did a bit of research into who uses this feature and why, so we could be sure we were answering their needs. You can see more about this in Alex’s post here.
Photos of MPs
Where there is a more recent and higher quality image available, we’ve updated the profile image we use for MPs. In some cases, this has replaced some pretty youthful faces — it’s clearly high time we caught up with this particular ticket!
Higher resolution or larger images also mean that they’ll be more useful to developers using the images (which are all available under an open licence) on other sites and apps.
Clearer access to the API
The API page (where developers and researchers can access TheyWorkForYou data) has been given a slick new design. We’ve updated it with new examples of how the API might be used, and streamlined the language and content to make it easier to understand.
We hope that all of these features will make it easier and more pleasant for you to use TheyWorkForYou, either when you’re checking up on what’s happened in Parliament for yourself, or using our data to make other parliamentary apps and sites.
Image: David Pisnoy
When something’s not right on your street, and you’ve gone out of your way to report it to the local council, the last thing you want is to get bogged down in a complex log-in procedure.
That’s why FixMyStreet has always put the log-in step after the reporting step, and has always allowed you to report a problem without needing an account or password at all.
But we know we can always do better, and in the 11 years that FixMyStreet has been around, new design patterns have emerged across the web, shifting user expectations around how we prove our identities and manage our data on websites and online services.
Over the years, we’d made small changes, informed by user feedback and A/B testing. But earlier this year, we decided to take a more holistic look at the entire log-in/sign-up process on FixMyStreet, and see whether some more fundamental changes could not only reduce the friction our users were experiencing, but help FixMyStreet actively exceed the average 2018 web user’s expectations and experiences around logging in and signing up to websites.
One thing at a time
Previously, FixMyStreet tried to do clever things with multi-purpose forms that could either log you in or create an account or change your password. This was a smart way to reduce the number of pages a user had to load. But now, with the vast majority of our UK users accessing FixMyStreet over high speed internet connections, our unusual combined log-in/sign-up forms simply served to break established web conventions and make parts of FixMyStreet feel strange and unfamiliar.
In 2014 we added dedicated links to a “My account” page, and the “Change your password” form, but it still didn’t prevent a steady trickle of support emails from users understandably confused over whether they needed an account, whether they were already logged in, and how they could sign up.
So this year, we took some of the advice we usually give to our partners and clients: do one thing per screen, and do it well. In early November, we launched dramatically simplified login and signup pages across the entire FixMyStreet network – including all of the sites we run for councils and public authorities who use FixMyStreet Pro.
Along the way, we took careful steps—as we always do—to ensure that assistive devices are treated as first class citizens. That means everything from maintaining a sensible tab order for keyboard users, and following best practices for accessible, semantic markup for visually impaired users, to also making sure our login forms work with all the top password managers.
Keeping you in control
The simplified log-in page was a great step forward, but we knew the majority of FixMyStreet users never used it. Instead, they would sign up or log in during the process of reporting their problem.
So, we needed to take some of the simplicity of our new log-in pages, and apply it to the reporting form itself.
For a few years now, the FixMyStreet reporting form has been split into two sections – “Public details” about the problem (which are published online for all to see) followed by “Private details” about you, the reporter (which aren’t published, but are sent to the authority along with your report, so they can respond to you). This year, we decided to make the split much clearer, by dividing the form across two screens.
Now the private details section has space to shine. Reorganised, with the email and password inputs next to each other (another convention that’s become solidified over the last five or ten years), and the “privacy level” of the inputs increasing as you proceed further down the page, the form makes much more sense.
But to make sure you don’t feel like your report has been thrown away when it disappears off-screen, we use subtle animation, and a small “summary” of the report title and description near the top of the log-in form, to reassure you of your progress through the reporting process. The summary also acts as a logical place to return to your report’s public details, in case you want to add or amend them before you send.
Better for everyone
As I’ve mentioned, because FixMyStreet is an open source project, these improvements will soon be available for other FixMyStreet sites all over the UK and indeed the world. We’ve already updated FixMyStreet.com and our council partners’ sites to benefit from them, and we’ll soon be officially releasing the changes as part of FixMyStreet version 2.5, before the end of the year.
I want to take a moment to thank everyone at mySociety who’s contributed to these improvements – including Martin, Louise C, Louise H, Matthew, Dave, and Struan – as well as the helpful feedback we’ve had from our council partners, and our users.
We’re not finished yet though! We’re always working on improving FixMyStreet, and we’ll be keeping a keen eye on user feedback after these changes, so we can inform future improvements to FixMyStreet.com and the FixMyStreet Platform.
You can help us keep improving our services.Donate now
Parliamentary votes (or ‘divisions’ as they’re known in the lingo) aren’t always the easiest things to understand; yet, as we know from our email inbox, they’re often what our users want to know about most.
For a long time TheyWorkForYou would display divisions as a plain list, usually at or near the end of a debate. When a user wrote to ask us how they could see how a specific representative had voted on the issue of the day, we’d point them towards the relevant section of the right page — but of course, it’s much better if you can find the information for yourself.
Things improved a little when we created the Recent Votes page, and separated out information for each vote onto their own pages. At that point, though, we were only displaying votes which counted towards the topics we cover on representatives’ Voting Record pages: in other words, those which helped us assess MPs’ and Lords’ stances on issues such as university tuition fees, fox-hunting, etc.
Now, with this new tranche of work, we’ve been able to make the following improvements:
- All votes are included on the Recent Votes page, not just ones feeding the voting records.
- The voting breakdowns are shown graphically, so you can see straight away what the rough proportions were, and to what extent each party’s members made up each side. It should also be easy to see immediately when a representative votes differently to the majority of their party!
- As we blogged recently, we’re including information on voting for anyone subscribed to MP alerts.
If you’d really like to understand the full context of each vote, we hope you’ll click through from these pages and read the preceding debates.
We hope you’ll now find it a lot easier to understand votes — and this certainly feels like a timely addition, given the interesting voting activity of recent days.
You can help us keep improving our services.Donate now
Image: Katie McNabb
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!