앱 바를 통한 주문형 UI 구현

Windows 8 앱 개발자 블로그

Windows 8 엔지니어링 팀에서 제공하는 Windows 8용 Metro 스타일 앱 개발의 이해

앱 바를 통한 주문형 UI 구현

  • Comments 0

좋은 앱을 만들려면 앱이 해당 범주에서 가장 뛰어나고 멋지게 보일 수 있는 부분을 집중적으로 다듬어야 합니다. Windows 8은 앱을 해당 범주에서 최고로 만들고 방해 요소를 최소화하는 작업을 간편하게 수행할 수 있는 참 메뉴나 앱 바 같은 도구를 제공합니다. 이러한 도구 사용법을 배운다면 사용자가 반할 만한 멋진 앱을 만들 수 있습니다.

앱의 가장 큰 특징에 집중

극장에서는 영화가 대형 스크린에서 상영되고 그외의 공간은 깜깜하기 때문에 관객은 화면에만 집중할 수 있습니다. 또한 서라운드 사운드가 극장 전체를 울리기 때문에 영화의 사운드에 집중할 수 있습니다. 사람들은 '반드시' 극장에서 봐야 하는 영화가 있다고 말을 합니다. 사람들이 극장에 가는 이유는 영화에 완전히 몰입할 수 있는 환경이 제공되기 때문입니다. 대화가 더 깨끗하게 들리고 화면은 더욱 생생합니다. 내가 마치 영화 속에 있는 듯한 느낌을 받습니다. 하지만 옆 사람이 걸려온 전화를 받는 순간 산만해지면서 이러한 경험에서 깨어납니다. 모든 방해 요소가 하나씩 모여 완벽한 영화 감상 분위기를 망쳐 놓고 맙니다.

개발자의 앱은 영화 극장, 앱 콘텐츠는 영화에 비유할 수 있습니다. 사용자가 앱에 몰입할 수 있는 환경을 만드는 것이 새 디자인의 핵심 아이디어입니다. 블로그 글 사용자의 이목을 사로잡는 Metro 스타일 앱 만들기에서 내 앱이 해당 범주에서 가장 뛰어난 점은 무엇인가를 설명하는 앱 소개 문구를 다루었습니다. 여러분의 앱에서 사용자들이 몰입할 수 있는 가장 뛰어난 부분을 결정하면 나머지 방해 요소는 Window 8에서 제공하는 도구를 사용하여 그들을 원할 때까지 숨겨 둘 수 있습니다. 우리는 Food with Friends라고 하는 예제 앱을 통해 이 아이디어를 연구했습니다.

Food with Friends에서 이러한 페이지를 실제로 디자인했습니다.

Food with Friends 계층

그림 1: Food with Friends 계층

Food with Friends의 기존 레이아웃을 기반으로 저녁에 외식하러 가자는 친구의 제안에 응답하여 친구가 좋아하는 레스토랑과 내가 좋아하는 레스토랑을 찾아볼 수 있습니다. 하지만 아직 할 수 없는 일도 있습니다. 희망 목록에 레스토랑을 추가하고, 전체 레스토랑 목록을 정렬하거나 필터링하고, 특정 레스토랑을 검색하는 작업은 아직 불가능합니다. 그래도 괜찮습니다. 중요한 기능인 것은 맞지만 앱을 돋보이게 하는 가장 큰 특징은 아니니까요. 지난 글에서 말씀드렸던 내용을 떠올려 보세요.

  • Food with Friends는 해당 범주의 앱 중에서 사용자가 친구들과 함께 저녁 식사를 할 레스토랑을 찾도록 도와주는 기능이 가장 뛰어납니다.

현재까지 구현된 앱 UI만으로도 이러한 기능을 실행하기에 전혀 부족함이 없습니다. 소개 문구의 가장 큰 장점이 완벽하게 구현되어 있습니다. 사용자가 희망 목록에 항목을 추가하거나 목록을 정렬 또는 필터링할 수 있는 단추와 위젯을 추가한다면 그러한 명령이 불필요할 때에도 어쩔 수 없기 화면에 보이기 때문에 사용자의 몰입을 방해합니다. 하지만 이러한 명령이 필요한 때가 분명 있습니다. 그렇다면 가장 큰 장점은 아니지만 중요한 기능인 것은 틀림없는 이 명령들을 어떻게 처리해야 할까요?

