'Fitts' Law' 검색 결과 2건

  1. 2008.12.12 인터페이스 사용성 정량화 (4)
  2. 2008.06.22 제대로 베끼기 - 마이크로소프트, 애플, Fitts' Law. (16)
The Humane Interface 3장에 이어 4장 스터디를 끝냈습니다. 4장의 주제는 정량화(quantification) 입니다. 키워드는 GOMS, 인터페이스 효율성, Fitts' Law, Hick's Law 입니다.


1. GOMS

GOMS는 Goals, Operators, Methods, and Selection rules의 약자로 사용자와 컴퓨터 사이에서 일어나는 인터랙션을 작은 단위들로 환원하기 위한 모델입니다. 이 책에서 저자는 단순화된 키보드입력 수준의 GOMS를 소개하고 있는데, 예를 들면:
마우스를 잡고 있던 손을 키보드 위로 옮기고(homing), 세자리 숫자를 입력한 후(keying, keying, keying), 엔터(keying)를 친다.
라는 일련의 동작은
HKKKK
로 표현됩니다. 근데 키보드 위로 옮긴 다음 숫자를 입력하기 전에 사용자가 "뭘 입력할지" 떠올리는 시간(mentally preparing)이 잠깐 필요하다면
HMKKKK
가 되겠죠.

이런 설명을 듣고 나면 전 항상 이런 궁금증이 생깁니다. 이렇게 환원해서 뭘 어쩔건데? 이거 왜 하지?

뭐 다양한 응용을 할 수 있겠지만 인터페이스의 효율성을 측정하고 개선하는 일에 응용할 수 있겠습니다. 예를 들어 keying은 0.2초, homing은 0.4초, m은 1.35초라고 하면, 위 인터페이스를 이용하여 작업을 완수하는데 걸리는 시간은
0.4 + 1.35 + 0.2 + 0.2 + 0.2 + 0.2
가 됩니다. 이런 식의 측정을 통해 화씨/섭씨 변환 UI의 효율성을 개선하는 사례를 소개하고 있습니다.


2. 인터페이스 효율성

저자는 인터페이스 효율성이라는 재미난 개념을 소개하고 있는데요, 쉽게 말하면 사용자가 인터페이스를 통해 컴퓨터에게 실제로 제공한 정보의 양이 컴퓨터가 과업을 수행하기 위해 필요한 정보의 양에 가까울수록 인터페이스의 효율성이 높다고 보겠다는 개념입니다. 전자가 후자에 비해 낮을 수는 없으므로 효율성은 0 에서 1 사이의 값을 갖습니다.

뭐 열역상에서의 효율성이나 정보이론에서의 효율성과 다르지 않은 개념입니다만, 이걸 인터페이스에 이렇게 적용한다는 시각이 재미난거죠. 정보이론의 전통을 따라 인터페이스가 필요로하는 정보량은 비트(bit) 단위로 계산합니다. n가지 선택사항 중 한가지를 고르는 문제가 요구하는 정보량은
log2n
이 됩니다. 설명을 읽어보니 사용자가 화면을 보며 이진검색(binary search)을 한다고 가정한 모양입니다. 그 가정이 맞건 안맞건 이 모델이 예측하는 바가 실제 실험 결과와 유사하다고 하니 저 같은 사람은 그냥 그런갑다 하고 넘어가면 되겠습니다. ㅎㅎ

여기까지 읽으면 또 아까랑 비슷한 의문이 생기죠. 인터페이스의 정보량 왜 측정하는데?

이게 인터페이스가 달성할 수 있는 효율성의 이론적 하한선을 규정해주기 때문입니다. 즉, 언제 디자인에 대한 투자를 멈춰도 좋은지에 대한 쓸만한 판단 기준이 된다는 얘기죠. 이렇게 써놓고 보니, 저자의 아들이 2년 전에 썼던 글 "Know when to stop designing, quantitatively"이 생각납니다. 아버지와 달리 그림도 좀 넣어주고 설명도 좀 친절하단 말이죠 ㅎㅎㅎ


3. Fitts' Law

Fitts' Law는 쉽게 말해서 클릭하기 좋게 만들려면
  • 버튼 크기를 키우던가,
  • 버튼을 화면 구석(변이나 모서리)에 놓던가,
  • 마우스 이동 거리를 짧게 만들던가.
