새삼스러운 일은 아니지만 Google은 시장을 대하는 태도가 전체적으로 불친절하고 이런 점은 항상 불만이었다.
다른 Google 서비스야 거의 독점적이고 Web 기반 서비스라고 백번 양보해도 Android의 경우에는 직접 서비스하는 것이 아니고 통신사/제조사 등의 기존 통신시장의 이해 관계자들이 활용할 수 있도록 제공하는 간접적인 서비스(?)라는 측면에서 그 불친절함이 시장을 혼란에 빠뜨리는 것이 아닌가 생각한다.
초기 HTC에서 G1/G2가 출시되었을 때만 해도 듣보잡이었던 플랫폼이 빠른 발전을 거듭하면서 양적인 측면에서는 iOS와 함께 모바일 플랫폼의 양대 축으로 자리 잡았지만 질적인 측면에서는 아직 많은 공격을 받는 것이 사실이고 그 바탕에는 플랫폼 진화 과정에서 Google의 불친절함이 자리잡고 있다고 본다.
[MENU], [HOME], [BACK], [SEARCH] 의 4개의 물리적인 키가 필요하던 초기 플랫폼 버전에서, 요구하는 물리적인 키가 많아 단말의 Form Factor에 제약이 발생할 수 있어서 단말 디자인 경쟁력이 떨어진다는 시장의 의견을 적극 반영하여 구글의 핵심 경쟁력과 직결된 [SEARCH]키를 과감하게 OPTION으로 처리하고 플랫폼에서 대안을 제시하는 것을 보았을때 시장과 적극 소통할 것이라 예상을 했었다.
그러나, 거기까지가 Google의 한계였는지 아니면 의도적으로 움직이는지는 확인할 수 없지만, 새로운 플랫폼이 나올 때마다 그 플랫폼의 컨셉이나 진화 방향에 대해서 구글은 시장과 소통하는데 적극적인 모습을 보이지 않고 있다.
이러한 구글의 행보로 인해서 Android 플랫폼이 시장이 선보인지 2년이 넘게 지나고 있는 이 시점에 통신사, 제조사, 3rd party 개발사들이 시장에 제공하는 최종 산출물을 보면 아직도 갈피를 잡지 못하고 우왕좌왕하거나 결과물을 생산해내기에 급급한 모습으로 비춰지고 있다고 본다.
특히, Android 4.0인 ICS(Ice-cream sandwich)를 사용하다보면 플랫폼 정체성에 의문을 가지게 된다.
지금까지 여러 공격에도 불구하고 [MENU], [HOME], [BACK]키라는 물리적인 키를 이용한 플랫폼의 UI/UX 컨셉을 유지하였고, 시장에서 사용자들이 플랫폼 사용법에 대한 기본적인 학습이 완료되었다라고 볼 수 있는 시간이 지난 이후에 [MENU]키를 삭제하고 SOFTKEY 체계로 플랫폼의 큰 틀을 흔들어 놓음으로써 시장에 굳이 새로운 혼란을 유발할 필요가 있었는지 의구심이 든다.
만약, 플랫폼의 큰 틀을 흔들어 놓을만큼 그 컨셉과 방향성이 중요하다면 여러가지 방법을 통해서 시장 관계자들에게 그 타당성을 설득하고 공감대를 얻어서 새로운 플랫폼에 맞춰 시장이 빨리 변화할 수 있도록 적극적으로 노력하는 것이 맞다고 본다.
불과 얼마전에 여러 경로로 공유된 Android UI Design Patterns를 보면 몇가지 예가 나오는데, Android 공식 Site보다 훨씬 구체적이고 필요한 사항에 대해서 더 잘 설명이 되어 있다. 물론 대부분의 내용은 Google Developer Day 2010에서 발표된 Roman Nurik’s의 slide를 인용하였기는 하지만 이러한 내용은 당연히 Android 개발자 공식 Site에서 적극적이고 지속적으로 알리는 것이 당연해 보이는데 왜 소극적으로 대응하는 것인지 안타까울 따름이다.
ICS 버전을 사용하면서 이상하다고 느끼는 몇가지 사례를 살펴보면,
우선 보통의 경우에 Application을 실행하면 아래 facebook 공식 어플처럼 [BACK], [HOME], [TASK], […] 이렇게 4개의 버튼이 보인다. [MENU]버튼이 OPTION처리 되어 […]로 표현된다는 점만 본다면 ICS 버전에서 어느 정도 수긍할 수 있는 변화라는 생각을 할 수 있겠다.
하단 가장 우측에 있는 […]버튼을 선택하면 Option Menu를 보여주는 방식도 기존 Gingerbread버전까지와 별반 다르지 않아 평범하다.
아래 Seesmic application의 경우에도 별반 다르지 않아 보인다.
그런데, Seesmic application은 […]버튼을 클릭하면 동일한 동작임에도 불구하고 Option menu 보여지는 방식이 다르다. 아직 ICS 버전 관련해서 자세한 내용을 파악하지 않아서 어떠한 차이에 의해서 발생하는 변화인지는 잘 모르겠지만 일단 동일한 동작에 대해서 다른 방식으로 보여지는 것 자체가 사용자에게 혼란을 줄 수 있는 충분한 여지가 있어 보인다.
그렇다면 여기서 추정할 수 있는 것은 facebook application이 ICS 버전에 대응하지 않은 것이고 Seesmic application이 ICS 버전에 맞춰서 동작한다고 볼 수도 있을 듯 하다.
보통 Android에서 Application의 Best practice를 찾기 위해서는 Android에 기본 탑재된 Google Mobile Service Application을 참고하게 되는데, 이 시점에서도 동일하게 ICS에 탑재된 Gmail application을 살펴보면 딱히 그런것 같지도 않다.
[…]버튼의 위치가 [BACK], [HOME], [TASK] 등의 SOFTKEY 영역에 있는 것이 아니고 Gmail만의 별도 기능 아이콘 옆에 배치되어 있다.
Gmail만 보면 Application에서 Option을 처리하는 UI guideline이 변경된 것처럼 생각할 수도 있으나 Gtalk application을 보면 […]버튼이 상단 ActionBar 맨 우측에 위치하고 있다.
이쯤되면 오기가 생겨서 이것 저것 안볼 수가 없다. 그래서 확인한 Google Calendar application은 더 가관이다.
월별 일정 화면에서는 Gtalk과 별반 다르지 않아서 넘어가고 상세 일정 화면을 클릭했더니 상단 좌측에 있는 아이콘이 [BACK]키와 동일한 동작을 한다.
Android UI guideline에서 하지 말라고 하는 그 동작이다.
이 외에도 ICS 버전을 쓰다보면 이해할 수 없는 것들이 몇가지 있는데 지금까지 문제라고 나열한 이런 내용들이 아직 ICS를 이해 못한 내 잘못이라고 생각하고 싶다.
앞으로 ICS를 더 써보고 여기저기 기웃기웃하면서 귀동냥을 더 많이하면 Google의 깊은 뜻을 이해할 지도 모르겠지만 아직까지는 잘 모르겠다.
그냥 누가 친절하게 알려주면 좋겠다. 그 ‘누구’가 Google이면 더 좋겠고.. 쩝!
왼쪽 상단 아이콘을 눌러서 전 메뉴로 돌아가는 건 ics에서 무지 흔히 나타나지 않나요? 메시지 앱이랑 전화번호부 앱도 같은 흐름이 나타납니다 (…) 버튼은 액션바에 두는 걸 기본으로 한 것 같아 보이지만 아직도 혼란 그 자체죠.
이렇게 휙휙 바꿔대는 게 구글 다운 거긴 한데. 누구 말마따나 하드웨어 안 만들어 본 티를 낸달까요. ㅎㅎ
저런 백버튼은 허니콤시절 부터 나온겁니다. 그리고 단순한 백버튼이 아니라 완전히 홈으로 가도록 설계 되어있을 겁니다.
상단 왼쪽 아이콘은 백버튼이 아니라 up버튼일겁니다. 다른 어플에서 왔을때 백버튼 누르면 그 어플로 돌아가지만 저버튼을 통해들어온 어플의 초기화면으로 갈수있게하는 용도입니다.
그외는 대부분 동의하는 문제들이네요 ㅠ 구글..
1. 상단 왼쪽 아이콘이 BACK버튼이 아니라 기능 HOME이나 UP버튼으로 말씀하시는 분들이 계신데, Android Honeycomb 이전 버전까지 Activity Stack 을 깨고 이동하는 Flow가 없었는데 쌩뚱 맞게 도입된 기능이라는 점을 말씀드리고 싶고,
2. Honeycomb 버전부터 있었다고 해서 그 기능이 타당하다고 생각하지는 않습니다. Google이 UI guideline에서 [BACK] 버튼을 넣지 말라는 것은 그 기능에 대한 의미가 아니라 [BACK]키에 의해서 동작하는 UI flow를 해치는 요소이기 때문에 넣지 말라고 한 것으로 이해하고 있습니다. 그 연장선 상에서 그게 BACK이던 UP이던 사용자 입장에서 이전 화면으로 돌아가는 경험은 동일하기 때문에 같다고 판단했습니다.
고민이 많으실듯… 워쩌라구~~ 하고 싶으시죠?
안드로이드 4.0에서의 가장 큰 특징은 진저브레드와 허니콤의 통합인거 같습니다..
쌩뚱맞은게 아니구요. 4.0부터 태블렛과 핸드폰을 통합해서 그래요.
위 글에서 “back와 같은동작을 한다”는 말은 틀리지만 일반 유저 입장에서는 그렀게 생각할 수 있겠네요.
오히려 상단에 있는 화살표 방향이 위로 되어있으면 윈도우 처럼 up키 라고 생각할 수 있을텐데 아쉽네요.
제가 쓴 글의 일부 표현이나 각론에 대해서 언급을 하시는 분들이 계신데, 개발자 입장에서 Gingerbread와 Honeycomb 통합이라는 것은 의미가 있겠지만 결국은 그 플랫폼을 사용하는 시장에게는 어떤 메시지를 주는 것일까요?
“사용자들에게 Tablet과 핸드폰을 통합한 UI이니 헷갈려도 당분간 써라~” 이렇게 주장해야 할까요?
아직 Android가 iOS에 비해서 UI/UX 적으로 취약하다고 공격을 받고 있는 상황이고 시장이 무르익지 않아서 혼전을 거듭하는 이 시점에 굳이 ICS라는 UI로 시장에 혼란을 유발해야 맞는 것일까, 기존 UI의 개선으로 해결가능한 부분이 있지 않았을까 하는 의문으로 느끼는 바를 기술했습니다.
그리고, 사소한 개선이 아닌 혁신에 가까운 이러한 거대한 변화라면 Google에서 좀더 적극적으로 시장에 설득을 하거나 해명을 하는 것이 맞지 않을까 하는 부분이 결론입니다. 지금까지 Android에 대한 Google의 노력은 시장에서 플랫폼을 이해하기에는 턱없이 부족했다고 봅니다.
이 글을 포스팅하고 얼마 후에 Google이 Android Design (http://goo.gl/mraFa) 이라는 공식 site를 통해서 ICS 이후 Android의 UI에 대해서 신경을 쓰는 부분은 시장에 긍정적일 것이라고 생각합니다.
사실 Gingerbread와 Honeycomb이 합쳐진것이라고 말하지만, 겉으로만 합쳐진듯 보일뿐, 사실 타블렛용으로 만든것은 타블렛용으로, 휴대폰용 앱으로 만든것은 휴대폰용으로 계속 이중적인 코드가 존재합니다. 다시말해, 하니콤용으로 만들었던 HD급용 타블렛 앱이 알아서 자동으로 4.0 스마트폰 (non-tablet) 용으로 맞춰서 돌지 않고 (해상도도 다르고), 폰용으로 돌려면 다시 2.3용 호환되게끔 짜나가야 2.3, 4.0용 폰을 모두 지원하는 거죠. 결국, 겉은 4.0 이지만, 내부에는 타블렛을 위한 허니콤 연장선상에서의 개발과 2.3의 연장선상에서 스마트폰용으로 개발을 해야한다는 측면에서 2개를 만들어야 합니다. 이번 UI 변경때문에, 앱 메뉴 설계도 버젼별로 잘 운영해야 하고… 에고고 해상도, OS 버젼별, 플랫폼별, 거기다 기존의 99%인 프로요/진저브레드 호환성 감안하려면 장난아니게 버젼구성이 많아집니다. 끄응…
1. 화면 하단에 …이 보이면 HC 이상을 지원하는 앱이 아닙니다. 화면 상단의 액션바라는 영역에 “액션 아이콘”이 위치하고 더 이상 표시할 공간이 없을 경우에 …을 표시하고 풀다운리스트를 보여주는게 HC 이상의 방식입니다. GB 이전의 앱이 자연스럽게 마이그레이션이 되지 않는 것이 아쉽지만 풀 하드웨어 가속에 대한 실험에서도 여러 레거시 앱이 망가질 수 있다는 것이 테스트된 상황이니 어떻게 할 방법은 없을 겁니다.
2. 액션바는 ICS에서 상하단으로 분리될 수 있게 되어 있습니다. (스플릿 뷰) 휴대폰 포트레이트 형태의 낮은 가로 여백을 고려한 것입니다. 액션바가 절반으로 나뉘어 화면의 상단, 하단으로 표기되도록 할 수 있고 XML에 split 설정만으로 가능하고요. 타블렛에서는 하단의 바(바텀바)와 상단의 바(액션바)가 하나로 통합되어 나타납니다. 물론 휴대폰에서 랜드스케이프 모드로 가면 스플릿 뷰는 사라집니다.
3. 화면 상단에 있는 “<"는 업 네비게이션입니다. 안드로이드의 Back 버튼은 백 네비게이션이죠. 둘의 차이는 명확합니다. 후자는 액티비티 스택을 기준으로 한 이전 상황으로 돌아가는 것이고 전자는 플래그먼트나 엑티비티의 계층 구조를 감안한 이동을 하게 해주는 것입니다. 사용자 입장에서 이전 화면으로 돌아가는 경험이 동일하다고 하셨는데 전혀 동일하지 않습니다.
이는 사용자의 행동 패턴을 반영한 것입니다. 카메라 촬영을 한 후 갤러리로 이동하게 된 경우 Back을 눌러서 이전 액티비티 스택으로 가는 것은 액티비티 스택 상의 시나리오지 실제 사용자의 시나리오는 아닙니다. 사용자는 연속적으로 사진을 촬영한 후 바로 갤러리로 이동해서 연속적인 사진을 확인하고자 합니다. 이 경우에 갤러리에서 Up 네비게이션을 누르면 사진 목록을 보면서 사용자는 즉시 여러 사진을 편집하거나 선택할 수 있습니다.
백 네비게이션이 호출자/피호출자 간의 연속적인 관계였다면 업 네비게이션은 같은 앱에서 사용자가 연속적인 동작을 하는 것에 더 비중을 맞추고 있습니다. 백은 애플리케이션 보다는 시스템적인 것이고 업은 애플리케이션에 종속된 개념이죠.
4. ICS는 HC 이후의 개선된 UI를 정제하면서도 휴대전화의 특징을 고려해서 가능한 적은 코드 작업으로 타블렛과 휴대폰에서 적합한 사용자 경험을 보여주도록 노력하고 있습니다. ICS가 막연히 타블렛과 휴대폰등을 고려해야 해서 기존보다 비용이 증가된다고 말하는 것은 근거가 약해보입니다.