Windows 8에서는 사용자가 앱의 UI에 액세스할 수 있는 표준 방법을 제공합니다. 이 UI는 사용자의 요청에 따라 작동하며 필요하지 않을 때에는 숨김 처리됩니다. 명령이 요청에 따라 작동하기 때문에 사용자의 몰입을 방해하는 요소로 앱 캔버스를 가리지 않아도 됩니다. 주문형 UI를 활용하면 앱 소개 문구에 따라 앱의 모든 픽셀에 집중할 수 있습니다. 거의 모든 앱에서 2가지 메커니즘을 사용하여 주문형 UI를 노출합니다. 즉, 참 메뉴와 앱 바를 사용합니다. 참 메뉴와 앱 바 모두 에코시스템의 경계를 넘어서 사용할 수 있고 언제나 표준 방법으로 호출되기 때문에 사용자는 필요할 때만 참과 앱 바를 가져오고 그 외의 시간에는 앱 콘텐츠에 집중할 수 있습니다.

참 메뉴

참 메뉴 바

그림 2: 참 메뉴 바

Windows 8을 설계할 때 거의 모든 앱에 빠지지 않고 들어가며 모든 사용자들이 바라는 기능이 있다는 것을 인식했습니다. 이러한 명령을 언제 어디서나 사용할 수 있도록 영구적인 집을 만들었는데 이것이 바로 모든 앱에 들어 있는 참 메뉴입니다. 참 메뉴는 모든 앱과 시스템 자체에서 검색, 공유, 장치 연결 및 설정 작업을 위한 시작점을 제공합니다. 시스템 내 어디에나 참 메뉴를 사용할 수 있습니다. 따라서 앱을 설계할 때 사용자가 다른 앱 또는 소셜 네트워크와 콘텐츠를 공유할 방법을 고민하거나 검색 상자를 어디에 두어야 할지 고심할 필요가 없습니다. 여러분이 개발하는 앱의 최대 장점은 그런 것이 아니니까요. 물론 설정은 중요합니다. 하지만 여러분이 개발하는 멋지고 재미있는 기능보다 중요하지는 않습니다. 참 메뉴는 사용자에게 이러한 기능을 사용할 수 있는 표준 방법을 제공합니다. 무엇보다도 사용자가 필요로 할 때까지 화면에 나타나지 않기 때문에 앱에서 가장 중요한 것, 즉 콘텐츠에 대한 몰입도를 떨어트리지 않습니다. 사용자는 오른쪽에서 화면을 살짝 밀거나, 마우스를 오른쪽 모서리로 끌거나, 모든 시스템에서 작동하는 Windows+C 키를 눌러 참 메뉴를 불러올 수 있습니다.

앱 바 및 탐색 표시줄

스포츠 앱의 앱 바 및 탐색 표시줄

그림 3: 앱 바 및 탐색 표시줄

참 메뉴는 사용자가 거의 모든 앱의 기능을 사용할 수 있는 표준 방법을 제공하는 데 반해 앱 바와 탐색 표시줄은 각 개별 앱에 한정된 기능을 사용할 수 있는 방법을 제공합니다. 탐색 표시줄을 사용하는 앱은 앱투앱(app to app)과 다릅니다. 앱 바의 명령은 앱, 페이지 또는 현재 선택 항목에 따라 달라집니다. 앱 바 및 탐색 표시줄이 앱투앱(app to app)과 다르기는 해도 모든 앱에 사용할 수 있는 강력한 도구임에 틀림없습니다. 사용자는 앱에서 무슨 일을 할 수 있는지 살펴볼 때 언제나 앱 바와 탐색 표시줄을 가장 먼저 확인합니다. 모든 앱이 이 방식으로 작동하기 때문이죠. 사용자는 앱 바 또는 탐색 바가 있는 모든 앱에서 화면 맨 위 또는 아래에서 살짝 밀거나, 앱의 아무 곳을 마우스 오른쪽 단추로 클릭하거나, 키보드의 Windows+Z 키를 눌러 주문형 UI를 가져올 수 있습니다.

Windows 8의 표준 주문형 UI를 사용하면 사용자가 사용자 인터페이스에 대해 고민하지 않고 앱 콘텐츠 탐색에 집중할 수 있도록 유도할 수 있습니다. 이것이 가능한 이유는 Windows와 모든 앱에서 일관적이고 예측 가능하기 때문입니다. 이 글의 나머지 부분에서는 뛰어난 앱 바를 설계 및 구축하는 방법에 대해 이야기를 나누겠습니다. 다음 글에서는 개별 참 메뉴와 같은 시스템의 다른 기능을 자세히 살펴보겠습니다. 앱의 최대 장점에 대한 몰입도를 유지하는 한편 Windows 8 앱 에코시스템의 장점을 최대로 활용할 수 있을 것입니다.

