BLOG main image
분류 전체보기 (239)
Rails (65)
Ruby (34)
이야기 (40)
스토리큐 (61)
그 밖에.. (30)
C# (6)
드리밍 인 코드
The note of Legendre
작은아이의 생각
agiletalk's me2DAY
[rails] Growl4Rails
美소년 ㅇㅅㅇ씨의 一日
마사키군의 생각
ayukawa's me2DAY
작은아이의 생각
agiletalk's me2DAY
63,409 Visitors up to today!
Today 14 hit, Yesterday 22 hit

 SUBSCRIBE

'2009/09'에 해당되는 글 7건
2009/09/29 11:28

달리기는 육체적인, 정신적인 건강을 위해 제가 선택한 운동입니다. 이 운동의 장점은 마음먹은 바로 그 때 혼자서도 할 수 있다는 점입니다. 누구나 달리기를 할 수 있기에 운동을 시작하기 위해 특별히 배울 것도 없습니다. 달리고 싶은 바로 그 때 운동화를 신고 달릴 수 있습니다. 혼자서도 달리기를 즐길 수 있고 작은 성취를 이룰 수도 있지만, 마라톤 동호회에 가입함으로써 즐거움을 배가시킬 수 있습니다. 전국 각지에 마라톤 동호회가 있습니다. 분당에 살고 있다면 분당마라톤 클럽 검푸가 있습니다.

 logo_title

제가 검푸에 가입한 때는 올해 7월 중순입니다. 그 이전에는 혼자 탄천을 달렸습니다. 무엇인가 부족함을 느끼면서, 풀코스에 대한 욕심이 생기면서, 같이 달릴 수 있는 동료가 필요함을 깨달으면서 검푸에 가입하게 되었습니다. 두 달 남짓 되는 기간 동안 모임에 참석하면서 얻은 것이 참 많습니다. 
첫째,  달리는 방법, 운동화 끈 묶는 법, 부상에 대처하는 법, 기록향상을 위한 체계적인 훈련방법 같은 귀중한 지식을 얻었습니다. 동호회에서 만난 선배님들은 한결같이 모두 친절하게 자신의 노하우를 가르쳐 줍니다.
둘째, 꾸준함의 위대함을 다시 한번 느낍니다. 검푸는 일 주일에 세 번 훈련을 합니다. 화요일은 언덕훈련, 목요일은 트랙에서 훈련, 일요일 아침에는 장거리 훈련을 합니다. 꾸준히 훈련에 참석하다 보니 기록이 몰라보게 좋아졌습니다. 두 달 남짓 동안 10KM 기록이 4분 정도(47분->43분) 좋아졌습니다. 불가능해 보였던 풀코스 완주를 이제는 할 수 있을 것만 같습니다.
셋째, 같은 목표를 가진 동료들을 얻었습니다. 사회에서는 각기 다른 일을 하고 있지만, 검푸로 모이는 동안 우리의 목표는 하나, “달리는 것” 입니다. 그들을 바라보는 것만으로 엄청난 자극을 느낍니다. “나도 저 선배님처럼 빠르게 달리고 싶다.” 혹은 “나도 저 선배님 나이에 저렇게 달릴 수 있을까?” 라는 생각이 나를 게을러지지 않게 합니다. 또한 그들의 격려와 응원이 꾸준함을 만듭니다. 매 훈련이 기다려지게 합니다.

어떤 일을 성취하려면 다음과 같은 세 단계가 필요합니다.
1. 하고 싶다는 욕구를 갖기.
2. 그것을 이룰 수 있는 방법을 찾기.
3. 실행하기.
검푸는 그 중 두 번째 단계인 기록향상을 위한 훈련 방법을 알려 주었습니다. 그리고 무엇보다 중요한 것은 세 번째 단계인 훈련을 실행할 수 있도록 해 줍니다. 가끔 이 훈련을 혼자서도 해낼 수 있었을까? 라는 생각을 해봅니다. 대답은 쉽지 않습니다. 같은 곳을 바라보는 동료를 갖는 것. 나보다 먼저 그 길을 간 사람들의 조언을 드는 것. 이런 것들이 실행에 미치는 영향은 대단합니다.

