하단 앱 바를 어떻게 사용할 것인가
새로운 UI에 대처하는 우리의 자세
얼마 전 Material Design 2.0이 발표되었습니다. 기존의 경직된 구조를 탈피한 다양한 커스터마이징, 스케치용 플러그인 등 다양한 내용이 추가되었지만 가장 눈길을 끈 것은 하단 앱 바(App bars: bottom)였습니다. 과거에는 소프트키와의 충돌을 걱정해 하단 탭조차 사용하지 않던 안드로이드가 2016년에 Bottom navigation을 추가하더니, 아예 앱 바까지 하단으로 끌어올 것이라고는 상상하기 힘들었죠. 이 글에서는 하단 앱 바가 무엇인지, 어떤 문제가 있는지, 그리고 어떻게 활용할 수 있을 것인지 이야기해보고자 합니다.
이렇게 생겼습니다특징
하단에 있다
가장 중요한 특징입니다. 사실 이게 다라고 봐도 됩니다. 하단에 있기 때문에 기존의 상단 앱 바(App bars: top)와 달리 접근성이 좋습니다. 한 손으로 핸드폰을 든 상태에서 엄지 손가락만으로 쉽게 앱 바에 접근이 가능하죠. 이로 인해 앱 바에 있는 액션들을 편리하게 사용할 수 있습니다. 가이드라인에서도 하단 내비게이션 드로어에 접근할 때(Access to a bottom navigation drawer)나 2-5개의 액션을 가진 화면에서(Screens with two to five actions) 사용하라고 하는데, 접근성이 좋기 때문에 가능한 일입니다.
FAB(플로팅 액션 버튼)가 붙어있다
FAB는 앱에서 가장 중요한 핵심 액션을 담고 있는 UI입니다. 그러나 상단 앱 바의 액션들과 떨어져 하단에 홀로 위치했습니다. 이 경우 핵심 액션이 상단에도 있고 하단에도 있어 사용자 입장에서 혼란스럽습니다. 그러나 하단 앱 바를 쓸 경우 모든 액션을 하단에 깔끔하게 모아놓을 수 있습니다. 이 때문에 가이드라인에서도 하단 앱 바와 FAB가 같이 쓰인다는 사실을 매우 강조합니다. 예시도 한두개를 제외하면 모두 FAB가 있는 케이스를 사용하구요.
무엇이 문제인가?
앱 바는 지금껏 한번도 상단에서 자리를 옮겨본 적이 없습니다. 안드로이드와 iOS 모두 항상 상단 앱 바를 사용해왔죠. 사용자 입장에서는 익숙하지 않고 불편할 수밖에 없습니다. 더 나아가 안드로이드의 많은 UI 컴포넌트들은 상단 앱 바가 있다는 전제 하에 만들어졌습니다. 그렇기에 앱 바를 하단으로 옮기는 것은 다른 컴포넌트들의 정상적인 배치에까지 영향을 끼칩니다.
2010년의 Gmail과 facebook. 이 때도 상단에 앱 바 형태의 UI를 사용했습니다탭과 함께 쓸 수 없다
안드로이드는 두 종류의 탭을 제공합니다. 상단 탭(Tabs)와 하단 탭(Bottom navigation)입니다. 많은 수의 앱이 탭을 사용하며 특히 하단 탭의 사용이 점점 증가하는 추세입니다. 하단 탭을 사용할 경우 선택된 탭에서 사용할 액션을 넣기 위해 앱 바가 필요합니다. 그러나 하단 앱 바와 하단 탭은 위치가 겹쳐 같이 사용 할 수 없습니다. 그렇기에 하단 앱 바를 사용할 수 있는 앱은 한정적입니다.
상단 탭의 경우는 조금 애매합니다. 가이드라인에서 상단 탭과 하단 앱 바를 동시에 넣는 내용은 없지만 형태를 생각하면 불가능하지는 않습니다. 일단은 쓰이지 않더라도, 이후에는 어떻게 될 지 좀 더 지켜봐야 할 것 같네요.
만들어봤는데 생각보다 어색하지 않습니다타이틀 영역이 없다
기존에는 상단 앱 바에 타이틀을 적어왔습니다. 그러나 앱 바가 하단으로 가면 타이틀을 적을 공간이 사라지게 됩니다. 이는 앱이 복잡해질수록 문제가 됩니다. 타이틀을 쓰지 않을 경우 현재 어느 화면에 있는지 파악하기가 힘듭니다. 그렇다고 타이틀을 쓰려니 앱의 상단 영역을 잡아먹게 되어 효율성이 떨어집니다.
그런데 뒤로가기 버튼의 위치는 예전과 동일하다
상단 영역이 사라지면서 타이틀 뿐 아니라 뒤로가기 버튼의 자리 또한 사라집니다. 그러나 가이드라인을 보면 뒤로가기 버튼, 닫기 버튼을 하단 앱 바에 위치시키면 안된다고 합니다. 대신 예전처럼 좌상단에 넣으라고 합니다. 이로 인해 상단 영역을 잡아먹고, 버튼이 위 아래 모두 존재하면서 일관성이 떨어집니다. 그렇다고 뒤로가기 버튼을 아래에 넣자니 소프트키와 바로 붙어 있어 우스운 모습이 됩니다. 어디에 넣기도 애매한 상황이 되죠. 다만 햄버거 버튼이 어느 화면에서나 계속 표시되어 내비게이션 드로어 접근성이 좋아진다는 장점은 있습니다.
타이틀과 버튼들이 제각각입니다앱 바를 숨기는 인터랙션이 부자연스럽다
화면을 더 넓게 쓰기 위해 스크롤 시 앱 바를 숨기는 앱이 많습니다. 밑에 있는 컨텐츠를 보기 위해 화면을 아래로 스크롤 할 때, 상단 앱 바는 컨텐츠와 같이 위로 올라가면서 사라집니다. 반대로 스크롤 할 때 다시 내려오구요. 화면과 같이 앱 바가 움직이기에 자연스럽습니다.
앱 바의 움직임이 자연스럽습니다그러나 하단 앱 바는 사라지는 방향이 반대입니다. 화면을 아래로 스크롤 할 때, 앱 바가 아래로 내려가면서 사라집니다. 컨텐츠는 위로 올라가는데 앱 바는 아래로 내려가는거죠. 반대의 경우에는 컨텐츠가 아래로 내려갈 때 앱 바가 위로 올라옵니다. 이는 기존과 방향이 반대일 뿐더러 직관에도 위배됩니다.
앱 바의 움직임이 부자연스럽습니다추가적으로 이야기하면, 가이드라인에 하단 탭 또한 스크롤 할 때 사라질 수 있다고 나와있습니다(Upon scroll, the bottom navigation bar can appear or disappear). 하단 앱 바와 같은 방향으로요. 그렇지만 구글의 앱 중 하단 탭을 적용하고 있는 유튜브, 구글 포토 등을 보면 스크롤 할 때 하단 탭이 사라지지 않습니다. 물론 여러 이유가 있겠지만 움직임이 자연스럽지 않다는 이유도 있었을 것 같네요.
모바일에서만 쓸 수 있다
하단 앱 바는 모바일 전용 UI입니다(Bottom app bars are a mobile-only component and are not applicable for tablet or desktop use). 그렇기에 스마트폰 뿐 아니라 다양한 기기에서 사용되는 서비스를 만들 경우 서비스 간 일관성이 떨어질 수 있습니다.
모바일과 태블릿에서 동일한 구조를 사용하는 경우가 많습니다그러면 언제 써야 하는가?
하단 앱 바는 탭과 함께 쓸 수 없기에 대부분 햄버거 버튼을 갖고 있습니다. 그렇기에 하단 앱 바의 활용은 내비게이션 드로어의 활용과 유사합니다.
하단 앱 바의 드로어는 하단에서 나옵니다흔히 드로어는
1) 핵심 기능 외에 다른 메뉴로 접근할 일이 적은 경우
2) 메뉴가 매우 많아 탭에 전부 담기 힘든 경우
3) 메뉴가 유동적이어서(메뉴 추가, 수정 및 삭제 가능) 탭으로 표현하기 어려운 경우
에 쓰입니다.
하단 탭 바는 엄지손가락만으로 쉽게 작업을 처리하는 것이 중요하기에 메뉴가 많은 2)에는 적합하지 않습니다. 메뉴가 많아서 손을 위로 이동해야 한다면 굳이 하단 앱 바를 쓰는 장점이 사라지는 것이죠.
1)과 하단 앱 바는 잘 어울립니다. 핵심 기능을 위한 액션을 FAB로 표현하면 유저에게 해당 기능을 더욱 강조할 수 있습니다. 또한 다른 메뉴로의 접근이 많지 않아 타이틀, 뒤로가기 등의 이슈로부터 비교적 자유롭습니다. 상단 앱 바에 비해 햄버거 버튼이 가깝고 호출된 드로어의 메뉴를 누르는 것도 쉽기에 3)에 적용해도 괜찮은 결과물을 기대할 수 있습니다. 1)과 3) 케이스의 앱을 만드신다면 하단 앱 바를 한번 고려해보시는 것도 좋을 것 같습니다.
구글도 이 점에 대해 많이 고민을 했는지 하단 앱 바에 정말 잘 어울리는 Google Tasks라는 앱을 만들었습니다. 기능은 간단합니다. 할 일을 추가하고, 다 했으면 체크하는 게 전부입니다. 화면도 목록이 나온 메인 화면, 세부정보 화면, 새 할 일을 추가하는 모달이 사실상 전부입니다. 핵심 기능이 명확하고(새 할 일 추가, 한 일 체크) 다른 메뉴로 접근할 일이 별로 없습니다. 그리고 메뉴가 유동적이어서(새 목록을 만들거나 삭제 가능) 탭으로 표현하기에는 적합하지 않죠.
메인 화면, 세부정보 화면, 새 할일 추가 모달. 매우 간단합니다요 근래 본 것 중 가장 독특한 UI다보니 첫 글을 이 주제로 시작하게 되었네요. 처음 써보는 글이라 어설픈 점이 많지만, 이런 재밌는 주제들에 대해 공유하고 같이 이야기를 나눌 수 있기를 바랍니다.
