Compartir a través de

How to support bidirectional UI (XAML)

  • Artículo

[ This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation ]

Design your apps to supply bi-directional text support (BiDi) for right-to-left writing systems.

Introduction

Microsoft has a long history of producing software for the Middle East and other regions that use a right-to-left writing system. Design requirements for those parts of the world are unique, because the writing systems that are commonly used there require bi-directional text support (BiDi). This is the ability to input and display text layout in either right to left (RTL) or left to right (LTR) order. Windows 3.1 was the first version of Windows to incorporate support for BiDi languages. In Windows 98 the UI orientation was mirrored so that the user experience would look and feel more natural when presented to Arabic or Hebrew speakers.

Windows 8 offers a no-compromise BiDi experience. Every element in new Windows UI is designed and joined into a rich and immersive right-to-left user experience, which showcases these languages in their most natural state.

A total of nine BiDi languages are included beginning with Windows 8:

  • Two fully localized languages (Arabic, Hebrew).
  • Seven Language Interface Packs for emerging markets (Persian, Urdu, Dari, Central Kurdish, Sindhi, Punjabi (Pakistan), and Uyghur). Two of these languages are new and exclusive to Windows 8.

Designing Windows Store apps for BiDi markets

Here is the Windows BiDi design philosophy, and case studies that show BiDi design considerations.

Bidi design elements

Four elements influence BiDi design decisions in Windows:

  • UI mirroring. UI flow allows right to left content to be presented in its native layout. UI design feels local to BiDi markets.
  • Consistency in user experience. The design feels natural in right to left orientation. UI elements share a consistent layout direction and appear as the user expects them.
  • Touch optimization. Similar to touch UX in non-mirrored UI, elements are easy to reach and feel natural to touch interaction.
  • Mixed text support. Text directionality support enables great mixed text presentation (English text on BiDi builds, and vice versa).

Feature design overview

The Windows platform supports the four BiDi design elements listed above. Let's look at some of the major relevant features in Windows, and provide some context in which they affect your app.

We adjusted the grid direction so that it would flow from right to left, meaning that the first tile on the grid is placed on the top right corner, and the last tile on the bottom left. This presents information in a pattern already familiar to users from printed publications such as books and magazines, where the reading pattern always starts at the top right corner and progresses to the left.

To preserve a consistent UI flow, the tiles on the grid always retain a right-to-left layout, meaning that the app name and logo are positioned at the bottom right corner of the tile regardless of the app UI language.

BiDi tile:

English tile:

Get tile notifications that read correctly.

Tiles have mixed text support. The notification region has built-in flexibility to adjust the text alignment based on the notification language. When an app sends Arabic, Hebrew, or other BiDi language notifications, the text is aligned to the right, and when an English (or other LTR) notification arrives it will align to the left.

A consistent easy-to-touch RTL user experience.

Every element in new Windows UI fits into the RTL orientation. Charms and flyouts have been positioned on the left edge of the screen so that they do not overlap search results or degrade touch optimization. They can be easily reached with the thumbs.

Text input in any direction.

Windows offers an on-screen touch keyboard that is clean and clutter-free. For BiDi languages, there is a text direction control key so that the text input direction can be switched as needed.

Use any app in any language.

Install and use your favorite apps in any language. The apps appear and function as they would on non-BIDi versions of Windows. Elements within apps are always placed in a consistent and predictable position.

Display parentheses correctly.

With the introduction of the BiDi Parenthesis Algorithm (BPA), paired parentheses always display properly regardless of language or text alignment properties.

Incorrect parentheses:

Correct parentheses:

New font.

Windows uses the new Segoe UI font for all BiDi languages. This new font is shaped and scaled for new Windows UI.

Case study #1: A BiDi music app

Overview

Multimedia applications make for a very interesting design challenge, because media controls are generally expected to have a left-to-right layout similar to that of non-BiDi languages.

Establishing UI directionality

Retaining the right-to-left UI flow is important for consistent design for BiDi markets. Adding elements that have left-to-right flow within this context is difficult, because some navigational elements such as the back button may contradict the directional orientation of the back button in the audio controls.

The Microsoft Music App retains a right-to-left oriented grid. This gives the application a very natural feel for users who already navigate in this direction across new Windows UI. The flow is retained by ensuring that the main elements are not just ordered from right to left, but also aligned properly in the section headers to help maintain the UI flow.