제 또 다른 목표 중 하나는 ‘뛰어난 루비 언어 개발자 되기’ 입니다. 지금 두 번째 단계에 머무르고 있습니다. 루비 언어 개발자들 사이에도 서로 자극을 줄 수 있는 정기적인 모임이 있었으면 좋겠다는 생각을 해봅니다. 

2009/09/28 07:58

Elevators at 240 Sparks

엘리베이터가 처음 나왔을 때 사람들은 그 느린 속도에 불평을 했다고 합니다. 그 불평을 잠재우기 위해 엘리베이터 안에 거울을 붙여놓았다고 합니다. 그 후 사람들은 거울을 보는 데 정신이 팔려서 더 이상 엘리베이터의 속도에 대해 불평을 하지 않았다고 합니다.

사람들은 보통 기다리는 일을 싫어합니다. 그에 비에 삶은 기다림의 연속입니다. 지하철이 오기를 기다려야 하고, 탄 후에는 목적지까지 데려다 줄 때까지 기다려야 합니다. 친구를 만나기 위해 약속장소에서 기다려야 합니다. 이 페이지를 보기 위해서는 브라우져가 실행되기를 기다려야 하고, 이 페이지가 불려지는 동안 또 기다려야 합니다.

사람들은 왜 기다리는 일을 싫어할까요? 그것은 아마 기다림의 다음 두 가지 속성 때문이지 않을까 싶습니다.

첫 번째는 기다리는 시간이 아무것도 하지 않고 버려지는 시간으로 생각되어집니다. 인간은 시간을 효율적으로 사용하고 싶어합니다. 수명이 한정되어 있다는 것을 고려해 볼 때 그것은 합리적입니다. 효율적으로 시간을 보내는 사람들의 생존 확률이 더 높았을 것입니다. 그런데 기다리는 행위는 시간의 효율성을 해칩니다.
엘리베이터에서는 원하는 층에 도착할 때까지 할 수 있는 일이 전혀 없습니다. 사람은 그 시간 동안 지루함을 느끼고 시간이 낭비되어진다고 생각합니다. 이제 엘리베이터에 거울을 붙입니다. 이제 엘리베이터 안에서 할 수 있는 일이 생겼습니다. 자신의 얼굴을 바라보는 일입니다. 사람은 보통 자기 자신에게 무한한 관심을 가지고 있기 때문에 이 행위는 아주 매력적인 일입니다. 이제 더 이상 사람은 엘리베이터에서의 시간이 낭비되어진다고 생각하지 않습니다. 더불어 지루함도 느끼지 않습니다.
출퇴근 시간이 한 시간 이상 걸린다고 이야기를 하면 사람들은 시간을 절약하기 위해 이사를 할 것을 권유합니다. 보통 출퇴근과 같이 어딘가로 이동하는 시간은 의미 없는 것으로 생각되어집니다. 이동을 하면서 무엇인가를 하기가 쉽지 않기 때문입니다. 특히 꽉 막힌 길을 운전을 하는 경우가 그렇습니다. 저는 이동수단으로 지하철을 타는 것을 좋아합니다. 지하철에서는 책을 읽기가 편하기 때문입니다. 사람들의 걱정과는 달리 긴 출퇴근 시간이 제겐 고통스럽지 않습니다. 제게는 그 시간이 기다리는 시간이 아닌 책을 읽는 시간이기 때문입니다.
컴퓨터에서는 멀티태스킹 기능이 기다리는 지루함을 없애 줍니다. 10GB 나 되는 파일을 복사하는 데는 꽤 오랜 시간이 걸리지만 문제없습니다. 그 동안 웹서핑을 할 수 있으니까요.

