Say we have an overlay DHTML panel on a web page that contains two buttons in the top occupying whole width of the dialog, like this:
Text for Button 1 and Button 2 should be localized. Content of checkbox group is static and should not be localized.
There can be a big difference between button text width in different languages (~100% extra space in comparison with English version).
The question is which strategy to apply for sizing Button 1 and Button 2 depending on the length of the text content:
Make buttons fixed width and truncate text content with ellipsis.
Make buttons fixed width and wrap text content on the subsequent lines making buttons grow in height.
Make buttons fixed width but make them wide enough to host text in all languages without truncation or wrapping.
Make buttons dynamically adjust width and make panel grow horizontally with their size.
I am leaning towards using third or forth option according to the several UI localization best practices that were found:
Preparing the User Interface for Localization
Best Practices for Globalization and Localization
Globalization Step-by-Step - UI Considerations
Still we have some debate in the team discussing the best option and it would be interesting to hear concious outer voice of the community.
I am interested in the best approach for this specific case as well general guidelines for solving web UI sizing issues in regards of localization.
Thanks!
As you perhaps know, text shortened with ellipsis (or with a single dot) could be incomprehensible:
How compr. is th.?
You should seen a lot of this staff in mobile area (phones, tablets, etc.), such translations look ugly. OK, with lower screen resolutions you actually end up with no choice (unless you can create some auto-scrolling text). But in case of web interface you certainly have a choice.
Typically, there are two kind of solutions corresponding to your points #3 and #4. Personally, I am leaning to #4 - make buttons auto-sizable. This of course will result with inconsistently sized buttons, but there is little we can do about it.
If you cannot use solution #4 (i.e. UI Designer is strong opponent of this technique), you may modify solution #3 a bit. Basically, what I used in past projects was, I had buttons of fixed sizes and default size was capable to fit most of languages (except Polish and Russian of course), but I also had several CSS classes that defined wider buttons. When localizing into "too long" languages I simply used the most wide button class I could. If the text still didn't fit, then I asked the translators for shortening it (usually re-phrasing it and shorten the text with a single dot as a last resort).
However, please keep in mind that it increases localization costs. This is the reason I would not recommend this method.
As for solution #2, you will end up with ugly looking UI. You simply have no control over how browser will wrap a text, and you will have a lot of texts that go outside the button clipping rectangle (overlap it).
As for solution #1, using ellipsis is a bad idea for two reasons. First one is, ellipsis is not valid in many languages (this especially regards to Asian languages). The second one is, as I understand you want to do that automatically. In this case, you won't be able to measure strings - their actual, on screen size, written with a fall-back font. In case of web UI, you don't know whether user has particular font installed, so you will be guessing the size (OK, with Dojo you can theoretically measure it on the client side). This will of course result in overlapping text (if you decide on dynamic shortening over your chosen font) or totally incomprehensible text (if you decide on shortening after say 8 characters). I had a project which started to use static shortening, it was a total mess. Then we switch to dynamic and it is still not good enough.
To counter potential UI Designer argument that goes "we have no space for string expansion", I can only say that means that you designed the interface incorrectly for it is too crowded. This is the point where I18n goes hand in hand with UI design best practices: strive for simplicity (in UI design). The result would be easy to use and easy to localize application.
Related
I wanted to know from someone with field experience, what the best practice of implementing a programm, with UI or CMD in multiple languages (letting the user choose e.g. between English, French, German) is.
If there already exists a discussion about this topic I would be grateful, if somebody could send me a link to it, the first few Google searches I only found things like how to choose a programming language
The first options that came to my mind where switch(globalStringLanguage) and #ifdef GERMAN #define PROGRESS Fortschritt... .
Would really like to know, if there is a best practice out there(and which one that would be) and how you guys implement it in your firm.
Thanks in advance for the replies,
1973ProgrammingDude
There are 4 'best practices / topics' that you can research:-
i18n - internationalisation
This is more about the way you design software. You design buttons etc. to 'lookup' the text they should contain from a dictionary file rather than hard coding them into your source code.
It also applies to things like dates and currency and allow them to be formatted differently depending on the language / locale.
If you design your product correctly you should be able to change all the text on buttons, links etc. and change the date format, currency formatting etc. with one language variable being changed.
Think of this part as designing your system to account for translation, local formatting and even right to left layouts for languages such as Arabic that are read from the right to the left
l10n - localisation
This is the process that follows on from designing your system under i18n. You would define formatting options so dates etc. are correct.
You would also define wording of buttons etc. so they are correct.
Finally you would also have a system so that content could be translated for the given locale.
Think of this part as the actual translation process.
l12y - Localisability
pretty much covers the process and considerations of l10n - just mentioned so you can research it for more complex scenarios and implementation ideas.
g11n - Globalisation
Encompasses all of the above standards, yet again just mentioned for reference as it occasionally throws up some different articles on Google when searching on how to solve a particular problem.
Quick sanity checks
When designing a system that supports glln it easier to have a couple of points to help make you think about decisions you are making.
If you enter ANY plain text within HTML tags / controls / whatever is applicable to your chosen programming language then you will likely have made a mistake. Every item of plain text should be programmatically inserted into a page.
Design a dictionary system - for every piece of plain text you want to add to the site add it to a dictionary. The dictionary can be a simple key:value list if you need with the key being the English translation and the Value being the translation for your locale. Make sure that you start with English:English translations so you can make sure you don't miss any. I would recommend JSON arrays as most translation companies will now understand how to use these nowadays without you needing to design a user interface for them.
When designing a widget / component consider implications of longer text - just because a layout works in English (i.e. a button group fits on one line) doesn't mean it will work in another. Some languages may be 3 times longer for the translation of a word so you must consider this when designing a layout.
Everything should be designed so it can easily be reversed. Right To Left versions of everything should be easy to implement so design your system so only a couple of variables need changing to create the RTL version. (i.e. if web based have a main CSS definition of a widget and then make sure a global CSS class applied to the body can switch the layout).
It isn't just text -> imagery needs to be different as different cultures will interpret an image differently. Also iconography should be internationalised as well as a dollar bill icon doesn't work well to represent money in the UK, never mind in other countries.
CSS Example but the principle applies to all languages / platforms
.widget{
//define general styles
}
.left-to-right .widget{
//add some formatting to adjust layout for left-to-right languages such as English when the 'left-to-right' global variable is set.
margin-left: 20px;
}
.right-to-left .widget{
//add some formatting to adjust layout for right-to-left languages such as Arabic when the 'right-to-left' global variable is set.
margin-right: 0px;
}
This is a topic that may be considered something not necessarily "programming related"; however, I feel it is since I'm asking for specific techniques.
Essentially, as a web developer, I work with a variety of platforms that include a WYSIWYG editor in the backend (TinyMCE, WYGWAM, etc) and one of the selling points of such systems is that it becomes easier to manage your own content because of these tools.
In theory, sounds great, in practice, not so much.
It can be way too easy for a client to break a layout by using many of the advanced features of a WYSIWYG editor. They can start floating things, setting too much margin/padding, etc.
Generally, I have tried to build any of these types of pages with only some sensible default styles applied to a few of the most common tags, such as setting a font size, colors, some margins, and some text decorations.
I would like to know if anyone has used anything more advanced to essentially turn the output of:
$cms->getContent();
...or equivalent into something that is effectively sandboxed and operates entirely agnostic of any other style/layout elements being used.
As often as possible, I express to clients that they should purchase an HTML/CSS book for Dummies and read it so that they aren't deer in headlights when they click "code view" in a WYSIWYG. But I know they don't do this, nor do they hire anyone who has experience, and it ends up allowing a client more control than they should responsibly have.
Plus, it sucks when you are using their sites as work samples to show others knowing they have the ability to take your beautiful design and development and make it look like crap.
A few things:
I have a standard WYGWAM config that I reuse on new sites by importing the exp_wygwam_configs table.
I keep options very limited in the editors
Areas of the page delineated for images should use a File field, with an image resizer like CE Image used to insure proper size
Client training. Make videos with Camtasia or similar tool if you have to.
Use a custom stylesheet for WYGWAM that has a small subset of styles, so they can choose h2...h4, for example, but not h1 or h5.
After encountering a lot of issues with WYSIWYG editors (which, by the way, never reflect accurately what you "get" in the end), I now prefer to leave only the most basic formatting features in the editor's configuration. For example, take a look at stackoverflow's editor.
It's got the following features: bold, italic, link, quote, pictures, lists, and alignments. The only special feature here are code sample and html, which are targeted to this site's audience. Most of your client don't need them.
I think it's the best approach, because if you give your clients the feeling that they can do whatever they want in the page, but in the end, this content is filtered when the page is rendered, they are going to be really frustrated. Not to mention the fact that the site will be slowed by the filtering process and the need to put the filtered content in cache.
Sometimes the client indeed wants to have a special layout in a page, but I think that can be best done by customizing the CMS so that it fits the client need.
Ours is an open-source Mac application localized by volunteers. These volunteers will do their work on special localization builds of the software (with unstripped nibs), then send us the changes to integrate into the original xib and strings files.
The problem is that, while there is a way to integrate string changes without blowing away previous size changes, I can't see a way to integrate new string and size changes (as when we add or replace views).
The only way to do both that I can see is for localizers to work directly with the original xibs and send us diffs. That means they have to download the entire source code, not just a localizable version of the release, work in Xcode as well as IB, and either run the diff command themselves (per xib) or install and use Mercurial.
Is there any better way for a xib-based application?
UPDATE January 2014: Apple’s ‘autolayout’ code combined with their ‘Base’ localization stuff took most my ideas and improved on them. I recommend against using my old tools that I talk about in this answer. But, also, man was I right!
I strongly strongly STRONGLY recommend against frame changes in localizations. I know this runs counter to Apple's advice, but there are SO MANY problems with allowing frame changes - you end up with a billion edge cases.
Imagine you have 10 XIBs in your app, and you support 12 languages. You've got 120 different layouts to support, now. You just can't do this.
Change the strings, leave the views where they are. Make 'em bigger in ALL languages, if you need to. It sounds like this shouldn't work but it does. (I won three Apple Design Awards with an app that's localized in 10 or so languages this way.)
Specifics:
For radio and checkboxes, just let them extend far to the right, beyond the last English character. That also provides a nice big landing area for imprecise mousers.
For buttons, they should be wide anyhow, because it never looks good to have text cramped in the middle of the buttons.
For titles on tableview columns, you should autosize when you load 'em up, if needed.
For explanatory text, you should have some extra space to the right, and maybe an extra line. It just makes the English version of the XIB seem less cluttered. Sure, the Germans are going to see a slightly tighter XIB, but, hey, they're Germans -- they're probably used to that. There's probably even a German word for it. "Deutscheninterfakkenclutterlongen."
If a text field is centered, just add equal space on both sides. There's no reason not to.
I've combined this with scripts that suck all the strings out of my XIBs and put them in .strings files, and then dynamically put the strings back at run-time, so anyone can localize my app without any special tools. Just drop in a bunch of .strings files and run it!
Blog post including full source: [Lost in Translations]¹.
I confess that I'm not all that familiar with the process of localizing Mac apps. But I did run across a script that's part of the Three20 iPhone library that seems like it might be useful: diffstrings.py is a Python script that "compares your primary locale with all your other locales to help you determine which new strings need to be translated. It outputs XML files which can be translated, and then merged back into your strings files."
EDIT: As a companion to Wil Shipley's answer to this question, I'll add a link to a blog post he just wrote that goes into more detail about localization, and provides some of the tools that he's built to ease the process.
Where I used to work, we had this issue as well. Our app was getting translated into 10 different languages.
At first, we tried doing what Wil suggested, which is to make everything super wide and fit in every language. Unfortunately, "online backup" might be pretty short in English, but in other languages (especially Spanish), it's really long ("copia de seguridad" just means "backup"). Widening our UI made everything look pretty terrible.
One day, I was playing around with some Core Animation stuff and discovered the CAConstraint class. CAConstraint is basically a way to define a layout relationship between two CALayers. You give one layer a name (like "layerA") and then say "layerB is constrained [in such-and-such a way] to a sibling layer called layerA". Then, whenever the layer named layerA is repositioned or resized, layerB automatically moves as well. It's really neat, and it's just what we were looking for.
After a couple of days of work, I came up with what is now CHLayoutManager. It's basically a re-make of CAConstraint and friends, but for NSViews. Here's a simple example of how it works:
CHLayoutConstraint * centerHorizontal = [CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMidX relativeTo:#"superview" attribute:CHLayoutConstraintAttributeMidX];
CHLayoutConstraint * centerVertical = [CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMidY relativeTo:#"superview" attribute:CHLayoutConstraintAttributeMidY];
[aView addConstraint:centerHorizontal];
[aView addConstraint:centerVertical];
This will keep aView centered in its superview, regardless of how the superview is resized. Here's another:
[button1 setLayoutName:#"button1"];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMinX relativeTo:#"button1" attribute:CHLayoutConstraintAttributeMaxX]];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMaxY relativeTo:#"button1" attribute:CHLayoutConstraintAttributeMaxY]];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeWidth relativeTo:#"button1" attribute:CHLayoutConstraintAttributeWidth]];
This will keep button2 anchored to the right edge of button1, as well as keeping button2's Y position and width the same as button1's.
Internally, CHLayoutManager uses an NSValueTransformer to calculate the new positioning information. Some of the CHLayoutConstraint initializers accept an NSValueTransformer, so you can create arbitrarily complex layout manipulations.
We used this for constraining and laying out the entire UI, and then doing all of the localization in code (and subsequently calling -sizeToFit, with some modifications). Our UI would just flow into its final layout. It turned out to be extremely convenient. We'd just package up our .strings files, send them off to the translators, and then drop them in to place when we got them back, and our app would instantly be localized for that language.
CHLayoutManager isn't perfect. It doesn't resolve conflicts, but simply applies constraints in the order they're added. So you can constrain (for example) the MinX of a view 42 different ways, but only the last one will be used. Also, if you constrain the MinX and the MaxX, they'll also be applied in the order they're added and will not end up stretching or shrinking the width. In other words, constraining one attribute of a view will not affect the other attributes. It's compatible with 10.5+ (GC and non). However, due to some changes in Lion, it's unlikely that I'll address the shortcomings.
Despite these shortcomings, it's an extremely flexible framework, and (IMO) some pretty nifty code. (Plus, I swizzle -[NSView dealloc]! Yay!)
Update
Now that AppKit has this same functionality (via NSLayoutConstraint), I recommend using that system instead of CHLayoutManager. It is far more robust.
Bear in mind that XIB files are merely XML files in an obscure format, so you can translate those easily enough, provided that you can find what strings there are there to translate in the first place. For example, here's the snippet that creates a button called Jenson:
<object class="NSButtonCell" key="NSCell" id="41219959">
<int key="NSCellFlags">67239424</int>
<int key="NSCellFlags2">134217728</int>
<string key="NSContents">Jenson</string>
...
</object>
So you can get that string translated and then substitute occurrences of it in the XIB with your translated value. In order to verify it's working as expected, you could change the language to use random keys instead (like BUTTON_TITLE) which will make it easier to spot when one's missing.
However, the positions/sizes of the items are fixed, so you can have titles that overflow the space given in a different language. That's one of the reasons why Macs have separate XIB files for every language, to allow adjustments to be made on a language-by-language basis, however difficult it is to maintain.
Before you throw me out into the cold with your bold assertions that this is not programming related, please hear me out.
I'm looking for a visual metaphor (Icon) to suggest the idea of inversion of a filter. So if a user has a filter which reduces a list of 10 items to 4, I want a button that will allow the user to invert the filter to display only the other 6.
Another wrinkle is that the UI will also have a button for removing the filter nearby.
While this certainly isn't a nuts-and-bolts programming question, I think it's relevant to the process of software creation. As a developer it's relatively easy to construct the mechanisms to perform complex filters, but it's all for naught if normal users find the presentation confusing.
If an icon doesn't jump to mind for you, then there probably isn't one that will have obvious meaning to your users either. You're better off using a text label for this.
If it must be an icon, then it doesn't matter much what it is, since users won't be able to guess it any way, but at least try to make it visually distinct and memorable if not particularly intuitive. MS Access uses a funnel to represent "filtering." Maybe use an upside-down or white-on-black funnel for inversion? (An X'ed-out funnel means "don't filter").
Whatever. Like I said, it doesn't matter much.
Maybe it's not the most appropriate, but what about the logical inverter icon?
Maybe something like this: Invert Selection?
If you really need an image, I'd suggest looking at image editing programs like GIMP or Photoshop and seeing how their "invert selection" buttons look.
16x16 pixels is enough to draw two small list boxes with an arced arrow going from one to the other where the second has an inverted selection list of the first.
alt text http://img524.imageshack.us/img524/6782/4092009000139am.png
I think the 3 icons above could be used in one spot with each user click causing a rotation through the 3 of them. I think the above icon set offers the following benefits:
F - clearly communicates it is for a filter control.
Red and Green - clearly communicate ON and OFF action.
The line above F means inversion (I think - based on memories of boolean algebra at university - I could be wrong?)
The use of yellow while still maintaining the F, links the new action (filter inverted) to the previous filter actions let still communicates it is different to the filter simply being turned on or off.
On icon click rotation could be, (starting) Red - Green - Yellow - Red. This is a widely understood rotation pattern that the user would quickly pick-up. Therefore no need for additional filter on/off button.
Simpler solution - a user only needs to look at a single icon (even perhaps only with peripheral vision) to deduce the current state of the control.
Although I'm specifically interested in web application information, I would also be somewhat curious about desktop application development as well. This question is driven by my work on my personal website as well as my job, where I have developed a few features, but left it to others to integrate into the look and feel of the site.
Are there any guides or rules of thumb for things like color schemes, layouts, formatting, etc? I want to ensure readability and clarity for visitors, but not be bland and dull at the same time.
As for my knowledge in this area - If you hand me a picture, I have enough knowledge to reproduce it on the screen, but if you ask me to design a new interface or redesign an existing one, I wouldn't know where to begin.
Usually, each operating System has user Interface Guidelines. For Windows, have a look here. (Edit: The links in that post are broken. But a Search for "User Interface Guidelines" on MSDN has articles about everything)
Apple has it's own as well. Also, you may want to keep accessibility in mind.
One tip to check if your colors have good contrast is taking a snapshot of it and converting to grayscale. If you can't read something, colors were surely bad choosen.
Plus, although it's not about user interfaces, Before & After Magazine can give you some pretty good hints about color, design and related topics. It even has got some free pdf's to download.
The book Designing Interfaces, by Jenifer Tidwell has a entire chapter on the subject (Chapter 9, excerpts accesible online).
The entire book is worth recommending.
For web UI, I'm going to go out on a limb here and say that the most important color in web design is white, or "light". This is the color on top of which you place dense tracts of content.
Dark text, light background, always, when it comes to your primary content areas.
And the most important rule in layouting is whitespace. Let the content breathe.
Following these two simple rules is worth more than most "user interface usability" guidelines.
And by the way, the MS user interface guidelines are (by and large) horrible. Read Jakob Nielsen, look at Apple design aesthetics, but stay away from the MS "neutral gray/blue crunchbox" 12-step Wizard 10pt text philosophy of UI.
(And I say that as a long-time MS GUI programmer)
I'm horrible at finding colors that look good together, so I cheat and use pictures from nature that are mostly the color I want (say, green) and then I use this website to pull out the main color scheme. Generally nature does a pretty good job of setting its own nice color schemes.
Use high contrast color combos; Black text on white background is the best example of a high contrast combo.
A bad combo is green text on red background. It's horrible for color blind people (like myself).
See what your site looks like to a color blind person: colorfilter.wickline.org
As for desktop applications: Whatever you do, do not use hand-picked colors. Stick with the named system colors such as "Window Background", "Menu Text", etc. Otherwise, people relying on OS accessibility features will be locked with your color choices (unable to choose a high-contrast theme, for instance) and to people who like to customize their desktop themes will think your application is fugly.
Here are some simple pointers for usability in your typography. These things mainly address readability and accessibility concerns.
DOs:
Use relative font sizing (em)
Identify language changes within a document using the LANG attribute
Black text on a white background
For headings, use H1, H2, etc. and nest them appropriately
Chunk up content and organize with headings that fit what your users are looking for
Write clear and simple copy
Align left, ragged right
Text-to-background color must be high contrast
DONTs:
Use "click here" or "more" as link text
Use underline for emphasis
More than 2 font-type families
Italics
Blocks of text using all caps
Use true red or true blue text on white background (chromatic aberration)