테이블 뷰

테이블 뷰는 하나의 열에서 여러 행을 사용하여 데이터를 보여준다. 각각의 행에는 텍스트나 이미지, 컨트롤을 같이 사용할 수 있으며, 여러 행들을 섹션 혹은 그룹으로 나눌 수 있다. 사용자는 뷰를 드래그 하거나 휙 튕겨서 행을 스크롤 할 수 있다.

<그림 8-1> 여러 가지 테이블 뷰

1. 사용

테이블 뷰는 아이폰 어플리케이션에서 극히 유용한데, 왜냐하면 정보의 규모에 상관없이 그것을 조직화하는 매력적인 방법을 제공하기 때문이다. 테이블 뷰는 특히 많은 아이템을 다루는 작업형 어플리케이션에서 가장 유용하며, 유틸리티 어플리케이션에서도 소규모의 테이블 뷰를 사용할 수 있다. 몰입형 어플리케이션에서는 정보를 표시하기 위해 테이블 뷰를 사용하지는 않겠지만, 짧은 옵션 목록을 보여주기 위해 테이블 뷰를 사용할 수도 있다.

테이블 뷰는 정보를 탐색하고 조작하기 위해 다음과 같은 요소들을 제공한다.

목록 아이템 변경에 대한 애니메이션 여부를 지정할 수도 있다. 이렇게 하는 것은 사용자가 직접 조작하고 있는 것 같은 피드백을 줄 수 있는 좋은 방법이다. 예를 들어 설정에서 '자동으로 날짜와 시간 설정' 항목을 끄면 해당 그룹이 자연스럽게 벌어지면서 새로운 두 개의 항목이 나타난다.

테이블 뷰는 사용자가 목록 아이템을 선택했을때 해당 행이 하이라이트 되는 피드백을 주며, 그 즉시 액션이 실행된다. 즉, 새로운 뷰가 나타나거나 아이템이 선택되었음을 표시하기 위해 체크 표시가 보여진다. 이처럼 선택이 된 후에 처리를 하지, 선택이 되고 있는 상태를 지속하는 것은 아니기 때문에, 행은 하이라이트 된 채로 남아있으면 안된다.

행을 눌러서 다른 화면으로 이동하는 경우에는 새로운 화면이 슬라이드되어 나타나는 동안 선택된 행이 하이라이트 되어 있으며, 다시 이전 화면으로 돌아올 때에는 앞서 선택했던 행이 잠깐동안 하이라이트된 채로 나타남으로써 사용자가 이전에 선택했던 것이 무엇이었는지를 알 수 있게 한다.

테이블 뷰는 모양에 따라 두 가지로 나뉜다.

테이블 뷰는 다양한 UI요소들을 이용하여 다음과 같은 다양한 사용자 액션을 제공한다.

2. 일반형 테이블 뷰 구성

일반형 테이블 뷰를 가장 단순하게 구성하면 목록 아이템만을 보여주며, 목록 아이템은 텍스트나 이미지, 혹은 더보기 표시와 같은 테이블 뷰 요소들을 가질 수 있다.

<그림 8-2> 단순한 일반형 테이블 뷰

계층 구조의 정보를 테이블 뷰로 보여줄 때는 더보기 표시가 필요하며, 사용자는 이 표시가 "해당 정보의 다음 페이지를 보여준다"고 이미 알고 있다. 더보기 표시는 하위 목록을 가진 아이템의 오른쪽에 보여져야 한다.

그러나 선택 기능으로서 테이블 뷰를 사용한다면 더 보기 표시가 반드시 필요하지는 않다. 선택 목록이 계층 구조형일 경우는 드물기 때문이다. 다만 사용자가 선택한 옵션 옆에는 체크 표시를 보여주어야 하는데, 이를 통해 사용자는 현재 선택된 것이 무엇인지 알 수 있다.

앞서 언급했던 것처럼, 사용자가 선택 가능한 행을 선택했을때 테이블 뷰는 자동으로 하이라이트된다. 이러한 하이라이트는 사용자가 어느 것을 선택했고 해당 선택이 진행된다는 것을 알 수 있게 하는 피드백이다. 목록에서 현재 선택된 것을 가리키기 위해 하이라이트를 지속시켜서는 안되며, 대신 체크 표시를 사용하도록 한다.

아이템 목록을 섹션별로 나눌 경우에는 섹션 헤더를 표시하여 섹션을 설명하고 시각적으로 각각의 섹션을 분리할 수 있다. 보통 목록이 긴 경우나 아이템들이 카테고리 별로 나뉘어 있을 때 사용한다.

<그림 8-3> 인덱스를 가진 테이블 뷰

일반적으로는 목록 상의 아이템이 두 개 화면 분량을 넘길 때 인덱스 뷰 사용을 고려해야 한다. 목록의 내용이 그렇게 길지 않을 때는 인덱스 뷰 없이 섹션 헤더로 정보를 표시한다.

<그림 8-4> 인덱스 뷰가 없는 섹션 구분

인덱스 뷰를 사용할 때는 그것을 방해할 수 있기 때문에, 오른쪽에 더보기 표시 같은 테이블 요소의 사용을 피해야 한다.

필요하다면 테이블 뷰의 시작 부분(첫번째 아이템 위)에 헤더를 표시할 수 있다. 그림 8-5는 그 예이다. 

<그림 8-5> 테이블 헤더

3. 그룹형 테이블 뷰 구성

그룹형 테이블 뷰에서는 적어도 하나의 그룹을 가지며, 각각의 그룹은 적어도 하나의 아이템을 가진다. 목록 아이템은 텍스트나 이미지, 혹은 테이블 뷰 요소를 포함할 수 있다.

<그림 8-6> 네 개의 그룹을 가진 그룹형 테이블 뷰

<그림 8-7> 하나의 그룹을 가진 그룹형 테이블 뷰

4. 테이블 뷰 요소

일반적으로 사용자는 목록 아이템의 어느 곳이라도 눌러서 선택할 수 있다. 그 외에도 테이블 뷰는 아이템에 대한 더 자세한 정보를 보거나 아이템을 삭제하기 위한 추가적인 몇 가지 요소들을 제공한다. 이러한 테이블 뷰 요소들(table-view elements)은 모든 아이폰 어플리케이션에서 일관되게 사용되며, 사용자들은 이 요소들의 모양과 의미에 익숙해져 있다. 테이블 뷰는 다음과 같은 요소들을 제공한다.

<그림 8-8> 삭제 컨트롤과 삭제 버튼

더보기 표시를 제외한 다른 요소들은 목록 아이템의 선택과는 별도의 액션을 수행할 수 있다.

5. 스위치 컨트롤

스위치 컨트롤은 yes/no 또는 on/off 처럼 서로 반대되는 둘 중의 하나를 선택할 때 사용한다. 임의의 상태에서 사용자는 어느 한쪽의 선택에 대한 표시만 확인할 수 있으며, 컨트롤을 슬라이드하면 가려져 있던 쪽을 볼 수 있다. 이렇게 스위치 컨트롤은 어느 한쪽이 항상 가려져 있기 때문에 사용자가 양쪽 값을 이미 알고 있을 때 사용하는 것이 좋다. 즉, 사용자가 단지 어떤 옵션이 있는지 확인하려고 스위치를 이동시키지 않게 한다.

스위치 컨트롤은 뷰에서 UI의 상태를 변경하기 위해 사용할 수도 있다. 사용자가 어떤 선택을 하면 새로운 행이 나타나거나 사라질 수도 있고, 활성화 혹은 비활성화 될 수도 있다.

<그림 8-9> 스위치 컨트롤

텍스트 뷰

텍스트 뷰는 여러 줄에 걸친 텍스트를 보여줄 수 있는 영역이다. 스크롤 뷰를 상속받았기 때문에 컨텐츠가 영역보다 커지면 스크롤이 가능하다. 예를 들면, 메일 어플리케이션에서 메일 작성의 마지막에 나타나는 서명 란에는 텍스트 뷰가 사용되고 있다.

<그림 8-10> 텍스트 뷰

편집 가능한 텍스트 뷰에서는 텍스트 뷰 안쪽을 눌렀을 때 키보드가 나타난다.

텍스트 뷰의 폰트, 컬러, 정렬은 변경이 가능하지만 개별 텍스트에 대한 적용은 불가능하며 전체 텍스트에 적용된다. 기본 값은 가독성이 가장 좋은 시스템 폰트에 검정 색이며, 기본 텍스트 정렬은 왼쪽 정렬이다. 텍스트에 다양한 폰트나 컬러 등을 적용하려면 웹 뷰를 사용하여 HTML로 스타일을 줄 수 있다.

웹 뷰

웹 뷰는 어플리케이션 화면에 풍부한 HTML 컨텐츠를 보여줄 때 사용한다. 예를 들면, 메일 어플리케이션에서는 메일 내용을 보여줄 때 웹 뷰를 사용한다.

<그림 8-11> 웹 뷰

웹 뷰는 웹 컨텐츠를 보여주기만 할 뿐 아니라 웹 페이지를 열어 탐색을 할 수 있는 요소들을 제공한다. 그러나 어플리케이션이 미니 웹 브라우저처럼 보이거나 동작하게 하는 것은 피하는 것이 좋다.

웹 뷰를 사용하면 웹 페이지나 웹 어플리케이션을 감싸는 간단한 아이폰 어플리케이션을 구현할 수 있다. 아이폰과 호환되는 최적화된 웹 컨텐츠를 만들기 위해서는 Safari Web Content Guide for iPhone OS를 참고한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

얼럿, 액션 시트, 모달 뷰는 사용자의 주의를 끌어야 할때, 혹은 추가적인 선택이나 기능을 제공해야 할 때 사용한다.

<그림 7-1> 액션 시트, 모달 뷰, 얼럿

동작

얼럿과 액션 시트, 모달 뷰는 모두 모달(modal)이다. 모달이라는 것은 사용자가 어플리케이션을 계속 사용하기 위해 명시적으로 버튼을 눌러 해당 뷰를 사라지게 해야 하는 것을 말한다. 물론 가끔은 사용자들에게 해당 액션의 위험성을 경고하거나 추가적인 선택을 제공하기 위해 이들이 필요할 수도 있지만 지나친 사용은 피해야 한다. 그 이유는 다음과 같다.

특히, 얼럿은 드물게 사용해야 한다. 얼럿이 너무 자주 나타나면 사용자는 그것을 사라지게 하는데 더 급급하게 되어 내용을 잘 읽어보지 않게 된다.

얼럿, 액션 시트, 모달 뷰는 서로 다른 목적의 커뮤니케이션을 위해 고안되었다.

이러한 뷰들은 그 외형이나 동작에서도 차이를 보이는데 이것은 그들이 보내는 메시지가 서로 다르다는 것을 강조한다. 사용자들은 이러한 뷰들의 외형이나 동작에 익숙해져 있기 때문에 이것을 일관적으로 또 정확하게 사용하는 것이 중요하다.