앱 바에 들어갈 기능

앱 바를 만들 때 고려할 첫 번째는 앱 바에 들어갈 기능입니다. 앞에서도 말했지만 앱 바는 사용자가 필요할 때 사용 가능한 기능일 뿐이지 여러분의 앱이 제공하는 최대 장점은 아니라는 사실을 기억해 두시기 바랍니다. 앱에 들어갈 기능은 앱의 수명 주기 동안 자주 사용될 것인지 여부를 판단하여 결정할 수 있습니다. Release Preview의 SkyDrive 앱에 들어간 앱 바를 예로 들어 살펴보겠습니다.

SkyDrive 앱 바

그림 4: SkyDrive 앱 바

SkyDrive 앱은 사용자가 어디서나 방대한 콘텐츠에 액세스할 수 있다는 것이 최대 장점입니다. 따라 앱 캔버스가 콘텐츠 탐색에 집중되어 있습니다. 물론 파일 추가 기능도 앱의 중요한 부분입니다. 파일 추가 기능이 없다면 무슨 방법으로 콘텐츠를 올리겠습니까? 하지만 파일 추가는 사용자가 항상 하는 작업이 아니기 때문에 추가 단추를 주문형으로 만드는 것이 가장 이상적입니다. 이러한 방식으로 사용자가 새 파일을 추가할 때를 제외한 모든 시간에 앱 캔버스의 모든 픽셀을 콘텐츠 탐색에 사용할 수 있습니다. 시스템 전체에서 앱별 숨김 UI가 나타나는 방식과 동일한 방식으로 앱 명령이 나타나기 때문에 사용자는 추가 명령을 불러오는 방법을 정확하게 알 수 있습니다.

앱 바 만들기

주문형 UI를 만드는 가장 좋은 방법은 WinJS 및 XAML의 AppBar 컨트롤입니다. 이러한 컨트롤을 사용하여 화면 하단에 앱 바를 만들고 상단에 탐색 표시줄을 만들 수 있습니다. 여담이지만 이전에는 앱의 탐색 표시줄에 집중했었죠.

뛰어난 앱 바에서 가장 중요한 것은 사용자가 화면 위/아래에서 살짝 밀기, 오른쪽 단추 클릭 또는 Windows+Z 키를 누르는 표준 동작으로 기능을 요청하면 사용 가능한 모든 앱 명령이 표시되어 한다는 점입니다. 앱 바 컨트롤은 이러한 동작을 완벽하게 구현할 수 있을 뿐만 아니라 앱의 전체적인 모양과 느낌에 딱 들어맞는 기본 앱 바를 매우 간단하게 만들 수 있습니다.

예를 들어 Food with Friends의 허브 페이지에 앱 바를 만든다면 새로운 저녁 식사 계획을 작성하는 기능은 무조건 들어가야 하니까 이 기능을 앱 바로 만들어야겠죠.

Food with Friends 앱 허브 페이지의 앱 바그림 5: Food with friends 앱 바

HTML

HTML로 간단하게 표준 앱 바를 만들 수 있습니다. AppBar 컨트롤을 만든 후 그 안에 AppBarCommand 컨트롤을 넣고 적절한 속성을 설정하면 끝입니다. 새로운 스타일과 일치하는 아이콘 목록을 이미 만들어 놓아 바로 사용할 수 있는 AppBarIcons 열거를 사용하면 이 작업이 훨씬 간단해집니다.

<div id="foodWithFriendsAppBar" data-win-control="WinJS.UI.AppBar">
<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'cmdAdd',
label:'New plan',
icon:'add',
section:'global',
tooltip:'Create a new plan'}"
>
</button>
</div>

XAML

XAML로 AppBar를 만들려면 AppBar 요소를 인스턴스화하고 AppBar를 표시하려는 위치에 따라 페이지 개체에서 BottomAppBar 또는 TopAppBar 속성으로 설정합니다. 그런 다음 Windows 스토어 앱용 기본 Visual Studio 프로젝트 템플릿에 제공되는 기본 스타일을 사용하여 AppBar에 단추를 추가합니다. XAML에서는 개발자가 원하는 레이아웃 패널 내에서 단추를 배치하여 AppBar의 단추 레이아웃을 결정할 수 있습니다.

<Page.BottomAppBar>
<AppBar>
<Grid>
<StackPanel Orientation="Horizontal" HorizontalAlignment="Right">
<Button Style="{StaticResource AddAppBarButtonStyle}"
AutomationProperites.Name="New plan"/>
</StackPanel>
</Grid>
</AppBar>
</Page.BottomAppBar>

