프로그래머를 위한 사용자 인터페이스 설계론 제7부: 바쁜 사용자들에게 어필하는 설계, 제 2 편

글 : Joel Spolsky
번역 : AhnLab
2000년 4월 27일 목요일

Bruce "Tog" Tognazzini (이하 Tog)는 애플 개발자 잡지에 UI에 대한 칼럼을 기고했다. 그의 글에는 많은 사람들이 지적하고 있는 UI 디자인 상의 문제점이 흥미롭게 기술되어 있다. 이러한 칼럼은 Tog의 웹사이트에 현재까지 실려 있으며, 나중에 집대성되어 Tong on Software Design과 같은 위대한 책에 실리게 되었다. Tog on Software Design은 UI 디자인에 대한 위대한 개론서로 상황을 흥미롭게 기술하고 있다 (Tong on Interface란 책이 더 훌륭하지만, 이 책은 지금 절판된 상태다).

Tog은 mile high menu bar 개념의 창시자로, 이를 통해 화면의 상단에 항상 붙어 있는 매킨토시의 메뉴 바가 윈도우의 메뉴 바보다 사용하기 쉬운 이유를 밝히고 있다. 윈도우에서는 각 애플리케이션 윈도우 내에 메뉴 바가 등장한다. 윈도우에서 파일 메뉴로 가려면 가로 1인치 옆, 세로 0.25인치 위로 이동해야 한다. 좌우로 상당히 정확하게 마우스를 움직여야 한다.

그러나 매킨토시에서는 마우스를 바로 스크린의 맨 위로 가져가면 된다. 얼마나 높이 있는지 생각할 필요도 없이 스크린 맨 끝까지 이동하면 된다. 사실상 클릭할 대상 메뉴가 가로로 1인치 옆에, 세로로 1마일 위에 있기는 하지만, 사용자는 이러한 수치를 생각할 필요 없이 위로 커서를 옮기는 것만 걱정하면 된다. 따라서 메뉴 아이템을 클릭하는 것이 그만큼 쉬워진다.

이러한 원칙에 근거해 Tog는 깜짝 퀴즈를 낸다: 스크린에서 마우스를 가장 쉽게 이동시킬 수 있는 5군데는 어디인가? 대답은 스크린의 4개 코너 부분 (이 지역에 마우스를 갖다 대기만 하면, 특정한 위치를 지정하지 않아도 된다)과 마우스의 현재 위치가 된다.

mile-high menu bar의 원칙은 매우 잘 알려져 있지만 완전히 이해되지는 못한 것 같다. 윈도우 95의 시작버튼 디자인을 볼 때, 윈도우 95 팀은 이 원칙을 완전히 잘못 이해한 것 같다. 윈도우의 시작 버튼은 스크린의 왼쪽 거의 맨 아래쪽에 자리잡고 있지만 완전한 왼쪽 코너를 아니다. 바닥과 스크린 왼쪽에서부터 각각 2 픽셀씩 떨어져 있다. 이점을 생각해 볼 때, 마이크로소프트는 “승리를보장하는기술을사용했지만실패를본” 그러한 경우라고 Tog는 기술하고 있으며, 이 때문에 시작 버튼을 클릭하기가 더욱 힘들었다고 말한다. 비록 스크린이 길이 1마일의 네모판에 지나지 않기 때문에 마우스로 클릭하는 것은 사실 별것이 아닐 수 있다. 하지만 무슨 이유에선지 몰라도 이것은 사실 별 것이 될 수 있다. 이에 대해 제대로 설명을 하려면 너무 복잡하여 하나님의 도움이 필요할 것 같다.

전 장에서 우리는 사용자들이 대화상자를 읽는 것을 얼마나 싫어하는지 이야기했고, 일을 수행하는데 문제가 생기지 않는 한 이를 읽지 않으려 할 것이라는 사실도 다루었다. 비슷한 이야기를 좀 더 해 보겠다.

사용자는마우스를제대로사용할수없다.

이 말을 액면 그대로 받아 들여서는 안된다. 여기서 의도하고자 하는 바는 프로그램을 디자인 할 때 마우스를 여러 번 사용하도록 해서는 안된다는 것이다. 여기에는 6가지 이유가 있다.