얼럿

얼럿은 어플리케이션 화면의 중앙에서 튀어 나와 현재 뷰의 앞에 떠있게(float) 되며, 중요한 정보를 매우 눈에 띄는 방법으로 보여준다. 얼럿이 기존 뷰와 접점을 가지지 않고 떠있다는 것은, 그것이 뜨는 이유가 어플리케이션이나 기기의 어떤 변경 사항으로 인한 것이지, 사용자의 최근 액션에 의한 것일 필요는 없다는 사실을 강조한다. 얼럿은 상황을 설명하는 텍스트를 제공해야 하며, 사용자에게 적절한 대체 액션을 제공하는 것이 이상적이다.

얼럿은 사용자에게 위험성을 지닌 결과를 받아들일지 거부할지에 대한 선택을 제공할 때도 사용할 수 있다. 이 경우 얼럿은 두 개의 버튼을 보여줘야 한다. 하나는 작업을 계속 수행하게 하면서 얼럿을 사라지게 하는 것이고, 다른 하나는 작업을 수행하지 않게 하면서 얼럿을 사라지게 한다. 후자의 경우는 보통 "취소"라는 이름을 사용한다. 얼럿이 떠있을때 홈 버튼을 누르는 것은 취소 버튼을 누른것과 동일하다.

얼럿을 드물게 사용하면 사용자가 그것에 대해 심각하게 여기게 할 수 있다. 어플리케이션 내에서 얼럿의 사용을 최소화하고 각각의 얼럿은 치명적인 정보나 유용한 선택을 제공하는지 확인한다. 일반적으로 다음과 같은 얼럿은 피해야 한다.

액션 시트

액션 시트는 사용자가 툴바에 있는 버튼을 눌러서 시작한 작업에 관계된 일종의 선택을 표시한다. 액션 시트는 다음과 같은 상황에 적합하다.

액션 시트는 항상 화면의 아래에서부터 나타나 자신의 뷰를 덮어버린다. 그러나 액션 시트는 얼럿과는 다르게 양쪽 끝이 화면 끝에 닿아 있기 때문에 어플리케이션 및 사용자의 가장 최근 액션과의 연관성을 강화한다.

액션 시트는 사용자가 그 작업을 어떻게 완료할 것인지 선택할 수 있게 몇 개의 버튼을 제공한다. 액션 시트에는 별도의 메시지를 추가할 필요가 없는데, 이것은 현재 수행중인 작업과 버튼 레이블을 조합해보면 사용자가 어떤 선택을 할 수 있는지에 대한 충분한 컨텍스트를 제공하기 때문이다. 액션 시트는 사용자가 버튼을 누르면 사라지며, 사용자에게 선택할 수 있는 액션들을 제공해야 하기 때문에 항상 하나 이상의 버튼을 제공해야 한다.

모달 뷰

모달 뷰는 화면의 아래에서부터 나타나 항상 어플리케이션 화면 전체를 덮어버린다. 이렇게 현재 어플리케이션의 화면을 가리기 때문에 사용자는 무엇인가를 완료할 수 있는 또 다른 모드로 전환되어 들어간다는 느낌을 더 강하게 받을 수 있다.

모달 뷰에서는 텍스트를 적절하게 사용할 수 있고 작업을 수행하기 위해 필요한 컨트롤들을 제공한다. 또한 모달 뷰는 일반적으로 현재의 작업을 완료하고 뷰를 닫는 버튼과 작업 내용을 버릴 수 있는 취소 버튼을 표시한다.

모달 뷰는 액션 시트보다 더 넓은 범위의 사용자 인터랙션을 지원한다. 액션 시트는 하나의 선택만 취하지만, 모달 뷰는 여러 개의 옵션을 선택하거나 정보를 입력할 수 있는 여러 단계의 인터랙션을 지원한다.

어플리케이션의 주 기능에 관계되며 모든 것을 충족시키는 작업을 달성하기 위한 방법을 제공할 필요가 있을때 모달 뷰를 사용한다. 모달 뷰는 특히 메인 어플리케이션 UI에 없는 사용자 인터페이스 요소를 필요로 하는 여러 단계의 하위 작업을 할때 적합하다. 메일 어플리케이션의 메일 작성 뷰는 모달 뷰의 좋은 예이다.

얼럿 디자인

얼럿에서 텍스트 및 버튼 수, 버튼 내용은 지정이 가능하지만 얼럿 자체의 배경은 변경이 불가능하다.

버튼 수는 지정 가능하지만 보통은 2개짜리가 가장 유용하다. 둘 중에 하나를 선택하는 것이 사용자에게 가장 쉽기 때문이다. 한 개의 버튼을 가진 얼럿은 정보를 알려주고 그것을 닫을 수 있게만 할 뿐, 사용자로 하여금 현재 상황을 제어할 수 있게 하지는 못하기 때문에 대부분 좋은 생각이 아니다. 3개 이상의 버튼을 가진 얼럿은 2개 짜리보다 훨씬 복잡하기 때문에 가능하면 피하는 것이 좋으며, 대신 액션 시트를 사용하는 것을 고려해 보아야 한다.

얼럿에서는 가끔 사용자가 내용을 신중하게 읽어보지 않고 버튼을 누르는 경우도 있기 때문에 기본 선택 값을 적절하게 제공해야 한다. 이러한 경우를 위해 밝은 색의 오른쪽 버튼이 안전한 기본 작업을 수행하도록 만든다. 예를 들면 이 버튼을 취소 버튼으로 할 수도 있고, 혹은 결과 행위가 위험하지 않다면 가장 일반적인 반응을 표현하는 버튼으로 할 수도 있다.

얼럿의 버튼 지정은 다음 가이드를 따른다.

얼럿의 주 기능은 사용자가 예상하지 못했던 일이 벌어졌음을 알려주는 것이다. 그렇기 때문에 텍스트는 명료하게 현재의 상황을 설명하고, 가능하다면 사용자가 그에 대해 무엇인가를 할 수 있게 만들 필요가 있다. 종종 현재 상황이나 이벤트에 대한 간단한 제목만으로도 충분하다.

비록 얼럿의 제목은 짧은 것이 권장되지만 충분한 정보를 제공하지 못하는 한 단어로 이루어진 제목을 사용하면 안된다. 예를 들어, "에러"라는 제목은 특히 비효율적인 제목인데, 이러한 제목은 사용자가 왜 얼럿이 나타났는지 이해하는데 아무런 도움이 되지 못하며 어플리케이션이 좀 더 유용한 정보를 제공하지 못한다는 인상을 준다. 사실상 얼럿의 어떤 텍스트에서도 "에러"라는 단어를 사용하는 것은 피해야 하고, 대신 실제 상황을 설명하는데 초점을 맞춰야 한다.

가끔은 얼럿에 컨텍스트나 추가적인 정보에 대한 간단한 메시지를 추가하는 것이 좋을 때가 있다. 예를 들어, 어떤 이벤트나 상황이 서로 다른 원인에 의해 일어난다면 이벤트를 설명하는 동일한 제목을 사용하되, 원인에 따라 메시지를 다르게 표시하는 방법도 가능하다. 어떤 경우에는 제목이 아무런 유용한 정보를 제공하지 않을 때도 있는데, 이 경우에는 제목을 생략하고 간단한 메시지를 통해 상황을 설명할 수 있다.

<그림 7-2> 두 개의 버튼을 가진 얼럿

액션 시트 디자인

액션 시트에서는 어플리케이션과 어울리는 배경을 선택할 수 있다. 또한 버튼의 수를 지정할 수 있으며 그 내용도 지정 가능하다.

얼럿과는 달리 액션 시트는 사용자가 행한 액션의 결과로서 나타나기 때문에 굳이 그걸 설명하려고 메시지를 표시할 필요가 없다. 

액션 시트의 배경은 두 가지 중에서 선택할 수 있는데, 네비게이션 바나 툴바의 컬러와 잘 맞는 것을 선택해야 하며 하나의 어플리케이션 내의 모든 액션 시트의 배경색은 동일해야 한다. 

취소 버튼은 액션 시트의 가장 밑에 배치되어야 하는데, 이것은 사용자의 시선이 취소 버튼으로 내려가기까지 모든 선택 사항들에 대해 잘 읽어볼 수 있게 하기 위함이다.

<그림 7-3> 액션 시트

쇼핑 리스트에서 모든 항목을 삭제하는 경우와 같이 위험성을 지닌 액션을 수행하는 버튼은 빨간 색을 사용해야 한다. 이러한 버튼은 액션 시트의 가장 위에 배치하는 것이 중요한데 그 이유는 다음과 같다.

<그림 7-4> 빨간 버튼의 위치

각각의 버튼이 서로 의미가 잘 구별되는 한 여러 개의 버튼을 사용할 수 있다. 

<그림 7-5> 버튼 4개짜리 액션 시트

모달 뷰 디자인

모달 뷰의 전체적인 모습은 어플리케이션과 잘 어울려야 한다. 예를 들어 모달 뷰에서는 그 안에서의 작업에 대한 완료 및 취소 버튼을 가진 네비게이션 바를 종종 사용하는데, 이것은 어플리케이션의 네비게이션 바와 동일한 배경을 사용해야 한다.

모달 뷰는 보통 해당 작업이 무엇인지에 대한 제목을 표시해야 한다. 적절하다면 뷰의 다른 영역에 더 자세한 설명이나 일부 가이드를 텍스트로 제공할 수 있다.

<그림 7-6> 모달 뷰

모달 뷰에서는 텍스트 필드나 버튼, 테이블 뷰 등 작업을 완료할 수 있는 어떠한 컨트롤도 사용할 수 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

상태 바, 네이게이션 바, 탭 바 그리고 툴바는 반드시 모든 어플리케이션에서 보여져야 하는 것은 아니다(몰입형 어플리케이션 중에는 이들 중에 아무 것도 안보여주는 경우도 있다). 그러나 반대로 이것들을 보여주려면 올바르게 사용하는 것이 중요한데, 이것은 아이폰 사용자들이 이들이 보여주는 정보와 이들이 수행하는 기능에 적응되어 있기 때문이다.

상태 바

상태 바는 신호 세기나 현재 네트워크 접속 상태, 배터리 잔량 등과 같은 기기에 관한 중요한 정보를 제공한다.

<그림 6-1> 상태 바

비록 전체화면의 몰입형 어플리케이션은 상태 바를 안보이게 할 수 있지만 이러한 디자인을 선택하는 것은 신중해야 한다. 사용자는 현재 기기의 배터리 잔량을 확인하고 싶어하는데, 이러한 정보를 보여주지 않는 것은, 게다가 이러한 정보를 보기 위해 사용자가 어플리케이션을 종료하게 하는 것은 이상적인 사용자 경험이 아니다.

