Android의 액션바
iOS의 네비게이션바
액션바와 네비게이션바를 곰곰히 생각해보다가 잡담을 끼적여봅니다.
액션바와 네비게이션바(ActionBar & NavigationBar)
개발을 하게될 때, 기획을 하게될때, 많이 고민하게 되는 부분이 바로 안드로이드의 액션바와 iOS의 네비게이션바입니다.
만드는 사람의 입장에서는 유저에게 같은 모습으로 보여지면서, 같은 기능, 같은 동작을 하길 원하게 되거든요. 하지만, 안드로이드와 iOS의 차이점들을 생각하면, 액션바와 네비게이션바는 같은 방식으로 동작하게 기획/개발 될 수 없는 부분들이죠.
이미 많은 사람들에게 익숙한 '네비게이션바'에 비해, 액션바는 얼마전에야 support v7 에서 지원되기 시작해 정식으로 사용된지는 얼마 되지 않았지요.
이제는 안드로이드에서도 support v7 appcompat 및 Navigation drawer 에 대한 내용이 공식적으로 공개되었고, 많은 애플리케이션들이 이를 사용해 개발하고 있어 이런 얘기를 해볼때가 된것 같네요. (상위 버전만을 타겟으로 하는 앱들에서는 사용되고 있었습니다. 하위 버전을 지원하는 앱들에서는 ActionBarSherlock으로 사용되고 있었지만요.)
개인적으로 저는 액션바와 네비게이션바는 '기본적인 기능'은 동일하지만 '주 목적'이 다르다고 생각합니다.
둘 모두 공통적으로 현재 화면이 어떤 화면인지를 텍스트로 보여주고, 현재 화면에서 유저가 할 수 있는 중요한 액션을 보여줍니다.
Up caret vs Left bar button
우선 액션바의 Up caret(상위 기호)와 네비게이션바의 Left bar button(좌측 바 버튼)을 보도록하죠. (여기서는 사이드메뉴에 대한 내용은 배제합니다.)
액션바에는 '상위 계층'(일반적인 경우)으로 이동 할 수 있는 버튼을 좌측에 위치시킵니다.
네비게이션바에는 '이전 화면'(일반적인 경우)으로 돌아갈 수 있는 버튼을 좌측에 위치시키죠.
네비게이션바의 '이전 화면' 버튼의 경우 이전 화면이나 버튼에 텍스트로 표시되어있는 화면으로 이동하게 됩니다. 아이폰/아이패드의 경우 홈버튼을 제외한 다른 메뉴키가 없기때문에 화면내의 클릭등으로 이동하는것을 제외하고는 앱 내에서의 네비게이팅은 네비게이션바에 의존하게 됩니다. 히스토리를 보관해 두고, 네비게이션바의 좌측 버튼으로 되돌아 갈 수 있는 루트를 제공해 주지 않으면 사용자는 혼란에 빠지게 되겠죠.(어떻게 해서도 첫 화면으로 되돌아 갈 수 없게된다는.. ㄷㄷ) 물론 개발 방식에 따라 '이전 화면'이 아닌 경우도 존재할 수 있겠죠.(개발하기 나름)
액션바의 경우는 네비게이팅에 있어서 좀 복잡해집니다. 백 키(소프트웨어 메뉴키/하드웨어 메뉴키 동일)로 이동할 경우와, '상위 계층'으로 이동할 경우 개념이 달라지죠. 경우에 따라 '백 키(Back Key) 이동'과 '상위 계층 이동' 이 같은 화면으로 이동할수 있습니다. 히스토리를 보관하기 때문에(BackStack) 안드로이드에서의 '백 키'는 iOS 네비게이션바의 '이전 화면으로 사용되는 Left bar button' 과 비슷한 역할을 한다고 보면 될 것 같습니다.
안드로이드에서의 네비게이션 중, 같은 계층에서의 뷰 전환, 특정상황에서는 '상위 계층 이동'과 '뒤로 이동'이 같은 기능을 할 수 있다.
안드로이드 애플리케이션 구조와 네비게이션
일반적인 안드로이드 애플리케이션은 이렇게 구성됩니다.(물론 만들기 나름이지만요.)
- 최상위 수준 뷰(Top level views)
- 카테고리 뷰(Category views)
- 세부/편집 뷰(Detail/Edit views)
(안드로이드 디자인 가이드 - 앱 구조 참고)
일반적인 안드로이드 앱이라면 이런 앱 구조안에서 화면을 전환하며 네비게이션을 해줍니다.
1) 최상이 수준 뷰는 상위 버튼(Up caret)을 표시하지 않고, 2) 시스템 이전 키는 사용차가 최근 본 화면을 역순으로 탐색하는데 이용하며, 3) 이전에 봤던 화면이 현재 화면의 계층적 부모라면 '이전 키'를 누르는 것과 '상위 버튼'을 누르는 게 동일한 결과를 가져오고, 4) 같은 계층의 뷰 간 전환이 일어났을 때는, '이전 키'와 '상위 버튼' 이 같은 결과를 가져오고, 5) 경우에 따라, 같은 계층 뷰 간 전환이 일어나더라도 '기록'을 남기는 경우, '이전 키'와 '상위 버튼'은 각각 동작하게 되고, 6) 외부 앱에서 진입한 경우, '이전 키' 는 외부 앱으로 돌아가지만 '상위 버튼'은 현재 앱의 하이라키에서 상위 계층으로 이동할 수 있으며, 7) 하나의 앱 내에서 카테고리 뷰를 건너뛰고 '최상위 뷰' > '디테일 뷰'로 이동한 경우에도, '이전 키'는 최상위 뷰로 되돌아 가도록 하지만, '상위 버튼'은 카테고리 뷰로 이동 할 수 있도록 해주는 거죠.
이외에도 상황에 따른 여러가지 네비게이션에 대해서는 안드로이드 디자인 가이드 - 네비게이션 을 참고하도록 하죠.
마지막으로 짧게 iOS 와 비교하자면, 안드로이드에서는 외부 앱에서 진입한 경우라도, 해당 화면이 '상위 계층 뷰'를 가지고 있다면, '상위 버튼'을 통해 '상위 계층 뷰'로 이동할 수 있도록 구성되어있습니다. 어디서 해당 화면에 접근했더라도 해당 앱에 남아서 사용할 수 있도록 보장해주는 것이지요. (디자인 가이드에는 '사용자가 앱 내에 남아 있을 수 있도록(보장) 해주는 상위버튼' 이라는 내용이 있죠.)
Action
네비게이션바는 Left bar button을 이전 화면으로 돌아가는 네비게이션을 위해 사용하기도 하지만, 액션을 위해서 사용하기도 합니다. 주로 최상위 계층 뷰에서 '편집' 버튼으로 쓰일때가 많죠. 추가적으로 Right bar button 을 통해서도 주요 액션을 사용할 수 있도록 해줍니다. 예를들자면, + 버튼 이라거나, 글쓰기, 편집 버튼 같은 것들이겠죠. 제한된 화면 크기로 인해, 2가지 이상의 액션에는 화면 구성상 잘 사용하지 않고요.(물론 여러개를 사용할 수 있고요, 타이틀이 짧거나 한 경우, 여유롭다면 2~3개를 사용하는 경우도 꽤 있습니다.)
액션바는 이름 그대로 Action 이라는 주목적을 위해 존재한다고 생각됩니다.
여기서의 액션은 '뷰 간 전환' 이나 말 그대로의 '액션(글쓰기, 탐색 등)'이 될 수 있습니다. 기본적인 액션에 대해서는 네비게이션바와 크게 다르지 않습니다. 해당 뷰에서 사용자에게 중요한 액션을 액션 버튼을 통해 노출하고 사용자가 사용할 수 있도록 해주지요.
네비게이션바와의 차이점으로는 '액션 버튼의 갯수'가 화면 너비에 따라 정해지고, '액션 오버플로우'가 있다는 점입니다. 큰 화면이거나 영역이 많을 수록 더 많은 버튼을 보여줄 수 있다는 점은 네비게이션바와 비슷하겠지만, 액션 오버플로우를 통해 '덜 중요한 액션'들을 처리함으로써 산만함을 줄일 수 있죠. Detail 뷰로 이동하게 되는 '탐색 액션'으로 어떤 결과를 보여주려 한다면, 탐색 후 이동 된 뷰에서의 '상위 버튼'과 '이전 키'는 동일한 기능을 하게 될거고요. 글쓰기, 편집등의 액션도 물론 마찬가지겠죠. 여기서 논점이 되야 하는 부분은, 액션바 역시 네비게이션바와 마찬가지로 액션들을 처리하지만, 추가 적인 기능들이 있고, 네비게이션바에 비해 더 디테일하게 액션 버튼들을 처리할 수 있도록 해준다는 것입니다. 액션 버튼들을 통한 화면 전환 역시 마찬가지고요.
안드로이드 액션바, 우측에 고정된 액션 오버플로우
ActionBar Tab vs NavigationBar Tab, iOS Tab
이번에는 안드로이드 액션바의 탭과, iOS Segmented control, iOS Tab control
을 봐야 하는데...
아... 방대하다. 일단.. 킵.. (킵이되면 언제 작성될지 모름..)
기.승.전.개인의 취향
글을 정리하다보니,
사실 이 말을 하려고 여기까지 글을 쓴것 같다는 느낌이...
안드로이드와 iOS는 기본적인 밑바탕에서의 개념이 많이 다릅니다.
안드로이드에서의 Activity, Fragment 가 생성되고 동작하는 방식과, iOS의 ViewController 가 생성되고 동작하는 방식은 별개의 이야기죠. (개발얘기 빼려고 노력하며 적었는데 결국은...)
거기에 더해, 액션바와 네비게이션바의 사용에 대해서도 기본적으로 비슷한 기능을 하지만, 많은 차이점 또한 가지고 있죠.
기획적으로 디자인적으로, 혹은 개발적으로 같은 화면을 보여주고 같은 유저경험을 가지게 하고 싶다라는 부분에 대해서 어느정도 공감합니다만.
아직도 많은 부분에서, iOS의 성향을 따라가고 있는 부분들을 보면 아무래도 속상한 부분들이 있죠.
우리나라에서 안드로이드가 상용화 된지도, 얼추 3년이 넘은것 같네요.
그동안 저를 포함한 사용자들은 안드로이드 기반 UI 에 익숙해졌고, 안드로이드에 특화된 UX에도 익숙해져왔죠. 하지만 우리나라에서는 아직도 많은 부분에서 안드로이드 스타일 UI 와 UX 가 배제되고 있다는 느낌입니다.
사실상 우리나라 전체 스마트폰 사용 비율 중 안드로이드가 90%에 육박합니다.
적어도 수치만으로만 놓고 보자면, 안드로이드에 중점을 맞춘 애플리케이션이 되어야 하는게 맞는데도, '신기하게도' 그런 모습들은 보기 힘든 경향이 있죠.
같은 화면이라 해도 iOS/안드로이드 화면의 구성요소들이 모두 같은 필요는 없다고 생각합니다.
각 플랫폼에 적합한 뷰들을 사용하고, 사용자에게 동일한 결과를 이끌어 내는게 더 사용자 친화적이라고 생각하고요.
더욱이 저는 안드로이드, 아이폰을 동시에 쓰는 사용자는 많지 않다는 견해고요. 이렇게 사용하는 사람들은 저처럼 대부분 IT 관련업계 종사자들이고요. 많은 모바일 애플리케이션 서비스 관련 업종 종사자들조차 하나의 플랫폼에 특화된 디바이스를 사용하는것도 심심찮게 볼 수 있습니다. 일반 사용자라면, iOS 와 안드로이드 애플리케이션의 화면 구성 차이라거나, UX 차이에 대해 모르고 있을수도있습니다. 어떻게 보면, '사용자'는 모르는 부분에 대해서 '우리'가 너무 예민하게 '공통적'으로 맞추려고 한다는 생각도 많이 들고요.
물론 모든 애플리케이션들이 안드로이드 디자인 가이드대로만 작성되어야 한다는 부분은 아닙니다. 각 플랫폼에 맞는 적합한 UX 와 구성요소를, 서비스를 만드는 사람들이 이해한 후 결정을 하는 정도의 노력은 필요하지 않을까 고민을 해보게 됩니다. (심지어 안드로이드 디자인 가이드에는 '디자인 원칙' 이라는 페이지가 존재하는데도 말이죠.)
서비스를 만드는 개인의 취향이겠지만, 단순히 iOS 스타일이 더 예뻐보인다거나 안드로이드 스타일로 하면 별로 같아 보인다거나(이 또한 개인의 취향이죠. 주관적인거고요.) 하는 등의 이유로 iOS 스타일을 따라가기보다는, 혹은 역으로 안드로이드 스타일이 익숙하고 iOS는 별로니까 안드로이드 스타일 하겠어 같은 이야기는 정말 재미없고 진부한 이야기가 되버리겠죠. 그런것 보다는 'iOS 플랫폼', '안드로이드 플랫폼'의 관점에서 각 UI 구성요소들을 이해하고, 그동안 유저들에게 축적된 UX 를 이해한 후, 기본적으로는 각 플랫폼에 최적화 시키겠지만 플러스 알파로, '우리는 이런 특화된 점을 가져가고 싶다.' 가 가장 베스트가 아닐까 생각해보게되네요.
그럼 잡담 끝!
'이런 저런 이야기 > 모바일에 대한 잡담' 카테고리의 다른 글
| [월간 싱글생활연구소 3호] 소문한번 내보자 >_< // (0) | 2013.11.14 |
|---|---|
| [스마트폰 추천어플] 친구의 친구도 친구다! 신개념 SNS 링쿤(Linkoon)! (0) | 2012.02.01 |