다른 한 가지는 기다리는 것에는 불확실성이 있기 때문입니다. 내가 기다리는 그 일이 정말 일어날 것인지 언제 일어날 것인지 알 수가 없는 경우가 많이 있습니다. 미래에 대한 불확실성은 사람들을 불안하게 합니다. 예측을 할 수 없기에 계획할 수도 없고, 계속 그 일을 신경 쓰고 있어야 합니다.
예를 들어 버스를 기다리는데, 이 버스가 10분 안에 올 것인지 한 시간이 걸릴 것이지 모릅니다. 그 때 사람은 정류장에 들어오는 모든 버스의 번호를 확인합니다. 내가 타야 할 버스가 올 때까지. 버스 번호를 확인해야 하기 때문에 기다리는 동안 다른 일을 할 수 없습니다. 그리고 버스 번호를 확인하는 일은 유용한 일이라고 생각하기 힘듭니다. 이런 불확실성은 버스의 도착시간 정보를 알려줌으로써 개선할 수 있습니다. 7번 버스가 10분 후에 도착한다는 사실을 알게 되면 앞으로 7분 정도는 책을 읽으며 보낼 수 있을 것입니다.
컴퓨터 프로그램에서는 프로그래스 바가 불확실성을 없애주는 역할을 합니다. 이 페이지가 로딩되는 시간 동안 브라우저의 하단에서는 프로그래스 바가 보여집니다. 이 프로그래스 바는 당신이 요청한 작업을 지금 수행하고 있음을 알려주고 곧 끝날 것이라는 것도 알려줍니다. 인간중심 인터페이스를 보면 실행시간이 0.25초가 넘는 작업의 경우에는 프로그래스를 보여줄 필요가 있다고 합니다.

정리하면, 어떤 제품을 만들거나, 프로그램을 만들 때는 사용자를 기다리지 않도록 해야 합니다. 그것이 불가능 하다면 – 아마 대부분의 경우 불가능할 것입니다. – 기다리는 동안 할 수 있는 일을 만들어 주어야 합니다. 그리고 얼마나 기다려야 하는지도 알려줘야 합니다. 그리고 자신의 삶이 보다 효율적으로 되기를 원한다면, 책읽기와 같이, 자신에게 기다림이 주어졌을 때 홀로 할 수 있는 일들을 준비해 가지고 다녀야 합니다.

'이야기' 카테고리의 다른 글

역방향 추론  (0) 2009/10/03
분당마라톤 클럽 검푸  (0) 2009/09/29
기다림에 대해서  (0) 2009/09/28
접근성(Accessibility)  (0) 2009/09/17
지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유  (0) 2009/09/06
TDD의 요건  (0) 2009/06/09
2009/09/17 23:50

지난주 UI study 시간에는 접근성 이란 주제를 가지고 토론이 있었습니다. 부끄럽게도 저 혼자만 접근성에 대한 개념이 없었습니다. 다행인 것은 부끄러운 기억은 오래 남기에 아마도 접근성에 대한 좋은 이야기들은 쉽게 잊혀지지 않을 듯 싶습니다.

접근성(Accessibility)은 제품을 얼마나 많은 사람들이 사용 가능한가를 나타냅니다. 위키피디아를 참조해 보면 접근성은 주로 장애인들도 사용할 수 있는가에 초점을 맞추는 것으로 보입니다. 잘 안보여도, 한 손이 불편해도, 들을 수 없어도 그 제품을 사용할 수 있다면 그 제품은 접근성이 좋은 것입니다. 이렇게 다양한 사람들이 제품을 사용하기 위해서는 사용방법을 또한 여러 가지로 제시해야 합니다. 따라서 접근성은 제품을 얼마나 다양한 방법으로 사용할 수 있는가라는 말로도 표현할 수 있습니다.
http://www.buyking.com/news/2009/03/news200903311402231/aa.jpg정수기에서 물 나오는 부분을 예로 들어 봅시다. 구형 정수기는 물을 받기 위해 두 손이 필요했습니다. 한 손으로는 컵을 잡고 한 손으로는 물 나오는 버튼을 눌러야 했습니다. 오른쪽 그림과 같은 요즘 정수기는 한 손만으로도 물을 충분히 받을 수 있습니다. 물 나오는 버튼을 컵을 이용해서 밀어서 누를 수 있습니다. 이와 같은 디자인은 두 손 사용자는 물론이고 한 손만 사용이 가능한 사람들도 쉽게 물을 받아 먹을 수 있게 해 줍니다.