예를 들어, 사진(Photo) 어플리케이션은 개별 사진을 전체화면으로 보여주면서 상태 바, 네비게이션 바 및 툴바를 몇 초 후에 페이드 아웃시킨다. 사진 어플리케이션에서는 사용자가 사진과 인터랙션하는 것이 아닌 사진을 보는 것에 집중하기 때문에 이것이 적당하다. 또한 사용자는 화면을 한번  눌러서 이러한 컨트롤들을 다시 볼 수 있다. 

그러므로 만약 어플리케이션에서 상태 바를 보여주지 않으려면 이와 같은 방식을 따라야하며, 한번의 탭으로 컨트롤들을 다시 보여주지 않는다면 적어도 상태 바를 보여주기 위한 별도의 제스쳐는 정의하지 않는 것이 최선이다. 사용자가 쉽게 이러한 제스처를 발견하고 기억하지는 않을 것이기 때문이다.

상태 바의 모양이나 행동에 대해 다음과 같은 몇 가지 커스터마이징이 가능하다.

<그림 6-2> 상태 바의 세 가지 스타일

네비게이션 바

네비게이션 바는 상태 바의 바로 아래에 위치한다. 네비게이션 바에는 일반적으로 현재 뷰의 제목과 현재 뷰의 내용에 대한 액션을 하는 컨트롤 및 이동(네비게이션)을 위한 컨트롤이 제공된다. 네비게이션 바는 특히 정보를 계층 구조형으로 배치하는 작업형 어플리케이션에 유용하다.

네비게이션 바는 두 가지 목적을 가진다.

<그림 6-3> 네비게이션 바의 두 가지 목적

네비게이션 바는 뷰의 제목을 중앙에 보여준다. 그림 6-4처럼 작업형 어플리케이션의 초기화면에는 제목만이 표시되는데, 이것은 아직 사용자가 다른 위치로 이동하지 않았기 때문이다.

<그림 6-4> 네비게이션 바의 제목 표시

사용자가 다른 뷰로 이동하면 네비게이션 바는 새로운 뷰의 제목을 표시하고, 이전 뷰의 제목이 뒤로 가기 버튼의 레이블로 붙는다. 예를 들어, 그림 6-5는 General 설정의 카테고리 중 하나인 Date & Time 설정에 들어갔을 때 네비게이션 바의 모습이다.

<그림 6-5> 이동 컨트롤 표시

선택사항으로 제목의 오른쪽에 버튼을 하나 추가할 수 있으며, 어플리케이션이 계층구조를 지원하지 않아서 뒤로 가기 버튼이 필요하지 않다면 그 자리(제목의 왼쪽)에 뷰의 내용에 영향을 줄 수 있는 다른 버튼을 추가할 수도 있다.

<그림 6-6> 뷰 내용을 관리하는 컨트롤 표시

위 그림들에서 볼 수 있는 것 처럼 네비게이션 바의 컨트롤들은 그 주위에 홈(bezel) 처리가 되어 있다. 아이폰 OS에서는 이것을 테두리(bordered) 스타일이라 부른다. 네비게이션 바의 모든 컨트롤들은 테두리 스타일을 사용해야 한다. 실제로는 네비게이션 바에서 평면(plain) 컨트롤을 사용하면 자동으로 테두리 스타일로 바뀐다.

네비게이션 바의 버튼에는 이미지를 추가할 수도 있고, 아이폰 OS가 제공하는 미리 정의된 버튼을 사용할 수도 있다.

네비게이션 바에 표시되는 모든 텍스트들에는 폰트를 지정할 수 있지만 가독성을 최대한으로 유지하기 위해서는 시스템 폰트를 사용할 것을 권장한다. UIKit 프레임웍을 사용하여 네비게이션 바를 생성하면 자동으로 시스템 폰트가 사용된다.

툴바

어플리케이션의 현재 컨텍스트 상에서 몇 가지 액션을 제공하려 한다면 툴바가 적당하다. 툴바는 화면 맨 밑에 위치하며 현재 뷰에 있는 객체에 관계된 액션을 수행하는 버튼들을 제공한다. 어플리케이션의 서로 다른 모드들을 전환하는 경우에는 툴바를 사용하면 안된다(이 경우에는 탭 바를 사용한다).

예를 들어 Mail 어플리케이션에서 메일을 확인할 때 툴바에는 삭제, 답장, 이동 등의 컨트롤이 제공된다. 이런 식으로 사용자는 메일 확인이라는 컨텍스트에 여전히 있으면서도 메일을 관리할 수 있는 명령들에 접근할 수 있다.

그림 <6-7> 현재 컨텍스트에서의 기능 제공

툴바에서 아이템들은 동일한 간격으로 배치된다. 사용자는 자신이 원하는 아이템을 쉽게 선택하고 싶어하기 때문에 툴바의 아이템 수는 몇 개로 제한하는 것이 좋다. 사용자 인터페이스 요소의 히트 영역은 44 x 44픽셀을 권장한다는 것을 기억한다면 아이템 숫자는 5개 이하가 적당할 것이다.

그럼 <6-8> 아이템의 적당한 간격

위의 그림들에서는 아이템에 홈처리가 되어 있지 않은데, 아이폰 OS에서는 이러한 스타일을 평면(plain) 스타일이라고 부른다. 툴바에서는 테두리 스타일이나 평면 스타일 어느 것을 사용해도 괜찮지만, 하나의 툴바에서 서로 다른 스타일을 혼합하여 사용해서는 안된다.

툴바 버튼에는 이미지를 추가할 수도 있고 아이폰 OS에서 제공하는 미리 정의된 버튼을 사용할 수도 있다. 커스텀 툴바 버튼을 만들 때는 가능하면 비슷한 사이즈로 만들어서 균형잡힌 모습을 유지해야 한다.

탭 바

어플리케이션에서 똑같은 데이터 집합에 대해 서로 다른 관점을 제공하거나, 어플리케이션 전체 기능과 관계있는 서로 다른 하위 작업을 제공하려면 탭 바를 사용한다. 탭 바는 화면의 가장 하단에 위치한다.

탭 바는 어플리케이션의 서로 다른 뷰나 모드 사이를 전환할 수 있게 하며, 사용자는 어플리케이션의 어느 위치에서도 이러한 모드에 접근할 수 있어야 한다. 그러나 탭 바는 결코 현재 모드의 요소들에 대한 기능 버튼을 가지는 툴바로서 사용되어서는 안된다.

예를 들어 시계 어플리케이션에서는 탭 바를 사용하여 세계 시계, 알람, 스톱워치, 타이머라는 네 가지 기능에 접근할 수 있다. 그림 6-9에서 서로 다른 모드가 선택되었을 때 탭 바가 어떤 모습으로 유지되고 있는지를 주목한다. 이것은 사용자가 현재 어느 모드에 있는지 알기 쉽게 하며, 다른 모든 모드들로의 접근을 가능하게 한다.

<그림 6-9> 탭 바에 의한 뷰 전환

탭 바는 각 탭에 아이콘과 텍스트를 보여주며 각 탭은 검정 배경에 동일한 너비로 보여진다. 사용자 인터페이스 요소의 권장 히트 영역은 44 x 44픽셀이기 때문에 5개 이하의 탭을 보여주는 것이 적당하며, 그 이상을 보여주게 되면 사용자가 특정한 탭을 선택할 때 어려움을 겪을 것이다. 임의의 탭이 선택되면 그 탭의 배경은 밝아지며 이미지는 하이라이트된다.

<그림 6-10> 선택된 탭의 모습

사용자를 간섭하지 않고 함축된 방법으로 커뮤니케이션하기 위해 탭에 배지(badge)를 표시할 수 있다. 이러한 형태의 피드백은 사용자가 현재 컨텍스트에서 작업하는데에는 치명적이지 않으면서도 알면 유용한 정보를 전달하기 위해 적당하다. 배지는 전화 어플리케이션에서 아직 확인 안된 음성 메시지(Voicemail) 숫자를 보여주는 것 처럼, 탭의 오른쪽 위 빨간 동그라미 안에 흰색 텍스트로 표시된다. 특정 탭에 배지를 표시하는 것은 어플리케이션의 특정 모드와 배지 내의 정보를 연결한다. (참고로 써드 파티 어플리케이션은 백그라운드에서 실행될 수 없기 때문에, 홈스크린의 어플리케이션 아이콘에는 배지를 표시할 수 없다.)

<그림 6-11> 배지

아이폰 OS는 그림 6-11의 즐겨찾기(Favorites)나 최근항목(Recents)과 같이 탭 바에서 사용할 수 있는 몇 개의 아이콘을 제공한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

사용자 인터페이스 요소가 어떤 식으로 사용되게 디자인되었는지를 이해하면, 그것을 적절하게 사용할 수 있고 필요할때 알맞게 커스터마이징해서 쓸 수 있다.

어플리케이션 화면과 컨텐츠

모든 어플리케이션은 그 종류에 상관없이 하나의 어플리케이션 윈도를 가진다. 프로그램적으로 윈도는 어플리케이션의 모든 정보를 보여주기 위한 배경을 제공하지만, 사용자는 이러한 윈도에 대해서는 알지 못하며 그대신 이동할 수 있는 화면의 집합으로서 어플리케이션을 경험한다.

사용자는 대부분 어플리케이션의 화면과 기기의 화면을 동일시한다. 그러나 어플리케이션의 화면은 스크롤을 통해 기기 화면의 영역을 넘어 확장될 수 있다. 예를 들어 연락처 화면은 전화(Phone) 어플리케이션에서 기기 화면 크기의 몇 배가 넘는 길이의 목록을 보여주지만 단 하나의 화면일 뿐이다.

각각의 어플리케이션 화면은 다양한 뷰와 컨트롤의 조합으로 보여진다. 어떤 뷰들은 그 뷰에서만 볼 수 있는 특정한 컨트롤들을 가지고 있고, 어떤 컨트롤들은 다양한 뷰에서 사용될 수도 있다. 

얼럿, 액션 시트, 모달 뷰는 다른 뷰들처럼 어플리케이션 화면 안에 존재하지 않고 화면 위에 떠있는 특이한 형태의 뷰들이다.

다음은 어플리케이션 사용자 인터페이스에서 특별한 상태를 갖는 네 가지 뷰들인데, 이것들은 어플리케이션마다 보일 수도 있고 보이지 않을 수도 있다.

<그림 5-1> 어플리케이션 화면

위와 같은 네 가지 뷰를 조합하여 보여주는 어플리케이션에서 네비게이션 바와 툴 바 사이의 영역을 컨텐트 영역(content area)라고 부른다. 어플리케이션은 이 영역에 테이블 뷰나 웹 뷰와 같은 일시적인 뷰들을 보여준다.

<그림 5-2> 컨텐트 영역 뷰

앞서 언급했던 것처럼 일부 컨트롤들은 특정 뷰에서만 사용 가능하다. 예를 들면 자세히 보기 표시(disclosure indicator) 컨트롤은 테이블 뷰에서만 볼 수 있다.

뷰와 컨트롤