앱 바에 들어갈 수 있는 컨트롤

앱 바에서 흔히 볼 수 있는 명령은 단추와 전환 단추이며 JS의 경우에는 플라이아웃도 자주 볼 수 있습니다. Release Preview의 메일 앱에 들어간 앱 바를 예로 들어 각 명령 유형을 살펴보겠습니다.

표준 단추, 전환 단추 및 플라이아웃을 사용한 메일 앱 바입니다. [More](자세히) 단추는 메뉴 실행, [글꼴] 단추는 플라이아웃 실행, [밑줄] 단추는 전환

그림 6: 메일 앱 바

메일 앱 바는 표준 단추(붙여넣기), 전환 단추(굵게, 기울임꼴, 밑줄), 메뉴 실행 단추(More(자세히)) 및 사용자 지정 플라이아웃(글꼴, 글꼴 색, 강조 표시)을 보여 주는 좋은 예입니다. JS로 이러한 단추 유형을 만드는 방법은 AppBarCommand 개체를 참조하시기 바랍니다. XAML의 경우 프로젝트 템플릿의 스타일을 따르고 플라이아웃의 경우 해제 동작이 가벼운 팝업 클래스를 사용하십시오.

앱 바 컨텍스트화

주문형 UI가 제대로 작동하려면 사용자가 UI를 찾을 위치를 정확하게 알고 있어야 합니다. 사용자가 앱의 모든 모서리를 돌아다니면서 확인하거나 모든 UI를 일일이 눌러서 숨겨진 다음 명령을 찾아야 한다면 그 앱은 사용자로부터 외면될 것입니다. 그렇기 때문에 훌륭한 앱 바를 만들려면 사용 가능한 모든 명령을 적시에 표시할 수 있어야 합니다. 관련 명령은 현재 페이지, 현재 선택 항목 또는 앱 상태를 바꾸는 모든 요소에 따라 달라질 수 있습니다. 전체적으로 사용 가능한 명령(항상 작동하므로)과 현재 상황에서만 사용할 수 있는 명령을 포함하여 모든 관련 명령을 표시해야 합니다. 예를 들어 아무 것도 선택하지 않은 상태에서 시작 화면을 마우스 오른쪽 단추로 클릭하면 앱 바에 모든 앱 단추만 표시됩니다.

시작 화면 앱 바

그림 7: 시작 화면 앱 바

타일을 마우스 오른쪽 단추로 클릭하여 선택하면 앱 바의 평상시 위치에 모든 앱 단추가 표시되고 왼쪽에는 타일별 명령이 표시됩니다.

타일별 명령이 표시된 시작 화면 앱 바

그림 8: 타일별 명령이 표시된 시작 화면 앱 바

모든 관련 명령을 표시한다면 사용자는 화면의 아무 곳을 마우스 오른쪽 단추로 클릭하여 모든 주문형 UI를 사용할 수 있습니다. 사용자는 실수로 타일을 선택하는 일이 없도록 주의하기만 하면 현재 위치에 신경 쓰지 않고 자유롭게 시작 화면을 마우스 오른쪽 단추로 클릭해도 됩니다. 나타났다가 사라지는 명령을 왼쪽에 배치함으로써(오른쪽에서 왼쪽으로 읽는 언어의 경우에는 오른쪽에 배치) 사용자는 현재 선택한 항목에 대해 어떤 일을 할 수 있는지 예측할 수 있습니다. 사용자는 아무 곳을 마우스 오른쪽 단추로 클릭하면 사용 가능한 모든 명령이 표시되고, 현재 선택한 항목에 한정된 기능은 왼쪽에 표시된다는 것을 알 수 있습니다.

나타났다가 사라지는 상황별 명령을 왼쪽에 배치한 이유는 인체 공학적 설계 때문입니다. 우리는 연구를 통해 대부분의 사용자가 터치 장치를 오른손으로 작동한다는 사실을 발견했습니다. 심지어 왼손잡이도 마찬가지였습니다. 선택 항목별 명령이 오른쪽에 표시된다면 오른손을 들어서 항목을 선택해야 하기 때문에 방금 나타난 명령을 손으로 가리게 됩니다. 이와 마찬가지로 대부분의 사용자가 터치 장치를 오른손으로 조작한다는 연구 결과에 따라 항상 표시되는 명령을 오른쪽에 배치하여 사용자가 오른손으로 바로 사용할 수 있도록 했습니다. 따라서 나타났다가 사라지는 명령은 왼쪽에, 특정 화면에 항상 나타나는 명령은 오른쪽에 배치하여 사용자가 보다 편하게 터치할 수 있도록 배려했습니다.