하라는 얘기입니다.

버튼 크기를 키우자는 얘기는 뻔한거라 생략하고, 버튼을 화면 구석에 놓은 사례는 MacOS의 메뉴(항상 화면 상단에 있습니다), MacOS의 Dock(항상 화면 하단 혹은 측면에 있습니다) 등을 떠올리시면 됩니다. 윈도XP의 시작메뉴는 예전 글에서 설명한 이유로 인해 매우 부적절한 사례입니다.

마우스 이동 거리를 짧게 만든 사례는 마우스 우클릭을 하면 버튼 바로 옆에 나타나는 컨텍스트 메뉴, 오피스 2007에 추가된 미니툴바 등을 들 수 있겠습니다:

참고로, Fitts' Law는 수식으로 쓰자면 아래와 같습니다:
a + b log2(D/S + 1)
a,b는 대상 환경에 따라 실험적으로 정해야하는 변수이고 D는 이동거리, S는 버튼의 크기입니다. 여기에도 log가 나오는군요.


4. Hick's Law

Hick's Law는 화면에서 뭘 고르려고 할 때 요소가 많아지만 많이질수록 시간이 늘어난다는 법칙입니다. 에 근데, 그냥 늘어나는게 아니라 base를 2로 하는 log 함수에 따른다는 얘기. 식으로 만들면 Fitt's Law랑 똑같다죠:
a + b log2(n + 1)
이렇게 적어놓고 보면 재미난 함의들이 몇 가지 보입니다. 그 중 하나를 책에서 인용하자면:
하나의 메뉴에서 8개의 선택 항목 중 하나를 선택하는 것이 2개의 메뉴에서 4개의 항목 중 하나를 선택하는 것 보다 빠르다.
라는 것입니다. 과연 그럴까 싶지만 통제된 상황에서 측정해보면 그렇다고 합니다.


5. 결론 혹은 저자가 강조하고자 하는 바

결론은 1) UI의 많은 요소가 정량화 가능하다. 2) 실제로 정량화/측정을 하건 안하건 각 법칙이 갖는 함의들을 체화하여 모든 디자인 과정에서 적절히 녹여내는 것이 중요하다. 입니다. (재미난 점 하나. 이 글 2, 3, 4번 섹션에 각각 수식이 하나씩 나오는데 전부 똑같이 생겼습니다. --; 세상은 로그라능 ㅋ)

PS: 아니 그러고보니, 오늘은 대머리장군님이랑 규하횽아랑 시비가 붙었던 시비시비로군요.

신고
MS의 애플 GUI 베끼기는 어제 오늘 일이 아닙니다(90년대에 이미 Apple은 MS를 고소했었죠). 물론 MS가 그대로 베끼기만 한 것은 아니고 나름 개선도 했습니다. 문제는, 원래의 아이디어에 담긴 의도를 제대로 파악하지 못한 상태에서 개선을 시도하는 바람에 개선 아닌 개악이 된 부분이 좀 있다는 것.


1. Fitts' Law

대표적인 예가 메뉴의 위치입니다. 애플의 OS에서는 예로부터(Lisa부터 Leopard에 이르기까지) 항상 모니터의 최상단 부분에 메인 메뉴가 고정됩니다. 반면 MS Windows에서 각 창의 메인 메뉴는 해당 창의 제목(title bar) 밑에 붙습니다. 하지만 창 밑에 달려 있는 메인 메뉴는 모니터 상단에 있는 메인 메뉴에 비해 상대적으로 마우스 조작이 어렵습니다. Fitts' Law를 무시하고 있기 때문이죠.

사용자 삽입 이미지사용자 삽입 이미지
(메뉴가 모니터 상단에 고정된 Leopard / 메뉴가 창 밑에 달려 있는 Windows XP)


Fitts' Law란 간단히 설명하자면 마우스를 이동시켜서 특정 위치에 놓는 작업이 얼마나 쉬운지는 마우스의 이동 거리와 목표 지점의 넓이에 의해 정해진다는 법칙입니다(원래의 Fitts' Law에는 총 네 개의 변수가 관여합니다. 단순화를 위해 생략). 즉 많이 이동하는 것 보다는 조금 이동하는 것이 좋고, 작은 버튼보다는 큰 버튼이 좋다는 얘기입니다.

