스터디가 끝나고 자주 가는 닭집이다. 중요한 건 벨 위치. 벨을 모서리에 붙여놨다. 술을 먹을 때, 사람들은 자주 팔짱을 끼고 탁자에 기댄다. 그러면 어김없이 저 벨이 눌러진다.
왜 술집 주인들이 벨을 주로 탁자에서 좁은 면 중간에 붙여 놓는지 전혀 이해를 못 하고 있는 것 같다. 저것 때문에 벨이 자주 잘못 눌러지는데, 아르바이트생은 와서 벨 위치를 알려주고 다시 간다. 참~ 쓸데없는 에너지 낭비. 잘 모르는 것은 보편적인 UI를 따르는 게 가장 안전하다.
아님. 추가 주문을 유도하려는 고도로 계산된 전략이거나~
이거 나름 시리즈.
처음 봤을 때, 그냥 괜찮은 디자인처럼 보였다. 나는 Ctrl+L로 주소창을 열고 URL 주소를 타이핑해서 사이트를 찾아가기 때문에, 저런 인터페이스는 그냥 예쁜 인터페이스에 불과했다. 키보드에 얹은 손을 마우스로 다시 옮기기도 귀찮아서 키보드로 할 수 있는 건 웬만하면 다 키보드로 하는 편이다.
최근 이 인터페이스가 정말 대단하다는 걸 알게 됐다. 아내가 웹 서핑을 하는 것을 옆에서 지켜보다가… 카페 때문에 주로 ‘다음’을 사용하는데, 어떤 사이트건 ‘다음’을 검색어로 넣어서 검색 결과를 클릭해서 이동하더라. (몰랐는데, 구글, 네이버에 ‘다음’ 검색어가 꽤 상위 랭크다.) 혹은 히스토리를 볼 수 있는 주소창 옆에 있는 버튼을 눌러서 ‘www.daum.net’을 찾아 이동한다.
요즘 프로그램 대부분이 업데이트가 있는지 감시하는 로직을 프로그램 코드 안에 심어 놓는다. 사용자들이 사용하는 프로그램을 최신 버전으로 갱신하는건 개발자에게 너무나 중요하기 때문이다. 치명적인 버그를 고친 버전을 업데이트 하지 않아 프로그램에 실망해 떠나기도 하고 프로그램 평판 또한 나빠지기 때문에 최신 버전을 알려주고 다운로드 버튼을 제공하는 게 이제 기본이 됐다.
버그가 수정되거나 새로운 기능이 들어간 업데이트를 알려주는 건 좋은데, 프로그램 실행할 때 업데이트를 하는 게 너무 귀찮다. 빨리 프로그램을 사용해야 하니깐~ 그래서 난 보통 나중에 업데이트 하기 버튼을 누르는데, 최근 페인트 닷넷에서 ‘프로그램을 끌 때 업데이트하기‘란 기막힌 옵션을 봤다. 어휴~ 이 생각을 못했구나.
사용자를 진짜 배려한 업데이트 옵션이다.
실수로 버튼을 잘못 눌렀다. 어떻게 하면 끌 수 있을까? 가장 좋은 인터페이스는 층 버튼이 토글로 작동하는 거다. 즉, 층 버튼을 다시 누르면 꺼지는 식으로 동작하는 게 가장 직관적이지.
구린 엘리베이터는 한번 누르면 못 끄게 돼 있는데, 눌러서 안 꺼지기에 “아 구린 엘리베이터구나”라고 생각했다. 허나…. 이 엘리베이터는 끄는 방법이 무려 더블 클릭. -_-) 그것도 조낸 빠른 속도로 더블 클릭해야지 꺼진다. @eljjoo씨 아니었으면 절대 몰랐지 싶다. 아님 화가 나서 미친 듯이 누르다가 “아~ 더블 클릭이구나!” 이렇게 발견하던가. 열폭한 사람만이 끌 수 있는 엘리베이터 되겠다.
꼭 한번 누르면 꺼질 것처럼 생겨서 말이야.
ACM문제 코드를 제출하기 전 예제를 몇 개 만들어서 돌리고 눈으로 검증하곤 했는데, 그렇게 하지 말고 유닛 테스트(unit test) 프레임 워크를 사용해서 알고리즘을 검증하면 되겠다 싶어서 google test를 붙였다. 이렇게 세팅하고 나니 google test 라이브러리에 종속성이 생겨서 프로젝트 세팅에서 빌드가 제대로 되도록 수정해야 했다. 것 참! 문제 풀 때마다 이거 매번 해주려니 짜증난다.
옳커니! 이럴 때 Project Template을 쓰면 딱 이겠네. google test 붙이고 틀을 잡아 놓은 프로젝트를 템플릿으로 구워 놓으면 정말 편할 것 같다. Creating Project and Item Templates – MSDN을 보니 자동으로 만들어 주는데, File > Export Template… 를 눌러서 마법사를 실행시키면 쿵짝쿵짝 쉽게 만들 수 있다고 한다. 뭐 이래? 이렇게 쉬워도 되는 거야?
미루어 왔던 응용 프로그램을 위한 최상의 사용자 환경을 만드는 방법 – MSDN을 드디어 읽었다.
정신병원에서 뛰쳐나온 디자인 – 앨런 쿠퍼를 무척 재미있게 읽은 기억이 난다. 이 책에서는 유저 인터페이스를 담당하는 디자이너를 고용하라고 하지만 그게 어디 쉬우랴. 결국, 유저 인터페이스를 디자인 하는데 많은 부분을 프로그래머가 담당하게 된다. 많은 부분을 담당하는 프로그래머가 정신줄 놓아 버리면 개떡같은 유저 인터페이스가 만들어져 버린다. 유저 인터페이스에 대한 지식이 프로그래머에게도 절실하게 필요하다. 이 분야 전문가와 같이 일하게 되기 전까지는…
앨런 쿠퍼의 책보다는 엄청 재미 없지만, 항목을 잘 나눠놓고 바로 적용할 수 있는 지침들이라서 정리하는 기분으로 읽었다.
프로그래머이다 보니 읽으면서 참 찔리는 점이 많았다. 특히 프로그래머는 대화상자를 좋아한다는 말에 절로 고개가 끄덕. 뭐 결론은 인터랙션 디자이너에게 맡기고 프로그래머는 관여하지 않는 쪽이 가장 낫다라고 난다. 그렇지만 아직까지 인터랙션 디자이너가 보편화된 직업이 아니다. 그렇기 때문에 절대 피해야 할 프로그래머의 인터페이스 관여가 조금씩 이루어 진다. 그렇기 때문에 인터랙션 디자인에 대해서 완벽하진 않지만 어느정도 알고 있어야 한다.
페르소나라는 단어를 이 책에서 처음 접했는데, 인터랙션 디자인은 물론 개발진 내부의 의사소통에도 엄청난 도움이 되는 것을 볼 수 있었다. 대략적이고 평균적인 사용자 집단 보다는 구체적인 페르소나 여러명을 사용자로 생각하고 디자인 한다는 것이 핵심. 친절한 소프트웨어가 되기 위해서는 무척이나 도움이 되지만 역시 재미를 목표로 하는 게임에는 페르소나를 잡는 다는 것 자체가 무척이나 무리가 될 것 같다. 하지만 UI를 비롯해 사용자와의 인터랙션에는 충분히 써 먹을 수 있을 것 같다.
직접 인터랙션 디자인을 맡아 참여했던 프로젝트에서 자기가 설명한 이론들이 이떻게 소프트웨어를 변화시켰는지 이야기 해 주는 부분들이 있었는데, 충분히 납득되는 이야기들이 다시 한번 인터랙션 디자인의 중요성을 느끼게 해주었다. 또한 이 부분들이 이 책에서 가장 재미 있었다. 더군다나 뭐 듣보잡이 이런 얘기를 하는 것도 아니고 비주얼 베이직의 아버지 앨런 쿠퍼의 얘기니 귀기울여 들을 필요가 있는 것도 당연하다.
프로그래머 – 사용자가 이것을 프린트하고 싶어하면 어떻하죠?
인터랙션 디자이너 – 로즈메리는 프린팅하는 데는 별로 관심이 없습니다.
프로그래머 – 하지만 누군가 프린트하기를 원할 지도 모르잖아요.
인터랙션 디자이너 – 우리는 로즈메리를 위해 디자인하는 것이지 ‘누군가’를 위해 디자인 하는 것이 아니에요.
221 page
진보한 프로그래머 – 로즈메리가 이것을 프린트하고 싶어할까요?
즐거운 인터랙션 디자이너 – 아니오. 하지만 제이콥은 분기별로 프린트된 리포트를 원할 수도 있어요.
진보한 프로그래머 – 좋아요. 그렇게 거의 필요하지 않은 경우라면, 괜히 우리가 직접 화려한 리포트 작성 기능을 만들 필요없이 돈으로 살 수 있는 도구를 하나 정해 라이센스를 받는 편이 우리의 시간과 노력을 절약할 수 있겠군요.
즐거운 관리자 – 그러면 출시 예정 스케줄을 2주나 앞당길 수 있어요!
222 page
