Timeshifting Interactive Blog

We’ve worked on a number of multilingual sites over the last few years, each coming with its own set of challenges. Often it’s easy to underestimate the extra amount of work an additional language will add. Design is the main area that needs to be considered, but it’s also important not to forget about messaging and quality assurance.

Design needs to take into account the different amount of space each language will need to say the same thing. Problem areas include menus, dialogs and buttons. For example, on any given button, the text in French will be four times wider than in Chinese; this means that not only will the button have to be wider, but its container also needs to be able to accommodate the extra length.

There are roughly four main language groups:

• English: 100% width
• European: on average 130% wider than English
• Complex Scripts (Thai, Arabic, Hindi, etc.): generally about 80% of the width of English
  and can be right-to-left
• CJK (Chinese, Japanese and Korean): on average 50% of the width of English

If the design requires copy to fit tightly, then a separate layout for each language or language group is the best option. The alternative is a design with built-in flexibility to handle variations in content width. Designing for the longest language, and allowing for the layout to contract if necessary, tends to be the best plan of attack. Trying to build a design that works for all languages, unless it’s very simple, generally ends up with a poor visual result.

Messaging is easy to overlook, but there are a lot of places where error messages can be generated. There’s the front-end in form validation and the back-end in Ajax responses; all the possible error, confirmation and status messages need to be translated. In addition, Quality Assurance needs to test every combination in every language – and if several languages are involved, the amount of work can really add up.

Multilingual sites can be straightforward if they’ve been well planned, but it’s never a case of just dropping in replacement copy over the English text!

We’re a big fan of using the latest APIs and pushing browser-based technologies to their limits. A recent project required complex Google Maps implementation, so the new version 3 API was the obvious choice. It’s many times faster than the previous version, has location services, and works well on mobile devices (like the iPhone). The project’s mapping functionality proved to be a success; however, it wasn’t without a few technical challenges along the way.

One of the problems with adopting new API’s is that the eco-system of code that interacts and extends it is often very immature as well. Code examples can also be a little sparse, though fortunately Google’s documentation was excellent in this regard. The difficulty is when you need something that’s not included in the box. Our map has markers, a lot of markers, thousands of them in fact, and to stop the browser impaling itself on a spike we needed marker clustering.

Clustering is where you replace several individual markers with a single marker group icon that indicates to the user that there is X number of markers in this location. The more you zoom out, the greater the number of markers grouped into each cluster. The clustering solutions for Google Maps version 2 were numerous, but for version 3 there was just a handful. The most suitable library was barely 3 weeks old, certainly immature, but as a port of a stable release of the same library for the v2 API it was a viable option.

This is where the having a strong knowledge of the language and the browsers you are working with is really helpful. The library definitely had a few bugs, but having come from a time before JavaScript libraries it was easy to write override methods to patch these until library author corrected them. In between the initial implementation and project release the library authors did in fact patch those issues, so we were able to drop in the latest code and dispense with these patches.

Another problem we faced was that the styling provided by the library was limited. It expected the marker to be centered on the location, rather than above the location as the design needed. Method overrides and a good understanding of cross-browser rendering bugs allowed us to extend the library to meet our – and our client’s – needs.

I still wonder if too many new programmers now rely too heavily on JavaScript libraries, without understanding how things work behind the scenes. Every browser will always have its quirks and a professional front end developer should know how to deal with these. I’m not advocating against using JavaScript libraries, as they definitely get projects out faster and reduce costs. But if things don’t work correctly, or if they require slightly different functionality, I wonder whether many programmers would cope without their jQuery fix.

Search is one of those things that seems simple but is difficult to do well. The most common problem users tend to face when searching is that either no results are returned, or there are too many irrelevant results.

On a recent project we had the case of a simple keyword search bar that not only had to return relevant results but aggregate data returned from several sources. The user expects to type a search and get nicely-formatted results that match their query. Our problem was that the results came in multiple formats from multiple servers with quite variable response times.

The project in question was a Google Maps API and Google Local Search API powered Facebook Application. A search query could match one of several things: an address (Google Maps API Geocoder), a business or landmark name (Google Local Search API with the current view port of the map), a user’s name or personal details (either from the local database or via the Facebook API), or a game location (from the local database). The Google-related searches are done in JavaScript and the Facebook/local database ones were SQL queries in PHP.

Our initial implementation was to have tabs. The Addresses search was run, results were shown, and the other inactive tabs when clicked would carry out their respective searches. The problem was that there was no guarantee the first search type (addresses in this case) would return any results, and if the businesses search had returned results it would have been much better to display that first. The tabbed interface was also very disjointed, as swapping tabs had to perform the search (causing a delay), and users expect switching tabs to be instant. Also, the usability suffered, because if the search resulted in a few matches of each type, you couldn’t see them all on one screen.

The final implementation was in two parts. Firstly, all the searches were executed in parallel via Ajax, displaying and updating a progress bar as each was completed. This visual feedback helped offset the now-longer delay before any results were displayed. Then the data returned from each API was normalized so it could be fed to a single HTML render, facilitating output into the same screen. This allows the results to be displayed in a single list, grouped by type. Types with no results (or ones that timed out) are omitted from the output, pushing the relevant results to the top.

Website testing or quality assurance seems to all too often get overlooked.  At the very least basic cross browser testing should be done, and it’s surprising how often issues here can sneak through, and not always those you’d expect.  The most common case is the ‘web designer’ with little front-end knowledge creating a site that only works in Internet Explorer, though a similar case is developers who work in Firefox or Safari making sites that work fine in those browsers but have weird glitches in IE.  However, cross browser is just the start.

For sites with user accounts every page should be tested with logged in and logged out states, do parts of the UI change between the two? Does the layout look weird or broken with elements added or removed? Does an Internet Explorer rendering bug occur on interaction? Then let’s add Ajax into the mix. When you start to consider these cases, it’s easy to see why you need solid QA plan and that allowing 20% of the development budget isn’t unreasonable, especially on iterative designs.

So are you sure your site actually works in all cases?  If not it might be time to reassess your QA strategy.