양방향 UI를 지원하는 방법(HTML)

[ 이 문서는 Windows 런타임 앱을 작성하는 Windows 8.x 및 Windows Phone 8.x 개발자를 대상으로 합니다. Windows 10용으로 개발하는 경우에는 최신 설명서를 참조하세요.]

RTL 쓰기 시스템을 위한 BiDi(양방향 텍스트 지원)를 제공하도록 앱을 디자인해 보세요.

소개

Microsoft는 오른쪽에서 왼쪽 쓰기 시스템을 사용하는 중동 및 기타 지역용 소프트웨어 제작에서 오랜 경험을 가지고 있습니다. 이 지역에서 주로 사용되는 쓰기 시스템에는 BiDi(양방향 텍스트 지원)가 필요하므로 고유한 디자인 요구 사항을 갖춰야 합니다. 이는 오른쪽에서 왼쪽으로(RTL) 또는 왼쪽에서 오른쪽으로(LTR) 텍스트 레이아웃을 입력하고 표시하는 기능입니다. Windows 3.1은 BiDi 언어에 대한 지원을 통합한 첫 번째 Windows 버전이었습니다. Windows 98에서는 아랍어 또는 히브리어 사용자에게 표시되는 환경이 보다 자연스럽게 느껴질 수 있도록 UI 방향을 반대로 적용했습니다.

Windows 8에서는 손상 없는 BiDi 환경을 제공합니다. 새로운 Windows UI에서 각 요소는 이러한 언어가 가장 자연스러운 상태로 표시되도록 디자인되어 다채로우면서 몰입이 가능한 RTL 사용자 환경에 결합되었습니다.

Windows 8에는

• 완벽하게 지역화된 2개의 언어(아랍어, 히브리어)와
• 신흥 시장을 위한 7개의 언어 인터페이스 팩(이란어, 우르두어, 다리어, 중앙 쿠르드어, 신디어, 펀잡어(파키스탄) 및 위구르어) 등, 총 9개의 BiDi 언어가 포함되어 있습니다. 이 중 2개 언어는 Windows 8에만 단독으로 처음 포함되었습니다.

BiDi 시장을 위한 Windows 스토어 앱 디자인

다음은 Windows BiDi 디자인 철학, 그리고 BiDi 디자인 고려 사항을 보여 주는 사례 연구입니다.

BiDi 디자인 요소

Windows에서 BiDi 디자인 결정에 영향을 주는 4가지 요소가 있습니다.

• 반대 방향 UI. UI 흐름이 기본 레이아웃에 RTL 콘텐츠를 표시할 수 있습니다. 따라서 UI 디자인이 BiDi 시장의 현지 제품처럼 보입니다.
• 사용자 환경의 일관성. RTL 방향의 디자인이 자연스럽게 느껴집니다. UI 요소의 레이아웃 방향이 일관되게 유지되며, 사용자가 예상하는 대로 표시됩니다.
• 터치 최적화. 방향이 반대가 아닌 UI의 터치 UX와 유사합니다. 요소에 접근하기 쉽고 터치 조작이 자연스럽습니다.
• 혼합 텍스트 지원. 텍스트 방향성 지원을 통해 BiDi 빌드의 영어 텍스트, 또는 그 반대의 경우와 같이 혼합 텍스트 표현이 가능합니다.

기능 디자인 개요

Windows 플랫폼에서는 위에 나온 4가지 BiDi 디자인 요소를 지원합니다. Windows에서 주요 관련 기능을 살펴보고 앱에 영향을 주는 일부 컨텍스트를 제공해 보겠습니다.

자연스럽게 느껴지는 방향으로 탐색

그리드의 첫 번째 타일이 오른쪽 맨 위에 있고 마지막 타일이 왼쪽 맨 아래에 있는, 즉 오른쪽에서 왼쪽으로 흐르는 그리드 방향을 채택했습니다. 따라서 읽기 패턴이 항상 오른쪽 맨 위에서 시작하여 왼쪽으로 진행되는 서적 및 잡지 등의 인쇄 출판물을 통해 사용자에게 이미 익숙한 패턴으로 정보를 표시합니다.