웹의 경우에는 제품을 정보로 생각해 볼 수 있습니다. 그리고 제품을 사용하는 다양한 방법을 정보에 접근하는 다양한 방법으로 생각해 볼 수 있습니다. 나의 일정에 대한 정보가 구글의 서버 어딘가에 있습니다. 이 정보에 접근하기 위한 기본적인 방법은 파이어폭스와 같은 브라우저를 이용하는 것입니다. 이 때 브라우저를 사용하는 사람이 눈이 불편해도, 잘 안들려도 일정을 확인할 수 있다면 접근성이 좋다고 할 수 있습니다. 어떤 사람은 PC가 아닌 모바일을 통해 구글의 일정을 확인하려고 할 수 있습니다. 어떤 사람은 아웃룩 프로그램을 통해 확인하려 합니다. 어떤 사람의 PC는 인터넷에 연결되어 있지 않습니다. 이 모든 사람들이 일정을 확인할 수 있다면 그것은 접근성이 좋은 것입니다.  웹의 경우 접근성을 매우 높일 수 있는 한 가지 효과적인 방법은 Open API를 제공하는 것입니다.

이쯤에서 정리를 하면, 접근성이 높은 제품은 그 제품을 사용하는 다양한 방법을 제공함으로써 누구라도, 어떤 환경에서라도 제품을 사용할 수 있는 것을 말합니다. 디자이너는 접근성 100%, 즉 모든 사람들이 사용할 수 있는 제품을 만드는 것을 목표로 합니다.

이제부터는 현실적인 이야기를 하도록 하겠습니다. 현재 90%의 사용자가 만족하며 사용할 수 있는 제품이 있습니다. 이 제품은 접근성의 측면에서 봤을 때 10%정도의 개선의 여지가 있습니다. 접근성을 향상시킬 여지가 있으니 개선을 해야 합니다. 그러나 한편으로는 개선을 통해 얻는 이익이 노력에 비해 작다면 개선의 의지는 줄어들게 마련입니다.

접근성 향상에는 한계효용 체감의 법칙이 작용합니다. 40%에서 50%로 향상시키는 것은 작은 노력으로 큰 효과를 얻을 수 있지만, 95%에서 96%로 향상시키는 것은 큰 노력이 필요하지만 얻는 효과는 작습니다. 그래서 현실에서는 100%를 목표로 하지 않고, 적당한 선에서 타협을 하게 됩니다. 그 타협은 매우 합리적이라고 생각됩니다. 모든 장애인들이 웹페이지를 사용할 수 있으면 좋겠지만, 그러기 위해서 드는 비용이 이익을 보장하지 못한다면 기업은 웹페이지를 개선할 필요를 느끼지 못합니다. 이런 측면에서 봤을 때 복지국가를 목표로 하는 한국에서 장애인차별 금지법의 제정은 적절하다고 볼 수 있습니다. 기업이 움직여야 할 동기를 제공하고 있기 때문입니다.

'이야기' 카테고리의 다른 글

분당마라톤 클럽 검푸  (0) 2009/09/29
기다림에 대해서  (0) 2009/09/28
접근성(Accessibility)  (0) 2009/09/17
지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유  (0) 2009/09/06
TDD의 요건  (0) 2009/06/09
아이콘 : 스티브 잡스  (0) 2009/05/21
2009/09/06 21:00