아이폰 OS에서 뷰와 컨트롤의 행동과 기본 모양은 UIKit이 결정한다. 가능하면 UIKit이 제공하는 표준 사용자 인터페이스 요소를 사용해야 하며 권장 사용법을 따라야 한다. 이것은 다음과 같은 점에서 중요하다.

많은 컨트롤들은 부분적으로 커스터마이징을 지원하는데 이것은 보통 텍스트나 이미지를 추가하거나 컬러를 변경하는 것이다. 몰입형 어플리케이션을 개발하고 있는 경우에는, 기본 컨트롤과 완전히 다른 컨트롤을 만드는 것이 적당하다. 왜냐하면 몰입형 어플리케이션은 자신만의 환경을 생성하며, 이러한 환경을 제어하는 법을 발견하는 것이 이러한 어플리케이션에서 기대되는 사용자 경험이기 때문이다.

그러나 일반적으로는 표준 액션을 수행하는 컨트롤의 외형을 근본적으로 바꾸는 것은 지양해야 한다. 표준 액션을 수행하기 위해 처음 보는 컨트롤을 사용하면 사용자는 그것을 사용하는 법을 발견하느라 시간을 낭비하게 될 것이고, 이 컨트롤이 표준 컨트롤에서는 볼 수 없었던 액션을 한다면 의아해 할 것이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

사운드

사용자는 아이폰에서 자신의 기호와 의도를 따르는 아주 멋진 사운드가 나길 바란다. 사용자는 가끔 설정에서 사운드가 꺼져있을때 조차도 소리가 나길 기대할 경우가 있는데, 이것은 사용자가 자신이 원하는 사운드는 듣고 싶어하고 자신이 원하지 않는 사운드는 듣고 싶어하지 않기 때문이다. 이러한 경향을 따르기 위해 아이폰 OS는 다음과 같은 기능을 지원하는 프로그래밍 인터페이스를 제공한다. 

어플리케이션에서 사운드를 어떻게 다룰지 결정하기 전에 먼저 주요 설정 상황에서 사용자가 어떤 것을 기대하는지를 이해할 필요가 있다. 

1. 벨/무음(Ring/Silent) 스위치 - 사용자가 기대하는 것

사용자는 다음과 같은 경우에 벨/무음 스위치를 사용한다.

예를 들어 극장에서는 다른 사람들을 방해하지 않기 위해 벨 소리를 끈다. 이 상황에서 사용자는 여전히 어플리케이션을 사용하고 싶어하지만 벨 소리같은 갑작스런 소리에 의해 놀라고 싶지는 않을 것이다. 

그러나 벨/무음 스위치는 사용자 액션이 직접적으로 소리에 관련된 것이거나, 사용자가 명시적으로 요청한 소리라면 이를 차단하지 않는다. 예를 들면,

이러한 특성은 사용자 컨트롤 원칙을 따른다. 사용자가 명시적으로 요청한 소리를 들려주는 것이 적당한지 아닌지를 결정하는 것은, 기기가 아닌 사용자에게 달려 있기 때문이다.

2. 볼륨 조절 버튼 - 사용자가 기대하는 것

기기에서 나는 모든 소리는 볼륨 조절 버튼을 사용해 조절할 수 있다. 이는 벨/무음 스위치가 켜져있는지 꺼져있는지에 상관없이 어떤 소리든 언제라도 음량을 줄일 수 있다는 것을 의미한다.

어떤 경우에는 어플리케이션의 사용자 인터페이스를 통해 사용자가 볼륨을 조절할 수 있게 하는 것이 적절할 수도 있다. 예를 들어, YouTube에서는 슬라이더 컨트롤을 통해 현재 보고있는 비디오의 볼륨을 조절한다. YouTube가 실행 중인 동안에는 슬라이더와 볼륨 조절 버튼 둘 다 비디오 볼륨에 영향을 미친다. 이것은 어플리케이션이 실행되는 동안 슬라이더가 볼륨 조절 버튼의 프록시 역할을 하기 때문이다. 슬라이더는 어플리케이션의 볼륨과 전체 시스템 볼륨에 영향을 미치며 벨 소리에는 영향을 미치지 않는다.

이와 마찬가지로 볼륨 조절 버튼으로 어플리케이션이 현재 재생 중인 오디오를 조절하면 전체 시스템 볼륨도 같이 조절되며, 벨 소리에는 영향을 미치지 않는다. (오디오가 재생되지 않는 상태에서는 볼륨 조절 버튼으로 벨 소리 크기를 조절할 수 있다.)

이러한 특성 역시 사용자 컨트롤의 원칙을 따르는데, 이것은 기기에서 얼마나 큰 소리가 나야할지 결정하는 것은 언제나 사용자이기 때문이다.

가끔은 어플리케이션 내에서 상대적이거나 독립적인 볼륨 레벨을 사용할 수도 있지만, 이 경우에도 최종 오디오 출력은 볼륨 조절 버튼을 사용하든 어플리케이션 컨트롤을 사용하든 상관없이 항상 시스템 볼륨을 따라야 한다. 이것은 어플리케이션의 오디오 출력에 대한 제어 권한은 언제나 사용자에게 있음을 의미한다.

3. 헤드셋과 헤드폰 - 사용자가 기대하는 것

사용자가 헤드셋이나 헤드폰을 연결한다는 것은 현재 재생중인 오디오를 계속해서 듣되 개인적으로만 듣기를 원하는 것이다. 그렇기 때문에 사용자는 오디오가 중지되지 않고 계속해서 재생되길 원할 것이다.

반대로 사용자가 헤드셋이나 헤드폰을 빼는 경우에는 자신이 듣고 있던 것이 남에게 자연스레 알려지길 원하지 않을 것이다. 그렇기 때문에 어플리케이션은 현재 오디오 재생을 중지시키고 사용자로 하여금 명시적으로 재생을 다시 시작하게 해야 한다.

4. 어플리케이션의 오디오 특성 정의

어플리케이션에서 소리를 내거나 녹을을 하려면 그 어플리케이션의 오디오 특성이 기기의 오디오 환경과 어떻게 잘 어울릴 것인가를 결정해야 한다. 대부분의 어플리케이션에서 이는 아이폰 OS가 정의한 표준 인터랙션을 받아들이는 것을 의미하는데, 이러한 인터랙션은 시스템 사운드 서비스(System Sound Services)에 의해 지원되며 시작음이나 피드백, 경고음과 같은 부수적인 사운드만을 재생하는 어플리케이션에 잘 어울린다. 

그러나 어플리케이션의 주 기능으로 오디오를 재생, 녹음 하거나 긴 사운드트랙을 재생하는 상황에서는 표준 인터랙션이 적절하지 않다. 이 경우에는 어플리케이션의 오디오가 시스템 오디오 환경과 어울리는 방식에 영향을 줄 수 있는 오디오 특성 그룹을 정의할 수 있다. 오디오 세션 서비스(Audio Session Services)로 이러한 오디오 특성을 정의할 수 있다.

어떠한 특성을 정의하더라도 전화 기능은 현재 실행 중인 어플리케이션을 중단시킬 수 있다. 모든 어플리케이션은 사용자가 걸려온 전화를 받는 것을 막아서는 안된다.

1) 시스템 사운드 서비스(System Sound Services)

어플리케이션의 기능에 부차적인 짧은 소리를 재생할 때는 시스템 사운드 서비스를 사용한다. 구체적으로 다음과 같은 경우들이 이에 해당한다.

다음은 시스템 사운드 서비스에 정의되어 있는 함수들이다.

AudioServicesPlayAlertSound는 되도록 적게 사용하도록 하고, 사용자에게 상황을 알려주는 것이 적당한 경우에만 사용하도록 한다.

2) 오디오 세션 서비스(Audio Session Services)

어플리케이션의 오디오 특성에 대한 특정 그룹을 정의하는 경우 오디오 세션 서비스를 사용한다. 다음과 같은 경우가 이에 해당한다.

간단하게 설명하면, 아이폰 OS는 오디오 세션을 사용하여 어플리케이션의 오디오가 기기에 어떻게 어울릴 것인지 결정하는 것을 도와준다. 오디오 세션을 사용하면 다음을 지정하는 것도 가능하다.

오디오 세션은 헤드셋 연결이 제거되는 것 같이 하드웨어적인 오디오 경로가 변화하는 경우나 강제 중단되는 경우에 이를 잘 처리할 수 있도록 노티피케이션을 제공한다.

어플리케이션의 오디오 특성 그룹을 정의하기 위해서는 오디오 세션 카테고리를 지정한다. 아이폰 OS는 7개의 카테고리를 제공하는데, 각각의 카테고리는 일정한 특성 그룹을 캡슐화한다. 카테고리를 적절히 지정하면 아이폰 OS가 그에 맞게 사운드를 제어해주어 사용자에게 더욱 좋은 경험을 제공할 수 있다.

대다수의 어플리케이션들은 하나의 카테고리만을 사용하며, 녹음과 재생같이 서로 매우 다른 방법으로 오디오를 사용하는 어플리케이션에 대해서만 하나 이상의 카테고리를 사용한다.

오디오 세션은 다음과 같은 오디오 프로그래밍 인터페이스에 의해 재생되는 사운드를 다룬다.

짧거나 부가적인 사운드에 대해서는 시스템 사운드 서비스를 사용할 수도 있지만, 이 경우 오디오 세션이 어떤 식으로든 시스템 사운드 서비스가 재생하고 있는 사운드를 제어하고 있지는 않는지 확인해야 한다. 

다음은 오디오 세션 카테고리에 대한 설명이다.

5. 복합적으로 사용하기

다음의 세가지 시나리오는 사용자에게 좋은 경험을 제공하기 위해 서로 다른 사운드 서비스를 어떻게 사용할 수 있는지를 보여준다.

[시나리오 1]

여러분이 블로깅 어플리케이션을 개발중이라고 가정해보자. 사용자는 텍스트와 이미지를 웹으로 올릴 수 있다. 짧은 시작음과 사용자 액션(포스팅이 완료되었을 때와 같은)에 따른 다양한 짧은 효과음들, 혹은 포스팅이 실패 했을때는 경고음을 들려주려 한다.

이러한 어플리케이션에서 사운드는 부가적이다. 주 작업은 오디오와는 아무런 관계가 없고 사용자는 소리 없이도 어플리케이션을 잘 이용할 수 있다. 이런 시나리오에서는 시스템 사운드 서비스를 사용해야 한다. 

[시나리오 2]

여러분은 새로운 언어를 학습할 수 있는 교육용 어플리케이션을 개발중이다. 어플리케이션이 시작되면 시작음을 들려주고, 사용자가 특정한 컨트롤을 누르면 피드백 사운드를 들려줄 것이다. 또한 사용자는 올바른 발음을 확인하기 위해 녹음된 단어나 문구를 들어볼 수 있다. 이렇게 서로 다른 사운드를 사용자가 기대하는 대로 들려주려면 다음을 따른다.