이 화면은 Food with Friends 허브 페이지에서 아무 것도 선택하지 않은 경우의 기본 앱 바입니다.

Food with Friends 허브 페이지에서 아무 것도 선택하지 않은 상태의 앱 바

그림 9: Food with Friends 허브 페이지에서 아무 것도 선택하지 않은 상태의 앱 바

레스토랑을 선택하면 해당 레스토랑을 희망 목록에 추가하거나 희망 목록에서 제거할 수 있어야 합니다. 따라서
레스토랑을 선택하면 앱 바에 희망 목록 전환 단추가 나타납니다.

Food with Friends 허브 페이지에서 이벤트 하나를 선택한 상태의 앱 바

그림 10: Food with Friends 허브 페이지에서 이벤트 하나를 선택한 상태의 앱 바

시작 화면과 마찬가지로 선택 항목에 따라 나타났다가 사라지는 명령을 왼쪽에 배치하여 항상 표시되는 새 계획 명령과 완전히 분리했습니다.

다음은 앱 바의 서로 다른 영역에 명령을 배치하는 방법과 명령이 나타났다가 사라지게 만드는 방법입니다.

HTML

명령을 왼쪽에 배치하려면 해당 명령을 선택 섹션으로 가져��니다. 기본적으로 명령을 숨기려면 숨김 속성을 참으로 설정합니다. extraclass 속성을 사용하면 간편하게 코드의 명령 집합을 참조할 수 있으므로 extraclass 속성을 사용하여 이벤트 선택 시 같이 표시되어야 하는 명령을 클러스터링합니다.

<div id="foodWithFriendsAppBar" data-win-control="WinJS.UI.AppBar">
<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'cmdAdd',
label:'New plan',
icon:'add',
section:'global'"
>
</button>

<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'cmdWishlist',
label:'Wishlist',
icon:'favorite',
section:'selection',
hidden:'true',
extraClass:'restaurantSelection'}"
>
</button>
</div>

앱 바에서 명령을 동적으로 표시하고 숨기려면 다음을 호출합니다.

var restaurantSelectionCommands = document.querySelectorAll(".restaurantSelection");
appbar.showCommands(restaurantSelectionCommands);

앱 바에 제공되는 모든 아이콘을 검색하려면 AppBarIcon 열거를 참조하시기 바랍니다. AppBarCommand 속성 전체 목록은 WinJS.UI.AppBarCommand 개체에서 확인할 수 있습니다.

XAML

XAML AppBar는 기본적으로 단추 레이아웃을 관리하지 않기 때문에 왼쪽 및 오른쪽 명령 섹션을 사용하는 사전 설정된 레이아웃을 따르려면 필요한 레이아웃 패널을 제공하여 단추를 호스팅해야 합니다. 그리고 다음과 같은 방법으로 열이 2개 있고 각 열이 AppBar의 절반을 점유하는 Grid를 사용합니다. 그런 다음 2개의 StackPanels을 추가하여 하나는 왼쪽, 다른 하나는 오른쪽에 정렬하고 단추를 넣습니다.

각 단추의 Visibility(표시) 속성을 설정하여 간단하게 XAML AppBar 단추를 표시하거나 숨길 수 있지만 이 작업만으로 단추가 적절하게 애니메이션 적용 또는 애니메이션 해제되는 것은 아닙니다. HTML AppBar의 애니메이션 적용 및 애니메이션 해제 동작을 일치시키려면 AppBar 단추를 호스팅하는 각 패널의 ChildrenTransitions 속성에 AddDeleteThemeTransition을 추가해야 합니다. 그런 다음 이 전환 애니메이션을 실행하려면 실제로 AppBar에 단추를 추가하거나 AppBar에서 단추를 제거해야 합니다.

<Page.BottomAppBar>
<AppBar x:Name="BottomAppBar1" IsSticky="True">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="50*"/>
<ColumnDefinition Width="50*"/>
</Grid.ColumnDefinitions>
<StackPanel x:Name="LeftPanel" Orientation="Horizontal" Grid.Column="0" HorizontalAlignment="Left">
<StackPanel.ChildrenTransitions>
<TransitionCollection>
<AddDeleteThemeTransition/>
</TransitionCollection>
</StackPanel.ChildrenTransitions>
</StackPanel>
<StackPanel x:Name="RightPanel" Orientation="Horizontal" Grid.Column="1" HorizontalAlignment="Right">
<Button x:Name="New" Style="{StaticResource AddAppBarButtonStyle}" AutomationProperties.Name="New" Tag="New"/>
<StackPanel.ChildrenTransitions>
<TransitionCollection>
<AddDeleteThemeTransition/>
</TransitionCollection>
</StackPanel.ChildrenTransitions>
</StackPanel>
</Grid>
</AppBar>
</Page.BottomAppBar>

