John Lindal’s Blog

Localizing User Interface Layout

November 22, 2008 on 6:16 pm | In Deep Thoughts, Programming | No Comments

Layout and Localization (l10n) have been on my mind a lot recently because these are two pieces of my company’s Big Bet on which I have been working and because the intersection of the two is an issue that I never resolved in the JX Application Framework. While taking a walk yesterday evening, I think I finally found the right answer. But first, some background…

I started real GUI programming with Think C and its class library on Mac OS 6. (My earlier games written in FORTRAN, while graphical, don’t really count ) This provided the same simple layout resizing functionality that I built into JX: fixed left, fixed right, or elastic (and the same for vertical). Back then, localization wasn’t a big deal, but since everybody was encouraged to put strings into the resource fork, it was theoretically simple, though painful in practice, to localize an application: simply replace the contents of the resource fork. I didn’t think deeply about it at the time, since I never actually localized any of my programs, but one would have to replace both the string bundles and the layouts, because the layouts contained all the labels, and the arrangement of items would have to change to accommodate changes in label length after translation.

Later, while I was transitioning to Linux and the X Window System, I heard about Galaxy. They had developed a springs-and-struts layout manager which, while I went starry eyed at its sophistication, I never really understood. It supposedly made the layout so flexible that it could automatically handle changes to label lengths due to translation. Truly an impressive feat, though now that I have analyzed the problem, it seems that it would have been quite confusing to use because of the complexity of the underlying behavior. Certainly, Java’s SpringLayout class is very complex, and I think it had the same goal.

Nowadays, I work within the web browser. This has also chosen to go down the path of algorithmic layout. The order in which the elements are listed in the HTML source provides the foundation, and CSS rules are used to control the layout algorithm: floating, absolute positioning, etc. To say that this is a mess is an understatement. Heroics are routinely required to achieve what would be quite simple in a desktop application.

This led me to the realization last night that algorithmic layout really is the wrong way to go. It may start out simple enough, and it may sound great that one layout will work for everything, but if it needs to be the foundation on which applications are built, it will eventually become unwieldy, and designers will curse its limitations.

So, back to the basics:

A designer’s drawing should be easy to translate into program data.

Start with fixed positioning.

The layout needs to expand and shrink gracefully.

Allow fixed or elastic behavior for each individual element.

The layout needs to be localized.

Create a separate layout for each locale. Help the engineers stay sane by ensuring that additions and removals affect all locales.

The layout needs to acommodate changes in font size.

The solution to this seems to beg for algorithmic layout, but I don’t think it’s necessary. OS X Finder only lets you change the font size of the file names (which is easy), not the rest of the text. Web browsers only let you change the size of the text in the page. If you want to change everything, scale all coordinates by the size of 1 em. It won’t look perfect, but for those who really need a bigger font, it will be infinitely better than squinting.

A bit of web searching revealed that Apple’s latest Interface Builder for OS X does just this. Their expand/shrink mechanism is more general than in JX, since it decouples the behavior of the left and right edges (same for top and bottom), thereby allowing proportional sizing, but it is still simple! A separate layout is created and maintained for each locale.

Coupled with the fact that fdesign only works on Linux, I’m clearly going to have to finally write Mondrian to give JX a real layout editor!