Honeycomb을 계기로 생각해본 Touch UI Homescreen의 방향

예전에도 Touch UI는 어떤 것인지 정의하고 어떻게 가야하는지 고민을 한참 하던 시절이 있었습니다. 그에 대해서는 조만간 별도로 포스팅하려고 합니다. 이번에는 최근 발표된 Honeycomb(Android 3.0)을 살펴보면서 현재 출시된 OS들의 Homescreen에 대해서 생각해보겠습니다.

Google Android

먼저 >Honeycomb을 살펴보겠습니다.
>Google Officially Posts Android 3.0 Sneak Peak, Touts “Holographic” UI
>CES 2011 | 베일벗은 안드로이드 3.0 ‘허니컴(Honeycomb)’

약간 아리송한 것은 Honeycomb이 tablet용이라고 발표된 것입니다. 그리고 여러 곳에서 Android tablet의 발표가 이어지고 있습니다. 그렇다면 스마트폰용 Android는 >Gingerbread 이후 어떻게 되는 것일지 모르겠네요. 차후 상황을 지켜봐야 하겠지요.

비교해볼 수 있도록 Gingerbread의 UI도 보겠습니다.
>Google Nexus S
Gingerbread UIGingerbread UI

어쨌든, Honeycomb은 tablet을 위한 OS라서 그런지 Gingerbread와는 homescreen이 많이 다릅니다. 기능도 많고 page flicking도 다르네요. 이로써 구글은 Android OS 2종류와 Chrome OS라는 3가지 OS를 운영하게 됐습니다. 언젠가 Android가 Chrome OS와 통합되지 않을까 했던 예상은 늦어지거나 틀리게 될 수도 있을 것 같습니다.
하지만 Homescreen의 구조를 보면 Android는 widget 방식이 기본이라는 것을 알 수 있습니다. 물론 short cut을 제공하는 menu 화면도 존재하고, homescreen에는 widget과 short cut(icon)을 섞어서 배치할 수 있습니다. 즉, App을 실행하면 App만의 UI를 가지고 있고 widget UI도 제공하면서 menu에서는 short cut도 있다는 것이 됩니다. Short cut의 역할은 명확하므로 특별할 것은 없겠죠. 다만 widget은 다릅니다.
Widget은 이전부터 있었던 UI 요소입니다. PC에서부터 있던 오래된 방식이지요. 별도의 실행 없이 언제든지 쉽게 내용을 살펴보거나 간단한 기능을 실행할 수 있는 장점이 있지요. App을 실행하지 않아도 homescreen에서 task를 처리할 수 있다는 장점은 있지만, widget마다 서로 다른 별도의 UI를 가지고 있으기 때문에 사용자는 많은 학습이 필요하고 귀중한 homescreen의 넓은 공간을 차지합니다. Honeycomb에서도 아무 곳에나 배치할 수 없고 미리 정의된 grid에 snap되는 것 같더군요. 또한 widget으로 간단한 작업을 할 수는 있지만 결국 실제 필요한 기능을 실행하려면 해당 App을 찾아서 실행해야 합니다. App의 모든 기능을 widget화할 수 없고 어떤 기능을 widget으로 만들지에 대해서도 정의하기 어려운 문제입니다.
개발의 측면을 봐도 background로 계속 실행되고 있어야 하기 때문에 리소스를 계속 점유하고 있으며 task 관리가 어렵다는 단점도 분명합니다. 필요한 App으로 진입이 쉽고 App UI가 충분히 쉽다면 widget의 제공이 왜 필요한지에 대해서는 개인적으로 의문을 버리지 않을 수 없네요.

Apple iOS

Apple도 iPad를 내놓으면서 App들의 UI를 새로 디자인했지만 기본적으로 homescreen의 디자인과 구조는 다르지 않습니다. iOS의 익숙한 모습과 같지요. 기본적인 Alert과 Notice방식도 같구요. 한번 볼까요.
>Apple iOS4.2