이렇게 하면 벨/무음 스위치가 꺼져 있는 경우 시작음이나 피드백 사운드는 들리지 않는다. 그러나 사용자가 컨텐츠를 듣기 위해 명시적으로 선택하는 경우는 그것을 들을 수 있다.

[시나리오 3]

화면상의 캐릭터가 다양한 임무를 수행하는 게임의 경우를 생각해보자. 시작음이나 효과음, 사운드트랙 등을 들려줄 수 있다. 이 경우 사용자가 기대하는 사운드를 들려주기 위해서는 다음을 따른다.

이렇게 하면 벨/무음 스위치가 꺼져 있는 경우 시작음이나 효과음, 사운드 트랙 등은 들리지 않는다. 그러나 음악(iPod)에서 노래를 재생하는 도중에 게임을 시작한다면 노래가 멈추고 사운드트랙과 효과음 등이 들린다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

시작

아이폰 어플리케이션은 사용자가 지체되지 않고 사용할 수 있게 시작 즉시 실행되어야 한다. 시작시에는 다음 사항들을 따르도록 한다.

종료

사용자가 다른 어플리케이션을 띄우거나, 전화를 받는 등의 기기 기능을 사용하면 어플리케이션은 종료된다. 여기서 중요한 것은 사용자가 어플리케이션을 종료시키기 위해 닫기 버튼을 누르거나 메뉴에서 종료를 선택하지는 않는다는 것이다. 종료시에는 다음 사항들을 따르도록 한다.

어플리케이션을 프로그램적으로 종료시키는 것은, 사용자에게는 그것이 충돌난 것처럼 보이기 때문에 절대 그렇게 해서는 안된다. 그러나 어떨때는 외부 환경으로 인해 어플리케이션의 기능을 실행시키지 못할 경우가 있는데, 이럴때는 사용자에게 현재 상태를 알리고 사용자가 무엇을 할 수 있는지 알리도록 한다. 이렇게 함으로써 사용자는 알맞는 조치를 취한 후 어플리케이션을 계속 사용할 것인지 아닌지를 선택할 수 있다.

외부 환경은 어플리케이션이 시작할때 뿐만 아니라 실행 중에도 바뀔수 있다. 어플리케이션의 주 기능을 사용할 수 없는 환경이 되었을때는 사용자에게 상황을 설명하고 무엇을 할 수 있는지 알려주는 화면을 보여주도록 한다. 예를 들어 iTunes 어플리케이션에서는 Wi-Fi가 연결되지 않았을때 왜 아이튠즈 뮤직 스토어에 접속할 수 없는지를 설명하고 어떻게 하면 이를 해결할 수 있는지 알려주는 화면을 보여준다.

<그림 4-1> 어플리케이션의 주 기능을 실행할 수 없을때

외부 환경 제약에 따른 또 다른 대안으로는 얼럿창을 표시하는 것을 들 수 있다. 예를 들어, 어플리케이션의 기능이 현재 위치를 사용하려 할 때 위치 서비스가 비활성화 되어 있다면, 얼럿창을 띄워 이것을 알려주고 사용자에게 위치서비스를 활성화 시킬 수 있는 기회를 제공하는 것이 효과적이다. 얼럿창은 디자인적인 면에서는 그리 유연성이 크지 않지만 다음과 같은 방법으로 사용하면 적당하다.

모든 얼럿은 사용자들이 그것을 덜 보게 될수록 더 효율적이다.

설정

설정(Settings)은 아이폰에 내장된 설정 어플리케이션에 의해 접근할 수 있다. 사용자는 설정을 이용하기 위해 어플리케이션을 종료해야 하기 때문에, 한번 이상 지정하게되는 설정은 피하도록 하고, 가급적이면 설정이 불필요하게 어플리케이션을 단순화시키도록 한다.

옵션(Configuration options)은 어플리케이션 내에서 제공되며, 보통은 화면의 뒷면에서 보여준다. 설정과 다르게 옵션은 자주 바뀔 수도 있다.

방향

사용자는 언제든 기기의 방향(orientation)을 돌릴 수 있으며, 현재 보고 있는 화면이 그에 따라 적절히 반응하길 기대한다. 다음 사항들을 확인하도록 하자.

예를 들어 iPod에서는 현재의 기기 방향에 상관없이 언제나 동영상을 가로 방향으로 보여준다. 이것은 사용자가 동영상을 보기 위해 물리적으로 기기를 돌려야 하는 것을 의미하는데, 중요한 것은 이러한 과정에서 iPod은 "회전" 버튼 같은 것은 제공하지 않는다는 것이며, 대신 사용자는 동영상이 가로방향으로 뜨는 것을 알기 때문에 기기를 돌린다는 것이다. 

이처럼 어플리케이션이 특정 방향으로 보여져야 한다면 사용자가 기기를 물리적으로 돌리게 하고, 사용자에게 기기를 돌리라고 하는 컨트롤이나 제스처는 사용하지 않도록 한다.

선택

아이폰 OS는 사용자가 무엇인가 선택할 수 있게 하는 몇가지 요소들을 제공한다. 이러한 방법들은 사용자가 이미 익숙해져 있기 때문에 어플리케이션에서는 이것들을 사용하도록 한다. 일반적으로는 데스크탑 어플리케이션에서 사용하는 메뉴나, 라디오 버튼과 비슷한 모양의 컨트롤 등을 만드려고 하면 안된다. 아이폰 OS에서 제공하는 선택 요소들은 다음과 같다.

약관

약관(EULA, End-User License Agreement)은 어플리케이션을 사용하기 전에 사용자가 반드시 동의해야 할 책임 한계 등을 명시한다. 이러한 약관은 사용자가 어플리케이션을 구매하기 전에 미리 확인해 볼 수 있도록 앱스토어에서 보여지기 때문에, 어플리케이션에서는 모든 경우에 대해 약관을 표시하지 않도록 한다. 다만, 이는 설치와 설치후 첫 실행의 경우에도 해당하지만, 이 경우에는 완전히 제한하지는 않는다. 또한 어플리케이션 실행중에 약관을 표시하기 위한 사용자 인터페이스 요소를 제공해서도 안된다. 이러한 가이드라인을 따르면 사용자를 방해하지 않으면서도 필요한 동의를 얻을 수 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

적절한 제스처 지원

사용자는 아이폰의 멀티 터치 인터페이스를 조작하기 위해 손가락을 사용한다. 손가락을 사용하는 것은 다음과 같은 몇가지 장점이 있다. 손가락은 언제 어디서든 사용할 수 있으며 다양한 움직임이 가능하다. 또한 마우스와 같은 외부 장치로는 불가능한 즉각적인 반응이나 기기에 연결된 느낌을 가질 수 있다.

그러나 손가락 사용에는 한가지 커다란 단점이 있는데, 그것은 마우스 포인터에 비해 손가락이 훨씬 크다는 것이다. 디스플레이 화면의 차원에서 손가락은 마우스 포인터만큼 정교할 수가 없다. 또한 텍스트 선택이나 드래그 앤 드롭 같은 마우스와 키보드 조합으로 이뤄지는 일부 액션들은 손가락 만으로는 해내기 힘들다.

그러나 사용자 인터페이스를 좋게 디자인하면 손가락 기반 입력 시스템의 문제점을 극복할 수 있다. 이것은 대부분의 경우 터치 영역을 평균적으로 조정하여 배치했는지 확인하고, 드래그 앤 드롭이나 복사 및 붙여넣기 등을 할 수 있게 다른 방법을 찾으며, 사용자들이 예상하는 액션으로 손가락 움직임에 반응하는 것을 의미한다.

특정 결과를 위해 사용자가 행하는 특정한 움직임을 제스처라고 한다. 예를 들어, 사용자는 어떤 것을 선택하기 위해 버튼을 누르고, 긴 목록을 스크롤 하기 위해 드래그하거나 손가락을 튕긴다(flick). 이러한 제스처들은 아이폰 기본 어플리케이션에서 일관되게 사용되기 때문에 사용자들이 이해하기 쉽다. 

물론 손가락으로 쓸거나(swipe) 손가락을 벌리는(pinch open) 등의 좀 더 복잡한 제스처도 기본 어플리케이션들에서 사용되긴 하지만 덜 일반적이다. 보통 이러한 제스처들은 어떤 작업을 실행시키는 유일한 수단으로서 보다는 단축 명령으로서 사용된다. 예를 들어 사용자는 메일 어플리케이션의 메시지 목록에서 각 행의 삭제 버튼을 나타나게 한 다음 그것을 누름으로써 메시지를 지울 수 있는데, 삭제 버튼을 나타나게 하는 방법은 두 가지가 있다.

첫번째 방법은 추가적인 단계를 거쳐야 하지만 편집이라는 명료한 레이블이 붙은 버튼을 누르면 되기 때문에 발견하기 쉽다. 두번째 방법은 신속하지만 쓸기(swipe)라는 좀 더 특별한 제스처를 사용자가 익혀야 한다.

그러므로 어플리케이션을 더 발견하기 쉽고 사용하기 쉽게 만드려면 가능한 가장 익숙한 제스터인 탭과 드래그만을 사용하도록 하자. 또한 덜 일반적인 제스처들(swipe, pinch 등)은 액션을 수행할 수 있는 유일한 방법이 되지 않도록 한다. 이때는 한두 단계를 더 거치더라도 액션을 수행하기 위한 단순하고 직관적인 경로가 있어야 한다.

대부분의 어플리케이션에서 새로운 제스처를 정의하는 것, 특히 새로 정의한 제스처가 이미 익숙한 다른 제스처에 관계된 액션을 수행하는 것을 피하도록 한다. 단 몰입형 어플리케이션은 예외인데, 이러한 어플리케이션에서는 오히려 새로운 제스처가 적절할 수도 있다. 가령 작업형 어플리케이션의 테이블 뷰에서 손가락으로 원을 그려 삭제 버튼을 꺼내는 것은 혼란스러울 뿐만 아니라 사용하기도 어렵지만, 게임에서는 무엇인가 회전을 시키기 위해 이런 제스처를 사용할 수도 있을 것이다. 

아래에 나와있는 표준 제스처들의 의미를 재정의하지 않도록 주의한다. 반대로 표준 제스처를 사용할때는 그에 맞는 응답을 하는지 확인한다.

브랜딩 요소 통합

브랜딩은 절묘하고 절제될 때 가장 효과적이다. 사용자는 어떤 정보나 흥미를 얻길 원하지 광고같은 것을 보고 싶어하지는 않는다. 그렇기 때문에 브랜드 컬러나 이미지 등을 잘 다듬어서 조심스럽게 어플리케이션에 녹여야 한다. 예를 들면 뷰나 컨트롤에 고유한 색깔을 사용하는 것이다.

이 원칙에 대한 예외는 홈스크린 아이콘이다. 홈스크린 아이콘은 오히려 브랜드에 초점을 맞춰야 하는데, 사용자는 홈스크린 아이콘을 자주 보게 되기 때문에 브랜드를 인식시키고 시선을 끄는 것에 주의를 기울여야 한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

