Since this launch, I’ve noticed that Google is keen to hear my feedback on the new design.

Really keen.

At first I just hit the close button. The second, third and possibly fourth time I did the same. Possibly the fifth time it appeared, I actually gave them feedback, telling them not to worry — the new design was fine, but please stop pestering me with the pop up.

Yet it kept coming back. It’s like a zombie: it won’t die unless you shoot it in the head. But the problem is, I don’t know where the head is.

Last Sunday, I knew I was going to be on my computer most the day doing work. First thing that greeted me when I checked my email? Of course, the pop up. So between now and then I’ve been taking screenshots every time it’s appeared. Between now and then, I’ve restarted Chrome and my computer several times, logged in and out of Google, submitted more feedback begging for them to stop bugging me and even took the damn tour of their new Gmail in a vain effort to get this black box out of my inbox. And it’s the same situation on my work computer: at least a few times a day, my little black box friend will rear its ugly little head.

I’ve feedback to Google twice about this, and heck I’ve even tried tweeting Gmail. What can possibly stop this menace?

Now, this is where I’m interested to see whether this is just a personal overreaction to a tiny detail. I’m a bit obsessive about details. I have zero unread emails in my inbox, and it sends a cold shiver down my spine when I see people with even a few unread emails not attended too. Perhaps this pop up is annoying me because it’s interfering with my carefully groomed email environment?

Or maybe it’s more that when a user sees an ‘x’ icon on anything, it’s an expectation that once you have clicked on that ‘x’, whatever dialogue is attached will disappear, forever, unless the user takes action that justifies its return.

And I haven’t done anything to justify its return. Why are Google doing this? Is the code to keep it hidden broken, or is a strategy to painfully wring as much feedback out as possible?

And is this annoying anyone else as much as me?

Update, 17th November 2011: Well, seems I’m not the only one who’s been bugged by this: http://www.google.co.uk/search?gcx=w&sourceid=chrome&ie=UTF-8&q=google+new+look+feedback+popup

But, that said, I haven’t seen the pop up for a few days. Hooray!

I went to the Tate site today and a little UN-style gathering of flags caught my attention.

What really bothers me about what the Tate have done here is that they’ve obviously put some thought into this design decision, but the logic behind the decision is broken.

They’ve realised that using the Chinese flag for Chinese might be a bit politically sensitive (to say people form Taiwan or Singapore) and that there is no standard recognisable flag for Arabic — so while Arabic and Chinese are presented as the name of their languages, French, German, Spanish, Portuguese, Greek, Japanese and Italian users are given flags.

Swiss users in particular must love this scenario: they must choose the French, German or Italian flags (or stick with the English!).

Why not just list all the languages like you did with Chinese and Arabic?

I wonder if there’s some obsession with flags that overrides the logic behind such a decision. A few possible thoughts:

1. we love flags because they’re graphical and a strong visual metaphor
2. they take up less space on the screen, therefore are seen as advantageous
3. they’re seen as ‘instantly recognisable’ therefore being more usable
4. we don’t want to ‘confuse’ other users by showing scripts/languages they won’t understand

Any other thoughts as to what is behind this enduring phenomena?

The reasons that make flags such powerful and strong symbols are exactly why they’re so bad for representing languages: you are coercing users into identifying with another country in order to proceed to content in their native language.

While watching the video (on the TED website) I noticed the subtitle options. TED has a fantastic translation scheme where users can transcribe translations for videos — a staggering 18,265 translations so far. But user experience-wise, this scheme has some critical issues.

The default labeling for the subtitle feature is ‘Subtitles Available in: X languages [Off]‘. Your main call to action to help people who perhaps don’t speak English is… well, in English. There’s not even any sort of icon to suggest non-English content is available: unless you speak enough English to understand ‘subtitle’ or ‘languages’, then your really reliant on pure luck to spot this. And even then, there’s another trap: you must know the English name for your language. This same issue repeats itself on the actual translation page — users are presented with a list of language names ‘in your language’ — but the language names are all in English.

It’s quite probable that most users will be able to find their own language in a list of English names. But it’s not fun, and by no means a good user experience — consider finding a link entitled ‘Inglés’ on a website in Spanish.

A similar problem is present on the TED homepage. To access the huge translation program, you need to select the link ‘Translations’. Again, you need to know the English word.

Interestingly, if you search for TED on Google in another language, it’s pretty good at sending you to the relevant translation pages. And if you have an in-browser translation feature (such as Chrome), this also makes it much easier to find these translations in your language (except even if you do translate the whole page, the subtitle options in Flash won’t get translated).

The TED strap-line ‘Riveting talks by remarkable people, free to the world’ is brilliant, yet I think the world could really enjoy TED a lot more if they made a few simple changes:

1. Redesign the video player. Create an icon denoting other language support (and my attempt below is by no means a great icon!) and vitally list languages in their native name (just like on Wikipedia entry pages) — also apply this anywhere else on the site where languages are listed.

Sure, there’s still English in the subtitles area, but I think something like this would be a tremendous step in the right direction. And an extra killer feature would be defaulting subtitles (if available) to the user’s language.

2. Look at the user’s default browser language and give them a clear invitation to view translations in their language:

Of course it’s easy for someone to think up design ideas for someone else’s website: I know nothing about how the TED site works and whether any of this is even feasible, but I still felt it worth noting these ideas down, as it would be great to see the TED site provide a better experience for non-English speaking users.

The rationale for this post came after attending a talk at SXSW 2011 — ‘Flash is Dead, Long Live Flash!‘. The presenters, Elliot Chong and Toby Miller, gave a great overview of strengths and weaknesses of both Flash and HTML 5. However, one point of debate they missed was localisation. Not that I expected to hear it, but I feel strongly about such things considering this is a big part of my day job. During the Q&A session, I brought up the point of localisation — but explaining technical trivialities on the spur of the moment in front of a large crowd of peers can be tricky: hence this post.

Let’s start with the simple things. Now Flash actually provides fine support for most languages — even Chinese and Japanese are OK. Until you get into complex scripts — we’re talking Arabic, Fari, Hindi, Urdu and many more. Basically any alphabet that changes the ligatures between characters, depending on the characters present.

Caveat: I’m a designer first and developer second… if I’ve got something wrong here please let me know — anything new I can learn to make my life easier is always appreciated!

So, let’s look at what problems Flash will give us trying to put Arabic text on to the stage. Let’s use the Arabic word for kitten. This is how it appears correctly rendered in plain old HTML (right aligned since Arabic is read right-to-left — another point to touch on, but we’ll get to that later).

Now, let’s try and show the same text in Flash…

Example one: classic text field (SWF size: 4kb)

The simplest way to put text on the stage in Flash is with a simple text box. Just create it on the stage, copy your text, and you’re away. But no, not with complex scripts. For some reason Flash is incapable of rendering the ligatures between characters together correctly in classic text fields. And the web is full of depressing forum posts about people enduring frustrations at what appears to be such a trivial thing.

Example two: dynamic text field (SWF size: 4kb)

Again, this renders exactly the same as example one. Having dashed your hopes of static text displaying properly, surely you didn’t expect to be able to use dynamic text fields?

Example three: Text Layout Framework (TLF) text field (SWF size: 52KB)

Hoorah! OK, so some credit to Adobe here — so you can display complex scripts properly straight on the stage. But only if you use the new Text Layout Framework, which requires Flash CS5 and Flash Player 10+. And you can expect an additional 50kb on top of the SWF size! Prior to Flash CS5′s release in April 2010, this was all but impossible: the only way to display complex scripts in Flash properly was either as a vector exported from something like Illustrator (which, by the way, has supported complex scripts for a long long time) or as a bitmap from Photoshop (again, supports complex scripts).

Example four: programmatic text field (SWF size: 52KB)

Let’s try creating the text field with ActionScript:

var myFormat:TextFormat = new TextFormat();
myFormat.color = 0x233515;
myFormat.size = 76;
myFormat.font = "Arial";
myFormat.align = TextFormatAlign.RIGHT;

addChild(myTextField);


Well, at least Flash renders the text in the correct order, but it still doesn’t correctly render the ligatures.

Example five: programmatic Text Layout Framework text field (SWF size: 112KB)

Let’s try creating the text field with ActionScript using the Text Layout Framework:

import flash.display.Sprite;
import flashx.textLayout.compose.StandardFlowComposer;
import flashx.textLayout.container.ContainerController;
import flashx.textLayout.elements.TextFlow;
import flashx.textLayout.conversion.TextConverter;
import flashx.textLayout.edit.SelectionManager;

var textFlow:TextFlow = TextConverter.importToFlow(markup,
TextConverter.TEXT_LAYOUT_FORMAT);
textFlow.flowComposer.addController(new ContainerController(this, 200, 100));
textFlow.flowComposer.updateAllControllers();
textFlow.interactionManager = new SelectionManager();


Hoorah, Text Layout Framework comes through again. But look at the file size now: 112KB. That’s 28 times the size of creating a simple text field programmatically.

Of course Text Layout Framework gives you a huge amount of text control, so the larger file size is somewhat understandable — but that big? Just to render a simple word?

These are all very simple examples, but just imagine how much more complex most projects will get in Flash if localisation is required. The extra complexity (and increased file size) from using Text Layout Framework would surely discourage most developers from using it, particularly if there is no need for localisation at the beginning of the project. This introduces a potential nightmare scenario of rewriting entire applications to use Text Layout Framework.

