액티비티

액티비티는 특정 한 콘텐트에 대해 -액티비티 뷰 컨트롤러를 이용해 - 시스템이 제공하거나 커스텀하게 제공되는 서비스를 나타낸다.

액티비티는:

• 사용자가 앱 안에서 수행할 수 있는 서비스에 대한, 커스터마이즈 가능한 오브젝트를 나타낸다.

• 바 버튼 아이콘과 유사해 보이는 아이콘에 의해서 제공된다.

사용자가 액티비티 뷰 컨트롤러에 있는 액티비티 아이콘을 탭하면 서비스를 시작할 수 있다. 그 결과로, 액티비티는 서비스를 곧바로 시작하거나, 서비스가 복잡하다면, 서비스를 시작하기 전에 보다 많은 정보를 요청할 수 있다.

앱이 수행할 수 있는 커스텀 서비스에 엑세스할 수 있도록 하기 위해 액티비티를 사용한다. iOS는 프린트, 트위터, 메세지 그리고 에어플레이와 같은 몇 가지 빌트-인 서비스를 제공한다는 것을 기억하라. 빌트-인 서비스를 수행하는 커스텀 액티비티를 만들 필요가 없다.

서비스를 나타내는 단순화한 템플리트이미지를 사용하라. 템플리트 이미지는 사용자가 볼 최종 아이콘을 만들기 위해 iOS가 사용하는 마스크이다. 최종 아이콘이 예쁘게 보이기 위해서 템플리트 이미지를 만들기 위해서는 다음 가이드라인을 따르라 :

• 적당한 알파 투명도값을 가지는 흑/백을 사용

• 그림자 효과를 사용하지 않는다

• 안티 앨리어싱을 사용한다

액티비티 템플리트 이미지는 (고해상도 기준) 70*70 픽셀로 측정되는 영역의 정 중앙에 위치해야 한다.

당신의 서비스를 간단명료하게 설명하는 액티비티 제목을 만들어라. 타이틀은 액티비티 뷰 컨트롤러에서 액티비티 아이콘 아래에 표시된다. 화면에서 잘 보이고 로컬라이즈 하기 쉽기 때문에 짧은 타이틀이 가장 좋다.타이틀이 너무 길면, iOS는 먼저 텍스트를 압착시키고- 그래도 길면- 잘라버린다. 일반적으로, 회사 이름이나 제춤 이름을 액티비티 제목에 넣지 않는 게 좋다.

액티비티 뷰 컨트롤러

액티비티 뷰 컨트롤러는 특정 콘텐트에 동작할 수 있는 시스템 제공과 커스텀 서비스들을 나열하는 임시 뷰를 제공한다.

액티비티 뷰 컨트롤러는 :

• 특정 콘텐트에 수행할 수 있는 설정가능한 서비스의 리스트를 표시한다.

• 아이폰에서는 액션 시트에서 나타나고; 아이패드에서는 팝오버에서 나타난다.

어떤 방식으로 지정된 콘텐트에 수행할 수 있는 서비스의 리스트를 사용자에게 제공하기 위해 액티비티 뷰 컨트롤러를 이용한다. 서비스는 복사나 트위터 그리고 프린트와 같은 시스템 제공 서비스일 수도 있고 커스텀일 수도 있다. 액티비티 뷰 컨트롤러를 사용하는 일반적인 방법은 선택한 콘텐트를 소셜 미디어 계정에 올리도록 하는 것이다.

액티비티 뷰 컨트롤러를 나타내는 커스텀 버튼을 만들지 마라. 사람들은 시스템이 제공하는 서비스들을 Share 버튼을 통해 접근하는 것에 익숙해져 있다. 이러한 학습된 동작을 이용하길 바라지, 같은 일을 하는 다른 방식을 제공함으로서 사용자를 혼란에 빠뜨리지 않도록 한다.

나열된 서비스들이 현재의 컨텍스트에 적당한지를 보장하라. 시스템이 제공하는 서비스 중 배제할 것과 포함할 커스텀 서비스를 지정함으로서 액티비티 뷰 컨트롤러에 나열된 서비스들을 바꿀 수 있다. 예를 들어, 사용자가 이미지를 프린트 하지 못하도록 하기 위해서, 액티비티 뷰 컨트롤러에서 프리늩 액티비티를 배제할 수 있다.

콜렉션 뷰

콜렉션 뷰는 순서있는 아이템의 콜렉션을 커스터마이즈 가능한 레이아웃에 관리한다.

콜렉션 뷰는 :

• 아이템들의 서브셋을 시각적으로 구별할 수 있는 부가적인 뷰를 포함하거나 배경 같은 장식 아이템을 제공한다.

• 레이아웃 간의 커스텀 애니메이션 되는 장면 전환을 지원한다 ( 기본값으로, 콜렉션 뷰는 사용자가 아이템을 삽입하고, 움직이고 삭제할 때 애니메이션을 제공한다 )

• 커스텀 액션을 수행하기 위해 제스처 인식기를 더하는 것을 지원한다, 기본적으로, 컬렉션 뷰는 탭(아이템을 선택)과 터치-앤-홀드( 아이템을 수정 )을 인식한다.