훌륭한 아이폰 어플리케이션의 특징들

# 단순하고 사용하기 편하다.

단순하고 사용하기 편하다는 것은 모든 종류의 소프트웨어에서 기본적인 원칙이지만 아이폰 어플리케이션에서는 특히 매우 중요하다. 아이폰 OS 사용자들은 어플리케이션을 사용하는 동시에 무언가 다른 것들을 하고 있을 수 있기 때문에, 해당 어플리케이션의 사용법을 신속하게 알아낼 수 없다면 돌아볼 것도 없이 다른 어플리케이션을 사용하게 될 것이다.

단순하고 사용하기 편한 사용자 인터페이스를 디자인 하려면 다음 사항들을 따르도록 한다.

1) 명확하게 하라

사용자가 어플리케이션 동작에 적응할 시간이 있다고는 장담할 수 없기 때문에, 어플리케이션은 사용자가 즉시 이해하고 이용할 수 있게 만들어야 한다.

어플리케이션의 주 기능은 즉시 드러나야 한다. 이것은 사용자가 선택해야 할 컨트롤의 수를 최소화하고, 컨트롤이 정확히 어떤 일을 하는지 레이블을 좀 더 명확히 함으로써 가능하다. 예를 들어, 아이폰 기본 어플리케이션 중의 하나인 시계 어플리케이션의 스톱워치 기능을 보면 어느 버튼이 시작/정지 버튼인지, 어느 버튼이 랩타임 버튼인지 한눈에 알 수 있다.

<그림 3-1> 스톱워치 기능

2) 위에서 아래로

사용자가 아이폰을 이용하는 모습을 몇 가지 예상해 볼 수 있는데, 사용자는 한 손에 아이폰을 들고 다른 손의 한 손가락으로 조작할 수도 있고, 혹은 한 손으로 들고 그 손의 엄지로 조작할 수도 있다. 또, 양손으로 아이폰을 들고 양손 엄지로 조작할 수도 있다. 어떤 경우에라도 사용자에게는 화면의 상단이 가장 잘 보이며 그로 인해 화면 상단의 접근성이 가장 좋다. 그렇기 때문에 사용자 인터페이스는 가장 자주 이용되는 정보를 상단에 배치해야 한다. 사용자의 시선이 화면의 상단에서 하단으로 내려감에 따라, 제공되는 정보는 일반적인 것에서 구체적인 것으로 혹은 고수준에서 저수준으로 보여져야 한다.

3) 사용자 입력 최소화

사용자가 정보를 입력하는 행위는 그것이 컨트롤을 누르는 것이든 키보드를 사용하는 것이든, 사용자의 시간과 주의를 빼앗는다. 어플리케이션에서 뭔가 유용한 것을 제공하기도 전부터 많은 사용자 입력을 요구하면, 사용자의 속도감은 떨어지고 계속 사용할 의욕 마저 떨어진다.

물론 사용자 입력을 받아야 할 경우도 있겠지만, 이 경우에도 사용자가 제공한 정보를 바탕으로 어플리케이션에서 가능한 많은 정보와 기능을 제공해야 한다. 이렇게 함으로써 사용자는 뭔가 진척되고 있으며, 어플리케이션 사용 간에 지체되고 있지 않다고 느낄 수 있다.

사용자의 입력을 받을때는 텍스트 필드보다는 테이블 뷰를 사용하자. 사용자에게는 단어를 입력하는 것보다 목록에서 아이템을 선택하는 것이 쉽다. 

4) 정보의 간결한 표현

사용자 인터페이스의 텍스트가 간단하고 직접적이면 사용자는 빠르고 쉽게 집중할 수 있다. 그러므로 가장 중요한 정보를 밝히되 간결하고 눈에 띄게 표현하여, 사용자가 너무 많은 단어들을 읽어보지 않더라도 이후에 무엇을 할지 예측할 수 있게 해야 한다. 예를 들면 신문의 편집자처럼 생각하면 된다. 마치 헤드라인에 정보를 함축시켜 표현하는 것처럼, 컨트롤에 간단한 레이블(혹은 잘 이해가되는 아이콘 등)을 사용하여 사용자가 한눈에 그 사용법을 이해할 수 있게 해야 한다.

5) 충분한 터치 영역 제공

컨트롤들이 너무 조밀하게 배치되어 있으면 사용자는 그것을 누를때 조심하기 위해 시간을 허비하게 되고, 실제로 잘못 누를 가능성 또한 커진다. 컨트롤 및 사용자 인터랙션 요소들의 간격을 확보하여 사용자가 최소의 노력으로 정확히 누를 수 있게 하자. 예를 들어, 계산기 어플리케이션의 버튼들은 각각 44 x 44만큼의 공간을 확보하고 있다.

<그림 3-2> 계산기 어플리케이션의 컨트롤 간격

# 주 기능에 집중한다

주 기능에 초점을 맞추고 유지하는 어플리케이션은 만족감을 주며 사용하기 즐겁다. 그러므로 어플리케이션을 디자인 할때는 제품 정의문에 초점을 맞추고 모든 기능과 사용자 인터페이스 요소들이 그것을 지원하도록 하자.

이를 위한 한가지 좋은 방법은 각각의 화면에 보여줄 것을 결정할 때 스스로에게 다음과 같이 질문하는 것이다. 

'이것이 과연 사용자가 지금 당장 필요한 정말 중요한 정보(혹은 기능)인가?' 

혹은 사용자가 상점에서 물건을 살 때 필요한 정보인지 다른 사람을 만나러 가는 중에 필요한 정보인지와 같이 구체적으로 질문해도 좋다. 만약 이러한 질문에 대해 '그렇지 않다'라면, 이제는 다른 상황에서라도 필요한 정보인지 아니면 결국 아무 곳에서도 중요하지 않은 정보인지를 결정한다. 예를 들어, 자동차 마일리지를 관리하는 어플리케이션이 자동차 판매자 위치도 관리한다면 뭔가 초점이 맞지 않고 있는 것이다.

어플리케이션을 단순하고 쉽게 만든다는 가이드라인을 따르면 솔루션에 집중하는데 도움이 된다. 특히, 어플리케이션을 명확히 하고 사용자 입력을 최소화하면 사용자는 어플리케이션의 가장 중요한 부분에 빨리 도달할 수 있으며, 이것이 솔루션에 초점을 맞출 수 있게 해주는 것이다. 예를 들어, 캘린더 어플리케이션은 날짜와 그날에 일어날 수 있는 이벤트에 초점을 맞춘다. 사용자는 오늘 날짜를 선택하는 명확한 레이블의 버튼을 사용할 수 있고, 보기 옵션을 선택할 수 있으며 이벤트를 추가할 수 있다. 가장 중요한 정보인 날짜와 그날의 이벤트가 가장 두드러지게 보이는 것이다. 또한 사용자 입력은 키보드로 일일이 입력하는 대신에 이벤트 날짜 및 반복 간격, 얼럿 옵션을 목록에서 선택함으로써 간소화 된다.

<그림 3-3> 캘린더 어플리케이션에서의 날짜와 이벤트

# 효과적으로 커뮤니케이션한다

커뮤니케이션과 피드백은 데스크탑 어플리케이션에서와 마찬가지로 아이폰에서도 중요하다. 사용자는 자신의 요청이 잘 진행되고 있는지, 혹은 다른 문제는 없는지를 알고 싶어 한다. 하지만 그렇더라도 정말로 중요한 사항이 아닌 경우에 얼럿창을 띄우거나 확인을 자주하는 등의 오버는 피해야 한다.

애니메이션은 그 자체가 사용자의 작업을 방해하거나 어플리케이션의 속도를 떨어뜨리지 않는다면 매우 효과적인 커뮤니케이션 방법이다. 절묘하고 적절한 애니메이션은 상태를 보여주거나 유용한 피드백을 제공하며, 어떤 액션의 결과를 사용자에게 시각화하여 보여준다. 그러나 과도하거나 불필요한 애니메이션은 어플리케이션의 흐름을 끊고 성능을 저하시키며 사용자를 짜증나게 한다.

어플리케이션에서 텍스트로 제공되는 모든 커뮤니케이션은 사용자 중심의 용어를 사용하도록 하며, 특히 사용자 인터페이스에서 기술적 용어를 남발하는 것은 피하도록 한다. 용어가 사용자에게 적절한지를 결정할 때는 대상 사용자에 대해 알고 있는 것을 사용하자. 예를 들어, 환경 설정의 Wi-Fi 네트워크 설정은 간결하고 어렵지 않은 말로 기기가 어떻게 네트워크에 접속하는지를 설명한다.

<그림 3-4> 사용자 중심의 용어 사용

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

제품 정의문

어플리케이션을 디자인하기 전에, 먼저 해당 어플리케이션이 하는 일이 무엇인지 정확하게 정의하는 것이 필수다. 이를 위한 한가지 좋은 방법은 어플리케이션의 주 목적과 대상 사용자를 간결하게 표현하는 제품 정의문(product definition statement)을 만드는 것이다. 이것은 구현하고자 하는 기능 목록으로 일관성있는 제품을 만드는 가장 좋은 방법 중의 하나이다.

제품을 정의하기 전에 먼저 대상 사용자를 정의하도록 한다. 이 어플리케이션은 경험자를 위한 것인가 초보자를 위한 것인가? 사용자는 이 어플리케이션을 진지하게 사용할 것인가 가볍게 사용할 것인가? 또는 특정한 작업을 수행하려는 사용자인가 아니면 단지 재미를 찾는 사용자인가? 이렇게 대상이 되는 사용자를 알면 그들이 특히 필요로 하거나 원하는 것들로 사용자 경험과 인터페이스를 커스터마이징 할 수 있다. 

아이폰 어플리케이션이기 때문에 다음과 같은 사용자들을 미리 예상해 볼 수 있다. 

이제 아이폰의 다른 모든 사용자들과 대상 사용자들을 구별할 수 있는 특성에는 무엇이 있을지 생각해본다. 사용자를 정확하게 정의할수록 사용자 인터페이스의 모습과 기능을 결정하는 것이 더욱 정확해 진다. 예를 들어 어플리케이션이 사업가들의 지출 내역을 기록하기 위한 것이라면, 사용자 인터페이스는 작업에 방해되는 많은 것들을 물어 볼 필요 없이, 올바른 분류를 제공하고 사용자가 비용을 입력하기 쉬워야 한다. 또한 전문적으로 보이고 하루에 몇번씩 봐도 질리지 않는 컬러를 제공해야 한다. 그러나 만약 어플리케이션이 10대를 위한 게임이라면 흥미로운 사용자 인터페이스를 제공하고 그들만의 느낌을 전할 수 있는 언어를 사용하며, 현재 유행하는 색상을 제공해야 할 수도 있다.

