탭(Tab)의 진화과정과 짧은 생각

탭(Tab)의 진화과정과 짧은 생각

탭(Tab)의 진화과정과 짧은 생각
Category
Share Story

오늘은 “tab”에 대한 의견을 말씀드리고자 합니다.

개인적으로는 오래된 고민입니다.
PastedGraphic-26

결론은 ‘탭’은 그닥 좋은 게 아니니 쓰지 말자(혹은 적게 쓰자)는 것이구요^^ 아래 내용은 제 주관적인 견해이고, 좀 재미도 없으니 천천히 읽어주시고^^ 주관적으로 이해해 주세요.

이것이 우리가 쓰는 탭의 기원입니다. 어른들이 쓰시는 수첩이나 장부등에서 많이 보셨을 겁니다. 많은 정보를 기준(a/b/c 등)에 따라서 분류/정렬해 놓고 빠르게 찾을 수 있도록 하는 기능이지요.

데스크탑의 GUI 표현력이 좋아지면서, 또한 작은 모니터에 많은 정보를 표현해야 하는 상황이 많아지면서, GUI는 위의 탭 – 메타포를 차용하게 됩니다.

2f807cbc1089f2db04ddf4bb0482ffc9

그리고 브라우저/윈도우의 발전에 따라, 이 탭도 같이 진화하게 되고, 의미도 조금씩 바뀌기 시작합니다.

탭간의 연속성이 없어졌구요. 작은 영역에 몰아넣는 기능이 주된 역할이 되었습니다.

조금 평면적이 되면서 ‘선택된’페이지가 맨 앞으로 오게 되었습니다. 원래 탭의 감수성이 희석된 것이죠.

이런 진화를 따라 탭도 모양을 바꾸게 되는데요.

스크린샷-2012-05-18-오후-8_08_43

원래의 ‘탭’과는 다르게 ‘메뉴의 나열’형태가 되어 버립니다. 뭐, 여기까지는 나쁘지 않습니다. 어찌됐건, 여기까지는 – 아래 이미지처럼 -하나의 탭과 한 페이지(브라우저)가 1:1 대응하니까요.

AC933-MR-Clear-Acrylic-5-ring-Round-Tab-book

웹이 발전하면서, 웹 UI도 이 ‘탭 메타포’를 차용하기 시작합니다.
여기서부터 조금 문제가 생기기 시작합니다.

PastedGraphic-44

window (browser) GUI에서는 탭 하나가 포함하는 영역이 명확했지만, 웹에서는 탭이 ‘어디까지 담는지’ 명확하게 보이지 않게 됩니다. (위 이미지에서 탭이 아래 전체를 포괄하는 것일까요, 아니면 위의 표만 담는 것일까요. ^^)

또한, 아래와 같은 문제도 생기게 됩니다.

PastedGraphic-54

여기서, ‘웹에서의 탭’은 기능을 하나 더 부여받습니다. 한 눈에 많은 정보를 보여줘야 하는 상황을 해결하는 가장 단순한 솔루션으로 거듭난 것입니다. (문제는, 가장 단순하고 ‘편한 아이디어이지, 항상 정답은 아니라는 것!!)

여기서부터 (디자이너로서) 탭이 맘에 안들기 시작합니다. ^^

이미 종이노트의 ‘탭’메타포/감수성이 많이 사라진 상황에서 ‘상투적으로’ 가로로 길게 씀으로써 지나치게 가로지향적이 되고, 화면 밀도 관리가 어려워지게 됩니다. 웹을 해 본 디자이너라면 한 번쯤 하게 되는 “왜 한 눈에 다 보여줘야 하지?” 같은 불만도 이쯤에서 터지지요. ^^

( 읽을자료 ) 사람들은 스크롤하지 않는다?

이 탭들이, 굳이 ‘탭’이어야 할까요? 메뉴리스트와 무슨 차이가 있을까요? ^^


 

여기까지가, 디바이스 GUI 이전까지의 ‘탭’의 진화 역사입니다.


위와 같이, ‘탭’은 여러가지 찜찜함을 안고서 디바이스까지 진입하게 됩니다. 그리고, 위의 고민을 한 우리의 선배들은 (특히 palm, apple) 다음과 같은 아이디어로 다시 탭을 단순화시킵니다.

PastedGraphic-71

