Usability of mixing LTR and RTL text?


Annoyingly, FourSquare has started be be a source of spam for me. I get friend request from people who only like certain brands of stores, from recruitment consultants trying to work out who I'm visiting, and from cultists who are desperate for me to visit Scientology centres.

I also get friend requests from people I've never met, including from Ahmed al-Najjar (احمد النجار). I've never met Ahmed and I've no wish to taint him as a spammer - I'm sure he's just misclicked in his friend request - but because Arabic is written right-to-left (RTL) it shows up some interesting design and usability imitations of FourSquare.

On the Android app, there's a curious problem.
LTR RTL

In layman's terms, I'm expecting to see "[name] [action]". What the computer is seeing as its instruction is "Place [name] at the start - then place [action]" - in this case, the [name] is placed and, because it is RTL, the [action] is placed after it - which means on space to the left.

Incidentally, their website doesn't suffer from this problem:
FourSquare RTL Web

In an average design environment, we may only encounter one text layout. In the west, that's usually Left To Right (LTR). If we're feeling exotic, we might internationalise all our assets and strings so that they support a fully RTL experience. (Of course, internationalisation and localisation is slightly more complex than that.)

So, the experience becomes:
"أحمد النجار يريد أن يكون صديقك."

That's fine, but what happens when we want to mix the scripts? Should we say
"أحمد النجار wants to be your friend."

Somehow that feels wrong. It's the lexical equivalent of writing "nedE ecnereT wants to be your friend". Yuck!

Do we accept that - whether one can or cannot read the script - a block of foreign text is read as a separate unit?

Bidirectional text support is present in most computers. Even if it does lead to some complex problems.

Combining the text into one layout is a solved problem - but it doesn't address the usability of mixing and matching. What is it that the user expects to happen? I think we can agree that their must be consistency between all UIs - in this case Web and Mobile.

As I see it, there are five approaches

  1. Keep original UI ordering - place the name where the user expects it to be.
  2. Take the ordering from the first element of the sentence.
  3. Whenever the text direction changes, start a new line.
  4. Translate the foreign text into the user's native language.
  5. Rotate or reverse the foreign text.

The common consensus is the first option. Take the overall direction of the text and place the reversed text in place.

However, of the above items, I think that starting a new line is the most satisfactory.

أحمد
wants to be your friend.

But, of course, that leads to

أحمد
is now friends with
تيرينس

Both of which could lead to vertical layout problems, as well as introducing alignment confusion.

أحمد

is now friends with

تيرينس

Gah!

But then, adjacency also provides problems. The W3C maintain some excellent guidelines for mixing bidirectional text. In this adjacency example, can you quickly determine which item should be checked to select "English"?

لغتي: العربية English‏ Français فارسی اردو

( Incidentally, number 5 isn't as strange as it sounds. In languages which are written Top-To-Bottom sometimes foreign characters are inserted in place but rotated!)
Hebei Wen'an jin fasheng dizhen - Beijing you zhengan

A Conclusion - of sorts

I think it's obvious that in this example, the FourSquare mobile app is wrong from my point of view. As the user, I expect the starting element to be at the left. From Ahmed's point-of-view, he as a user expects the starting element to be on the right.

Yet, for both of us, it's an unsatisfactory and inconsistent experience.

Bidirectional support in Unicode solves the layout problem. Yet I'm not sure if it solves the semantic problem. Indeed, I wonder if that can be solved at all.


Share this post on…

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre> <p> <br> <img src="" alt="" title="" srcset="">