콜렉션 뷰를 사용해 사용자에게 리스트에 표시할 필요없이, 아이템의 세트를 보고 다룰 수 있는 방법을 제공하라. 컬렉션 뷰는 엄격하게 직선 레이아웃을 강요하지 않기 때문에, 사이즈가 다른 아이템들을 표시하는 데에 특히 잘 맞다.

콜렉션 뷰는 매우 확장적인 커스터마이즈를 지원하므로 과격한 새 디자인을 만들수 있는 능력 때문에 산만해지는 것을 피하는 게 중요하다. 콜렉션 뷰가 사용자의 테스크를 개선시키길 원하지; 콜렉션 뷰가 사용자 경험의 초점이 되길 원하지는 않는다. 다음의 가이드라인은 사람들이 좋아하는 콜렉션 뷰를 만드는 것을 도와준다.

테이블 뷰가 더 좋은 선택인 경우 콜렉션 뷰를 사용하지 말라. 때때로, 리스트에 나타내는 게 사람들이 정보를 보고 이해하는 데 더 쉬울 수 있다. 예를 들어, 문자 위주의 정보의 경우 스크롤되는 리스트에 있는 경우에 사람들이 보고 이해하기가 더 쉽다.

사람들이 아이템을 선택하기 쉽게 하라. 콜렉션 뷰안의 아이쳄을 탭 하기가 어렵다면, 사용자들은 당신 앱을 사용하는 것을 즐거워하지 않을 것이다. 사용자가 탭하려는 모든 UI 오브젝트들이 그러하듯이, 콜렉션 뷰 안의 각 아이템의 최소 타겟 영역이 44*44 포인트이 되도록 하라.

다이나믹하게 레이아웃을 변경하려면 주의깊게 하라. 콜렉션 뷰는 사용자가 아이템을 보고 인터렉션하는 동안에도 레이아웃을 바꿀 수 있도록 한다. 만약 당신이 콜렉션 뷰의 레이아웃을 다이나믹하게 조정하고자 한다면, 그 변화가 의미가 통하도록 하고, 사용자들이 추적하기 쉽게 하라. 콜렉션 뷰의 레이아웃을 아무런 명백한 동기 없이 변경하는 것은 사람들에게 당신 앱이 예측불가능하고 사용하기 어렵다는 인상을 준다. 다이나믹 레이아웃 변경 중에 현재의 초점이나 컨텍스트를 잃었다면, 사용자들은 당신의 앱을 더 이상 다룰 수 없다고 느낀다.

콘테이너 뷰 컨트롤러

콘테이너 뷰 컨트롤러는 커스텀한 방식으로 자식 뷰 또는 뷰 컨트롤러들을 관리하고 제공한다. 시스템이 정의한 콘테이너 뷰 컨트롤러들은 탭 바 컨트롤러, 네비게이션 바 컨트롤러, 그리고 스필릿 뷰 콘트롤러이다. (각각의 링크에서 자세히 배울 수 있다.)

콘테이너 뷰 컨트롤러는 기정의된 외관이나 동작이 없다.

콘테이너 뷰를 이용해 사용자가 커스텀한 방식으로 네비케이트 하는 콘텐트를 표시하는 데 사용하라.

커스텀 콘테이너 뷰 컨트롤러가 정말 필요한지 스스로에게 물어보라. 사용자들은 스필릿 뷰 컨트롤러나 탭 바 뷰 컨트롤러처럼 표준 콘테이너 뷰 컨트롤러의 외관과 동작에서 편안함을 느낀다.당신의 커스텀 콘테이너 뷰가 가지는 잠재적인 이익이, 사용자가 그것을 알아보지 못하거나 즉각적으로 동작방식을 알지 못하는 것보다 커야 한다.

당신의 커스텀 콘테이너 뷰 컨트롤러가 양쪽 방향에서 다 잘 동작하는지 확인하라. 콘테이너 뷰 컨트롤러를 portrait와 landscape 모두에서 일관된 경험을 사용자에게 제공하도록 디자인하는 것은 매우 중요하다.

일반적으로, 껌뻑거리는 뷰 장면전환을 삼가라. 커스텀 뷰 컨트롤러를 디자인 하기 위해 스토리보드를 사용하면, 콘텐트 뷰 들간의 장면전환을 위한 커스텀 애니메이션을 제공하는 것이 쉽다. 하지만 대부분의 경우, 화려한 뷰 장면전환은 사용자들이 그들의 테스크에 집중하는 데 거슬리고 당신 앱의 미적인 감각을 떨어뜨린다.

이미지 뷰

이미지 뷰는 하나 또는 일련의 애니메이션 이미지를 표시한다.

이미지 뷰는 :

• 기정의된 모양이 없으며 기본적으로 사용자 인터렉션도 지원하지 않는다.

• 이미지가 늘어나거나, 크기조정되거나 딱 맞게 되거나 특정 위치에 핀이 되어야 한다면, 이미지 뷰와 그 부모 뷰 모두의 프라퍼티를 점검하라.

iOS 7에서, 템플리트 이미지를 가진 이미지 뷰는 이미지에 현재 틴트 컬러를 적용한다. (점검해 봐야 할 내용)