1. 종종 사용자들은 마우스 이외의 다른 포인팅 기기를 즉 트랙볼, 트랙패드, IBM 노트북 ThinkPad에 있는 붉은색 버튼을 사용하는데 이들은 마우스보다 사용하기가 더 어렵다.
2. 종종 사용자들은 그다지 좋지 못한 상황에서 마우스를 사용한다. 아주 복잡한 책상, 마우스가 고르게 작동하지 못하게 하는 더러운 트랙볼, 5달러짜리 싸구려 마우스라 제대로 작동하지 않는 경우들을 생각할 수 있겠다.
3. 어떤 사람들은 컴퓨터에 익숙하지 않아 마우스를 정확하게 사용하는 것에 미숙할 수 있다.
4. 어떤 사람들은 말 그대로 아무리 연습해도 결코 마우스를 제대로 사용할 수 없는 경우가 있다. 예를 들어 관절염이 있다거나, 손이 심하게 떨린다거나, 손목 관절에 이상이 있는 경우, 이외 기타 장애가 있는 경우 나이에 관계없이 마우스를 제대로 사용할 수 없다.
5. 마우스를 움직이지 않고 같은 자리에서 더블클릭을 하는 것이 굉장히 어렵다고 많이들 생각한다. 따라서 이들은 애플리케이션을 실행하려 할 때, 스크린에서 애플리케이션을 종종 드래그하게 된다. 이런 사람들은 데스크톱을 확인해 보면 금방 알 수 있는데, 프로그램을 시행하려 할 때 2번 중 1번 꼴로 아이콘들을 이동시키기 때문에 이들 컴퓨터의 바탕 화면이 엉망이 되어 있다.
6. 비록 최적의 상황에서도 마우스를 사용하는 것이 매우 느리게 느껴질 때가 있다. 만약 디자이너가 마우스를 사용한 다단계 운영을 실행하도록 한다면, 사용자들은 진전이 없다고 생각할 것이고, UI가 제대로 반응을 하지 않는다고 생각해 무척 답답해 할 수 있다는 것을 알아야 한다.

옛날 내가 엑셀 관련 일을 할 때, 노트북에는 내장된 포인팅 기기가 없었고, 마이크로소프트는 키보드 옆면에 끼울 수 있는 clip-on 트랙볼을 만들었었다. 지금은 손목과 손가락으로 마우스를 사용한다. 마치 노트에 글씨를 쓰는 것과 마찬가지이다. 초등학교에 다닐 때 사람들은 습자연습을 하고 글씨쓰기를 배운다. 그러나 트랙볼은 엄지손가락으로만 작동하는 것이다. 그 결과 마우스와 동일한 정확성을 갖도록 트랙볼을 통제하는 것은 훨씬 더 어렵다. 대부분의 사람들은 1~2픽셀 정도의 작은 오차 범위 내에서 마우스를 사용하고 있다고 생각하는데 트랙볼을 사용하는 경우 오차는 3~4 픽셀 정도로 커진다. 본인이 엑셀 팀에 있었을 때, 항상 스텝들에게 마우스만이 아닌 트랙볼을 사용한 새로운 UI를 고안해 낼 것을 강조하였다. 또한 이들에게 자기가 원하는 대로 정확하게 마우스를 옮길 수 없다면 사람들이 어떤 기분이 들겠는지를 생각해 보라고 말하곤 했다.

가장 껄끄러운 UI 요소 중 하나는 바로 아래의 그림과 같이 밑으로 메뉴가 늘어지는 드롭다운 콤보 리스트 박스이다.

 

오른쪽의 바닥을 향하고 있는 화살표를 클릭하면 다음과 같이 확장된다.

 

 