private void AddEventSelectionCommands(object sender, RoutedEventArgs e)
{
Button inButton = new Button();
Button vetoButton = new Button();
Button mehButton = new Button();

inButton.Style = App.Current.Resources["AcceptAppBarButtonStyle"] as Style;
inButton.AutomationProperties.Name = "In";
vetoButton.Style = App.Current.Resources["CancelAppBarButtonStyle"] as Style;
vetoButton.AutomationProperties.Name = "Veto";
mehButton.Style = App.Current.Resources["HelpAppBarButtonStyle"] as Style;
mehButton.AutomationProperties.Name = "Meh";

// Make it the second item
LeftPanel.Children.Insert(1, inButton);
LeftPanel.Children.Insert(2, vetoButton);
LeftPanel.Children.Insert(3, mehButton);
}

필요할 때 바로 제공

상황별 앱 바를 만드는 과정 중 하나로 사용자가 필요로 할 때 나타나도록 해야 합니다. 예를 들어 사용자가 시작 화면에서 손가락으로 타일을 아래로 살짝 밀거나, 타일을 마우스 오른쪽 단추로 클릭하거나, 타일을 Ctrl+스페이스 키로 눌러 타일을 선택하면 사용자가 선택을 취소할 때까지 앱 바가 자동으로 표시되어야 합니다. 사용자는 어떤 '작업을 수행하기 위해' 타일을 선택합니다. 앱 바는 작업을 수행하는 위치이므로 사용자가 타일을 선택하면 앱 바를 표시해 주어야 합니다. 이와 마찬가지로 사용자가 메일을 작성하는 동안 텍스트를 선택하면 메일 앱 바에 복사/붙여넣기 명령과 서식 지정 명령이 표시됩니다. 사용자가 어떤 작업을 수행하기 위해 텍스트를 선택했을 가능성이 높기 때문입니다.

일반적으로 앱 바는 해제 동작이 가볍습니다. 다시 말해서 사용자가 앱 바의 외부 영역을 탭하면 앱 바가 사라집니다. 어떤 항목을 선택하여 프로그래밍 방식으로 앱 바를 불러올 때마다 앱 바의 해제 동작을 비활성화하여 고정하는 것이 중요합니다. 이렇게 해야만 사용자가 어떤 작업을 마친 후에도 앱 바가 사라지지 않기 때문에 사용자가 선택 항목을 변경하거나 추가 항목을 선택할 수 있습니다. 항목 선택이 취소되면 해제 동작을 다시 활성화해야 합니다.

HTML

다음은 선택되는 개체를 처리하는 코드입니다.

var restaurantSelectionCommands = document.querySelectorAll(".restaurantSelection");
appbar.showCommands(restaurantSelectionCommands);
appbar.sticky = true;
appbar.show();

When the selection is cleared, you would write the inverse code:
var restaurantSelectionCommands = document.querySelectorAll(".restaurantSelection");
appbar.hideCommands(restaurantSelectionCommands);
appbar.sticky = false;
appbar.hide();

선택 항목에 따라 상황별 명령을 제공하는 앱 바를 표시하고 숨기는 작업 예를 보려면 HTML AppBar 컨트롤 샘플을 참조하시기 바랍니다.

XAML

XAML에서는 목록에 SelectionChanged 처리기를 사용하여 항목이 선택되었는지 또는 항목 선택이 취소되었는지 여부를 확인할 수 있습니다. 항목이 선택되면 메서드를 호출하여 명령을 표시하고, AppBar의 IsSticky 속성을 참으로 설정한 다음 AppBar를 표시합니다. 항목 선택이 취소되면 메서드를 호출하여 명령을 숨기고, AppBar의 IsSticky 속성을 다시 거짓으로 복원한 다음 AppBar를 ���습니다.

private void RestaurantList_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
ListView lv = sender as ListView;
if (lv.SelectedItem != null)
{
ShowRestaurantCommands();
BottomAppBar.IsSticky = true;
BottomAppBar.IsOpen = true;
}
else
{
HideRestaurantCommands();
BottomAppBar.IsSticky = false;
BottomAppBar.IsOpen = false;
}
}