다음은 UI study 에서 진행한 인간중심 인터페이스 스터디 중 4장 정량화에 대한 내용입니다.

정량분석

인터페이스 디자인의 좋고 나쁨을 어떤 기준을 통해 수치화시키는 작업을 정량화라고 합니다.

왜 필요한가?

  • 디자인을 평가할 때 "예쁘다", "편하다" 와 같은 막연한 표현 대신 숫자를 이용해 비교를 함으로써 논란을 줄여 줍니다.
  • 구체적인 근거를 제시함으로써 상대방을 설득하기 쉬워집니다.
  • 인터페이스를 더 나은 방향으로 개선해 나가고 있는지 확인을 할 수 있고, 더 개선할 여지가 있는지 알 수 있습니다.

책에서는 정량분석에 대한 방법으로 GOMS(model of goals, operations, methods, and selection rules), Raskin의 효율 측정, Hick의 법칙, Fitts의 법칙을 소개합니다.

주의) 정량분석은 절대적인 기준이 될 수 없으며, 정성분석과 같은 다른 방법론들과 균형을 맞추어야 합니다.

 

GOMS 모델

GOMS 모델은 어떤 작업(task)을 수행할 때 걸리는 총 시간을 계산하는 방법을 제시하고 있습니다. 그 방법은 다음과 같습니다. 하나의 작업을 연속적인 기본 제스처의 단위로 나눕니다. 그리고 그 기본 제스처들의 수행시간을 모두 더합니다. 기본 제스처들의 수행시간은 실험을 통해서 얻어낼 수 있습니다. 수행시간은 보통 평균값을 사용합니다.

기본 제스처는 다음과 같은 것들이 있습니다.

  • 키누름시간(K) : 0.2초
  • 포인팅시간(P) : 1.1초
  • 호밍시간(H) : 0.4초
  • 정신적 준비시간(M) : 1.35초
  • 반응시간(R) :

아이폰 같은 터치 인터페이스가 보편화됨에 따라 기본 제스처에 터치, 흔들기와 같은 것들도 포함될 수 있겠습니다.

 

효율성 측정

정보량을 기준으로 인터페이스가 얼마나 효율적인가를 측정할 수 있습니다.  인터페이스의 효율성은 다음과 같은 공식에 의해 계산되어집니다.

정보 효율성 = 작업을 수행하기 위해 꼭 필요한 정보량/사용자가 제공한 정보량

javascript의 경고창(alert) 과 같이 확인 버튼 하나만 있는 경우는 필요한 정보량이 0이 되기 때문에 효율성도 0입니다.

예를 들어 숫자 하나를 키보드로 입력받는 입력창의 효율성은 다음과 같이 계산됩니다.

꼭 필요한 정보량은 숫자 하나에 대한 가지 수 만큼입니다. 0-9까지 10개의 숫자가 있고 따라서 정보량은 log2(10) = 2.3 입니다.  즉 숫자 하나를 입력받기 위해서는 최소한 2.3byte가 필요합니다.

100 개의 자판을 가진 키보드를 이용해 숫자를 입력한다고 하면, 숫자를 입력하기 위해 사용자가 제공하는 정보량은 log2(100) = 6.7 정도 입니다.(키 하나하나 눌려지는 확률이 동일하다고 가정합니다.) 즉 사용자는 숫자 하나를 입력하기 위해 100개의 자판 중 하나를 선택해야 하고, 그 가지 수를 표현하기 위해서는 6.7byte가 필요합니다.

그래서 정보 효율성은 2.3/6.7 = 0.34 입니다.

이와 같은 경우 정보 효율성을 개선하기 위한 간단한 방법으로는 숫자 전용자판을 이용하는 것입니다.

문자 효율성은 정보를 문자의 갯수로 한정시킴으로써 효율성을 보다 간편하게 구할 수 있게 해 줍니다.

