6. Adjusting the UI
Appearances are often deceiving.
Aesop
Display and appearance for your app can change drastically when your customer changes the system language. The most common change is the length of strings for words, causing truncation or overlapping of controllers and other unsightliness. Even more drastic a change is when your customer changes from a left-to-right (LTR) language (English, French, Polish, Russian, Spanish, etc.) to a right-to-left (RTL) language (Arabic, Hebrew). With a right-to-left language, your customer will expect your UI elements to shift position in your view controller. If you have not enabled UI elements to support RTL languages, your customers’ experience will be subpar. This chapter covers those potential changes in the UI and shows you how to prepare for them so that they are nonissues for your customer. We’ll talk about testing for these aspects ahead of time, being assisted by constraints to handle these UI changes, and other UI elements. We’ll continue working with our sample app, as well as adding a new view controller to demonstrate support for right-to-left languages.
Auto Layout and Constraints
Let’s start with a quick summary and hopefully review for you all about Auto Layout and constraints. Auto Layout is a system that defines relationships between UI elements. These relationships include distances between sibling views and distances between views and their super views. And as with any relationships, these distances can be close, far away, or flexible. These distances are tracked and controlled by the fundamental building block known as a constraint. Constraints can be static values, measured in points, or can be set with standard equality statement, such as less than or equal, or greater than. All constraints are based on the same formula, which includes an equality function, a constant value, and a multiplier. By adjusting variables of this formula, you get absolute, relative, or a combination of constraints.
One of the default entries for a constraint size is “Standard value.” This is 8 points between neighboring views and 20 points between a view and its super view. We’ll use Standard value quite frequently in our examples.
Auto Layout is enabled by default, on the File Inspector tab in the Interface Builder Document section.
Internationalization Implications
By working with Auto Layout, you allow the system to handle laying out the UI elements. Essentially, this layout includes the constraint setting plus the size of the view in reference to the available area in the super view. Auto Layout has a concept of “intrinsic size” for views, which is the minimum amount of space needed to hold and display the view’s contents. When working with labels, for example, this is essentially the amount of space needed to properly display all the characters. As we work with localized strings—which will vary in length, both longer and shorter—this combination of constraint settings and intrinsic size will automatically adjust to give us the best display for our strings by automatically adjusting the frame size.
Avoiding Clipping
In the preceding chapter, we noticed some localized labels being truncated or “clipped” when we were dealing with longer strings than the English strings we set up for. This was happening with several view controllers, but let’s focus on the Quotes and Scripts view controller. Open the Quotes and Scripts view controller and take a look at the top label containing the text “Quotations et ....” This string is clipped due to no constraints being set for this view controller. Because of that, the label width is based on the length of the English string (Quotes & Scripts) contained in the QuotesAndScriptViewController.strings (English) file. We need this label to not clip with any language and, in our case, display the entire French string “Quotations et Scripts,” which contains 21 characters.
To adjust the label to prevent text clipping, follow these steps:
1. Select the XIB in the Project Explorer and then select the label.
2. Click the Pin button (see Figure 6.1).
3. Set a top constraint to the displayed value, 68. Note this is a hard-coded value but is strictly arbitrary. I’ve listed it here to be consistent with the project on my GitHub account.
4. Click the Align button.
5. Enable the Horizontal Center in Container option.
Figure 6.2 shows the results.
Now let’s take care of the Script and Variant labels to avoid clipping or truncating. As mentioned earlier, I am hard-coding constraint values here. I have a two-fold reason for this: One is to match the layout of my GitHub project, and the other is to have a “wrong” case to demonstrate what we can correct.
1. Select the Variant label and then click the Pin button.
2. Set the Leading constraint to the Standard value.
3. Set the Trailing constraint to the Standard value.
4. Set the lower Y constraint to the displayed value (“212” in my case).
5. Click the Add 3 Constraints button.
6. Select the variantCode label, and then click the Pin button.
7. Set the Trailing constraint to the displayed value (“141” in my case).
8. Set the lower Y constraint to the displayed value (“212” my case).
9. Click the Add 2 Constraints button.
10. Fire up the app, tap the plus sign, and then tap Quotes and Scripts.
This is not bad (see Figure 6.3), but there’s too much clipping on the variantCode label.
Let’s fix the clipping on the variantCode label. To do so, follow these steps:
1. Select the Trailing constraint on the variantCode label (see Figure 6.4).
2. Click the Attributes Inspector button.
We’d like this label to expand depending on the string level but have at least a Standard constraint against the right side of its super view. Even if we get some clipping from these constraints, that’s a design decision we’ll need to make.
3. Set the Constant to Use Standard Value.
4. Set the Relation to Greater Than or Equal. This will give us flexibility with our label width, or more precisely, the intrinsic width of the contents of the label.
5. Fire up the app, tap the plus sign, and then tap Quotes and Scripts.
Looks good (see Figure 6.5)!
Now let’s hit the Script and scriptCode labels, adjusting them by following these steps:
1. Select the Script label and then click the Pin button.
2. Set the Leading constraint to the Standard value.
3. Set the Trailing constraint to the Standard value.
4. Set the lower Y constraint to the Standard value. Make it relative to its nearest neighbor, the Variant label.
5. Click the Add 3 Constraints button.
6. Select the scriptCode label and then click the Pin button.
7. Set the Trailing constraint to the displayed value (“156” in my case).
8. Set the lower Y constraint to the Standard.
9. Click the Add 2 Constraints button.
At this point, let’s make the Trailing constraint conditional as we did with the variantCode label:
1. Select the Trailing constraint on the scriptCode label.
2. Click the Attributes Inspector button.
We’d like this label to expand but have at least a Standard constraint against the right side of its super view. Even if we get some clipping from these constraints, that’s a design decision we’ll need to make.
3. Set the Constant to Use Standard Value.
4. Set the Relation to Greater Than or Equal. This gives us flexibility with our label width, or more precisely, the intrinsic width of the contents of the label.
5. Fire up the app, tap the plus sign, and then tap Quotes and Scripts. The results of our changes to the trailing constraint are shown in Figure 6.6.
As it is right now, our implementation of constraints has the results "scripts" label being displayed as truncated. Displaying the result in this manner may point to not a change in code or constraints, but potentially a design change. And having an actual result for your team to see can aid in support for this decision or support in putting resources into a different type of change, changing the font size, having different messaging, or replacing the text with an icon. Nicely done! We’ve got our view controller more appropriately handling and displaying strings. In our next section, we’ll create a new view controller to demonstrate what happens when we plan everything from the start layout, strings, and constraints.
Right-to-Left Languages
We’re going to add a new view controller to our I18nExerciser project. This view controller will be focused on right-to-left languages, but we don’t need to design it exclusively for right-to-left support. Thanks to Auto Layout, the majority of the support comes automatically. If we are smart setting up our constraints, we have to do it only once and we get this support:
Support for right-to-left languages
Correct string layout for localized text
Correct layout for rotating the device
Our example will demonstrate all three.
Right-to-left languages are those in which the character flow starts at the right side of the page and moves to the left, wrapping at that point and starting again on the right side. For iOS 7.0, the two supported right-to-left languages are Arabic and Hebrew. Supporting these languages in our app involves two requirements:
Adding localization for the desired language
Using leading and trailing constraints
When working with constraints, all UI elements include leading and trailing constraints. Your controls will automatically respect the language setting of your system and reposition themselves on the correct sides of your view controller when these constraints are properly configured.
Note
The main reason we have “leading” and “trailing” constraints as opposed to “left” and “right” constraints is due to text flow. Because not all languages start at the left margin, but all do have a starting point, that starting point is known as “leading,” and the ending point is “trailing.” Constraints have built-in language direction respect. You can disable this by selecting the constraint, and then, in the Attributes Inspector, unchecking the Respect language direction in the First Item and the Second Item pull-down menus.
Let’s add a new view controller to the I18nExerciser project:
1. From Xcode, select File, New, File.
2. Choose Cocoa Touch under iOS.
3. Click Objective-C Class and then Next.
4. Name your class RightToLeftVC. Make it a subclass of UIViewController.
5. Enable Also Create XIB File.
6. Click Next and save the files in your project folder.
7. Import the RightToLeftVC.h header file into the LocaleTableViewController.m file.
8. Modify the “listings” array in the LocaleTableViewController.m file to include our new view controller. Name the entry “Right to Left Support.”
9. Wrap our view controller name in the NSLocalizedString() macro.
10. In LocaleTableViewController.m, modify the switch statement in the tableView:didSelectRowAtIndexPath: method to push our new view controller. Verify that the case is pointing to the correct index:
case CORRECTINDEX:
[self loadRightToLeftVC];
break;
11. Add the custom method, loadRightToLeftVC, to the implementation file like this:
-(void)loadRightToLeftVC{
RightToLeftVC *rightToLeftVC = [[RightToLeftVC alloc] init];
[self.navigationController pushViewController:rightToLeftVC animated:YES];
}
To configure the XIB, follow these steps:
1. From Xcode, select the RightToLeftVC.XIB file from the Project Navigator.
2. In the Utilities pane, from the Object library, drag two labels, one text field, and one text view onto the view controller. Have the layout match what’s shown in Figure 6.7.
3. Enable Hebrew localization for this XIB by selecting the RightToLeftVC.XIB file in the Xcode Project Explorer and enabling Hebrew in the Localization section of the File Inspector tab.
To code the UI, add the following outlets to the implementation file. Wire them accordingly to the XIB via a Ctrl-drag:
@property (weak, nonatomic) IBOutlet UITextView *textView;
@property (nonatomic, weak) IBOutlet UITextField *textField;
Enable localization support for Hebrew by adding that language via the Project Info tab under the Localization section (see Figure 6.8). We need to add a right-to-left language in order for our app to respond to it.
Now let’s walk through setting up our constraints. I broke down the configuration by view.
Name Label Constraint Settings
1. Select the Name label and then click the Pin button.
2. Set the upper Y constraint to a value of 82. Its nearest neighbor is the super view.
3. Set the Leading constraint to the Standard value.
4. Set the Trailing constraint to the Standard value.
5. Click the Add 3 Constraints button.
Text View Label Constraint Settings
1. Select the Text View label and then click the Pin button.
2. Set the Leading constraint to the Standard value.
3. Set the Trailing constraint to a value of 221.
4. Set the upper Y constraint to the Standard value.
5. Click the Add 3 Constraints button.
Text Field Constraint Settings
1. Select the Text Field to the right of our Name label and then click the Pin button.
2. Set the Trailing constraint to a value of 144. Its nearest neighbor is the super view.
3. Set the upper Y constraint to a value of 73. Its nearest neighbor is the super view.
4. Click the Add 2 Constraints button.
Text View Constraint Settings
1. Select the UITextView and then click the Pin button.
2. Set the Leading constraint to the Standard value.
3. Set the Trailing constraint to the Standard value.
4. Set the upper Y constraint to the Standard value.
5. Set the lower Y constraint to a value of 163. Its nearest neighbor is the super view.
6. Click the Add 4 Constraints button.
Now, as we’re looking at the height of the text view and thinking ahead, it might not be fully displayed on a rotated device. Let’s add a conditional height constraint:
1. Select the UITextView and then click the Pin button.
2. Enable Height and note the current height. In my case, it’s 257.
3. Click the Add 1 Constraint button.
4. With the text view still selected, click the Attributes Inspector.
5. Set the Relation to Less Than or Equal.
Let’s look at a preview of our layout, in both portrait and landscape. We can certainly accomplish this via launching our app in the Simulator, but Xcode’s Assistant Editor has a preview capability for us to consider.
1. With our XIB displayed, click the Assistant Editor button.
2. In the title bar area of the Assistant Editor, click Preview and then the listing for the XIB.
3. In the lower-right side, click the Apply Landscape Orientation button. Figure 6.9 shows our landscape preview.
The UITextView we’ve added gives us an editable, scrollable, multiline text region. This view also supports right-to-left languages; to automatically enable that support directly, we need to set the text view’s textAlignment property to NSTextAlignmentNatural. Setting the textAlignment property to this constant tells the text view to use the default alignment associated with the current language. Modify our viewDidLoad method in the RightToLeftVC.m implementation file:
- (void)viewDidLoad
{
[super viewDidLoad];
self.textView.textAlignment = NSTextAlignmentNatural;
}
Let’s see what we’ve got! Launch or switch to the Simulator, Settings app, General, International, Language. Set the language to Hebrew (
). Launch the I18nExerciser app, tap More, and tap Right to Left Support (see Figure 6.10).
Keyboards and Screen Coverage
When you tap into a control, say, a text field, the keyboard can potentially cover that controller. To give your customer the best experience possible, you want to shift the view containing the control up so that it displays above the displayed keyboard. But scroll the view by how much? For the majority of the iOS supported languages, the height of the keyboard is constant at 216px. The size of the onscreen keyboard varies based on the device and language used. Your app can get the exact keyboard size by registering as an observer for one of these notifications and then looking at the value for the UIKeyboardFrameBeginUserInfoKey object in the user info key:
UIKeyboardWillShowNotification
UIKeyboardDidShowNotification
UIKeyboardWillHideNotification
UIKeyboardDidHideNotification
First, add an observer to watch for the keyboard being displayed:
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(keyboardDisplayed:) name:UIKeyboardDidShowNotification object:nil];
The following code, keyboardDisplayed:nsNotification, will be called when the keyboard is displayed. When called, this code will return the height of the keyboard as a float value.
- (float) keyboardDisplayed:(NSNotification *)nsNotification {
NSDictionary *userInfo = [nsNotification userInfo];
CGSize kbSize = [userInfo[UIKeyboardFrameBeginUserInfoKey] CGRectValue].size;
return kbSize.height;
}
Listing 6.1 combines grabbing the height of the onscreen keyboard and scrolling the view.
Listing 6.1 Scrolling the View When the Keyboard Appears
- (void) keyboardWillShow:(NSNotification *)notification {
NSDictionary *userInfo = [notification userInfo];
CGSize keyboardSize = [userInfo[UIKeyboardFrameBeginUserInfoKey] CGRectValue].size;
CGRect frame = self.view.frame;
frame.origin.y = -keyboardSize;
[UIView animateWithDuration:0.3 animations:^{
self.view.frame = frame;
}]; }
Tools and Testing
There are many options available to test your strings and look for potential truncation and other types of layout issues. They are much easier than creating your own strings and changing the system language and so on. These options include pseudo localization and build switches, both described in detail next.
Pseudo Localization
Pseudo localization is different from our other localization processes in the fact that it does not use “real” language strings. It is a process of creating a “fake” language in order to mimic the characters used in the actual language. Pseudo localization uses a combination of doubled-up English characters, accented characters, and other characters—typically brackets (]). Some pseudo-localized text would include “
,” “
,” and “
.” This allows for the following:
Quickly checking each screen and verifying that strings have been localized. If they haven’t, they’ll display as English strings or whatever your Base language is.
Easily testing UI elements if you have allowed enough space for their associated text. In a real-world example, if you have a Buy button, that English text takes up only three characters, whereas the Spanish term “Comprar” takes up seven characters and could potentially display clipped. Pseudo-localization strings are lengthy by default to quickly alert you to issues like this.
Some pseudo-localization tools worth investigating include these:
Translate Toolkit (http://docs.translatehouse.org/projects/translate-toolkit/)
Pseudolocalizer (https://itunes.apple.com/us/app/pseudolocalizer/id503026674?mt=12)
Translation service Babble-on (www.ibabbleon.com/pseudolocalization.html)
Launch Switches
Launch switches are arguments passed on application launch that override the current NSUserDefaults value for the duration while the app is running. Several launch switches are available that provide an expedited way to quickly test some localization features. These switches include the following:
AppleLanguages—This switch allows us to specify what language to run the application under. This is more convenient than going through the steps of setting the System language (Settings app, General, International, Language) and then switching to the app and launching it. The syntax for this switch is -AppleLanguages (Two letter language code).
NSDoubleLocalizedStrings—This takes the existing localized strings and does exactly what it describes, doubles them. For example, if you have a button labeled “Tap to continue,” with this switch enabled, the button label appears as “Tap to continue. Tap to continue.” This switch helps test for layout and especially for any clipping of long strings. It also saves us from the need to test with actual lengthy German strings, such as “Siebentausendzweihundertvierundfünfzig,” which is the word for the integer 7,254. NSDoubleLocalizedStrings is a Boolean and its syntax is -NSDoubleLocalizedStrings YES.
NSShowNonLocalizedStrings—With this switch enabled, any UI strings that have not been localized will display in all caps, and the corresponding .strings entries missing localization will be logged out to the console. This is a Boolean as well, and the syntax to enable this switch is -NSShowNonLocalizedStrings YES. From my own experience working with this switch, the best results I’ve gotten are only one UI string displayed in all capitals and only one entry logged out. I have found these results echoed in several blogs and online forums I’ve researched. With that in mind, you are now aware of the existence of this switch, but I cannot recommend using it.
To set up launch arguments, follow these steps:
1. In Xcode, on the Xcode toolbar, select your target and then choose Edit Scheme from the Scheme toolbar (see Figure 6.11) to bring up the Edit Scheme dialog (see Figure 6.12).
2. On the left side, select Run I18nExerciser and then click the Arguments tab.
3. Click the plus sign.
4. Add the argument name with a dash in the Arguments Passed On Launch section, that is, -AppleLanguages (es).
5. Build and run your application.
Previewing Rotation in Xcode
The iOS Simulator is convenient for testing both the general layout and also how that layout will respond to rotation. With your application launched in the Simulator, simply pressing Cmd+left or right arrow key will rotate the device. Another option is to stay within Xcode, not even build your application, and see a preview of both portrait and landscape orientation via the Assistant Editor. The general steps to accomplish this are as given here:
1. Launch Xcode and open your project.
2. Select your XIB or Storyboard.
3. Click the Show the Assistant Editor button.
4. As shown in Figure 6.13, click Automatic, Preview, and then the XIB Preview. This displays a preview in portrait orientation. Now, let’s add another Xcode pane so that we’ll have an active preview for Landscape.
5. On the keyboard, hit Cmd+J (Jump to Selection). With the resulting pane displayed (see Figure 6.14) on the keyboard, hit the right arrow, and then the down arrow. Then press Return.
6. Back at the top of the Xcode window, click Automatic, Preview, and then the XIB Preview. Click the Apply Landscape Orientation button to change the preview to Landscape. The results of your efforts should match Figure 6.15.
Now when whenever you make a change to the XIB or Storyboard layout, that layout will automatically be applied and displayed in the Preview panes.
UI Localization
In this section I want to discuss a bit of a gamut of topics, and what they have in common is user interface consideration for locales. Really, there are no hard-and-fast rules here, simply areas to consider prior to designing the interface for your app.
Images
A couple of great callouts were made in Apple’s WWDC 2012 session “Internationalization Tips and Tricks” in regard to using images. The first example to call out is using graphics as linguistic puns, specifically having an image of a honeybee and then the word “clever” to have a resulting phrase of “be clever.” Although this sort of works for an English-speaking audience, it would fail miserably for a Spanish speaker because the potential translation of this phrase is “abeja inteligente,” which means “smart honeybee.” It’s best practice to avoid using images in this way.
A more poignant example is of an image used for a traffic stop sign. With an American audience, having a red octagon symbol is perfectly understandable. A Japanese audience would expect not an octagon, but a red triangle (see Figure 6.16). It’s not impractical to include both symbols with your application. As we saw in the preceding chapter, image files can be localized as well, as long as they have the same filename and are contained in the appropriate localization resource folder. Also, it is not unreasonable to localize the string “Stop” for both localizations and to superimpose that text over the image.
Right-to-Left Images
Earlier in this chapter, we covered having our UI support right-to-left languages and what’s involved in enabling that support. As with text, we need to think less about “left” and “right” and more about “leading” and “trailing.” The same applies to images, both with the direction of the text they include and with the flow of the images. Included in Figure 6.17 and Figure 6.18 are IKEA advertisements in Arabic and English, respectively. Notice in Figure 6.17 that not only the text alignment but also the images follow that alignment, with the image of the bookshelf on the right side (“trailing”). One item that is worth critiquing is the image of the form. If you look closely, you can see that text on that image is actually left-aligned.
Figure 6.17 Image support for a right-to-left language. Used with the permission of Inter IKEA Systems B.V.
Figure 6.18 Image support for a left-to-right language. Used with the permission of Inter IKEA Systems B.V.
Programmatically “Flipping” Images
Supporting right-to-left languages might require having specific image resource requirements. Within your code you can test for the current language your app is running under and load the appropriate images based on that. Alternatively, you can flip the images programmatically.
Included here is a code snippet to return a mirrored image:
- (UIImage *)flipImage:(UIImage *)image
{
UIImage *flippedImage = [UIImage imageWithCGImage:image.CGImage
scale:image.scale
orientation:UIImageOrientationUpMirrored];
return flippedImage;
}
This will return an image that is flipped horizontally. I encourage you to play with the other UIImageOrientation constants to ensure you get your desired results:
UIImageOrientationUpMirrored
UIImageOrientationDownMirrored
UIImageOrientationLeftMirrored
UIImageOrientationRightMirrored
Colors
Colors can have different meanings and different connotations for the locale and culture. Table 6.1 lists a few colors and their meanings for the given region. Pay the most attention to the color of the text because that will have the most impact on your customer. Text color will stand out the most as opposed to graphics or clipart where your customer is seeing a variety of colors.
String Length
When your English strings are translated, there’s no guarantee the language those strings have been translated to will take up the same amount of space. In fact, there is the potential that text can take double the space when it is translated into Spanish, for example. Looking at IBM’s Globalization Guidelines (www-01.ibm.com/software/globalization/guidelines/a3.html), you can see that many European languages can double or even triple the required “physical” space. This is especially important to keep in mind when you’re working with buttons and other types of controls that should be concise, typically one word, and should have no text wrapping.
This section gives you a heads up for planning your interface and your UI layout. I’m not expecting you to have your translations in hand as you’re designing your layout and your UI. This is information to keep in the back of your mind. Say, for example, you have a string of text that is taking up the entire width of a table cell in a table view; bear in mind that you could have potential UI expansion when translating to the other languages.
Table 6.2 gives a good indication of the amount of needed additional space for text after translation.
Table 6.3 gives an actual translated example, which includes the resulting count of characters included in the translations.
Single-Letter Icons
You know that your screen real estate is limited for your iOS application. You’re using icons and symbols appropriately to compensate for this. Excellent. When you are designing icons for toolbars and tab bar items, it is best to avoid any kind of lettering with those images. A capital “B” is widely understood when it comes to representing a “bold” toolbar button. Unfortunately, this is meaningless for Spanish, in which it would be a capital “N” (“negrita”), and in Russian we would need “п” (“
”). Be wary of these extra and unnecessary translations.
Body-Part Metaphors
Using images of the human anatomy is helpful and allows for quick understanding of the feature. One of the most reliable and innocuous examples is using an image of an ear to represent volume adjustment and audio input. The anatomy parts that would be best avoided include the arm and hand, or more specifically gestures made by them. The American “OK” (
) and “thumbs up” (
) signs are considered obscene in other marketplaces. Also consider how these symbols would be interpreted by people who communicate via sign language.
Also, if your icon needs to include a human face or human figure, ensure that the image is gender neutral.
Locale Maps
This last section is meant more for fun than practicality. My hope is to simply get you into a different frame of mind for a different perspective when it comes to maps of the world as seen by other locales. Other than tradition, there’s no important reason for maps to have north pointing “up.” It makes as much sense to have south pointing up. From a perspective of Australian citizens, they could prefer a world map with Australia in the center and at the top. The organization ODT has many of these perspective maps available on their Web site: http://odtmaps.com.
If your application includes maps and geopolitical regions, do ensure that those maps are appropriate for the regions for which you are including localization support.
Summary
This chapter covered the internationalization of your app’s UI. We looked at how changing string lengths and text directions directly affects layout and appearance. We worked with Auto Layout and constraints through several scenarios, including truncating, overlapping, and rotation. Auto Layout also demonstrated its usefulness when dealing with both left-to-right and right-to-left languages. We looked at test tools, namely, launch commands, to give us a quick heads up on how our layout was managing string display. We wrapped up this chapter by looking at handling keyboard sizes and UI localization.
The next chapter takes our app out into the great big world!