Text handling

The artist bio in the screen above is left aligned, while other artist related text pieces such as album and track names preserve right alignment. The bio field is a fairly large text element which reads poorly when aligned to the right simply because it is hard to track between the lines while reading a larger text block. In general, any text element with more than two or three lines containing five or more words should be considered for similar alignment exceptions, where the text block alignment is opposite to that of the overall app directional layout.

Manipulating the alignment across the app can look simple but often exposes some of the boundaries and limitations of the rendering engines in terms of neutral character placement across BiDi strings. For example, the following string can display differently based on alignment:

English String (LTR) Hebrew String (RTL)
Left Alignment Hello World! בוקר טוב!
Right Alignment !Hello World !בוקר טוב

 

To ensure artist information is properly displayed across the music app, the development team separated text layout properties from alignment. In other words, the artist info might be displayed as right-aligned in many of the cases but the string layout adjustment is set based on customized background processing. The background processing determines the best directional layout setting based on the content of the string.

Example: Without custom string layout processing, the artist name "The Contoso Band." would appear as ".The Contoso Band".

Specialized string direction preprocessing

When the app polls our servers for media metadata, it preprocesses each string prior to displaying it to the user. During this preprocessing, the app also does a transformation to make the text direction consistent. To do this, it checks if there are neutral characters on the ends of the string. Also, if the text direction of the string is opposite to the app direction set by the Windows language settings, it appends (and sometimes prepends) Unicode direction markers. The transformation function looks like this in C#:

string normalizeTextDirection(string data) 
{
    if (data.Length > 0) {
        var lastCharacterDirection = DetectCharacterDirection(data[data.Length - 1]);

        // If the last character has strong directionality (direction is not null), then the text direction for the string is already consistent.
        if (!lastCharacterDirection) {
            // If the last character has no directionality (neutral character, direction is null), then we may need to add a direction marker to
            // ensure that the last character doesn't inherit directionality from the outside context.
            var appTextDirection = GetAppTextDirection(); // checks the <html> element's "dir" attribute.
            var dataTextDirection = DetectStringDirection(data); // Run through the string until a non-neutral character is encountered,
                                                                 // which determines the text direction.

            if (appTextDirection != dataTextDirection) {
                // Add a direction marker only if the data text runs opposite to the directionality of the app as a whole,
                // which would cause the neutral characters at the ends to flip.
                var directionMarkerCharacter =
                    dataTextDirection == TextDirections.RightToLeft ?
                        UnicodeDirectionMarkers.RightToLeftDirectionMarker : // "\u200F"
                        UnicodeDirectionMarkers.LeftToRightDirectionMarker; // "\u200E"

                data += directionMarkerCharacter;

                // Prepend the direction marker if the data text begins with a neutral character.
                var firstCharacterDirection = DetectCharacterDirection(data[0]);
                if (!firstCharacterDirection) {
                    data = directionMarkerCharacter + data;
                }
            }
        }
    }

    return data;
}

The addedUnicode characters are zero-width characters and, as a result, do not impact the spacing of the strings. This code does carry a potential performance penalty since detecting the direction of a string requires running through the string until a non-neutral character is encountered. Each character that is checked for neutrality is first compared against several Unicode ranges as well, so it isn't a trivial check.

Case study #2: A BiDi mail app

Overview

In terms of UI layout requirements, a mail client is fairly simple to design. The Microsoft Mail app that comes with Windows is mirrored by default. From a text handling perspective the mail app is required to have more robust text display and composition capabilities in order to accommodate mixed text scenarios.

Establishing UI directionality

The UI layout for the Microsoft Mail App is mirrored. The three panes have been reoriented so that the folder pane is positioned on the right edge of the screen, followed by the mail item list pane to the left and then the email composition pane.

Additional items have been reoriented to match the overall UI flow and touch optimization. These include the app bar and the compose, reply, and delete icons.

Text Handling

UI

Text alignment across the UI is usually right-aligned. This includes the folder pane and items pane. The item pane is limited to two lines of text (Address, and Title). This is important for retaining the right-to-left alignment, without introducing a block of text that would be difficult to read when the content direction is opposite to the UI direction flow

Text Editing

Text editing requires the ability to compose in both right to left and left to right form. In addition, the composition layout must be preserved by using a format, such as rich text, that has the ability to save directional information.