문자 효율성 = 작업에 필요한 최소 문자수/사용자에게 요구하는 문자수

 

Fitts 법칙

Fitts 법칙은 어떤 표적을 얼마나 쉽게 선택할 수 있는지를 측정할 수 있도록 해줍니다.

표적이 클수록, 표적과의 거리가 가까울 수록 선택하기 쉽다는 의미입니다.

T = a + b*log2(D/S +1)
T : 선택하는데 걸리는 시간
D : 커서와 표적 사이의 거리
S : 표적의 크기
a,b : 실험에 의해 특정된 상수

예를 들어 폼의 확인 버튼을 디자인 할 때 클릭하기 쉽게 하도록 하기 위해서는 버튼을 크게 만들고, 버튼을 폼의 마지막 입력 창과 가깝도록 만들면 클릭하기 쉬워집니다.

그 비율이 log로 증가하고 있다는 것이 흥미롭습니다. 아주 작은 버튼을 조금 크게 만들면 클릭이 확 쉬워지는 반면, 충분히 큰 버튼을 더 크게 만드는 것은 그 개선 효과가 미미해집니다.

가장자리

화면 중 가장자리 부분은 Fitts 법칙에 의해 특혜를 보고 있는 공간입니다. 화면의 가장자리는 마우스 커서가 더이상 이동할 수 없는 지역이기 때문에 더 넓은 표적의 크기를 가지게 됩니다. 무슨 뜻이냐면, 화면의 최상단에 상태바가 있다고 가정할 때, 이 상태바를 선택하기 위해서 마우스를 과감하게 이동시켜도 커서가 화면을 뚫고 지나가지 못하고 화면의 최상단에 위치하게 됩니다. 그래서 가장자리에 위치한 버튼은 약 5cm정도 크기를 더 갖는 효과를 볼 수 있습니다.

Fitt의 법칙을 적용한 다양한 예를 보실 수 있습니다.

1. 메뉴 네비게이션 

하위 메뉴를 상위 메뉴근처에 보여줍니다. 따라서 하위 메뉴를 선택하기 쉬워집니다.

2. 맥의 화면 상단에 위치한 메뉴바

맥 에서는 화면의 최상단에 위치한 메뉴바(File, Edit..)가 애플리케이션의 메뉴입니다. 이는 Fitt의 법칙을 잘 따른 구현으로 메뉴를 선택함에 있어서는 효율적이지만, 직관적인 면에서는 좋지 않은 듯 합니다. 직관적인 면에서는 애플리케이션에 메뉴를 포함시킨 윈도우의 방식이 더 좋아 보입니다.

3. 맥에서의 hot spot

화면 네 구석에 자주 사용하는 메뉴를 지정할 수 있습니다.

4. 윈도우의 시작버튼

윈도우의 시작버튼도 가장자리 효과를 이용하고 있습니다. 다만 잘못 베꼈다는 날카로운 지적도 있네요.

 

Hick의 법칙

Hick의 법칙은 선택의 가지 수가 많아질 수록 선택을 하는데 걸리는 시간이 더 많아진다 입니다. 복잡한 결정을 내릴 때가 간단한 결정을 내릴 때보다 더 많은 시간이 걸립니다. Hick의 법칙은 다은과 같은 공식으로 표현됩니다.

T = a + b*log2(n+1)
T : 선택을 하는데 걸리는 시간
n : 선택의 가지 수
a,b : 상수

Fitt의 법칙과 마찬가지로 시간이 선택 갯수의 log에 비례한다는 것이 흥미롭습니다. 3개에서 6개로 메뉴가 늘어날 때 느껴지는 복잡도가 50개에서 70개로 늘어날 때 느껴지는 복잡도보다 더 큽니다.

 

결론

