태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'opera mini'에 해당되는 글 2건

  1. 2012.07.31 모바일용 웹 브라우저의 'Tab 전환 방식'에 대한 사례 분석 (3) by 김 동후
  2. 2010.03.24 아이폰 웹브라우저 페이지 전환 : adjacent in space by 無異
2012.07.31 21:29

모바일용 웹 브라우저의 'Tab 전환 방식'에 대한 사례 분석



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를 통해 탭을 이동시킵니다. 


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에서는 별도의 '설정 패널'을 제공하고 있습니다. 리모컨을 화면 위로 불러와서 컨트롤 하는 방식으로 생각하시면 됩니다.
탭 전환만을 위한 패널이 아니기 때문에 사용자가 탭 전환이 필요할 때 이 패널을 바로 떠올릴지는 의문입니다.


4. 정리
Chrome의 불편한 탭 전환 방식에 놀라서 시작된 '사례 조사'를 마무리합니다. 
iOS에서 제공하고 있는 모바일용 웹 브라우저의 사례들을 살펴보면, 다양한 형태의 탭 전환 방식이 있다는 것을 확인할 수 있습니다. 그러나 그것이 디자인 차별성을 위한 것인지, UI사용성을 개선하기 위한 결과물인지는 판단할 수 없습니다.
중요한 것은, 사용자가 최소한의 노력으로 네비게이션을 할 수 있도록 도와주는 것입니다. 더불어 Chrome의 사례처럼 사용자에게 불편함을 주는 UI설계는 항상 경계해야 할 것 같습니다.

이번 블로그는 iOS 모바일용 웹 브라우저의 탭 전환 방식에 대해 이야기하고 있습니다. 관점이나 해석을 넣기 보다는 있는 그대로의 현상을 분석하는데 초점을 맞추었습니다. 따라서 너무 진지하게 보지 마시고 UI컴포넌트에 대한 상식을 넓힌다는 의미에서 글을 읽어주셨으면 좋겠습니다.



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 3
Ad Test...
2010.03.24 13:06

아이폰 웹브라우저 페이지 전환 : adjacent in space

 

아이폰의 사파리 브라우저는 모바일 스크린에서 제대로 웹을 사용할 수 있는 최초의 브라우저라는데 큰 의미가 있습니다. 폰의 작은 화면에서 웹페이지를 보려면 화면의 확대 축소가 꼭 필요하게 되는데, 아이폰의 사파리는 축소한 경우에도 이미지와 폰트를 깔끔하고 읽기좋게 렌더링하여 보여줍니다. 직관적인 핀치 제스쳐나 더블탭을 이용한 자동 폭맞춤은 확대축소 조작의 번거로움을 없애주고요. 폭맞춤 상태에서 스크롤을 하면 옆으로 삐져나가지 않고 상하로만 움직이도록 보정해주는 특허도 작지만 실제 경험적으로는 상당히 편리하고요

 

carousel 방식의 사파리의 페이지 관리

사용 효율보다는 간결하고 학습이 쉽도록 하는 애플의 UI 철학에 공감은 하면서도 폰에서 웹브라우징을 많이하다보니 사파리의 페이지(탭 또는 창) 관리 방식은 불편합니다. 하단 툴바 오른쪽의 페이지버튼을 누르면 화면이 줌아웃되면서 현재 열려있는 페이지들을 선택하는 모드가 됩니다. 이런 UI 디자인 패턴을 carousel 이라고 하는데 여러 요소를 보여주어야 하나 공간이 부족한 경우에 회전목마처럼 돌려가면서 보도록 하는 것이지요. 다른 페이지를 선택하기위해서는 한페이지씩 원하는 페이지가 나올때까지 넘기고 나서 다시 한번 tap해주어야 합니다.

검색에서 새창을 열도록 하면 다시 검색 결과 페이지로 돌아오기 위해서 이렇게 페이지 전환을 하는 경우가 빈번해서 많이 답답합니다.


 

 

오페라 미니의 페이지 전환 방식

https://www.youtube.com/watch?v=OpTCS3g-cBY&feature=player_embedded

 

이번에 아이폰용으로 발표된 오페라 미니는 페이지가 중첩되기는 하지만 한 화면에 보여서 따로 페이지를 넘기지 않아도 됩니다. 물론 썸네일 화면이 작고 제목이나 url을 표시못하는 트레이드오프는 있지만 사실 페이지를 선택하는데는 꼭 이미지가 크지 않아도 구분이 가능하거든요. 

또 오페라 미니는 전체 화면을 축소한 썸네일이 아니라 북마크에서 보이는것처럼 좌상단의 일부를 캡쳐하여 보여줍니다. 화면이 너무 작아져서 구분이 안될 수 있는 문제를 피하는거죠. 또 대부분 페이지가 좌상단에 로고를 넣거나 하여 아이덴티티 영역으로 사용하고 있기때문에 구분하는데 도움이 될것 같습니다.

새로운 페이지를 여는것도 사파리가 페이지버튼을 누른 후에 반대편에 새로운 페이지 버튼이 생기는것에 비해 바로 접근이 쉬운 위치에 생깁니다.

 

iPad의 페이지 관리

 

http://www.apple.com/ipad/features/safari.html

 

이번에 출시되는 ipad에서는 사파리의 페이지 관리가 그리드 형태로 바뀌어서 한번에 선택할 수 있게 되었습니다.

다만 새 페이지 열기가 맨 마지막에 표시되어 페이지 열린 수에 따라 항상 변하게 되는데 ipad에서는 툴바가 상단에 있어서 새페이지를 열기 위해서는 상단에 있는 페이지 버튼을 누르고 손을 많이 움직여줘야 하더라고요. 손목만 까딱하면 되는 마우스와는 달리 팔을 움직여야 하는 터치 태블릿에서는 새로운 스트레스증후군 http://en.wikipedia.org/wiki/Repetitive_strain_injury 이 나타날 수도 있을 것 같아요.

 

추가: 아이패드를 사용해보니까 아이폰에 비해서 편해지긴했지만 이 탭선택 모드로 들어가고 나오는것 자체가 짜증나더라구요. 예상대로 탭선택 버튼이 상단에(멀리) 작은 버튼으로 있어서 선택이 쉽지 않습니다. 탭선택 모드가 된 후에는 아래쪽에서 탭 썸네일을 선택해야해서 움직임이 많고요.


adjacent in space rather than stacked in time


edward tufte http://www.edwardtufte.com/ 는 항상 정보를 공간에 펼쳐놓는 것이 시간에 쌓아놓는 것 보다 좋다고 얘기합니다.

책에서는 정보요소간의 관계를 비교하고 컨텍스트를 이해하는데 있어 하나씩 하나씩 보기보다는 한꺼번에 보여주는것이 좋다는 의미로 쓰였지만 정보디자인 차원 말고도 불필요한 인터랙션을 줄여준다는 점에서 고려해볼 필요가 있습니다.

반복된 조작이 필요한 곳에서 이 원칙만 지켜지면 사용을 좀 더 편하게 할 수 있습니다. 그런데 의외로 꼭 필요하지 않은 경우에도 그냥 트렌드처럼 잘못된 디자인 패턴을 사용하는 경우가 많은 것 같습니다.

꼭 필요한 경우가 아닌데도 정보를 stacked in time 방식으로 잘못 사용된 경우가 또 어떤게 있을까요?

[참고##정보디자인##]


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...