가능한한, 이미지 뷰의 모든 이미지들은 같은 크기와 같은 스케일을 가지도록 하라. 만약 이미지가 다른 사이즈를 가지면, 이미지 뷰는 그것들을 각각 조정한다; 이미지들이 다른 스케일 값을 가진다면, 비 정상적으로 렌더될 것이다.

맵 뷰

맵 뷰는 지리학적인 데이터를 제공하며 빌트-인 Maps 앱이 제공하는 대부분의 기능을 지원한다.

A map view:

• 표준 맵 데이터, 위성 이미지 또는 둘을 합친 정보를 이용해 지리학적인 영역을 표시한다.

• 애노테이션(한 점을 표시하는 것)과 오버레이(경로의 윤곽이나 이 차원적인 영역)을 표시할 수 있다.

• 프로그램적으로 또는 사용자 컨트롤에 의한 줌과 패닝을 지원

지리학적 영역의 인터렉티브한 뷰를 사용자에게 제공하기 위해 맵 뷰를 사용한다. 길 찾기 앱을 만들고 있다면, 맵 뷰를 이용해 사용자의 길을 표시하라. ( 길 찾기 앱을 만드는 보다 많은 정보는 95 페이지의 “Routing”을 보라.)

일반적으로, 사용자가 맵과 인터렉트 하도록 하라. 사람들은 빌트-인 Maps 앱과 인터렉팅 하는 것에 익숙해져 있으며, 당신의 맵에서도 비슷한 방식으로 인터렉션 가능할 것으로 예상한다.

일관된 방식으로 표준 핀 컬러를 사용하라. 맵 핀은 당신의 맵에서 관심지점(POI)의 위치를 보여준다. 사람들은 빌트-인 Maps 앱의 핀 컬러에 익숙하기 때문에, 당신의 앱에서 그 의미를 재정의하지 않는 것이 좋다. 표준 핀 컬러를 사용하는 경우, 다음과 같은 방식으로 사용한다 :

• 빨간색은 목적지를 위해 사용

• 녹색은 출발점을 위해 사용

• 보라색은 사용자 지정 포인트에 사용

페이지 뷰 컨트롤러

페이지 뷰 컨트롤러는 두 가지- 스크롤링이나 페이지 넘기기- 중 하나의 스타일을 이용해 다중 페이지 콘텐트를 관리해 나간다. iOS 7 시뮬레이터에서 페이지 컬은 아래 그림과 같이 생겼다.

페이지 뷰 컨트롤러는 :

• 스크롤링 스타일에 대해서는 기본적인 외형이 없다.

  페이지 컬 스타일에서는, 페이지 뷰 컨트롤러가 책 안쪽의 두 페이지 사이의 모양을 더할 수 있다.

• 지정된 스타일에 따라, 한 페이지에서 다른 페이지로 장면전환 애니메이션 한다.

  스크롤링 스타일에서는, 현재 페이지에서 다음 페이지로 스크롤 이동한다; 페이지 컬 스타일에서는, 현재 페이지가 책이나 노트패드의 페이지처럼 젖혀지는 것 처럼 보인다.

페이지 뷰 컨트롤러는 사용자가 직선적인 방법으로 (이야기의 텍스트처럼) 접근하거나 자연스럽게 덩어리로 나눌 수 있는 콘텐트(칼렌더 처럼)를 제공하는 데 사용하라..

필요하다면, 사용자가 비선형적인 방식으로 콘텐츠에 접근할 수 있도록 커스텀한 방식을 만들어라. 페이지 뷰 컨트롤러는 사용자들이 항 페이지에서 이전 또는 다음 페이지로 이동하도록 한다; 이는 인접하지 않은 페이지로 점프할 수 있는 방법을 제공하지 않는다. 만약 페이지 뷰 컨트롤러가 비 선형적인 방식으로 사용자들에게 콘텐트를 제공하길 원한다면 (사전이나 책의 목차처럼) 콘텐트의 다른 영역으로 이동할 수 있는 커스텀한 방식을 직접 구현해야 한다.

팝오버 (아이패드만 가능)

팝오버는 사용자가 컨트롤을 탭하거나 화면상의 특정 영역을 탭했을 때 나타나는 임시 뷰이다.

팝오버는 :

• 화면의 콘텐트 위를 덮는 셀프-컨테인드 뷰이다.

• 항상 자신이 나타난 위치를 가리키는 화살표를 표시한다.

• 뒤편의 콘텐트를 흐리게 만드는 반투명 백그라운드를 가진다

• 폭 넓은 오브젝트와 뷰들을 가질 수 있다 :

  • 테이블, 이미지, 맵, 텍스트, 웹 또는 커스템 뷰들

  • 네비게이션 바, 툴바, 탭 바

  • 현재 앱 뷰의 오브젝트에 따라 행동하는 컨트롤이나 오브젝트들

  (기본적으로, 팝오버 안의 테이블 뷰, 네비게이션 바, 그리고 툴바들은 팝오버의 블러링이 보이도록 투명한 백그라운드를 사용한다.)

아이패드 앱에서, 액션 시트는 항상 팝오버 안에서 나타난다.

