双方向対応の UI をサポートする方法 (HTML)

[ この記事は、Windows ランタイム アプリを作成する Windows 8.x および Windows Phone 8.x 開発者を対象としています。Windows 10 向けの開発を行っている場合は、「最新のドキュメント」をご覧ください]

右から左への書記体系向けの双方向テキスト サポート (BiDi) を備えたアプリを設計できます。

はじめに

Microsoft には、右から左への書記体系を使う中東などの地域向けに製品を提供してきた長い歴史があります。これらの地域向けの設計要件は独特のものです。それは、この地域で一般に使われる書記体系は双方向テキスト サポート (BiDi) を備える必要があるためです。これは、右から左 (RTL) または左から右 (LTR) の順序のテキスト レイアウトを入力して表示する機能です。Windows 3.1 は BiDi 言語に対するサポートを備えた最初のバージョンの Windows でした。Windows 98 では、UI の方向がミラー化されることで、アラビア語やヘブライ語を母国語とするユーザーにとってのユーザー エクスペリエンスは外観と操作感がより自然なものになりました。

さらに Windows 8 では妥協のない BiDi エクスペリエンスが実現します。新しい Windows UI のすべての要素は、右から左への読み取り順序に対応する多様な没入型ユーザー エクスペリエンスに合わせて設計され、これらの言語を最も自然な形で示すことができます。

Windows 8 からは合計 9 種類の BiDi 言語が含まれるようになりました。

• 2 種類の完全にローカライズされた言語 (アラビア語、ヘブライ語)。
• 新興市場向けの 7 種類の言語インターフェイス パック (ペルシャ語、ウルドゥー語、ダリー語、中央クルド語、シンド語、パンジャーブ語 (パキスタン)、ウイグル語)。これらの言語のうち 2 つは新たに Windows 8 だけに加わったものです。

BiDi 市場向け Windows ストア アプリの設計

Windows に関する BiDi 対応の設計哲学を紹介し、BiDi 対応の設計時の考慮事項を示すケース スタディを取り上げます。

BiDi 対応の設計要素

4 つの要素が、Windows の BiDi に関する設計上の決定に影響を与えます。

• **UI のミラー化。**UI のフローで右から左への読み取り順序のコンテンツをネイティブ レイアウトに表示できるようにします。UI デザインが BiDi 市場に対してローカルなものになります。
• **ユーザー エクスペリエンスの一貫性。**右から左の方向で自然に感じられるデザインを提供します。UI 要素が、共通した一貫性のあるレイアウト方向でユーザーの期待どおりに表示されます。
• **タッチの最適化。**ミラー化されていない UI におけるタッチ UX によく似た、簡単で自然なタッチによる対話式操作で UI 要素を操作できるようにします。
• **混在テキストのサポート。**テキスト方向のサポートにより、混在テキストを美しく表示できます (BiDi ビルドに英語のテキストを表示、または英語ビルドに BiDi テキストを表示)。

機能設計の概要

Windows プラットフォームは、上記の 4 つの BiDi 対応の設計要素をサポートしています。ここでは、Windows の主な関連機能について説明し、それらの機能がアプリに影響する場合のコンテキストを取り上げます。

自然な形になる方向に配置します。

グリッドの方向が右から左の順序になるように調整されました。つまり、グリッド上の最初のタイルは右上隅に配置され、最後のタイルは左下隅に配置されます。これにより、本や雑誌などの刊行物でユーザーにとってなじみのあるパターンで情報が表示されます。読み取りパターンは常に右上隅から始まり、左に向かって進んでいくことになります。

一貫性のある UI のフローを維持するために、グリッドに配置されたタイルは常に右から左のレイアウトが保持されます。つまり、アプリの UI 言語に関係なく、アプリ名とロゴはタイルの右下隅に配置されます。

BiDi 対応のタイル:

英語のタイル:

正しく読み取ることができるタイル通知を表示します。

タイルは混在テキストをサポートします。通知領域には、通知言語に応じてテキスト配置の方向を調整できる柔軟性が組み込まれています。 アプリでアラビア語、ヘブライ語などの BiDi 言語の通知を送信する場合、テキストは右揃えに調整され、英語またはその他の左から右方向 (LTR) の言語の通知を受信した場合、その通知は左揃えに調整されます。

一貫性のあるタッチしやすい RTL ユーザー エクスペリエンス。

新しい Windows UI のすべての要素は、RTL の読み取り方向に適合します。チャームとポップアップは画面の左端に配置されているため、検索結果に重ならず、快適なタッチ操作の邪魔になることもありません。親指で簡単に操作できます。

任意の方向にテキスト入力できます。

Windows には、すっきり整理されたスクリーン タッチ キーボードが備わっています。BiDi 言語の場合、テキスト方向のコントロール キーがあるため、テキスト入力の方向を必要に応じて切り替えることができます。

任意の言語でアプリを使うことができます。

任意の言語でお気に入りのアプリをインストールして使うことができます。アプリは、BIDi 対応ではないバージョンの Windows の場合と同じように表示され、機能します。アプリの要素は常に一貫性のある予測可能な位置に配置されます。

かっこを正しく表示できます。

BiDi Parenthesis Algorithm (BPA) を導入すると、言語やテキスト配置の方向に関係なく、ペアになったかっこは常に正しく表示されます。

