탭(Tab)의 진화과정과 짧은 생각
탭(Tab)의 진화과정과 짧은 생각
오늘은 “tab”에 대한 의견을 말씀드리고자 합니다.
결론은 ‘탭’은 그닥 좋은 게 아니니 쓰지 말자(혹은 적게 쓰자)는 것이구요^^ 아래 내용은 제 주관적인 견해이고, 좀 재미도 없으니 천천히 읽어주시고^^ 주관적으로 이해해 주세요.
이것이 우리가 쓰는 탭의 기원입니다. 어른들이 쓰시는 수첩이나 장부등에서 많이 보셨을 겁니다. 많은 정보를 기준(a/b/c 등)에 따라서 분류/정렬해 놓고 빠르게 찾을 수 있도록 하는 기능이지요.
데스크탑의 GUI 표현력이 좋아지면서, 또한 작은 모니터에 많은 정보를 표현해야 하는 상황이 많아지면서, GUI는 위의 탭 – 메타포를 차용하게 됩니다.
그리고 브라우저/윈도우의 발전에 따라, 이 탭도 같이 진화하게 되고, 의미도 조금씩 바뀌기 시작합니다.
탭간의 연속성이 없어졌구요. 작은 영역에 몰아넣는 기능이 주된 역할이 되었습니다.
조금 평면적이 되면서 ‘선택된’페이지가 맨 앞으로 오게 되었습니다. 원래 탭의 감수성이 희석된 것이죠.
이런 진화를 따라 탭도 모양을 바꾸게 되는데요.
원래의 ‘탭’과는 다르게 ‘메뉴의 나열’형태가 되어 버립니다. 뭐, 여기까지는 나쁘지 않습니다. 어찌됐건, 여기까지는 – 아래 이미지처럼 -하나의 탭과 한 페이지(브라우저)가 1:1 대응하니까요.
웹이 발전하면서, 웹 UI도 이 ‘탭 메타포’를 차용하기 시작합니다.
여기서부터 조금 문제가 생기기 시작합니다.
window (browser) GUI에서는 탭 하나가 포함하는 영역이 명확했지만, 웹에서는 탭이 ‘어디까지 담는지’ 명확하게 보이지 않게 됩니다. (위 이미지에서 탭이 아래 전체를 포괄하는 것일까요, 아니면 위의 표만 담는 것일까요. ^^)
또한, 아래와 같은 문제도 생기게 됩니다.
여기서, ‘웹에서의 탭’은 기능을 하나 더 부여받습니다. 한 눈에 많은 정보를 보여줘야 하는 상황을 해결하는 가장 단순한 솔루션으로 거듭난 것입니다. (문제는, 가장 단순하고 ‘편한 아이디어이지, 항상 정답은 아니라는 것!!)
여기서부터 (디자이너로서) 탭이 맘에 안들기 시작합니다. ^^
이미 종이노트의 ‘탭’메타포/감수성이 많이 사라진 상황에서 ‘상투적으로’ 가로로 길게 씀으로써 지나치게 가로지향적이 되고, 화면 밀도 관리가 어려워지게 됩니다. 웹을 해 본 디자이너라면 한 번쯤 하게 되는 “왜 한 눈에 다 보여줘야 하지?” 같은 불만도 이쯤에서 터지지요. ^^
이 탭들이, 굳이 ‘탭’이어야 할까요? 메뉴리스트와 무슨 차이가 있을까요? ^^
여기까지가, 디바이스 GUI 이전까지의 ‘탭’의 진화 역사입니다.
위와 같이, ‘탭’은 여러가지 찜찜함을 안고서 디바이스까지 진입하게 됩니다. 그리고, 위의 고민을 한 우리의 선배들은 (특히 palm, apple) 다음과 같은 아이디어로 다시 탭을 단순화시킵니다.
아래 메뉴를 ‘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’이 되는 겁니다. ^^
브라우저의 크기가 가변적이어서 어디를 구획해야 하는지 지정해줘야 했던 ‘웹에서의 탭’의 역할이, 크기가 고정된 디바이스로 들어오면서 다시 초기 윈도우-탭의 역할로 돌아가게 된 것입니다.
그런데…
여전히 우리는 이와 같은 UI들을 자주 보게 됩니다. 뭐, 클라이언트의 요청이었는지 고민이 적었는지는 알 길이 없지만요. ^^
“첫 뷰에서 무슨 메뉴가 있고 그 안의 대표 메뉴를 보여주고 싶은데 탭 말고 방법이 있나요?” 라는 질문에 대해서 애플 가이드라인은 다음을 제안합니다.
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 ^^
많이들 안쓰시는 키보드 분리기능. ^^
전 가끔 아이패드를 두 손으로 쥐고 서서 타이핑할 때 위와 같이 분리해서 쓰곤 하는데요.
위에 표시된 것과 같이, 키판이 없는 영역을 눌러도 다른쪽에 있는 끝 쪽 글자가 눌러진답니다. 재밌습니다. 멋집니다. ^^
(이와같은 깨알같은 GUI 팁들만 모아놓은 사이트는 여기)
– BS Kim (가치디자인그룹)[catlist name=”Design Tip” numberposts=5 excerpt=”yes” pagination=”yes” excerpt_size=”0″ title_only=”yes“]