팝오버는 다음을 위해 사용한다 :

• 초점이 맞춰지거나 선택된 오브젝트에 관련된 부가적인 정보 또는 아이템의 리스트를 표시하기 위해.

• 스크린 상의 무엇인가와 매우 관련이 깊은 옵션들의 리스트를 포함하는 액션 시트를 표시하기 위해

• Display the contents of the left pane when a split-view–based app is in portrait. If you do this, you either provide an appropriately titled button that displays the popover—preferably in a navigation bar or toolbar at the top of the screen—or allow people to make the swipe gesture to hide and reveal it. = 스필릿-뷰-기반의 앱이 portrait일 때, 왼쪽 팬의 콘텐트를 표시하기 위해. 이렇게 한다면, 당신은 팝오버를 표시하는 적당한 제목이 붙은 버튼을-아마도 네비게이션 바나 화면 상단의 툴바를 통해 - 제공하거나 사용자들이 숨기거나 보이기 위해 스와이프 제스처를 사용할 수 있도록 해야 한다. (두번째껀 무슨 소리지?)

“디스미스 팝오버" 버튼을 제공하지 마라. 팝오버는 더 이상 그 존재가 필요없게 되면 자동으로 닫혀야 한다. 팝 오버가 더 이상 필요없는 순간을 판단하기 위해, 다음 시나리오를 생각해 보자.

일반적으로, 사용자가 팝오버의 경계 바깥을 탭하면 사용자의 작업을 저장하라. 팝오버들이 명백한 닫기(dismissal)를 요구하지는 않기 때문에, 사용자들은 실수로 닫아버릴 수가 있다. 팝오버 내에서의 사용자의 작업은 Cancel 버튼을 탭 한 경우에만 무시하라.

팝오버 화살표를 그것을 나타낸 요소에 가능한 직접적으로 지시하도록 하라. 이렇게 함으로서 사용자들에게 팝오버가 나타난 위치를 기억하게 하 연관된 테스크나 오브젝트가 무엇인지 알게 한다.

사람들이 뒤에 있는 앱 콘텐트를 보지 않고 팝오버를 사용할 수 있도록 하라. 팝오버는 그 뒤의 콘텐트를 가진다. 그리고 사용자들은 팝오버를 다른 위치로 드래그 할 수 없다.

한 번에 하나의 팝오버만 볼 수 있다. 한 번에 하나를 초과하는 팝오버(또는 팝오버와 비슷하게 보이고 동작하는 커스텀 뷰)를 표시할 수 없다. 특히, 동시에 하나의 팝오버에서 다른 것이 나타나는 계층적이거나 연속적인 팝오버들을 표시하는 것을 삼가야 한다.

팝오버 위에서 모달 뷰를 디스플레이 하지 마라. 경고를 제외하고, 팝오버 위에는 어떤 것도 올라오면 안된다.

가능하다면, 사용자가 하나의 팝오버를 닫고 새로운 것을 여는 것을 한 탭으로 할 수 있게 하라. 이 동작은 여러개의 바 버튼이 다른 팝오버를 열 때 특히 바람직하다. 사용자들이 추가적인 탭을 하는 것을 방지하기 때문이다.

팝오버를 너무 크게 만들지 말라. 팝오버는 전체 스크린 크기만큼으로 나타나면 안된다. 그대신에, 그 콘텐츠를 표시하기에 충분한 크기를 가지면서 나타난 위치를 지시할 수 있으면 된다.

이상적으로, 팝오버의 너비는 최소한 320 포인트 이상이지만 600 포인트 이상은 넘지 않는 게 좋다. 팝오버의 높이는 제한되어 있지 않으므로, 아이템의 긴 리스트를 디스플레이하는 데 사용할 수 있다. 하지만 일반적으로, 어떤 작업을 수행하거나 액션 시트를 제공하는 팝오버에서 스크롤은 지양해야 한다. 시스템이 팝오버의 너비와 높이를 화면에 잘 맞게 조정할 수 있다는 것을 염두에 두라.

팝오버 안에서는 표준 UIControl과 뷰들을 사용하라. 일반적으로, 표준 컨트롤과 뷰들을 포함하고 있을 때 팝오버가 보기에 가장 좋고, 사용자들이 이해하기도 쉽다.

커스텀 팝오버도 팝오버처럼 보이게 만들어라. UIPopoverBackgroundView API를 이용해 팝오버의 시각적인 면들을 커스터마이즈 하는 게 쉽지만, 사람ㄷ르이 팝오버라고 인식하기 어려운 디자인을 만드는 것은 삼가라. 만약 팝오버의 모양을 너무 많이 바꾸면, 사용자들의 이전 경험이 당신 앱을 사용하는 방ㄹ법을 이해하는 데 도움이 되지 못하게 된다.

가능하다면, 팝오버의 크기는 보이는 동안에 변경하라. 동일한 정보에 대해 미니멀한 뷰와 확장된 뷰를 보여주는 데 팝오버를 사용한다면 팝오버의 크기를 변경해야 할 것이다. 팝오버의 사이즈를 조정할 때는, 그 변화를 애니메이션하는 게, 팝오버가 새로운 것으로 교체되었다는 느낌을 주지 않기 때문에 좋다.