명령 레이아웃

다음은 명령의 레이아웃을 결정하는 단계입니다. 명령을 배치하기에 가장 좋은 위치는 화면의 왼쪽과 오른쪽입니다. 터치를 사용할 경우 대부분의 사용자가 태블릿의 옆면을 잡고 사용하기 때문에 명령을 가장자리에 배치하면 사용자가 손의 위치를 변경하지 않고 손가락으로 명령을 사용할 수 있습니다. 마우스를 사용할 경우 피츠의 법칙에 따라 사용자는 커서를 아래쪽 모서리로 이동하는 동작을 가장 편하게 느끼고 신속하게 수행할 수 있기 때문에 명령이 가장자리와 가까울수록 사용하기 편리합니다.

이제 어떤 명령을 어디에 배치할 것인지, 어떤 기준에 따라 왼쪽에 배치할 명령과 오른쪽에 배치할 명령을 나눌 것인지만 결정하면 됩니다. 여기에 대해서는 Metro 스타일 앱의 명령 디자인에서 자세히 살펴보겠지만 간략히 설명하자면 앱 바 디자인의 모든 요소가 그렇듯이 예측 가능한 위치에 명령을 배치해야 합니다. 가장 많이 사용되는 화면과 명령의 레이아웃부터 시작하되 위치를 잘 잡아야 합니다. 레이아웃의 제 1법칙은 가장 많이 사용되는 명령을 가장자리와 가장 가깝게 배치하는 것입니다. 많은 인기를 끌고 있는 다른 앱의 명령 레이아웃을 따라하는 것도 좋은 방법입니다. 이러한 방식을 따르면 사용자는 앱을 사용하기도 전에 작동 방식을 예측할 수 있습니다. 그런 다음 후속 화면에서 공유 명령은 같은 위치를 유지하고 나머지 명령은 그 주변에 배치합니다. 명령이 홈으로 사용하는 위치가 있으면 배치를 변경하지 마세요. 이렇게 하면 사용자는 명령이 어디에 있는지 쉽게 익히고 본능적으로 앱을 사용할 수 있으며, 앱의 주요 콘텐츠에 몰입할 수 있습니다.

항목 선택 또는 앱의 현재 상황에 따라 명령이 나타났다가 사라지는 경우가 많이 있습니다. 예를 들어 Food with Friends의 레스토랑 목록 페이지에는 레스토랑 목록을 볼 때에만 표시되는 명령이 몇 개 있고(예: 정렬) 지도 보기에서만 사용 가능한 명령이 있습니다(예: 현재 지도 위치를 중앙에 표시). 이러한 경우 두 상황에서 모두 표시되는 명령을 가장자리에 가깝게 배치하면 사용자가 두 항목 간에 전환해도 명령 위치가 바뀌지 않습니다.

Food with Friends의 모든 레스토랑 페이지에서 사용자는 목록 보기와 지도 보기 간에 전환할 수 있습니다. 보기가 변경되면 사용 가능한 명령도 바뀌기 대문에 배치가 매우 중요합니다.

Food with Friends 목록 보기의 모든 레스토랑 페이지입니다. 현재 보기에 종속된 모든 명령은 보기 전환 명령 옆에 배치되어 있습니다. 새로 만들기는 꾸준히 사용되는 명령이기 때문에 오른쪽에 표시됩니다.

그림 11: Food with Friends 목록 보기의 모든 레스토랑 페이지

  Food with Friends 지도 보기의 모든 레스토랑 페이지입니다. 현재 보기에 종속된 모든 명령은 보기 전환 명령 옆에 배치되어 있습니다. 새로 만들기는 꾸준히 사용되는 명령이기 때문에 오른쪽에 표시됩니다.

그림 12: 지도 보기의 모든 레스토랑 페이지 

목록 보기에서 필터 명령이 정렬 명령 왼쪽에 배치되고 지도 스타일 단추가 지도 보기에 배치된 이유를 이해하시겠습니까? 이렇게 하면 사용자가 두 보기 간에 전환해도 모든 공통 명령이 위치를 바꾸지 않고 홈에 머물러 있기 때문에 앱 바가 안정적이고 예측 가능합니다.

보기 전환