일관된 UI 흐름을 유지하기 위해, 그리드의 타일은 항상 RTL 레이아웃을 유지합니다. 즉, 앱 UI 언어와 상관없이 앱 이름과 로고가 항상 타일의 오른쪽 아래에 위치합니다.

BiDi 타일:

영어 타일:

올바르게 읽히는 타일 알림을 가져옵니다.

타일에는 혼합 텍스트가 지원됩니다. 알림 영역은 기본적으로 유연하므로 알림 언어를 기반으로 텍스트 맞춤을 조정할 수 있습니다. 앱에서 아랍어, 히브리어 또는 기타 BiDi 언어 알림을 보내는 경우에는 텍스트가 오른쪽에 맞춰지고, 영어 또는 기타 LTR 알림이 도착하면 왼쪽에 맞춰집니다.

터치하기 쉬운 일관된 RTL 사용자 환경

새로운 Windows UI의 모든 요소는 RTL 방향에 맞춰져 있습니다. 참 메뉴와 플라이아웃은 화면의 왼쪽 가장자리에 배치되었으므로 검색 결과와 겹치거나 터치 최적화 성능이 저하되지 않습니다. 즉, 엄지 손가락으로 쉽게 접근할 수 있습니다.

방향에 상관없이 텍스트 입력

Windows에서는 깨끗하고 깔끔한 화상 터치 키보드를 제공합니다. BiDi 언어의 경우 텍스트 방향 제어 키가 있어 텍스트 입력 방향을 필요에 맞게 전환할 수 있습니다.

모든 언어로 앱 사용

좋아하는 앱을 어떤 언어로든 설치 및 사용할 수 있습니다. 앱은 Windows의 비 BiDi 버전처럼 표시되고 작동합니다. 앱 내부 요소는 항상 일관되고 예측 가능한 위치에 배치됩니다.

괄호를 올바르게 표시

BPA(BiDi 괄호 알고리즘) 도입으로 언어 또는 텍스트 맞춤 속성과 상관없이 쌍을 이루는 괄호가 항상 제대로 표시됩니다.

잘못된 괄호:

올바른 괄호:

새 글꼴

Windows에서는 모든 BiDi 언어에 대해 새 Segoe UI 글꼴을 사용합니다. 이 새 글꼴은 새로운 Windows UI에 맞게 모양 및 배율이 조정됩니다.

사례 연구 1: BiDi 음악 앱

개요

일반적으로 미디어 컨트롤에는 BiDi 언어가 아닌 언어와 유사한 LTR 레이아웃이 적용될 것으로 예상되므로 멀티미디어 응용 프로그램의 디자인 변경은 매우 흥미롭습니다.

UI 방향성 설정

RTL UI 흐름을 유지하는 것은 BiDi 시장에서의 디자인 일관성을 위한 핵심입니다. 이 컨텍스트 내에 LTR 흐름을 가진 요소를 추가하기란 어렵습니다. 뒤로 단추 같은 일부 탐색 요소의 방향이 오디오 컨트롤에서 뒤로 단추의 방향과 반대일 수 있기 때문입니다.

Microsoft 음악 앱에서는 RTL 방향 그리드를 유지합니다. 따라서 새로운 Windows UI에서 이미 이 방향으로 탐색하고 있는 사용자에게 응용 프로그램이 아주 자연스럽게 느껴집니다. UI 흐름을 유지하는 데 도움이 될 수 있도록 주요 요소가 오른쪽에서 왼쪽으로 정렬되게 할 뿐 아니라 섹션 헤더에서도 적절히 배열되게 하여 이 흐름이 유지됩니다.

텍스트 처리

화면 위쪽의 아티스트 소개는 왼쪽 맞춤이지만, 앨범 및 트랙 이름 등, 다른 아티스트 관련 텍스트는 오른쪽 맞춤을 유지합니다. 소개 필드는 상당히 큰 텍스트 요소입니다. 비교적 큰 텍스트 블록을 읽는 동안에는 줄을 따라가기 어렵기 때문에 소개 필드를 오른쪽에 맞추면 잘 읽을 수 없습니다. 일반적으로 다섯 단어 이상이 포함된 두 줄 또는 세 줄 이상의 텍스트 요소는 이와 유사한 맞춤 예외로 고려되어야 합니다. 여기서 텍스트 블록 맞춤은 전체 앱 방향 레이아웃의 맞춤과 반대입니다.