스크롤 뷰

스크롤 뷰는 사용자들이 스크롤 뷰의 경계영역보다 큰 콘텐트를 볼 수 있도록 한다. (아래 그림처럼 스크롤뷰보다 넓고 높은 이미지를 표시할 수 있다.)

스크롤 뷰는 :

• 미리 정의된 모양은 없다

• 임시 스크롤 인디테이를 처음 나타날 때와 사용자가 인터렉트할 때 잠깐 깜빡인다.

• 제스처의 속도와 방향에 따라 사용자가 자연스럽게 느끼는 방식으로 콘텐트를 드러낸다.

  스크롤 뷰의 콘텐트를 드래그하면, 콘텐트는 터치를 따라온다; 콘텐트를 플릭하면, 스크롤 뷰는 콘텐트를 빠르게 드러내고 사용자가 화면을 터치하거나 콘텐트의 끝에 닿으면 멈춘다.

• 페이징 모드로 동작할 수 있다. 드래그나 플릭 제스처는 콘텐트의 앱에서 정의된 페이지 하나만큰 드러내는 방식이다.

제한된 영역에 큰 뷰-또는 많은 수의 뷰들-를 사용자가 접근할 수 있도록 스크롤 뷰를 사용하라.

줌 기능을 적당히 제공하라. 당신의 앱에서 의미적으로 통한다면, 사용자가 핀치나 더블-탭을 이용해 스크롤뷰안에서 줌 인 - 아웃을 할 수 있도록 만들어라. 줌을 가능하게 만들면, 최대와 최소 스케일 값을 설정해서 컨텍스트 안에서 사용자의 테스크가 의미가 통하게끔 하라. 예를 들어, 사용자가 텍스트를 문자 하나가 화면을 채울 정도로 줌-인할 수 있도록 하는 것은 콘텐트를 읽기 쉽게 만드는 것은 아니다.

페이징-모드 스크롤 뷰에는 페이지 컨트롤 사용을 고려하라. 콘텐트를 페이지나, 화면크기나 다른 어떤 크기로 나누어서 표시하길 원한다면, 얼마나 많은 덩어리들이 있는 지와 지금 현재 보고 있는게 어디쯤에 있는지를 알려주기 위해서 페이지 컨트롤을 사용할 수 있다.

페이징-모드의 스크롤 뷰와 함께 페이지 컨트롤을 사용한다면, 페이지 컨트롤과 같은 축 방향의 스크롤 인디케이터는 사용하지 않는 게 좋다. 스크롤 인디케이터를 없애는 건 페이지 컨트롤에 주의를 기울이도록 하며, 콘텐트에 걸처 모호하지 않은 페이지를 제공한다. 페이지 컨트롤에 대한 보다 자세한 정보는 “Page Control”(페이지 181)을 보라.

일반적으로, 한 번에 하나의 스크롤 뷰만 표시하라. 사람들은 이따금씩 스크롤할 때 큰 스와이프 제스처를 만들기 때문에, 한 화면에 이웃한 스크롤 뷰와 인터렉트 하지 않도록 하는 것은 어려울 수 있다. 만약 한 화면에 두개의 스크롤 뷰를 넣기로 결정했다면, 서로 다른 방향으로 스크롤 하도록 해서 하나의 제스처가 두 뷰 모두를 스크롤 하지 않도록 한다. 예를 들어, 아이폰의 portrait 방향에서 Stocks 앱은 주식 시세를 , 수평으로 스크롤하는 회사-특징 정보 위에, 수직으로 스크롤하는 뷰에 표시한다.

** 위에서 People을 사용자로 많이 번역했는데, 사람들로 번역하는 게 맞다고 봄. HIG 문서는 인간에 대한 탐구이기 때문에 굳이 사용자로 번역하는 게 좋지 않은 듯.

스필릿 뷰 컨트롤러 (아이패드에서만)

스필릿 뷰 컨트롤러는 풀-스크린 뷰 컨트롤러로서 두개의 옆으로 나란한 뷰 컨트롤러를 관리한다.

스필릿 뷰 컨트롤러는 :

• 두개의 팬을 디스플레이 한다. (왼쪽 팬의 너비는 모든 방향에서 320으로 고정되어 있다; 오른쪽 팬의 너비는 커스터마이즈 가능하다)

• 장치가 landscape 방향일 때 왼쪽 팬을 팝오버에 표시하는 것도 부가적으로 가능하다.

• 폭 넓은 오브젝트와 뷰들을 포함할 수 있다 :

  • 테이블, 이미지, 맵, 텍스트, 웹 또는 커스텀 뷰들

  • 네비게이션 바, 둘바 또는 탭 바

스필릿 뷰 컨트롤러를 고정적인 정보를 왼쪽 팬에 표시하고, 관련된 상세 정보 또는 부가적인 정보를 오른쪽 팬에 표시하는 데 사용하라. 이 디자인 패턴에서 사람들이 왼쪽 팬에서 아이템을 선택하면, 오른쪽 팬은 그 아이템과 관련된 정보를 보여준다(이런 일이 일어나도록 코드를 짜야한다)