모든 인터페이스를 정량분석을 통해서 측정할 수는 없겠지만, 그리고 현실적으로 거의 이루어지지 않고 있지만, 이 방법을 알고 인터페이스를 만드는 것과 모르고 만드는 것에는 큰 차이가 있을 것입니다.

책에 나온 한 구절을 통해 내용을 정리합니다.

정량분석을 통하지 않고는 우리의 작업이 얼마나 잘 진행되고 있는지, 개선의 여지는 없는지 도무지 알 방법이 없다.

2009/09/06 18:38

그 과정은 다음과 같다.

달리기한 내용을 기록하고 그 기록들을 확인할 수 있는 간단한 웹서비스를 만들고 싶었다. 기록할 수 있는 폼, 기록을 볼 수 있는 페이지. 일단 이것으로 될 것 같다. 그러기 위해 rails 프로젝트를 생성하고, 사용하고 싶었던 gem과 plugin들을 떠올려 봤다. rspec, jquery, authlogic, cucumber, compass, haml 등등.. 그러던 중 이런 내용들을 할 일 목록을 통해 정리를 해 놓으면 좋을 것 같았다. 그래서 내가 알고 있는 가장 좋은 이슈 관리 시스템인 jira를 설치했다. 이왕 하는 거 jira 서버에 도메인을 하나 주면 좋겠다. 그래서 jira를 개인 비서처럼 사용하면 좋을 것 같았다. jira는 톰캣을 사용하니까 apache와 tomcat을 연동하면 될 것 같다. 그래서 토요일 오전 내내 fedora 서버에 tomcat을 설치하고, 설정하고, apache에 대해 알아보면서 시간을 보냈다.

개발자들은 무엇인가를 만들기 위해 필요한 연장을 먼저 만드는 경향이 있다고 한다. 그 연장은 무엇인가를 쉽게 만들 수 있게 해 줄 것이고, 두고두고 유용하게 사용될 것이다. 분명히 그럴 것이다. 문제는 그 연장을 만들다 보면 연장을 만들기 위한 또 다른 연장을 만들 필요를 느낀다. 이런 식으로 연장의 연장을 만드는 일이 계속된다. 정작 만들고자 하는 무엇인가는 미루어진 채.

지금의 내겐 달리기 내용을 기록하는 간단한 웹 페이지가 언제 만들어질 지 도무지 모르겠다. 버전 관리 시스템을 정해야 하고, 배포를 어떻게 할 지 정해야 한다. 이런 것들이 지금 꼭 필요한 일일까? 이런 고민에 또 한동안 시간을 보낸다. 그러다가 결국에는 생각나는 것은 뭐든지 해보기로 했다. 개인적인 일이니까, 빨리 하지 않아도 되니까, 뭐라도 하면 뭐라도 얻게 될 테니까. 그러나 일정의 지연이 조직 혹은 개인의 이익과 연관된다면 문제는 달라진다. 그 때 필요한 것은 어느 정도의 연장까지 만들 것인지를 신속하게 정하는 것이다. 누군가가 그 일을 아주 잘 해 낸다면 프로젝트는 편하게 진행될 수 있다. 프로젝트의 일정을 아무리 넉넉하게 잡아도 결국에는 마감에 쫓기게 된다고 말하는 사람도 있다. 그것은 아마 일정 안에 해야 할 일이 막연하기 때문은 아닐까? 일정을 지키기 위해 정말 필요한 것은 해야 할 일들을 명확히 정하는 것이다.

'이야기' 카테고리의 다른 글

기다림에 대해서  (0) 2009/09/28
접근성(Accessibility)  (0) 2009/09/17
지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유  (0) 2009/09/06
TDD의 요건  (0) 2009/06/09
아이콘 : 스티브 잡스  (0) 2009/05/21
넛지(Nudge)  (0) 2009/05/20
2009/09/03 23:23