생각해 보라. ‘Times New Roman’이라는 글자체를 선택하기 위해 얼마나 많은 마우스 클릭을 해야 하는가? 우선 화살표를 클릭해야 하고, 그리고 나서 스크롤 바를 사용해 Times New Roman이 나올 때까지 조심스럽게 밑으로 내려가야 한다. 이런 드롭다운 양식의 메뉴는 한 번에 2~3개 정도의 아이템을 볼 요량으로 디자인 된 것이기 때문에 특히나 이렇게 글자체의 선택이 많은 경우 계속 스크롤링 하는 것이 결코 쉽지 않다. 조심조심 엄지 손가락을 움직이거나 (움직일 수 있는 폭이 좁기 때문에 제대로 작동하지 않을 것이다), 화살표를 계속 클릭하거나 또는 엄지와 다른 손가락 사이의 공간을 클릭하려고 애를 써야 할 것이다. 그러나 엄지 손가락이 너무 낮게 되면 더 이상 작동하지 않고, 사용자는 더욱 애로를 느낄 것이다. 우여곡절 끝에 Time New Roman까지 도달했다고 해도 이것을 다시 한번 클릭해야 한다. 만에 하나 클릭을 제대로 하지 못하면 처음부터 다시 시작해야 한다. 각 장을 새로 시작할 때 예쁜 글씨체를 사용하기 위해 이런 절차를 10번 정도 더 겪어야 한다면 사용자는 진짜 짜증이 날 것이다.

Poxy 콤보 드롭다운 방식은 더 많은 짜증을 유발한다. 모든 옵션이 포함될 정도로 충분하게 드롭다운을 한다면 이 문제는 아주 간단히 해결될 것이다. 현재 사용되고 있는 콤보 박스의 90%는 드롭다운을 할 수 있는 공간이 충분히 없으며, 이는 디자이너가 잘못하고있는것이다. 만약 메인 편집 박스와 스크린 아래 부분 사이에 공간이 충분하지 않다면, 그룹다운은 모든 아이템을 보여줄 수 있도록 커져야 한다. 스크린의 맨 위에서 맨 아래까지의 모든 공간을 차지한다고 해도 이렇게 하는 것이 옳다. 만약 위에서부터 아래까지 모든 공간을 채우고도 더 나열될 아이템이 있다면 마우스를 모서리에 가져갔을 경우 자동 스크롤이 되어야 한다. 불쌍한 사용자가 작디 작은 스크롤 바를 움직이느라 고생하도록 해서는 안된다.

덧붙여 콤보가 화면에 나타나기 전 편집 박스의 오른 쪽으로 이동하기 위해 작은 화살표를 클릭해야 하는 데 이는 바람직하지 않다. 콤보박스 위의 어느곳을 클릭해도 이동이 되게끔 하는 것이 바람직하다. 이렇게 되면 클릭 대상물을 10배 정도 확대하는 셈이 되고 마우스로 목표물을 클릭하기가 훨씬 쉬워진다.

마우스 사용과 관련된 또 다른 문제점인 편집 박스에 대해 살펴보자. 이미 알고 있을 수도 있는데 매킨토시의 모든 편집 박스는 두툼하고, 널찍하고, 굵은 글씨체인 시카고 체를 사용한다. 그다지 예쁘지 않아서 그래픽 디자이너들을 끝없이 실망시킬 수 있다. 그래픽 디자이너들 (UI 디자이너들과는 달리)은 얇고, 다양하고, 다양하게 스페이스를 준 글자체가 더 예쁘고 보기에 좋고 읽기도 쉽다고 생각한다. 사실 다 맞는 이야기이다. 그러나 그래픽 디자이너들은 이러한 지식을 책에서 배운 것이고 실제로 스크린에서 체험을 통해 배운 것은 아니다. 텍스트를 편집할 때, 모노 스페이스가 더 유리하다. “I”와 “i”와 같은 얇은 글자는 분별하고 선택하기가 쉽다. 이러한 사실은 사용 용이성 테스트를 받고 있는 한 60세 노인을 관찰한 후 알게 되었다. 이 노인은 각고의 노력을 들여 Fillmore Street라는 거리 이름을 편집하려 하고 있었다. 이때 우리는 8포인트 크기의 Arial 글자체를 사용했고, 다음과 같은 모습을 하고 있었다.

 

                               

 

여기에서 “I”와 “L”은 넓이가 1픽셀 정도이다. 밑의 박스에서도 “I”와 “L”역시 너비가 1픽셀이다 (밑의 예에서는, “RN”과 “M” 를 구별하기가 힘들기 때문에 편집 박스의 단어는 Fillrnore처럼 보인다).