앱 전반의 맞춤을 조작하면 앱이 정돈되어 보일 수 있지만 때로는 BiDi 문자열에서 중립 문자 배치와 관련하여 다른 렌더링 엔진의 일부 경계와 제한이 노출되기도 합니다. 예를 들어, 다음 문자열은 맞춤을 기반으로 다르게 표시될 수 있습니다.

	영어 문자열(LTR)	히브리어 문자열(RTL)
왼쪽 맞춤	Hello World!	בוקר טוב!
오른쪽 맞춤	Hello World	בוקר טוב!

 

음악 앱에서 아티스트 정보가 제대로 표시되도록 하기 위해 개발 팀에서는 텍스트 레이아웃 속성을 맞춤에서 분리했습니다. 즉, 아티스트 정보는 많은 경우에 오른쪽 맞춤으로 표시될 수 있지만 문자열 레이아웃 조정은 사용자 지정된 후순위 처리를 기반으로 설정됩니다. 후순위 처리는 문자열의 콘텐츠를 기반으로 최적의 방향 레이아웃 설정을 결정합니다.

예제: 사용자 지정 문자열 레이아웃을 처리하지 않으면 아티스트 이름 "The Contoso Band."는 ".The Contoso Band"로 나타납니다.

특수 문자열 방향 전처리

앱이 Microsoft 서버에 미디어 메타데이터를 폴링하면 사용자에게 이를 표시하기 전에 각 문자열을 전처리합니다. 또한 앱은 이 전처리 중 변환을 사용하여 텍스트 방향을 일관되게 합니다. 이를 위해 앱은 문자열의 끝에 중립 문자가 있는지 확인합니다. 또한 문자열의 텍스트 방향이 Windows 언어 설정에서 설정된 앱 방향과 반대인 경우 유니코드 방향 마커를 추가합니다. 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;
}

addedUnicode 문자는 길이가 0이므로 문자열의 간격에 영향을 주지 않습니다. 이 코드를 실행하면 문자열 방향을 감지하는 데 비중립 문자가 나올 때까지 문자열 실행이 필요하므로 잠재적으로 성능이 저하됩니다. 중립성 여부를 확인하는 각 문자는 여러 유니코드 범위에 대해 처음으로 비교되므로 이는 중요한 검사입니다.

사례 연구 2: BiDi 메일 앱

개요

UI 레이아웃 요구 사항과 관련하여, 메일 클라이언트는 디자인하기가 아주 쉽습니다. Windows와 함께 제공되는 Microsoft Mail 앱은 기본적으로 방향이 반대입니다. 텍스트 처리 관점에서 메일 앱이 혼합 텍스트 시나리오를 수용하려면 한층 강력한 텍스트 표시 및 구성 접근 권한 값을 갖추어야 합니다.

UI 방향성 설정

Microsoft Mail 앱의 UI 레이아웃은 방향이 반대입니다. 폴더 창이 화면의 오른쪽 가장자리에 오고, 메일 항목 목록이 왼쪽에, 그리고 그 아래에 메일 작성 창이 오도록 세 개의 창이 재배치되었습니다.

추가 항목은 전반적인 UI 흐름과 터치 최적화를 위해 방향이 다시 지정되었습니다. 여기에는 앱 바를 비롯하여 작성, 응답 및 삭제 아이콘이 포함됩니다.

텍스트 처리

UI

UI에서 텍스트 정렬은 주로 오른쪽 맞춤입니다. 폴더 창과 항목 창도 여기에 포함됩니다. 항목 창은 텍스트 두 줄(주소, 제목)로 제한됩니다. 이는 콘텐츠 방향이 UI 방향 흐름과 반대인 경우 읽기 어려운 텍스트 블록을 사용하지 않고 RTL 정렬을 유지하는 데 있어 중요합니다.

텍스트 편집

텍스트 편집에는 LTR 및 RTL 양식 둘 다로 작성할 수 있는 기능이 필요합니다. 또한 작성 레이아웃은 적절한 형식(예: 방향성 있는 정보를 저장할 수 있는 기능을 가진 서식있는 텍스트)을 사용하여 유지되어야 합니다.