직접적인 사용자 테스트는 개발/기획 단계에서 생각하지 못했던 문제들을 손쉽게 알려 준다. 개발자의 관점이 아닌 사용자의 관점에서 프로그램을 어떻게 바라보는지 알 수 있게 해 준다. 사용자가 기능을 어떻게 이해하는지, 어떤 부분에서 어려움을 느끼는지 확인할 수 있다. 다만 사용자 테스트를 하기 위해서는 어느 정도의 준비가 필요하다. 적당한 사용자를 포섭해야 하고, 테스터는 그 사용자의 행동을 볼 수 있어야 한다. 다행인 것은 문제점들을 확인하기 위해서 많은 사용자를 대상으로 사용자 테스트를 할 필요는 없다고 한다. Jakob Nielen 의 글을 보면 6명의 사용자가 프로그램을 사용하는 것을 지켜보면 프로그램의 문제점들을 대부분 알 수 있다고 한다.

웹서비스를 개발하고 있다면, 여기 사용자 테스트를 위한 한 가지 멋진 툴이 있다. Userfly 는 사용자의 행동들 – 마우스 이동/클릭, 키보드 입력 – 을 저장해서 나중에 확인할 수 있게 해 준다. 즉 사용자가 사이트에 들어와서 한 행동들을 다시 재현할 수 있다. userfly의 사용방법은 매우 간단하다. 회원가입 하면 제공되는 javascript 코드를 페이지의 <head> 태그 안에 넣어주기만 하면 된다. 이 때부터 들어오는 사용자의 행동들이 기록되기 시작한다. 기록된 내용은 userfly 사이트에서 확인할 수 있다.

userfly.com from Chris Estreich on Vimeo.

userfly 사이트에서는 기록된 내용을 확인할 수 있을 뿐만 아니라, 기록을 잠시 중단 할 수도 있고, 특정 IP에 대해서 기록을 하지 않도록 설정할 수도 있다. 무료 사용자는 한 달에 10개의 사용자 기록을 저장할 수 있다. 10개 이상을 저장하고 싶다면 유료 모델로 전환해야 한다. 값은 비교적 저렴하다. 1000개를 기록하는데 25$이다.

사용하면서 아쉬웠던 점들은

  • userfly는 굉장히 무거운 javascript를 사용하고 있는 듯 하다. 모든 사용자 행동들을 userfly 서버로 전송해야 할 테니 그럴 만도 하다. 그래서 IE6에서는 티가 날만큼 느려진다.
  • javascript를 제대로 재현하지 못하는 듯이 보인다.
2009/09/02 17:38

CSS와 HTML 구성한 웹페이지가 있다. 이 페이지를 프린터로 출력을 하면 내가 보고 있는 페이지 그대로 출력이 될까? 화면 그대로 출력되지 않는다면 얼마나 비슷하게 나올까?

CSS를 이용해서 프린터 친화적인 페이지를 만들어 보자. 출력을 위한 CSS는 다음과 같이 media를 print로 해 주어야 한다.

  1. <link type="text/css" rel="stylesheet" media="print" href="/stylesheets/print/coupon.css"/>

화면을 위해서는 media를 screen으로 해 준다.

  1. <link type="text/css" rel="stylesheet" media="screen" href="/stylesheets/print/coupon.css"/>

화면에 보이는 그대로 출력을 하고 싶다면 위 두 태그를 모두 사용한다.

clip_image001

페이지를 멋지게 꾸민 후 인쇄하기 버튼을 만들어서 이 버튼을 누르면 인쇄 창이 나오도록 해 주자. 이것은 javascript를 이용해서 할 수 있다.

  1. <a onclick="window.print(); return false;" href="#">인쇄하기</a>

페이지를 만들 때 주의해야 할 것은

프린터는 background 프로퍼티를 무시한다. 이 프로퍼티는 사용하지 말자. 그대신 position: absolute 같은 것들은 잘 동작한다. 이들을 이용해서 이미지 위에 다른 element를 위치시킬 수 있다.

prev"" #1 next