不適切なかっこ:

適切なかっこ:

新しいフォント

Windows では、新しい Segoe UI フォントを使ってすべての BiDi 言語に対応しています。この新しいフォントは、新しい Windows UI に応じた外観と大きさになっています。

ケース スタディ #1: BiDi 対応のミュージック アプリ

概要

マルチメディア アプリは、非常に興味深い設計上の問題を提起します。一般にメディア コントロールは、BiDi 以外の言語の場合と同様の左から右のレイアウトであることが想定されているためです。

UI の方向の設定

BiDi 市場向けの設計で一貫性を確保するためには、右から左への UI のフローを保持することが重要です。このコンテキストで左から右へのフローの要素を追加するのは困難です。戻るボタンなどの一部のナビゲーション要素が、オーディオ コントロールの戻るボタンの方向と矛盾を生じる可能性があるからです。

Microsoft ミュージック アプリでは、右から左への方向のグリッドが保持されます。そのため、既に新しい Windows UI でこの方向による操作を行っているユーザーにとっては、アプリで非常に自然な操作感が得られます。主な要素を右から左の読み取り順序にするだけでなく、セクション ヘッダーでも適切な方向の配置を行うことは、UI のフローを維持するために有効です。

テキストの処理

上の画面のアーティストの略歴は左揃えですが、アルバム名やトラック名などのその他のアーティスト関連テキストは右揃えが維持されています。略歴のフィールドは非常に大きなテキスト要素であり、右揃えの場合、大きなテキスト ブロックを読み取るときに行を追うことが難しくなるため、読みづらくなります。一般に、5 つ以上の語句を含む行が 3 行以上あるテキスト要素で、同様の位置揃えの例外を考慮する必要があります。この場合、テキスト ブロックの位置揃えがアプリの全体的な方向レイアウトとは逆になります。

アプリ全体の位置揃えの操作は単純そうに見えますが、多くの場合、BiDi 文字列におけるニュートラル文字の配置の点で、レンダリング エンジンの限界や制限を伴います。たとえば、次の文字列は位置揃えによって異なって表示される場合があります。

ミュージック アプリでアーティスト情報が適切に表示されるようにするために、開発チームではテキスト レイアウトのプロパティを位置揃えから切り離しました。つまり、アーティスト情報は多くの場合に右揃えで表示されますが、文字列レイアウトの調整は、カスタマイズされたバックグラウンド処理に基づいて設定されます。バックグラウンド処理では、文字列の内容に応じた最適な方向レイアウト設定が判断されます。

例: カスタムの文字列レイアウト処理を適用しない場合、アーティスト名 "The Contoso Band." は ".The Contoso Band" と表示されます。

文字列の方向の特殊な前処理

メディア メタデータの有無についてアプリがサーバーをポーリングする場合、アプリはユーザーへの表示前に各文字列を前処理します。また、この前処理の際に、アプリはテキストの方向を統一するための変換を行います。これを行うために、アプリは文字列の末尾にニュートラル文字がないかどうかを確認します。また、文字列のテキストの方向が Windows の言語設定で設定されたアプリの方向と逆である場合は、Unicode 方向マーカーを追加 (場合によっては、先頭に追加) します。この変換関数は、JavaScript では次のように表示されます。

function normalizeTextDirection(data) {
    if (data) {
        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;
}

追加される Unicode 文字は幅が 0 の文字であるため、文字列の間隔に影響を与えることはありません。 文字列の方向の検出は、ニュートラル以外の文字が検出されるまで文字列全体を対象に続ける必要があるため、このコードによってパフォーマンスの低下を招く可能性があります。また、ニュートラル文字であるかどうかの確認対象となるそれぞれの文字については、最初に複数の Unicode の範囲との照合も行われるため、これは単純なチェックではありません。

ケース スタディ #2: BiDi 対応のメール アプリ

概要

UI レイアウト要件の点では、メール クライアントは設計が非常に単純です。Windows に付属する Microsoft メール アプリは、既定でミラー化されています。テキスト処理の観点から、メール アプリには、混在テキストのシナリオに対応するために、しっかりとしたテキスト表示機能とテキスト作成機能が必要です。

UI の方向の設定

Microsoft メール アプリの UI レイアウトはミラー化されています。3 つのウィンドウが配置し直され、フォルダー ウィンドウは画面の右端に配置され、メール項目一覧ウィンドウがその左に続き、さらにその左にメール作成ウィンドウが配置されます。

その他の項目も、UI のフロー全体とタッチの最適化に適合するように配置し直されます。 その他の項目には、アプリ バーや作成、返信、削除の各アイコンがあります。

テキストの処理

UI

UI 全体のテキスト配置は、通常は右揃えです。これには、フォルダー ウィンドウや項目ウィンドウが含まれます。項目ウィンドウはテキスト 2 行に制限されます (アドレスとタイトル)。このことはテキスト ブロックを導入しないで右から左の配置を維持するうえで重要です。テキスト ブロックがあると、コンテンツの方向が UI の方向フローと逆であるときに読み取りが困難になります。

テキストの編集

テキストを編集するには、右から左と左から右の両方の形式で記述できる機能が必要です。さらに、方向に関する情報を保存できるリッチ テキストなどの形式を使って構成レイアウトを保持できる必要があります。