만약 Filimore나 Fiilmore, Fillrnore로 잘못 타이핑을 하더라도 이를 알아차릴 사람은 많지 않다. 심지어 알아차렸다 해도 이들은 상당한 시간을 들어 눈에 잘 들어오지 않는 글자를 선택하고 정정하기 위해 마우스를 사용해야 할 것이다. 이들은 하나의 알파벳을 선택하기 위해 2 픽셀 정도 크기의 깜빡이는 커서를 사용하는 것을 몹시 힘들어 했다. 아래의 예처럼 만약 굵은 폰트 (Courier Bold체)를 사용했더라면 작업은 훨씬 쉬었을 것이다.  

 

                   

 

더 많은 공간을 차지하는 것은 사실이다. 그래픽 디자이너들이 싫어할 수도 있다. 하지만 어쩌겠는가. 이렇게 함으로써 사용이 더 편리해 지고 편집도 더 쉬워질 수 있다.

---

일반적으로 프로그래머들은 다음의 사고 패턴을 가지고 있다. 만약 3개의 숫자 즉 0, 1, n이 있다고 가정하고, n이 사용되는 경우 모든 n이 동일해야 한다는 것이다. 이러한 생각은 0이나 1을 제외하고는 코드에 어떠한 상수도 포함시킬 수 없다라고 믿기 때문에 비롯되었다. (아마 사실일 것이다) (0과 1 이외의 상수는 “마법의 숫자”라 불린다. 여기에 대해서는 더 이상 거론하고 싶지 않다.)

예를 들어 만약 여러 개의 문서를 열 수 있는 프로그램이 있다면, 이 프로그램은 또한 무한히 많은 문서 (기억할 수 있는 한) 혹은 프로그래머 들이 인정하는 유일한 마법의 수인 최소한2^32개의 문서를 열수 있어야 한다고 믿는 경향이 프로그래머들 가운데 팽배하다. 만약 20개의 문서밖에 열 수 없다면 프로그래머들은 이를 무시할 것이다. 20이 뭐지? 왜 20개지? 

모든 n이모두동일하게가능해야한다 생각은 프로그래머들로 하여금 사용자들이 윈도우의 크기를 조정해 이동한다면, 사용자들이 윈도우의 위치 선택을 할 때 가장 마지막 픽셀까지 유연성이 완벽하게 보장되어야 한다라고 생각하도록 만들었다. 결국 윈도우를 스크린 맨 윗부분에서 2픽셀 밑에 위치시키는 것이 윈도우를 정확하게스크린 맨 위에 두는 것과 “동일하다”는 것이다. 

그러나 이는 사실이 아니다. 사실 윈도우를 스크린의 맨 위에 꼭 붙여야 할 이유는 많다 (이렇게 함으로써 스크린의 크기가 커진다). 그러나 스크린의 맨 윗부분과 윈도우의 상단에 2픽셀의 간격을 둘 이유는 전혀 없다. 고로 현실적인 관점에서 볼 때, 0은 2보다 훨씬 더 유사하다.

WinAmp 을 제작한 Nullsoft의 프로그래머들은 지난 10여 년간 자신들의 발목을 잡아왔던 이러한 프로그래머들의 고정 관념에서 벗어날 수 있었다. WinAmp에는 훌륭한 특성이 있다. 윈도우를 스크린의 모서리 부분으로 가까이 끌어다 놓아, 둘 사이 간격이 몇 픽셀 안으로 들어오게 되면, 윈도우는 자동적으로 스크린 모서리에 철썩달라붙는다.  0이 2보다 가능성이 많다는 것을 고려할 때, 사용자가 바라는 것이 바로 이러한 기능 아닐까? (Juno의 메인 윈도우도 비슷한 특성을 보여준다. 이 프로그램은 내가 본 프로그램 중 스크린 위에서 “박스 안에 위치해 있고”, 가장자리를 넘어서 끌어다 놓기를 할 수 없는 유일한 프로그램이었다.)

약간의 유연성은 상실하겠지만 대신, 마우스를 정확하게 작동하는 것이 힘들다는 생각이 반영된 그러한 사용자 인터페이스를 갖게 될 것이다. 왜 이렇게 해야 할 것인가? (모든 프로그램이 사용할 수 있는)이러한 혁신은 아주 지혜로운 방법으로 윈도우 관리의 짐을 덜어 준다. 자신의 UI를 자세히 살펴보고 잠시 휴식을 취하라. 우리가 고릴라 혹은 영리한 오랑우탄이라고 가정해 보자. 그러면 마우스를 사용하는 것이 얼마나 힘든지 알게 될 것이다.