앱의 가로 방향부터 명령 배치를 시작하는 것이 기본이지만 앱 바의 세로 방향 모양과 앱을 동시 보기로 표시했을 때 보이는 모양에도 신경을 써야 합니다. 기본적으로 WinJS 앱 바는 사용 가능한 너비에 따라 자동으로 명령을 재배치하여 언제나 최대 10개의 명령을 화면에 딱 맞게 표시합니다. 세로 방향으로는 앱 바가 명령 레이블을 끌어 오고 동시 보기에서는 단추가 2개의 행에 배치됩니다. 이러한 작업은 자동으로 수행되며 보기를 전환해도 앱 콘텐츠가 바뀌지 않을 때 활용하면 매우 좋은 기능입니다.

XAML 앱 바를 사용하거나 WinJS 앱 바의 사용자 지정 레이아웃을 사용할 경우 콘텐츠 및 명령의 레이아웃을 전적으로 개발자가 제어해야 합니다. 즉, 세로 방향과 동기 보기에서 모든 명령이 화면에 딱 맞게 표시되도록 세심한 주의가 필요합니다. 이러한 경우 모든 단추 레이블을 끌어 오고, 명령을 메뉴로 그룹화하고, 해당 상태와 관련이 없는 명령을 숨기는 전략을 사용하는 것이 좋습니다.

동시 보기의 한 메뉴에 목록 보기와 지도 보기 옵션을 모두 배치

그림 13: 동시 보기로 표시한 모든 레스토랑 지도 보기

Food with Friends 앱은 동시 보기에서 앱 바의 모양을 완벽하게 갖추면서도 모든 관련 명령을 유지하는 방법을 볼 수 있는 좋은 사례입니다. 이 예에서 단추가 행 하나에 모두 표시되도록 단추 개수를 5개로 줄이면 목록 보기와 지도 보기가 전환됩니다.

            

나만의 앱 만들기

AppBar 컨트롤을 사용하면 간편하게 기본 앱 바를 만들 수 있습니다. 또한 앱 스타일에 딱 맞게 컨트롤을 손쉽게 사용자 지정할 수 있습니다. 일반적인 사용자 지정 작업으로 단추의 색, 모양 또는 스타일을 변경할 수 있습니다. 여러분의 창의력을 발휘해 보시기 바랍니다. 앱 바는 앱이 자연스럽게 확장되는 느낌을 주어야 하므로 앱의 나머지 부분과 같은 분위기를 연출해야 합니다. 여기에 대한 예는 HTML AppBar 컨트롤 샘플XAML AppBar 컨트롤 샘플에서 찾을 수 있습니다.

사용하는 명령에 따라 앱 바와 전혀 다른 방식의 주문형 UI를 표시하는 것도 고려해 볼 수 있습니다. 여러분에게 매우 좋은 경험이 될 테니 마음껏 창의력을 발휘해 보세요. 단, 사용자는 화면 위/아래에서 살짝 밀기, 오른쪽 단추 클릭 또는 Windows+Z 키를 누르는 표준 동작을 수행할 때 숨겨진 UI가 표시될 것으로 기대한다는 점과 개발자는 UI를 분리하여 앱 바를 해제할 수 있다는 두 가지 사실을 꼭 기억해야 합니다. 표준 주문형 UI 이벤트에 대한 자세한 내용은 EdgeGesture 클래스를 참조하시기 바랍니다.

결론

새로운 디자인의 대부분이 앱의 가장 뛰어난 장점에 집중되어 있습니다. 여러분의 앱을 다른 앱과 차별화하는 요소를 강조하고 그 외에 앱 몰입도를 방해하는 요소는 주문형으로 처리하여 제한해야 합니다. 앱 바를 사용하여 명령 배치 및 앱 바의 컨텍스트화에 대해 일반적으로 통용되는 원칙을 따른다면 사용자가 명령 레이아웃을 파악하느라 고생하는 일 없이 앱의 차별화 요소에 푹 빠져서 앱을 마음껏 즐길 수 있습니다. Windows 8에서 제공하는 도구와 원칙을 사용하여 앱의 가장 큰 장점에 배치할 UI에 집중한다면 사용자로부터 좋은 앱이라는 평가를 받을 수 있습니다.

주문형 UI의 규칙에 대한 자세한 내용은 http://design.windows.com앱 바 관련 지침을 참조하시기 바랍니다. JS의 AppBar 컨트롤에 대한 자세한 내용은 HTML AppBar 컨트롤 샘플, XAML AppBar 컨트롤 샘플, WinJS.UI.AppBar 개체Windows.UI.Xaml.Controls.AppBar 클래스에서 확인할 수 있습니다.

그럼 멋진 앱을 만들어 보시기 바랍니다!

- 수석 Windows 프로그램 관리자, Jon Gordner

  • Loading...
Leave a Comment
  • Please add 3 and 8 and type the answer here:
  • Post