Other gotchas with Flash and localisation

Font embedding

Embedding fonts in your project? Your standard Latin character set (which covers most European languages) is pretty light weight. Let’s look at kitten in other languages:

Example six: Latin font embedding (SWF size: 55KB)

Even adding in Latin I, Latin A and Latin B extended character sets for a font only adds about 56kb to your file (using Arial Unicode as your font). That’ll cover pretty much any Latin-based alphabet, from Icelandic through to Turkish. But now, let’s add Cyrillic and Greek.

Example seven: Latin, Cyrillic and Greek font embedding (SWF size: 85KB)

Now we’re looking at another 32kb on top — 85kb in total. Now that’s really not much… but let’s now look at Chinese and Japanese.

Example eight: Latin, Cyrillic, Greek, Simplified Chinese and Japanese font embedding (SWF size: 3.8mb)

For an embedded font that covers Latin, Cyrillic, Simplified Chinese and Japanese — you’re looking at a whopping 3.8mb.

So, if you’re planning on localising with dynamic Flash applications across many languages, you have two choices:

1. Don’t embed fonts, just use device fonts — you’ll lose your nice text on many PCs, but your file size will be manageable
2. Embed fonts but create different files for each language — again, file size manageable but then you’re re-creating a whole bunch of files, and maintenance can become quite a nightmare if you’re not careful

The right-to-left UI

Many right-to-left (RTL) languages are also complex scripts, so we’ve got a bit of a double-whammy here. Arabic, Farsi, Urdu… and even Hebrew (although at least that’s not a complex script!). Since RTL users read right to left, a good UI designer will re-align the interface in the same way: for instance, check out Google Israel or Google in Farsi, and notice how the entire screen is ‘flipped’ around. Even close buttons on dialogue boxes get flipped (such as this example from GNOME on Linux).

This means you should do the same for all UI inside your Flash application. While it’s a bit of a hassle at first, what I’ve found causes the most problems when doing this is Flash’s Cartesian coordinate system — X and Y works great for left-to-right, but not so for right-to-left.

Align an object to the top left? Easy:
mc_object.y=10;
mc_object.x=10;

But for RTL, we want it on the top right.
mc_object.y=10;
mc_object.x=(stage.stageWidth-10);

When you’re doing that for all your UI elements, it can turn into a real chore. Never mind if you run into stage.Width calculation bugs which do happen when viewing the SWF in various browsers.

What if we were developing a HTML/CSS/Javascript application instead?


#object{position:absolute;top:10px;}
.rtl #object{right:10px;}
.ltr #object{left:10px;}


Much, much easier! (Of course, there are plenty of browser bugs with CSS too, so it’s by no way perfect, but it is much better).

Flash UI Components

Using Flash’s inbuilt UI Components will cause you some problems too. You can move the scrollbar on a scrolling TLF text field to the right at least (you can do this programmatically, too):

Example nine: right-to-left scrollbar (SWF size: 119kb)

But it appears many other components (such as the combobox) have no TLF support or the ability to make them more RTL friendly (all the text below is rendered incorrectly in Arabic):

Example ten: other Flash UI components (SWF size: 49kb)

Conclusion

For anyone looking at creating Rich Internet Applications that will work across different locales, given the growing market acceptance of CSS3, HTML5 and already accepted tools such as jQuery, Flash is looking like a really hard task for such work.

But disregarding all those points, let’s go back to the main thrust of this post: why is Flash so lousy at localisation? There are an estimated 65 million Arabic users online, and if you want to use Flash to provide content for these users, you’re in for a ludicrous development experience. For me, it’s really not good enough. Years ago Flash was targeted as being highly inaccessible, and even though it has made good progress, it’s highly inaccessible in another way: that of localisation.

Download example Flash files from this post (1mb).

Manually entering dates is also frustrating as some part of the Javascript intermittently clears the field when changing focus between the fields. Initially I honestly couldn’t get a date in. I’ve since tried again and it worked (barely). Just as well there’s a fairly obvious Reservations link in the top bar.

By the way, anyone know of any good hotels in Calgary?

…well-equipped to welcome visitors with disabilities. Our facilities include: lifts, wheelchair access, adapted toilets, and audio guides for selected exhibitions.

The irony of all this is that in the HTML version of the site (as opposed to the Flash) this text is rendered in a GIF with no alt text (and not considering the fact the site launches several pop-up windows). So unlucky if you’re visually impaired.

Or does this raise the question of whether you could truly appreciate a Design Museum if you were visually impaired? Or an art gallery? Or museums in general?

Regardless I do love the irony of disability services information appearing in probably the most inaccessible way possible.