마지막으로 어떤 기능들을 제공할지를 생각해본다. 대상 사용자를 유념하면서 기능 목록을 하나의 문장인 제품 정의문으로 요약해 본다. 예를 들어, 데스크탑용 iPhoto 어플리케이션의 경우 사용자들은 사진을 보거나 구성, 편집, 인쇄, 공유 등을 할 수 있다. 그러나 좋은 제품 정의문은 단지 기능에만 초점을 맞추는게 아니라 대상 사용자도 기술한다. 그러므로 iPhoto에 대한 제품 정의문은 "아마추어 사진가를 위한 사용하기 쉬운 사진 관리 어플리케이션"이 바람직 할 것이다. 여기서 대상이 되는 사용자를 문장에 포함시키는게 얼마나 중요한지를 알 수 있는데, "전문 사진가를 위한 사용하기 쉬운 사진 관리 어플리케이션"이었다면 iPhoto의 모습이 얼마나 달라졌을까 상상해 보자.

좋은 제품 정의문은 개발 과정 전체에 걸쳐서 기능이나 툴, 용어들이 적절한지 판단할 때 사용해야 할 도구이다. 특히 제품 정의문에 부합되지 않는 요소들은 제거하는 것이 중요한데, 아이폰 어플리케이션에는 주요 작업에 초점을 맞추지 않는 기능을 포함할만한 여유공간은 없기 때문이다.

예를 들어, 사람들이 물건을 사러갈때 이용할 어플리케이션을 만든다고 생각해보자. 계획단계에서는 다음과 같이 사용자가 할 수 있는 많은 행동들을 떠올릴 수 있다. 

그러나 예상컨대 사용자는 자신이 구매하려는 모든 것을 기억하고 싶어하고, 가능하면 저렴하게 구입하고 싶어하며, 서둘러 물건을 구매하여 집으로 돌아가려는 사람이라 가정해 본다면, 제품 정의문을 "시간적 여유가 없는 사람들을 위한 쇼핑 리스트 작성 및 쿠폰 검색"으로 정의할 수 있을 것이다. 이러한 정의문을 통해 잠재적인 기능 리스트들을 필터링해 나가면, 쇼핑 리스트를 쉽게 작성, 저장 및 사용하는데 먼저 초점을 맞추게 될 것이다. 또한 쇼핑 리스트 상의 아이템들에 대해 쿠폰을 검색하는 기능을 제공할 수도 있다. 비록 나머지 다른 기능들이 유용하더라도(다른 어플리케이션에서는 주요 기능일 정도로), 이 어플리케이션의 제품 정의문에는 부합되지 않는다.

제품 정의문을 확실히 결정하고 기능을 걸러나가기 시작하면, 처음에 정했던 어플리케이션 스타일이 여전히 올바른 것인지를 확인해 볼 수 있다. 특정한 어플리케이션 타입을 정해두고 개발 과정을 시작했다면, 제품 정의문을 정의하는 과정이 그것을 확 바꿔 놓을 수도 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

훌륭한 어플리케이션은 그것이 실행되는 하드웨어와 무관하게 몇가지 기본적인 휴먼 인터페이스 디자인 원칙을 따른다. 이러한 원칙들은 디바이스의 성능이 아닌, 사용자들의 생각과 행동에 기반을 두고 있다. 사용자 인터페이스가 사용자에게 미치는 영향을 과소평가 해서는 안된다. 좋지 않은 사용자 인터페이스는 훌륭한 어플리케이션도 사용하기 싫게 만들기 마련이다.

메타포(Metaphors)

가능하면 어플리케이션에서 사용하는 객체나 액션을 실세계의 것들로부터 모델링한다. 이것은 특히 어플리케이션을 처음 사용하는 사용자들이 빨리 적응할 수 있도록 도와준다. 예를 들어, 폴더는 고전적인 소프트웨어 메타포인데 사람들은 실세계에서 어떤 사물들을 폴더에 보관해 두기 때문에, 컴퓨터의 폴더에 데이터를 넣어두는 것을 빨리 이해할 수 있다. 

아이폰에서는 재생에 관련된 컨트롤들이나 무엇인가를 하기 위해 컨트롤을 두드리는 것, 스위치를 밀어서 켜고 끄는 것, 휠을 돌려서 데이터를 선택하는 것 등이 여기에 속한다. 

비록 메타포가 아이폰 OS에서의 객체와 액션 사용을 대신해서 표현하지만, 메타포를 사용하는 것이 오히려 소프트웨어로 구현된 메타포를 제한해서는 안된다. 다시 폴더의 예를 들어보면, 실제 폴더와 소프트웨어적인 폴더와의 물리적 용량은 전혀 다르다. 

또한 아이폰 OS에 이미 존재하는 메타포들을 재정의하지 않도록 한다. 새로운 메타포를 사용하는 것보다는 표준 컨트롤과 액션을 사용하는 것이 낫다. 대부분의 사용자들이 알아볼 수 있는 메타포가 아니라면 오히려 혼란스러울 뿐이다.

직접 조작(Direct Manipulation)

직접 조작이라는 것은 사용자들이 뭔가 추상적인 것이 아닌 눈에 보이는 것을 다루고 있다고 느끼게 만드는 것이다. 이 원칙을 따르면 사용자들이 어떤 객체를 직접적으로 조작했을 때 그 행동에 대한 결과를 좀 더 쉽게 이해할 수 있다. 

아이폰 OS에서 사용자들은 멀티 터치 인터페이스를 통해 직접 조작하는 느낌을 받을 수 있다. 제스처를 사용해서 화면 상에 있는 객체들을 직접 다루고 있다는 느낌을 받는데, 이것은 객체들을 조작하는데 있어 마우스와 같은 중간 장치를 사용하지 않기 때문이다. 

직접 조작을 강화하기 위해서는 다음 사항을 따르도록 한다.

눈으로 보고 선택하기(See and Point)

일련의 옵션이나 커맨드, 데이터 등을 기억하는 것은 사람보다 어플리케이션이 더 잘한다. 그러므로 어떤 선택이나 옵션을 보여줄 때는 목록 형태로 보여주도록 하자. 이렇게 하면 사용자는 쉽게 목록에서 찾아서 선택할 수 있다.

사용자에게 텍스트를 입력하게 하는 것은 사용자의 시간을 뺏을 뿐만 아니라, 어플리케이션에서도 자주 오류 검사를 해야 하기 때문에 양쪽에게 다 좋지 않다. 텍스트 입력을 하게 하는 대신 선택할 수 있는 목록을 보여주면, 사용자가 그것을 조작하는 법을 기억하기보다 어떤 작업을 달성하는 것에 집중하게 할 수 있다.

피드백(Feedback)

액션에 대한 결과를 보여주는 것과 더불어, 사용자는 컨트롤을 조작했을때 즉각적인 피드백을 받거나 시간이 걸리는 작업에 대해 그 진행 상황을 알아야 할 필요가 있다. 어플리케이션은 모든 사용자 액션에 대해 어떤 눈에 띄는 변화로 응답해야 한다. 예를 들어, 목록에서 아이템을 선택하면 가볍게 하이라이트 되게 할 수 있다. 소리로 피드백을 주는 것도 물론 도움이 되지만, 이것은 메인으로 사용되거나 단독으로 사용될 수는 없다. 사용자가 소리를 잘 들을 수 없는 장소에 있거나 어떤 이유로 아예 꺼놓을 수도 있기 때문이다.

아이폰 OS는 장치가 일시적으로 바쁜 것에 대해 진행중 표시기(activity indicator)를 자동으로 보여준다. 수 초 이상이 걸리는 작업에 대해서는 진행 상태를 표시하던지 관련 메시지를 보여주어야 한다.

애니메이션은 그것이 섬세하고 의미를 가지는 한 사용자 피드백의 매우 좋은 수단이 될 수 있다. 그러나 애니메이션은 그 자체가 사용자 경험의 초점이 되는 것이 아니라, 피드백을 제공하는 수단으로써 사용자 경험을 강화해야 한다.

사용자 컨트롤(User Control)

어떤 액션을 시작하고 컨트롤하는 것은 어플리케이션이 아니라 사용자여야 한다. 또한 액션은 단순하고 직관적으로 만들어서 사용자가 쉽게 그것을 이해하고 기억할 수 있어야 한다. 가능하면 언제나 사용자가 이미 익숙해져 있는 표준 컨트롤과 액션을 사용한다.

작업을 진행하기 전에는 그것을 취소할 수 있는 많은 기회를 제공하도록 하고, 사용자가 잠재적으로 무엇인가를 삭제할 수 있는 액션을 시작할때는 반드시 확인을 받도록 한다.

심미적 통합(Aesthetic Integrity)

비록 어플리케이션의 궁극적인 목적이 특정 작업을 수행하는 것이지만, 그 외형적인 측면을 과소평가 해서는 안된다. 이것은 어플리케이션의 외형이 그 기능성에 큰 영향을 주기 때문인데, 복잡하고 이치에 맞지 않는 모습을 한 어플리케이션은 이해하기도 힘들 뿐더러 사용하기도 힘들다.

심미적 통합은 어플리케이션이 얼마나 예쁜가에 대한 정도가 아니다. 그것은 어플리케이션의 외형과 기능이 얼마나 잘 통합되어 있는가에 대한 정도이다. 예를 들어, 작업형 어플리케이션에서는 표준 컨트롤을 제공하여 작업을 부각시키고, 부가적인 장식 요소들은 배경으로 유지해야 한다. 몰입형 어플리케이션은 오히려 그 반대인데 사용자는 이러한 어플리케이션에 대해 재미를 찾을 수 있는 멋진 외관을 기대한다. 그러나 몰입형 어플리케이션이 비록 오락성을 제공하는데 초점을 두더라도, 그 외형은 여전히 어플리케이션이 제공하는 작업과 잘 통합될 필요가 있다. 이러한 어플리케이션의 사용자 인터페이스 요소는 신중하게 디자인되어야 하고 내부적으로 일관성있는 경험을 제공해야 한다. 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

어플리케이션 스타일 분류

비주얼이나 동작 특성, 데이터 모델, UX 등에 따라 어플리케이션을 세 가지 스타일로 구분해 볼 수 있다. 먼저 강조해 둘 것은 이렇게 스타일을 구분하는 것은 어플리케이션이 반드시 어떤 스타일로 구분되어야 한다는 것이 아니라, 어플리케이션 디자인을 결정하는데 도움을 주기 위한 것이다. 해당 어플리케이션이 제공하는 정보나 기능에 따라 적절한 접근 방법을 택하도록 하자. 다음 사항들을 염두에 두면 이를 결정하는데 도움이 될 것이다.

- 사용자는 어떤 동기에 의해 해당 어플리케이션을 사용하게 될 것인가

- 사용자는 해당 어플리케이션을 사용하면서 어떠한 경험을 하게 될 것인가

- 해당 어플리케이션의 목적이나 관심의 초점은 무엇인가

- 사용자가 찾는 정보를 어떻게 조직화하고 보여줄 것인가

1) 작업형 어플리케이션 (Productivity Applications)