오른쪽 팬이 왼쪽 팬보다 좁게 만들지 마라. 오른쪽 팬이 왼쪽 팬보다 더 좁으면, 스필릿 뷰 컨트롤러는 화면의 너비를 채울 수 없게 되고 전체적인 외관이 불균형적으로 된다.

네비게이션 바를 양쪽 팬에 동시에 표시하지 마라. 이렇게 하면 사용자들은 그 두 팬들간의 관계를 구별하기 어렵게 만든다.

일반적으로, 왼쪽 팬에서 현재 선택을 지속적인 방식으로 표시하라. 오른쪽 팬의 콘텐트가 바뀔 수 있지만, 그것은 항상 왼쪽 팬에서 선택된 아이템과 관련있는 것이어야 한다. 이런식의 보기 경험은 사람들에게 왼쪽 팬의 아이테마과 오른쪽 팬의 콘텐트 사이의 관계를 이해하는 데 도움을 준다.

적당하다면, 왼쪽 팬에 접근할 수 있는 다른 방식을 제공하라. 기본적으로, portrait 방향에서는 오른쪽 팬만 표시되고, 왼쪽 팬을 보이고 숨길 수 있는 버튼을 (전형적으로 네비게이션 바에) 제공한다. 스필릿 뷰 컨트롤러는 보고 숨기는 액션에 스와이프 제스처도 지원한다. 앱에서 스와이프 제스처를 다른 곳에 사용하지 않는다면, 사람들이 스와이프를 통해 왼쪽 팩에 접근할 수 있도록 한다. (역자 주 ; iOS 7에서 팝오버로 나오지 않으면서 가능해진 제스처)

테이블 뷰

테이블 뷰는 스크롤되는 단일 컬럼의 다중 로우들에 데이터를 제공한다.

테이블 뷰는 :

• 섹션으로 구분되거나 그룹으로 나눌 수 있는 로우들에 데이터를 표시한다.

• 사용자가 로우들을 더하거나 삭제하고, 다중 로우를 선택하고, 로우 아이템에 대한 자세한 정보를 보고, 다른 테이블 뷰를 볼 수 있는 컨트롤들을 제공한다.

iOS는 두가지 스타일의 테이블 뷰를 정의한다 :

플레인 스타일. 플레인 스타일에서, 로우들은 레이블이 붙은 섹션에 의해 분리될 수 있으며 뷰의 오른쪽 모서리를 따라서 부가적인 인덱스가 나타날 수 있다. 섹션의 첫 번재 아이템이 나나기 전에 헤더가 보일 수 있고, 마지막 아이템 뒤에 푸터가 보일 수 있다.

(역자 주 ; 슬라이드 자료의 테이블 뷰 그림 교체하기. 인덱스는 그림을 삽입.)

그룹드 스타일. 그룹드 스타일에서, 로우들은 그룹지어서 표시되며 그 그룹 앞에는 헤더가 붙고 뒤에는 푸터가 붙는다. 그룹드 테이블 뷰는 항상 리스트 아이템 그룹을 하나 이상 가지며 - 로우당 하나의 리스트 아이템 - 모든 그룹은 항상 하나 이상의 아이템을 가진다. 그룹드 테이블 뷰는 인덱스를 가지지 못한다.

양쪽 스타일 모두, 사용자가 선택가능한 아이템을 탭하면 테이블 로우는 즉각적으로 하일라이트 된다. 로우 선택이 새로운 화면으로의 네비게이션을 일으킨다면, 선택된 로우는 새로운 스크린이 밀려들어오는 순간 즉각적으로 하일라이트 된다. 사용자가 이전 화면으로 돌아가기하면, 원래 선택되었던 로우가 다시 즉각적으로 하일라이트 되어서 사용자에게 이전 선택을 상기시켜준다. (하일라이트 상태로 남아있지 않는다.)

iOS는 테이블 뷰의 기능을 확장할 수 있는 몇 가지 테이블 뷰 요소들을 가지고 있다. 다른 곳에 기록된 것이 없다면, 이 요소들은 테이블 뷰에서만 사용할 수 있다.

위에 나열된 테이블-전용 요소들에 더해서, iOS는 리프레시 컨트롤을 선언해 두어서, 사용자들이 테이블의 콘텐트를 리프레시 할 수 있도록 하였다. 보다 자세한 정보는 “Refresh Control”을 보라.

iOS는 4 종류의 테이블 뷰 셀 스타일을 선언해 두어서, 플레인과 그룹드 테이블 뷰 모두에서 가장 일반적인 레아웃을 구현한다. 각각의 셀 스일은 다른 종류의 정보 종류에 맞게 맞춰져 있다.

디폴트 (UITableViewCellStyleDefault). 디폴트 셀 스타일은 로우의 왼쪽 끝에 부가적인 이미지를 포함하며, 왼쪽 정렬된 제목을 보여준다.

디폴트 스타일은 추가적인 정보에 의해 구별될 필요가 없는 아이템들의 리스트를 표시하기에 좋다.