Fitts' Law의 발음

Designing for Interaction의 번역서를 보니 Fitts' Law를 피쳇의 법칙으로 옮겨놓고 사람 이름도 피쳇으로 만들었던데 이거 좀 오역이겠죠?

아마도 Fitts' Law의 발음이 fitzez law(Fitts 에 소유격인 어포스트로피 s가 붙어서 표기는 Fitts' 로 하고 읽기는 fitzez로)라서 "피쳇의 법칙"이라고 했을텐데 우리 말로는 그냥 피츠의 법칙이 맞는 것 아닐까요?

Fitts' Law에 따르면 모니터 화면의 가장자리는 매우 중요한데 왜냐하면 마우스가 화면의 가장자리를 벗어날 수 없기 때문에 가장자리에 딱 붙어 있는 버튼은 무한대의 넓이를 가진 것이나 마찬가지이고 따라서 매우 쉽게 클릭할 수 있게 됩니다. 모서리 중에서도 특히나 네 꼭지점 부분 - 좌상단, 좌하단, 우상단, 우하단 - 은 매우 소중히 활용해야할 자리입니다(x, y축 모두 무한대 넓이이면서 한정된 영역입니다. 활용가치도 높고 희소성도 높습니다).


창을 최대화해도 메뉴보다 타이틀바가 위에 있기 때문에 여전히 문제입니다. 최대화된 창의 타이틀를 가지고 할 수 있는 조작이라고는 더블클릭을 통해 최대화를 취소(Restore - 원래대로)하는 기능이 전부인데 말이죠.


2. 한편, 근접성의 법칙(Law of Proximity)은?

혹자는 Fitts' Law도 좋지만 "Law of Proximity"도 중요하다고 말합니다. 즉, 관련된 요소를 서로 근접한 곳에 놓아야 한다는 법칙입니다. 그런 의미에서 본다면 각 메뉴를 창 안에 넣어놓는 것에도 장점은 있습니다.

하지만 MS가 과연 Fitts' Law와 Law of Proximity 사이에서 고민하다가 Law of Proximity를 선택하기로 결정한 것일까요? 전 아니라고 봅니다. 왜냐하면 Fitts' Law와 Law of Proximity가 전혀 상충되지 않는 영역들에 대해서도 Fitts' Law를 어기고 있는 부분들이 많기 때문이죠. 이를테면 테스크바 우측 끝에 있는 시스템 트레이(system tray)의 아이콘은 별 이유도 없이 밑바닥에서 몇 pixel 떨어져 있어서 모서리의 장점을 전혀 활용하지 못하고 있습니다.

사용자 삽입 이미지
(아무 이유 없이 하단에서 약간 떠 있는 트레이 아이콘들)

시작 버튼(Start buttom)도 그렇습니다. 기본 설정에서는 모서리의 장점을 활용할 수 있도록 되어 있지만 테스크바를 두 칸으로 잡아늘이면 이유없이 위로 붕 떠버립니다.

사용자 삽입 이미지
(테스크바를 두 칸으로 늘이면 붕 뜨는 시작 버튼)

결국 별 고민이 없었다는 것이죠.

한편 Leopard의 Dock은 어떻게 커스터마이징하더라도(측면에 붙이건 하단에 붙이건, 크기를 키우건 줄이건) 모서리를 잘 활용할 수 있게 되어 있습니다:

사용자 삽입 이미지
(시각적으로는 떠 있지만 마우스가 최하단에 딱 붙어 있어도 아이콘을 클릭할 수 있습니다)

결론: 어떤 요소이건 간에 그것을 제대로 베끼려면 그 요소를 만드는 과정에서 했던 고민들을 최대한 파악한 후 베껴야 한다. 주먹구구 식으로 베끼고 개선한답시고 이리저리 뒤틀면 오히려 "개악"이 되는 경우가 많다.

PS: 점점 넓어지는 모니터 화면, 다중 모니터 등 최근의 추세를 고려하면 Fitts' Law나 모서리의 중요성에 대해 약간 재고할 필요가 있겠습니다만, 큰 맥락에서는 여전히 유효하다고 생각합니다.
신고
< Newer     Older >

티스토리 툴바