작업형 어플리케이션에서는 세부화된 정보를 구성하고 조작하는 작업이 가능하다. 이러한 어플리케이션의 주된 목적은 어떠한 작업을 수행하는 것이다. 즉, 사용자가 원하는 것을 빨리 찾아내어, 필요한 행동을 쉽게 수행하고 작업을 완료하는 것이 목적이다.

작업형 어플리케이션에서는 사용자 데이터를 주로 계층적으로 구성한다. 사용자는 어떤 정보에 대해 점점 더 구체화된 정보를 찾아 들어감으로써 원하는 세부 단계에 도달할 수 있다. iPhone OS에서는 이러한 과정을 최대한 효율적으로 하기 위해 테이블 뷰를 도입했다.

<그림 1-1> 작업형 어플리케이션은 정보를 계층 구조화한다.

사용자 인터랙션 모델은 다음과 같이 구성된다.

- 목록을 구성한다.

- 목록에 추가하거나 목록에서 삭제한다.

- 원하는 단계의 세부 정보에 도달할 때까지 파고 들어간다(drill-down). 해당 단계의 정보를 가지고 작업을 수행한다.

작업형 어플리케이션은 인터페이스를 많이 커스터마이징하지 않으며, 주로 단순하게 구성된 표준 뷰와 컨트롤을 사용한다. 이것은 작업형 어플리케이션의 목적이 정보 및 작업에 맞춰져 있기 때문이다.

다른 어플리케이션 스타일들과 비교했을때 설정(Settings)을 제공할 가능성이 가장 높은데, 이것은 작업형 어플리케이션이 많은 정보에 대해 여러가지 방법으로 접근하고 관리해야 하기 때문이다. 그러나 사용자가 설정을 바꾸게 하는 일은 거의 없어야 하기 때문에, 메인 UI에서 다룰 수 있는 단순한 설정 변경을 이곳에서 다뤄서는 안된다.

2) 유틸리티 어플리케이션 (Utility Applications)

유틸리티 어플리케이션은 사용자의 입력을 거의 받지 않으며 단순한 작업을 수행한다. 사용자는 어떤 정보에 대해 요약된 내용을 보고, 제한된 수의 객체에 대해 단순한 작업을 수행한다.

<그림 1-2> 날씨 어플리케이션

사용자는 자신이 관심있어하는 정보를 빠르고 쉽게 보고 싶어하기 때문에 유틸리티 어플리케이션의 UI는 잘 정리된 단순한 뷰와 컨트롤을 사용한다.

유틸리티 어플리케이션은 정보를 단순한 목록으로 구성한다. 일반적으로 유틸리티 어플리케이션에서의 각 뷰는 똑같은 데이터 구성과 동일한 세부화 정도를 가지면서, 단지 소스만 서로 다르다.

<그림 1-3> 단순한 목록 형식으로 구성

유틸리티 어플리케이션의 사용자 인터랙션은 매우 단순하다. 사용자는 어플리케이션을 실행시켜서 요약된 정보를 찾아보며, 그 정보에 대한 소스 설정을 변경할 수도 있다. 이러한 소스는 자주 변경할 수 있는 것이기 때문에 주로 메인 뷰의 뒷면에서 그러한 변경 옵션을 제공한다. 사용자는 우측 하단의 정보 버튼을 눌러서 메인 뷰의 뒷면을 볼 수 있으며 설정을 마친 후에서는 완료 버튼을 눌러서 앞면으로 돌아온다. 유틸리티 어플리케이션에서 주로 하는 이러한 옵션 변경은 어플리케이션 기능의 일부이며, 설정 어플리케이션에서 어플리케이션에 특화된 설정을 제공해서는 안된다.

<그림 1-4> 날씨 어플리케이션의 뒷면

3) 몰입형 어플리케이션 (Immersive Applications)

몰입형 어플리케이션은 컨텐츠 위주의 비주얼한 풀스크린을 제공하며 사용자 경험에 초점을 맞춘다. 사용자의 몰입도를 높이기 위해 텍스트 정보는 많이 표시하지 않으며, 커스터마이징된 UI를 주로 사용한다.

<그림 1-5> 게임 이외의 몰입형 어플리케이션

몰입형 어플리케이션의 사용자 인터랙션은 어플리케이션이 제공하는 사용자 경험에 따라 다르다. 옵션 설정 또한 설정 어플리케이션을 사용할 수도 있고 화면의 뒷면을 이용하여 제공할 수도 있다.

어떤 스타일을 선택할 것인가

실제로는 어플리케이션의 스타일을 제대로 결정하기가 쉽지 않은데 이해를 돕기위해 예를 하나 들겠다.

먼저 뭔가 하고 싶은 주제를 선택했다면, 그와 관계된 객체 및 작업들에 대해 생각해 보자. 사람들은 하나의 주제에 대해 여러 가지 방면으로 생각을 떠올린다. 예를 들어, 야구라는 주제를 선택했다면 거기에는 야구 팀이나 경기, 통계, 역사, 선수 등 여러가지 관계 있는 것들이 있다. 단순히 야구라는 주제는 하나의 어플리케이션으로 만들기에는 너무 큰 주제 이므로 그 범위를 야구 선수로 축소해 보자. 이제는 야구 선수에 관계된 어플리케이션을 보다 쉽게 떠올려 볼 수 있을 것이다. 가령 야구 카드(MLB 카드 같은) 같은 것들 말이다.

먼저 작업형 어플리케이션 스타일을 생각해 볼 수 있다. 이 어플리케이션에서는 팀별, 선수별, 시즌별 계층 구조로 카드 목록을 보여주고 상세 정보 뷰에서는 그것에 대해 메모를 남길 수 있다. 또한 유틸리티 어플리케이션 스타일을 생각해 볼 수도 있는데, 특정 카드들에 대한 현재 거래가 등을 요약해서 보여 줄 수 있을 것이다. 카드를 이용한 퍼즐 게임 등을 생각한다면 몰입형 어플리케이션 스타일이 적당할 것이다.

중요한 것은 한 가지 어플리케이션 스타일만을 반복하지 않는 것이다. 여러가지 서로 다른 어플리케이션 스타일을 사용해 보면서 그 특징들을 잘 조합해 보면 좋은 스타일의 어플리케이션을 만들 수 있다.

어떤게 좋을지 잘 모르겠다면 어플리케이션을 최대한 단순하게 만들자. 사용자들이 이 어플리케이션을 사용하면서 어떤 반응을 보이는지 살펴본 후에, 스타일을 완전히 바꾼다던지 혹은 더 구체적인 버전을 만든다던지를 결정할 수 있다.

기존 어플리케이션의 아이폰용 포팅

기존의 데스크탑 어플리케이션을 아이폰용으로 포팅할 때는 있는 그대로 포팅해서는 안된다. 데스크탑과 모바일 간에는 각각의 사용자가 원하는 것이 다르기 때문이다. 아이폰 사용자들은 이동중이거나 제약사항이 있는 환경에서 이용할 가능성이 크기 때문에 보통은 어플리케이션을 실행시켜서 간단히 사용하고 이내 다른 어플리케이션으로 전환한다. 만약 기존의 데스크탑 버전이 사용자가 오랫동안 그 어플리케이션에 집중해야 하는 것이었다면, 아이폰 버전에서는 그 어플리케이션의 구조나 목적을 다시 생각해 봐야 한다. 

여기에는 80-20 법칙이 도움이 될 것이다. 대부분의 사용자들(적어도 80퍼센트)은 어플리케이션의 매우 제한된 기능만을 사용할 것이고, 소수의 사용자들(많아야 20퍼센트)만이 전체 기능을 사용할 것이다. 그렇다면 과연 매우 적은 사용자들을 위해 전체 기능을 제공할 것인지를 고민해 보야야 한다.

데스크탑 어플리케이션 포팅 사례

1) Mail

데스크탑용 Mail 어플리케이션은 많은 기능들을 여러개의 패널을 가진 하나의 윈도에서 보여준다. 이것은 언제라도 데스크탑 띄워두고 필요할때 다시 메일 윈도로 돌아오기에 편하다. 

<그림 1-6> 한 쌍의 윈도만으로 많은 기능을 제공하는 Mail 어플리케이션

그러나 모바일 사용자의 경우는 핵심 기능에 빨리 접근할 수만 있으면 된다. 그렇기 때문에 아이폰의 Mail 어플리케이션은 사용자들이 이메일을 가지고 할 수 있는 가장 중요한 작업들(메일 수신, 작성, 보내기 등)에 중점을 두었다. 

Mail 어플리케이션은 작업형 어플리케이션의 좋은 예이다. 사용자는 일반적인 범위(메일 계정)에서부터 구체적인 범위(메시지)로 목록을 타고 들어간다. 사용자는 하단 툴바의 컨트롤들을 통해 메일에 대한 작업을 수행할 수 있으며, 상단 네비게이션바의 정보를 통해 계층 구조 상의 현재 위치를 쉽게 알 수 있다.

<그림 1-7> 아이폰용 Mail에서는 메일을 확인하거나 보내는 것이 쉽다

2) iPhoto

데스크탑용 iPhoto는 단순히 사진이라는 주요 기능 뿐만 아니라 편집, 인쇄 등의 많은 확장 기능들을 제공한다. 

<그림 1-8> iPhoto의 사용자 인터페이스

그러나 모바일 사용자의 경우에는 사진을 편집할 시간도 없을 뿐더러, 인쇄는 바라지도 않는다. 중요한 것은 사진을 신속하게 볼 수 있는 것과 다른 사람들에게 공유하는 것이다. 

아이폰의 Photos 어플리케이션은 완전히 사진에만 초점을 맞췄다. 심지어 슬라이드 쇼 기능에서는 모든 컨트롤을 숨기고 전체 화면으로 보여준다. 사용자는 언제라도 원할 때 컨트롤을 볼 수 있다.

Photos 어플리케이션은 작업형 어플리케이션 스타일과 몰입형 어플리케이션 스타일을 적절하게 혼합한 예이다. 사용자는 앨범, 사진 목록 등을 통해 원하는 사진을 계층 구조적으로 접근할 수 있으며, 원하는 사진은 전체 화면으로 볼 수 있다.

<그림 1-9> Photos 어플리케이션 화면

참고로, Photos에서는 액션 시트(action sheet)라는 임시 뷰를 사용한다. 이것은 사진을 보고 있다는 사용자 경험을 중단하지 않고도 추가적인 기능을 제공할 수 있다. 

<그림 1-10> Photos에서 액션 시트가 보여지는 모습

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

아이폰이 다른 플랫폼과 다른점

아이폰 어플리케이션을 디자인하기 위해서는 제일 먼저 아이폰과 다른 플랫폼과의 차이점을 알아야 할 필요가 있다.

아이폰 어플리케이션의 종류

아이폰용 소프트웨어는 그 구현 방식에 따라 세 가지 카테고리로 나눠볼 수 있다. 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.