서브타이틀 (UITableViewCellStyleSubtitle). 서브타이틀 스타일은 로우의 왼쪽 끝에 부가적인 이미지를 포함하며, 왼쪽 정렬된 제목 한 줄과 그 아래에 왼쪽 정렬된 서브타이틀을 보여준다.

텍스트 레이블의 왼쪽 정렬은 리스트를 훑어보기 쉽게 만든다. 이 테이블 셀 스타일은 리스트 아이템이 비슷하게 생겼을 때 보기에 좋다. 왜냐하면 사용자들은 디테일 텍스트 레이블에서 부가적인 정보 얻어서 텍스트 레이블에 이름 붙은 아이템들을 구별하기가 좋기 때문이다.

밸류 1 (UITableViewCellStyleValue1). 밸류 1 스타일은 왼쪽 정렬된 제목과 오른쪽 정렬된 부제목이 보다 가벼운 서체로 같은 줄에 있다.

밸류 2 (UITableViewCellStyleValue2). 밸류 2 스타일은 오른쪽 정렬된 제목은 파란색 서체로, 바로 옆 같은 줄의 왼쪽 정렬된 부제목은 검은색 서체로 표시한다. 이미지는 이 스타일에는 맞지 않는다.

밸류 2 레이아웃에서, 텍스트와 디테일 텍스트 사이의 미묘한 마진은 사용자들이 디테일 텍스트 레이블의 첫 단어에 집중할 수 있도록 한다.

테이블 뷰를 이용해 많든 적든 정보를 깨끗하고 효율적으로 표시하라. 예를 들면 :

• 사용자가 선택할 수 있는 옵션의 리스트를 제공한다. 리스트에서 체크마크를 이용해 사용자에게 현재 선택한 옵션을 보여준다.

  사용자가 테이블 로우의 아이템을 탭하면 나타나는 선택의 리스트를 표시하는 데에는 플레인 또는 그룹드 테이블 뷰를 사용하라. 사용자가 버튼이나 테이블 로우에 있지 않은 UI 요소를 선택해서 나타나는 선택의 리스트를 표시하는 데이는 플레인 테이블 뷰를 사용하라.

• 계층적인 정보를 표시한다. 플레인 테이블 스타일은 계층적인 정보를 표시하는 데 잘 맞춰져 있다. 각각의 리스트 아이템은 다른 리스트에 표시되는 다른 정보의 서브셋을 이끌 수 있다. 사용자들은 각각의 연속된 리스트에서 하나의 아이템을 선택함으로서 계층의 경로를 따라 갈 수 있다. 디스클로저 인디케이터는 사용자에게 로우의 어느 부분이든 탭을 하면 새로운 리스트에서 그 정보의 서브셋이 나타날 것이라고 말한다.

• 개념적으로 그룹화된 정보를 표시하라. 두 종류의 테이블 뷰 스타일 모두 정보의 섹션들 사이에 헤더와 푸터 뷰를 공급함으로서 컨텍스트를 제공하도록 한다.

iOS 6.0 이후에는, 헤더 또는 푸터에서 텍스트 또는 커스텀 뷰를 디스플레이 하기 위해 헤더-푸터 뷰를 설정할 수 있다. - 이는 UITableViewHeaderFooterView의 인스턴스이다 - 자세한 정보는 UITableViewHeaderFooterView 클래스 레퍼런스.를 보라.

테이블 뷰를 사용할 때는 다음 가이드라인을 따르라 :

사용자가 리스트 아이템을 선택할 때마다 항상 피드백을 제공하라. 사용자들은 테이블 로우 안의 선택가능한 아이템을 탭 하면 테이블 로우가 즉각적으로 하일라이트 될 것이라 예상한다. 탭을 하고 나면, 아이템이 선택되거나 사용가능하게 되었다는 것을 가리키기 위해 새로운 뷰가 나타날 것으로 예상한다. ( 또는 로우가 체크마크를 표시)

테이블 콘텐트가 방대하거나 복잡하다면, 뭔가를 디스플레이하기 전에 모든 데이터가 가용해질 때까지 기다리지 마라. 그 대신에, 화면 위의 로우들에 문자 데이터를 즉각적으로 채우고 이미지같은 복잡한 데이터는 가능해 질 때 디스플레이 하라. 이 기법은 사용자에게 유용한 정보를 즉각적으로 제공해 줘서 사용자가 받아들이는 앱의 반응성을 높인다.

새로운 데이터를 기다리는 동안, “김 빠진" 데이터를 표시하는 것을 고려해 보라. 이 기법은 자주 변경되는 데이터를 다루는 앱에는 권장되지 않으나, 보다 고정된 앱들에서는 사용자들에게 유용한 정보를 바로 보여줄 수 있다. 이것을 하기로 마음먹기 전에, 데이터가 얼마나 자주 변경되는지와 사용자들이 새로운 데이터를 빠르게 보는 것에 의존하는 지를 측정해보라.

