Appbar: Bottom에 대해
고민해볼 필요가 있다
새로 업데이트된 머티리얼 디자인. 무작정 쓰기 전에 고민을 해봐야 한다.
출처 : https://material.io/design/ 지난 5월 새롭게 업데이트된 머티리얼 디자인 2.0!
기존의 획일화된 스타일과 Do, 아니면 Do not으로 엄격히 나눈 느낌이 있던 머티리얼 디자인 1.0과는 달리,
새로운 머티리얼 디자인 2.0은 다양한 스타일과, 머티리얼 디자인을 베이스로 개성 있는 디자인을 표현하는 'Material theming'. 그리고 새로운 컴포넌트들 등 정말 파격적으로 바뀌었다는 말이 어울리는 업데이트였다.
그런데 새로 추가된 컴포넌트 중 Appbars: Bottom은 보고 나서도 한동안 나를 고민에 빠지게 했다.
본문에 들어가기 앞서,
구글 I/O 익스텐디드 2018 서울 디자인 세션.
2018년 6월 9일 열린 'Google I/O Extended 2018 Seoul'에선,
Design Spectrum의 김지홍 디자이너님께서 발표하신 Review: Material Design from I/O라는 제목의
세션이 있었다.
마운틴뷰에서 열린 'Google I/O'의 현장 스케치와 새로 업데이트된 머티리얼 디자인 2.0을 간단하게 정리하는 세션이었는데, 역시나 새로운 컴포넌트인 Appbars: Bottom에 대해서도 정리해주셨다.
정말 인기가 많았던 세션. 옆 세션에서 의자를 가져오는 사람이 있을 정도로 붐볐다.김지홍 디자이너님께서 정리해 주신 Appbars: Bottom은
모바일 디바이스에서만 사용
2개~5개의 액션이 있는 스크린
꼭 FAB와 함께 사용
이렇게 Appbars: Bottom을 정리해주셨다. 그런데 내가 졸려서 잘못 필기를 한 건지, 마지막 번째인
꼭 FAB와 함께 사용
은, 구글이 제시하는 가이드라인과는 달랐다.
꼭 FAB가 있어야하는 건 아니다. 출처(https://material.io/design/components/app-bars-bottom.html#anatomy)세션이 끝난 뒤, 나는 김지홍 디자이너님께 내가 생각하고 있는 Appbars: Bottom의 문제점에 대해 어떻게 생각하시는지 여쭤봤고, 디자이너 님께선, 더 고민해볼 필요가 있는 컴포넌트이며, 국내외 여러 디자이너들도 문제점에 대해 이야기하고 있다고 알려주셨다. 그리고 Use-case가 많이 나와야 봐야 조금 더 역할 및 사용성이 명확해질 것 같다고 말해주셨다.
디자인에 정답이라는 건 없다.
그래서 나는 내가 생각하는 Appbars: Bottom의 문제점을 브런치에 정리해보려 한다.
글을 읽고 있는 당신이, 나와 같은 생각을 가지고 있을지 아니면 다른 생각을 가지고 있을지 모르겠지만
확실한 건 아무 생각 없이 내 글을 읽고 아무런 고민 없이 내 의견을 수용하진 않았으면 좋겠다.
나는 여러 경험과 고민, 실험, 토의 등으로 디자인이 발전한다고 생각하고 있기에,
자신의 의견 없이 다른 사람의 의견을 맹목적으로 수용하는 건 발전을 저하하는 일이라고 생각한다.
그럼 시작합니다!
문제점 첫 번째,
뒤로 가기는 어디에?
머티리얼 디자인이 없던 안드로이드에도 '뒤로가기'는 앱바에 있었다.사람들은 UX에 익숙해지면, 쉽게 벗어나질 못한다. 안드로이드를 계속 써온 사람에게 아이폰을 쥐어 준다면, 메뉴와 뒤로 가기 버튼이 없고, 홈 화면에 위젯이 없다는 사실에 충격을 받고 답답해 쓰러질지도 모른다.
(물론 반대로 아이폰의 UX에 익숙해지면 안드로이드를 답답해하기 시작할 것이다.)
안드로이드의 뒤로 가기도 같은 맥락이다. 어떤 어플이든 하위 액티비티에서 다시 상위로 돌아오기 위한
'뒤로 가기'는 꼭 있을 수밖에 없다. 안드로이드에선 머티리얼 디자인이 공개되지 않았던 시점에도 뒤로 가기 버튼을 앱바의 좌측에 배치했었다. 다시 말해, 언제나 왼쪽 위에는 뒤로 가기가 있었다는 점이다.
그렇다면, 앱바가 아래로 내려온 Appbars: Bottom에서는 어떻게 될까?
짜잔! 뒤로가기를 찾아보세요!위 이미지를 보고 상단 좌측을 먼저 봤다면 이미 뭔가 잘못되어있음을 알 수 있을 것이다.
Appbars: Bottom내에 있는 뒤로 가기는 안드로이드 사용자들이 빨리 인지할 수 없다. 또한 지금 보고 있는 화면이 아래 화면에서 터치를 한번 더 해서 들어간 세부 페이지라는 점과, Appbars: Bottom에 있는 왼쪽 화살표 아이콘이 다시 상위 액티비티로 돌아갈 수 있다는 점 모두 알아 채기 힘들다.
더 이상 뒤로갈 엑티비티가 없는 메인에서는 상관이 없다물론 더 이상 뒤로갈 수 있는 액티비티가 없는 메인에서는 상관이 없다.
여하튼 이러한 이유와, Temporary sufaces에 덮일 수도 있다는 이유로 인해 구글은 뒤로 가기 버튼에 대한 가이드라인을 제시했다.
Temporary sufaces에 덮힐 수도 있다고만 하지만 생각보다 더 많은 문제점이 있다"그러면 뒤로 가기 버튼을 위로 올리면 되는 문제 아닌가!"라는 생각을 할 수 있을 텐데,
물론 Appbars: Bottom을 사용해서 중요한 액션들을 인체공학적으로 편리한 위치에 배치해서
사용하기 편하게 할 수 있다. 하지만, 나는 '뒤로 가기' 역시 중요한 액션들 중 하나라고 생각한다.
(어차피 세부 화면에 들어갔으면 언젠가는 나올 거니까)
그런데 뒤로 가기는 위에, 앱바는 아래에 놓으면서 까지 할 필요가 있는지는 의문이다.
뒤로 가기에 위에 있음으로 인해, 아래로 내려간 앱바의 위치를 다른 요소들이 사용할 수 있게 된 것도 아니다.
게다가 예시 어플은 스크롤이 가능한 액티비티인데, 스크롤을 했다고 뒤로 가기가 사라지면 안 되니 플로팅을 하면, 굳이 차지할 필요 없는 공간을 사용한다고 생각한다.
엥? 이렇게 보니 왼쪽이 더 예뻐보이긴 하다Appbars: Bottom과 Appbars: Top를 비교해 봤을 때, 사용성을 뒤로 두고 보면 Appbars: Bottom이 더 깔끔해 보이긴 하다. 하지만 처음 화면을 봤을 때 볼 수 있는 텍스트 양이 2줄 차이가 난다.
왼쪽 화면에서 스크롤하면 Appbars: Bottom가 아래로 내려가서 괜찮아질 수도 있다고 생각하지만
스크롤했을 때 Appbars: Top 또한 숨길 수 있으므로 이거에 대해서는 한 번 더 생각을 해 봐야 할 거 같다
(물론 둘 다 스크롤했을 때 앱바를 숨긴다고 하면 왼쪽은 뒤로 가기가 계속 보인다는 장점이 있다. 하지만 만약 스크롤했을 때 앱바를 안 숨긴다면? 위랑 아래 둘 다 바를 플로팅 해야 하는 걸까?)
문제점 두 번째,
타이틀은 어디에?
출처 : https://material.io/design/components/app-bars-top.html#usage안드로이드에서 앱바는 내가 지금 보고 있는 액티비티가 어떤 액티비티인지 타이틀을 표시해주는 역할도 하고 있었다. 내가 스크롤을 해도 앱바는 언제나 나의 위치를 알려주었다.
하지만 앱바는 앱바지만, 아래에 있는 앱바 Appbars: Bottom는 타이틀을 가지지 않는다.
'받은 편지함' 이라는 액티비티 이름이 Appbars: Bottom의 밖에 있다.스크롤 문제는 이미 첫 번째 문제점에서 짚었기 때문에 반복하진 않겠다.
사실, Appbars: Top의 타이틀 섹션은 생각보다 많은 일을 한다. 내가 현재 있는 액티비티, 혹은 검색어, 웹페이지의 주소 등 아래 유튜브 어플처럼 여러 중요한 텍스트들을 담을 수 있다.
코너 선생님... 제발 우리 카라랑 엘리스 좀 살려주세요 아 플스4랑 디트로이드 사고 싶다여기서 잠깐! 다시 한번 우리가 언제 Appbars: Bottom을 쓸 수 있는지 생각해보자!
이럴 땐 가능합니다!
모바일 기기 일 때
2개~5개의 액션이 있을 때
이럴 땐 안됩니다!
bottom navigation bar가 있는 앱
1개의 액션 혹은 액션이 없을 때
자 그럼, 유튜브와 같은 검색 화면에는 Appbars: Bottom을 쓸 수 있을까? 몇 번 양보해서 Appbars: Bottom에 타이틀을 넣는다고 해도 검색이라는 1개의 액션밖에 없으므로 사용해선 안된다.
그러면 아래와 같은 경우는 어떻게 될까
Appbars: Bottom에서 검색 버튼을 누르면 유튜브와 비슷한 형식의 검색 액티비티로 간다고 생각해보자.
아까만 해도 아래에 있던 앱바가 위로 올라왔다! 만약 유튜브와 같은 검색 이 아니라 1개의 액션 혹은 액션이 없는 화면이어서 Appbars: Bottom를 사용할 수 없다면 Appbars: Top을 쓰게 될 텐데 어떤 화면은 앱바가 아래에, 어떤 화면은 위에 있다는 것 자체가 통일성이 없다. 이 점이 사용자들에게 불편하게 다가갈지, 아니면 놀랍게도 아무런 불편함이 없을지는 실험을 해보거나 Use-case를 찾아봐야 할 것 같다.
문제점 세 번째,
모바일이 아닐 땐 어디에?
결론부터 말하자면 계속 말해왔 듯이, Appbars: Bottom는 모바일 기기에서만 사용 가능하다.
음..... 왜 안될지 알거같다하지만 만약 모바일과 데스크톱을 모두 지원하는 서비스의 디자이너라면,
모바일과 데스크톱에 통일된 사용자 경험을 제공하고 싶을 것이다. 그런 관점에서 머티리얼 디자인은 좋은 방안이 될 수 있다. 이는 머티리얼 디자인의 목표에도 쓰여 있다.
플랫폼, 디바이스, 입력 방식에 상관없이 통일된 사용자 경험을 제공하자!그렇지만 만약 당신이 Appbars: Bottom를 사용했다면, 완벽히 통일한 사용자 경험은 제공할 수 없다!
위의 예제 이미지에서 보았다시피, 모바일에서 사용되면 '인체 공학적이고 중요한 액션을 편하게 사용할 수 있다'라는 장점이 데스크톱에서는 적용되지 않는다. 마우스를 사용하는 환경과 터치 환경과는 큰 차이가 있으니 당연한 결과다.
좌측 : iOS의 Google Task, 우측: 새로운 웹 Gmail에 있는 Google Task같은 Google Task라도, 너비가 비슷해도, 구글은 웹 버전에선 Appbars: Bottom를 사용하지 않았다.
이미 통일된 사용자 경험이라고 하기엔 차이가 있다.
Appbars: Bottom를 모바일 이외에서 사용하지 말라는 구글의 이유는 확실히 알겠으나,
Appbars: Bottom를 썼을 때, 통일된 경험을 줄 수 없다는 건 사실인 것 같다.
마치며.
블로그 포스트를 위해 이 이미지를 만드는 것 보다, 제목을 정하는게 더 오래걸렸다.정말 개인적으로 나를 만나서 "Appbars: Bottom에 대해 어떻게 생각하세요?"라고 질문했을 때, 내가 답할 만한 주장들을 글로 정리해 보았다. 글 중간에 말했다시피, 나와 다르게 생각하는 사람들이 있을 수 도 있다. 또한 내 주장들이 확실하게 검증된 것이라 말할 수 도 없다. 그저 아무 생각 없이 Appbars: Bottom을 처음 본 디자이너가 생각할 수 있는 문제점이라고 말할 수 것 같다.
만약 위 문제점에 대해 다른 생각이 있거나, 내가 제시한 것 말고 또 다른 문제점이 있다면, 아니면 정말 Appbars: Bottom으로 멋지게 해결할 수 있는 점들이 있다면, 댓글이나 페이스북 개인 메시지를 통해 나 또는 다른 디자이너 들과 활발하게 토의해보고, 디자인을 더 발전시킬 수 있는 기회가 되길 희망해 본다.
