모바일용 웹 브라우저의 'Tab 전환 방식'에 대한 사례 분석
2012. 7. 31. 21:29ㆍUI 가벼운 이야기
1. 탭 전환 방식에 관심을 가지게 된 계기 :
iOS 용 Chrome이 나왔다고 하여 사용해보았습니다.
Chrome의 전체적인 사용성에 대한 언급은 따로 하지 않겠습니다.(워낙 분석을 잘 해놓은 분들이 많으니까요) 어쨌든.
필자는 Chrome의 여러가지 특징 중에서 'Finger Action'을 통한 탭 전환 방식에 대해서 주목하게 되었습니다.
Chrome에서는 One Finger Swipe를 통한 탭 전환 방식을 제공하고 있습니다. 두 개 이상의 탭이 열려있으면 좌/우 Swipe를 통해 탭 이동을 할 수 있도록 하는 기능입니다.
Chrome의 Swipe 탭 전환 방식은, 간단한 동작으로 화면 전환이 가능하고 Content area의 어느 위치에서든 Finger Action이 적용되기 때문에 특정한 버튼을 찾아 가지 않고도 탭을 전환할 수 있는 장점이 있습니다. 그런데 이러한 인터랙션으로 인해 (매우) 불편한 점이 있다는 것을 경험하게 되었습니다.
탭 전환을 위한 Swipe를 하였는데 화면 내의 메뉴가 이동한다!!
그렇다고 메뉴 전환이 완벽하게 되는 것도 아니다.
액션이 충돌하면서 탭 전환도 되지 않고, 메뉴 전환도 중간에 멈추는 현상이 발생한다.
위의 이미지는 모바일 네이버 화면입니다. 모바일 전용 사이트의 경우 좁은 화면을 효과적으로 활용하기 위해 메뉴(탭) 이동간 Swipe를 활용하는 경우가 많습니다. 바로 이 부분에서 문제가 발생합니다. One Finger Swipe라는 하나의 Finger Action속에, 두 가지의 컨트롤 요소(브라우저의 화면 전환, 사이트 내부의 메뉴 이동)가 충돌하게 되면서
사용자의 실수를 유발하게 된다는 것입니다. 물론 범위를 명확하게 구분지어 주고 Swipe동작을 취해주면 실수는 줄일 수 있습니다. (테스트를 해 본 결과, 탭 전환의 경우 화면 끝에서 끝, 사이트 내의 메뉴(탭) 전환의 경우 메뉴가 가진 영역 내에서 동작을 취해줘야 컨트롤 할 수 있습니다.) 하지만 굉장히 신경을 쓰면서 동작을 취해도 원하는 방향으로 100%컨트롤이 되지 않습니다.
이 시점에서 '모바일 웹 브라우저에서 효과적인 탭 전환 방식은 무엇일까? 어떤 종류의 탭 전환 방식이 있을까?'라는
생각을 하게 되었습니다.
생각을 하게 되었습니다.
2. 글을 쓰는 목적
이 글에서는 다양한 모바일 웹 브라우저를 분석하여, 탭 전환 방식에 대한 사례들을 정리해보려고 합니다. 특별한 솔루션을 제안하려는 글이 아닙니다. 개인적인 관점이나 해석은 최대한 배제하려고 하였으며 있는 사용자의 입장에서 '있는 그대로의 현상'을 분석하는데 초점을 맞추고 있습니다.
이 글에서는 다양한 모바일 웹 브라우저를 분석하여, 탭 전환 방식에 대한 사례들을 정리해보려고 합니다. 특별한 솔루션을 제안하려는 글이 아닙니다. 개인적인 관점이나 해석은 최대한 배제하려고 하였으며 있는 사용자의 입장에서 '있는 그대로의 현상'을 분석하는데 초점을 맞추고 있습니다.
결론을 미리 말씀드리면 '(절대적으로)가장 좋은 탭 전환 방식은 없다'라고 생각합니다. 소프트웨어의 컨셉이나 구현 방식에 맞는 탭 전환 방식을 선택하고 화면에 적용하면 된다고 생각합니다. 따라서 이번 글은 UI컴포넌트에 대한 상식을 넓힌다는 의미에서 부담없이 봐주셨으면 좋겠습니다.
3. 사례 분석
현재 App store에 나와 있는 Web Browser 중에 6개의 사례를 분석하였습니다.
대상은 다음과 같습니다. Safari, Chrome, Opera Mini, Mercury, Atomic Lite, Dolphin
위의 Browser를 분석해보니 현재 Mobile Web Browser에서의 탭 전환 방식은 크게 3가지로 구분됩니다.
1) Tab 방식
2) Swipe 방식
3) Visual Tab 방식
4) 기타
1) Tab 방식
모바일 뿐만 아니라 PC 환경의 웹 브라우저에서도 일반적으로 사용되는 방식으로 가장 일반적인 탭 전환 방식입니다
가장 직관적이고 시각적으로 명확한 탭 전환 방식이라고 할 수 있습니다. 다만 화면 내에 일정한 영역을 필요로 하기
때문에, 화면이 작은 모바일 환경에서는 비효율적인 요소가 되기도 합니다. 그래서 일부 앱에서는 탭 영역을 숨길 수 있도록 하는 기능을 두기도 합니다. Mercury, Opera Mini, Dolphin 브라우저가 Tab 방식을 적용하고 있는 대표적인 사례입니다. 가로폭이 좁은 모바일 화면에서 구현하다보니 보통 2.5개의 Tab을 노출시켜주고 있으며 Swipe를 통해 탭을 이동시킵니다.
때문에, 화면이 작은 모바일 환경에서는 비효율적인 요소가 되기도 합니다. 그래서 일부 앱에서는 탭 영역을 숨길 수 있도록 하는 기능을 두기도 합니다. Mercury, Opera Mini, Dolphin 브라우저가 Tab 방식을 적용하고 있는 대표적인 사례입니다. 가로폭이 좁은 모바일 화면에서 구현하다보니 보통 2.5개의 Tab을 노출시켜주고 있으며 Swipe를 통해 탭을 이동시킵니다.
2) Swipe 방식
좌우 Swipe를 통해 탭을 전환하는 방식입니다. 간단한 동작으로 탭을 전환할 수 있다는 장점이 있습니다. 또한 탭 영역이 화면에 노출되지 않기 때문에 공간적으로도 이득을 볼 수 있습니다. 그러나 화면 내에 좌우 Swipe를 필요로 하는 요소가 있다면 인터랙션이 충돌하는 경우가 발생하게 됩니다. 하나의 동작에 두 개의 기능이 영향을 받을 수 있다는 것입니다. 때문에 사용자가 의도하지 않은 결과가 나올 수 있게 되며 이것은 사용성을 저하시키는 요인이 됩니다.
그러나 일부 앱에서는 인터랙션 충돌에 대한 문제점을 Two Finger Swipe 방식으로 보완하고 있습니다.
Mercury와 Atomic Lite의 경우 Two Finger Swipe를 탭 전환 방식으로 제공하고 있으며
화면 네비게이션을 위한 One Finger Swipe와 탭 전환을 위한 Two Finger Swipe를 명확하게 구분하고 있습니다.
때문에 동작의 충돌로 인한 불편함이 줄어들었습니다. One Finger Swipe의 단점을 보완해주는 좋은 해결책이라고 생각합니다.
Dolphin의 경우, 사용자가 제스처를 지정할 수 있는 기능을 제공합니다. 물론 현재 버전의 Dolphin에는 '탭 전환을 위한 제스처 지정'은 제공하지 않습니다. 하지만 탭 전환에도 제스처 기능을 제공한다면, 동선이 겹치지 않는 범위 내에서 사용자가 원하는 제스처를 지정하여 탭 전환을 편리하게 할 수 있을 것입니다. 이러한 방향도 하나의 해결책이 될 수 있다고 생각합니다.
3) Visual Tab 방식
Tab에 Thumbnail 형태의 미리보기를 제공하는 방식입니다. Opera Mini, Chrome, Safari 에서 위와 같은 방식의 전환 방식을 제공하고 있습니다. Thumbnail 이미지를 통해 이동하려는 페이지를 명확하게 식별할 수 있는 장점이 있습니다.
Opera의 경우 메인 화면에 불러오는 방식으로 되어 있으며, Chrome/Safari의 경우는 버튼을 눌러 Visual Tab 화면으로 이동하여 선택하는 방식으로 되어 있습니다. 같은 방식이지만 디자인 방향 따라 사용자가 느끼는 차이가 클 것으로 생각됩니다.
4) 기타
Mercury에서는 별도의 '설정 패널'을 제공하고 있습니다. 리모컨을 화면 위로 불러와서 컨트롤 하는 방식으로 생각하시면 됩니다.
Mercury에서는 별도의 '설정 패널'을 제공하고 있습니다. 리모컨을 화면 위로 불러와서 컨트롤 하는 방식으로 생각하시면 됩니다.
탭 전환만을 위한 패널이 아니기 때문에 사용자가 탭 전환이 필요할 때 이 패널을 바로 떠올릴지는 의문입니다.
4. 정리
Chrome의 불편한 탭 전환 방식에 놀라서 시작된 '사례 조사'를 마무리합니다.
iOS에서 제공하고 있는 모바일용 웹 브라우저의 사례들을 살펴보면, 다양한 형태의 탭 전환 방식이 있다는 것을 확인할 수 있습니다. 그러나 그것이 디자인 차별성을 위한 것인지, UI사용성을 개선하기 위한 결과물인지는 판단할 수 없습니다.
중요한 것은, 사용자가 최소한의 노력으로 네비게이션을 할 수 있도록 도와주는 것입니다. 더불어 Chrome의 사례처럼 사용자에게 불편함을 주는 UI설계는 항상 경계해야 할 것 같습니다.
이번 블로그는 iOS 모바일용 웹 브라우저의 탭 전환 방식에 대해 이야기하고 있습니다. 관점이나 해석을 넣기 보다는 있는 그대로의 현상을 분석하는데 초점을 맞추었습니다. 따라서 너무 진지하게 보지 마시고 UI컴포넌트에 대한 상식을 넓힌다는 의미에서 글을 읽어주셨으면 좋겠습니다.