iOS는 위의 이미지를 통해 명확히 파악할 수 있죠. iPhone의 Homescreen은 기존 feature phone의 복잡하고 어려운 UI 구조를 한방에 깨버리고 depth를 없애버린 단순하지만 대단한 paradigm shift였습니다. 핸드폰 제조사의 현장에서 느낀 것은 분명히 그런 정도였었죠.
보통 UI를 평가할 때 기준이 몇 번의 touch와 depth 이동이 필요하고, 사용자가 얼마나 빨리 그 경로를 파악해서 필요한 task를 성공적으로 실행하느냐가 기준입니다. 그런데 기존의 평가 기준으로 갖다대기가 어려울 정도로 iPhone의 homescreen은 단지 한 두번의 touch로 필요한 기능에 진입합니다. depth로 따지면 1 depth인 것이죠. 이것은 정말 단순하지만 ‘직관적인 Touch UI’의 기준을 보여준 것이었습니다.
각각의 App들이 grid로 homescreen에 배치되고 customize가 쉬우면서 직관적입니다. 페이지 이동을 빼면 터치 한번에 원하는 기능을 실행할 수 있습니다. 이보다 쉽고 직관적일 수가 없습니다. 처음 써보거나 심지어 컴맹이나 애기들 조차 한 두번 터치해보고 쉽게 이해하고 사용합니다. 복잡하지도 않으니 에러도 적습니다.
그러니 누구나 이렇게 단순하고 쉬운 Homescreen을 만들고 싶었겠지만 똑같이 따라할 수는 없었습니다. 그래서 많은 곳에서 고민을 했고 선택할 수 있는 가장 좋은 다른 방법은 widget 방식의 homescreen입니다. iOS외의 다른  OS들은 디자인은 다르지만 widget 방식의 homescreen 구조를 채택했습니다. 다른 OS들을 확인해보겠습니다.

다른 OS들의 Homescreen

먼저 HP가 인수한 Palm의 >WebOS2.0입니다. 인상적인 실적을 올리지는 못하고 있지만 >Palm이 출시되었고 >Palm pad도 있습니다. 2월 9일이면 더 추가된 >내용을 알 수 있겠죠.

App들의 스크린샷이 Panel이 되고, 각 panel이 widget같은 역할을 하며 별도의 widget도 존재합니다. Panel은 실제 app의 UI와 동일하지만 homescreen에 배치된 형태는 widget이라고 할 수도 있겠죠. Multitasking에 강점을 가졌다고 하는데 사용자가 많은 것을 기억해야 하기도 합니다.

그리고 다음은 MS의 >WM7의 UI를 보겠습니다. WM7은 자신들만의 특화된 homescreen을 보여주고 있습니다. 그런데 단순하게 생각하면 각각의 tile과 hub들이 widget이라고 볼 수 있을 것 같습니다. 디자인에 주력해서 스타일리쉬하지만 단순하고 쉬울 것 같지는 않습니다.

Widget이 대세가 될 것인가?

결론적으로 저는 widget은 가장 직관적이고 쉬운 Touch UI의 homescreen은 아니라고 생각합니다. 그 이유는 앞에서 언급한 사용사 측면과 개발 측면의 문제들 때문이지요. 현재 Touch UI는 Lock화면 – Homescreen – App 의 구조를 가지고 있습니다. 제조사나 OS 측면애서 가장 중요한 부분은 역시 homescreen이라고 할 수 있습니다. 그런데 Apple iOS에서 가장 단순한 방식을 가져간 상태에서 Android를 비롯한 다른 OS는 widget을 내세우게 됐습니다. 예전에 UI trend를 예상할 때 widget이 거론되기도 했습니다만, 이 부분은 OS에서 관리하는 부분이고 분명하게 in-house UI의 영역이 될 수밖에 없습니다. 어떤 OS도 App에게 widget이 될 수 있는 권한을 주기는 어려울 겁니다.(HP WebOS는 가능할지도)

iPhone이 왜 사용이 쉬운가 라는 부분은 많은 분석이 나올 수 있겠지만 저는 가장 큰 이유를 homescreen과 거기서 나오는 단순한 UI 구조를 꼽습니다. 하지만 다른 OS들이 다양한 형태의 widget으로 대응하는 한 숫적으로는 widget이 적용된 디바이스가 더 많아지겠죠. 이제 Touch UI의 시대가 되었고 사람들은 적응하고 있습니다. 개인적으로 더 좋은 형태의 Touch UI/UX가 기준이 되었으면 싶지만, 이 문제는 여러 부분에서 영향을 받을 수 밖에 없을 거라고 생각이 됩니다. App이나 Content쪽이 아닌 제조사나 사업자 등의 in-house UI와 관련된 분들은 widget의 디자인과 역할에 대해서 많은 고민을 해야 할 것이구요.

One thought on “Honeycomb을 계기로 생각해본 Touch UI Homescreen의 방향”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>