데이터가 로딩이 느리거나 복잡하다면, 처리가 진행중임을 보여줘라 테이블이 복잡한 데이터만을 가진다면, 뭔가 유용한 정보를 바로 보여주기가 어려울 수 있다. 그러한 드문 경우에는, 텅 빈 로우를 보여주는 것을 피하는 것이 중요하다. 왜냐면, 빈 로우는 당신의 앱이 멈추었다는 것을 암축할 수도 있기 때문이다. 그 대신에, 테이블은 회전하는 액티비티 인디케이터와 정보성 레이블 (“Loading…”같은)을 화면의 중앙에 디스플레이한다. 이런 동작은 진행이 계속되고 있다고 사용자를 안심시킨다.

가능하다면, Delete 버튼에는 커스텀 타이틀을 사용하라.당신 앱의 동작 방식에 대해 더 깊은 이해를 할 수 있게 도울 수 있다면, 시스템-제공 Delete 제목을 대체하는 제목을 만들어라.

최대한, 잘림을 방지하기 위해 간결한 텍스트 레이블을 사용하라. 잘린 단어와 구문은 사용자가 욽어보고 이해하기 어려울 수 있다. 텍스트 자름은 모든 테이블 셀 스타일에 자동이지만, 어떤 셀 스타일을 사용하고 있고 어디에서 잘리느냐에 따라 크고 작은 문제점을 만들 수 있다.

테이블의 오른쪽 모서리에 디스플레이되는 인덱스를 테이블 뷰 요소와 결합하지 마라. 테이블의 오른쪽에 디스플레이 되는 테이블 뷰 요소들- 디스클로저 인디케이터같은-과 인덱스가 겹쳐보일 수 있다.

비표준 방식으로 테이블 로우들을 레이아웃라고 싶다면 커스텀 테이블 셀 스타일을 만들어라. 표준을 크게 바꾸는 것 보다는 커스텀 테이블 셀 스타일을 만드는 게 낫다. 직접 셀을 만드는 방법을 배우려면 Table View Programming Guide for iOS 문서의 “Customizing Cells”부분을 보라.

텍스트 뷰

텍스트 뷰는 다중라인의 텍스트를 받아들이고 표시한다.

텍스트 뷰는 :

• 어떤 높이의 사각형이다.

• 콘텐트가 그 바운드보다 크다면 스크롤을 지원한다.

• 커스텀 서체, 컬러 그리고 정렬을 지원한다. (기본적으로, 텍스트 뷰는 왼쪽 정렬된 검은 색 시스템 폰트를 디스플레이 한다.)

• 사용자가 텍스트 뷰 안쪽을 터치하면 편집을 지원한다. (키보드의 입력 도구와 레이아웃은 사용자의 언어 설정에 의해 결정된다.)

항상 텍스트는 읽을 수 있도록 하라 애트리뷰티드 스트링을 이용해 창의적인 방식으로 다중의 서체, 컬러 그리고 정렬방식을 조합할 수 있지만, 글자를 읽을 수 있도록 하는 게 핵심이다. 텍스트 뷰에 디스플레이 할 텍스트를 얻기 위해 다이나믹 타입을 지원하고 UIFont의preferredFontForTextStyle메소드를사용하는 것은 좋은 생각이다. 다이나믹 타입 지원에 대한 가이드 라인은 "Text Should Always Be Legible" 페이지 52; 프로그램적인 정보는 Text Programming Guide for iOS문서의 “Text Styles”를 보라.

사용자들이 입력할 것으로 예상되는 콘텐트의 타입에 따라 맞추기 위해 다른 키보드 타입을 지정하라. 예를 들어, 사용자들이 URL, PIN, 전화번호를 쉽게 입력하도록 만들고 싶을 수 있다. 그러나 Note는 사용자의 언어 설정에 따라 결정될 뿐, 입력 메소드와 레이아웃을 제어하지 않는다.

iOS는 몇 종류의 키보드 타입을 가지고 있는데, 각각은 서로 다른 입력을 위해 디자인 되어 있다. 사용가능한 키보드 타입에 대해 공부하고 싶으면, UIKeyboardType 문서를 보라. 앱에서 키보드를 관리하는 법을 배우려면 iOS App Programming Guide의 “Managing the Keyboard”를 읽으라.

웹 뷰

웹 뷰는 rich HTML 콘텐트를 디스플레이 할 수 있는 영역이다.( 여기 iPhone 의 Mail 앱에서 보이는 네비게이션 바와 툴 바 사이)

웹 뷰는 :

• 웹 콘텐트를 표시

• 전화 번호를 전화 링크로 변환하는 것과 같이, 웹 콘텐트에 대해 자동화된 처리를 수행한다.

만약 웹 페이지나 웹 앱을 가지고 있다면, 웹 뷰를 이용해 웹 페이지나 웹 앱을 감싸는 것을 제공함으로서 간단한 iOS 앱을 만들 려고 맘 먹을 수도 있다. 웹 뷰를 이용해 당신이 관리하는 웹 콘텐트에 접근하려는 계획이 있다면, Safari Web Content Guide를 반드시 읽으라.

웹 뷰를 이용해 마치 미니 웹 브라우저처럼 보이고 동작하는 앱을 만드는 것을 지양하라.사람들은 웹 콘텐트를 브라우즈 하기 위해 iOS 에서는 Safari를 사용하기 때문에, 이 방대한 기능들을 당신의 앱 안에서 반복하는 것은 권장하지 않는다.