아래 메뉴를 ‘tab bar’로 정의해 버린 것이죠.

iOS interface Guidelines에서는 탭 바를 이렇게 규정합니다.
A tab bar gives people the ability to switch between different subtasks, views, or modes.

탭의 진화 마지막은 ‘메뉴’와 다르지 않았으니, 이걸 ‘tab’이라 규정해버린 겁니다. tab(:색인)과 tap(:두드리다)의 말장난도 한 몫 했을거구요. ^^

원래 우측에 있던 ‘종이탭’이 윈도우를 통하면서 상단으로 올라갔고, 이제 손으로 조작이 용이하단 이유로 하단으로 내려온 것이죠. 그리고, 이제 본화면 (custom content 부분) 안에 들어가는 탭은 무조건 ‘tab in tab’이 되는 겁니다. ^^

브라우저의 크기가 가변적이어서 어디를 구획해야 하는지 지정해줘야 했던 ‘웹에서의 탭’의 역할이, 크기가 고정된 디바이스로 들어오면서 다시 초기 윈도우-탭의 역할로 돌아가게 된 것입니다.

그런데…

mzl_nfrkzhyy_320x480-75

여전히 우리는 이와 같은 UI들을 자주 보게 됩니다. 뭐, 클라이언트의 요청이었는지 고민이 적었는지는 알 길이 없지만요. ^^

“첫 뷰에서 무슨 메뉴가 있고 그 안의 대표 메뉴를 보여주고 싶은데 탭 말고 방법이 있나요?” 라는 질문에 대해서 애플 가이드라인은 다음을 제안합니다.

segmented_control

scope_bar_with_search

segment (세그먼트 콘트롤) 과 scope bar(스콥 바)가 그것입니다.

Segmented Control
A segmented control is a linear set of segments, each of which functions as button that can display a different view.

Scope Bar
A scope bar allows users to define the scope of a search. A scope bar is available only in conjunction with a search bar, and is often displayed below it.

모양이 ‘현대화된 탭’과 다르지 않지요^^ 하지만, 제시하는 것은 분명히 다릅니다.

1. 이 가이드라인은, 화면의 한계를 제시함으로서 위의 지마켓과 같은 ’여러 콘트롤의 난립’을 방지하려는 수단입니다.

2. 일정한 위치를 선점함으로써 최상의 퍼포먼스를 유지하기 위함입니다.

물론, 이것이 위의 질문에 대답은 되지 못합니다. 좀 개발자 중심의 이야기지요. ^^

사실 위의 지마켓 디자인은, “한 눈에 더 많은 정보를 보여줘!!!” 라는 클라이언트의 요청이 가장 컸겠지요. ^^

“숨기면 안돼!!!”
“이것도 중요하고 저것도 중요해!!”


여기부턴 저희가 ‘전문가로서 클라이언트를 설득해야 하는 영역’이라고 생각합니다. ^^

결론이 애매하지만, 제가 드리는 요점은 이겁니다.

1. 웹과 디바이스의 통일성은 디자인 요소에서 이루어져야 하지 구조/기능을 가져오려고 해서는 안된다.

2. 그런 의미에서 탭은 디바이스에서 재정의 되었으므로, 또한 이미 포지셔닝이 애매해져버린 UI 도구이므로, 모바일에선 재번역해서 쓰거나, 신중하게 사용해야 한다.

3. 이해하지 못하는 클라이언트(혹은 기획자^^)들은 최대한 설득해보고, 그게 가능할 만큼의 힘(!)을 키우자.

 

감사합니다.

 

ps. 재밌는 UI tip ^^

PastedGraphic-34

많이들 안쓰시는 키보드 분리기능. ^^
전 가끔 아이패드를 두 손으로 쥐고 서서 타이핑할 때 위와 같이 분리해서 쓰곤 하는데요.

위에 표시된 것과 같이, 키판이 없는 영역을 눌러도 다른쪽에 있는 끝 쪽 글자가 눌러진답니다. 재밌습니다. 멋집니다. ^^

(이와같은 깨알같은 GUI 팁들만 모아놓은 사이트는 여기)

 

– BS Kim (가치디자인그룹)[catlist name=”Design Tip” numberposts=5 excerpt=”yes” pagination=”yes” excerpt_size=”0″ title_only=”yes“]