다음의 dna lens를 유용하게 잘 이용하고 있었는데, 날이 갈수록 그 효용성이 떨어짐을 느낀다.
처음 lens를 접했을 때는,
1) 나의 관심사와 비슷한 주제(IT/Web/Programming)에 대해
2) 경험상 신뢰할 수 있는(Daum DNA Lab) 모더레이터가
3) 그 품질을 보장할 수 있는 블로그들을 선별하여
제공해주었기에, 아무런 불만 없이 게으르게 수동적으로 받아 읽기만 해도 충분했었는데...
어느날인가부터 Lens에 등록되는 블로그들이 늘어나기 시작하더니, 약 230개의 블로그가 등록되어 있는 현재로서는, 들어가보나 마나한 페이지가 되어버렸다.
나에게 있어 lens는 게으른 구독을 위한 좋은 소스였는데 안타깝다.
조금 삼천포로 빠져서...
요즘 웹 2.0 서비스들은 "참여"를 서비스의 핵심요소로 여기는데, 글쎄. 사용자는 게을러질 권리가 있다고 보는데...
위키페디아가 참여서비스일까? 만약 위키페디아를 읽기 위해 반드시 위키페디아에 글을 쓴다거나 하는 행위가 필요하다면 "참여"라고 말하겠지만. 실제로는 99%의 사용자는 그저 읽기만 할 뿐 아닌가.
"참여"라는 미명으로 부지런한 사용자가 되기를 원하는 서비스들은 그다지 좋아보이지 않는다. 자신들이 해야할 일을 "웹 2.0"이라는 포장으로 사용자에게 떠넘기는 꼴이니까. 가장 좋은 "참여"는, 자신들이 "참여"하고 있다는 것조차 모를 때 이루어지지 않을까?
다시 lens 이야기로 돌아와서,
lens opml을 받아서 RSS 리더기에 등록시키는 삽질을 했다. 그리고는 기존에 등록된 것과 중복된 것들, 관심없는 것들 등등을 삭제하는 작업을 몇시간 했더니, 약 60개의 블로그가 살아남아 RSS 리더기에 추가되었다.
혹시나 내가 몰랐던 좋은 블로그가 있을까 해서 해본 삽질인데, 들인 시간에 비해 얻은 건 별로 없다. 살아남은 블로그들의 대부분은 이미 알고 있고 한번쯤은 구독기에 등록했었던 블로그들이라서.
그 결과 현재 내 RSS 리더기에 170여개의 피드들이 등록되어 있다.
결국, 진지한 삽질이었던 셈인데, 피드들을 삭제하면서 깨달은 점을 몇개 마지막으로 덧붙여본다.
1) 신변잡기들이 많은 블로그들을 삭제했다. - 스토킹 취미가 있지 않은 이상, 아무리 좋은 문장력과 소소한 감동이 있더라도 타인의 삶을 훔쳐보는 것은 피곤한 일이다. 물론 내가 실제로 알고 있는 지인들의 경우는 예외.
2) 미투데이 포스팅이 많은 블로그들을 삭제했다. - 미투데이 자체에 대한 유감은 아님을 노파심에 미리 밝혀두며, 선문답 혹은 하이쿠를 연상시키는 짧은 문장만으로는 제3자는 이해할 수 없는 암호나 다름없기에. 그런 글들만으로 차있는 블로그들은 내가 그 블로거와 각별한 친분이 있는 것이 아닌 이상 읽어야 할 이유가 없기 때문.
3) 포스팅 주기가 길거나, 심지어 잠시 운영중지 중인 블로그는 오히려 살아남았다. - 진짜로 가치있는 글들이라면 한달에 한번 올라오더라도 감히 구독기에서 삭제할 수 없었다. 오히려 그렇게 장기간 잠수중인 블로그들이 다시 부활하는 날이 더 기다려질 뿐.
4) 반대로 너무 포스팅주기가 짧은 블로그들은 삭제되었다. - 포스팅 주기가 짧아서라기보다는, 포스팅 자체가 가치없는 경우가 많아서.
5) 홍보용 블로그들이 삭제되었다. - PR용으로 운영하는 블로그들을 정기 구독할 이유는 없는 것 같다. 홍보정보가 필요하다면, 직접 해당 블로그를 찾아가서 원하는 내용을 검색해보는 쪽이 매번 나오는 자화자찬 포스팅들을 읽어보는 것보다는 효율적인 듯 해서.
뭐, 내 구독기에서 삭제된 블로그들도 나 읽으라고 쓰는 글들이 아닐테니 별 상관없겠지만.
진짜 마지막으로, 현재까지 내 게으른 블로깅을 위해 가장 도움이 되는 소스는 조프의 주절주절. digg나 del.icio.us보다 내게는 훨씬 편리하다.
2007년 4월 28일 토요일
2007년 4월 27일 금요일
No more metablog
메타블로그의 홍수다. 도깨비뉴스가 메타블로그에 뛰어들었고, 블로그코리아가 부활할거라 한다.
블코랑 직간접적으로 인연이 있는지라 관심있게 보지 않을 수 없는데....
메타블로그는 여전히 유효한가? 처음 블코가 세상에 나왔을 때와 지금은 시간이 흐르고 상황도 바뀌었다. 내 생각은 그저 그렇다 쯤.
여전히 메타블로그에 대한 관심들을 가지는 건, 미디어의 소통채널로써의 메타블로그의 영향력을 무시할 수 없을 뿐더러, 컨텐츠 어그리게이팅의 좋은 수단이기 때문...
한편으로는 여전히 메타블로그에 뛰어드는 플레이어들이 있다는 것은 그만큼 기존의 메타블로그가 부족한 점이 있어서라는 반증일 수도 있고...
그런데 도대체 메타블로그의 용도는 무엇이란 말인가...
서비스 벤더 입장으로서는 트래픽과 컨텐츠 수집, 그리고 영향력이 직접적인 이유가 될 것이다.
허나 사용자 입장으로서는 고만고만한 메타블로그들이 늘어나봤자 무슨 이득이 있을까?
자신의 글이 유통되는 채널은 분명 메타블로그를 이용함으로써 얻는 가장 직접적인 이유이겠으나...
메타블로그의 딜레마는, 사용자가 늘어나고 영향력이 많아질 수록 개개 블로거의 위상은 점점 축소되어 마침내 메타블로그에 가입하든 말든 별 차이 없는, 오히려 검색엔진 쪽의 유입량이 더 많아지는 상태가 되곤 한다.
양질의 블로그와 컨텐트를 획득할 수 있다는 취지 역시, 사용자 pool이 많아지고 대중성이 넓어질 수록, 개개인에게 관심있고 유의미한 가치있는 블로그와 컨텐트를 찾기 더 어려워진다. 그도 그럴 것이, 대중의 선택은 늘 보편타당한 가치를 지향하게 되고, 집단 전체의 평균에게는 의미있을지는 몰라도, 개별 개인의 특화된 욕구에는 미흡한 것이 선택되기 마련. 그런데 도대체 "평균"과 일치하는 개인이라는 것이 어디에 있던가.
특화된 주제에 관련된 미니-메타블로그로 이 문제를 돌파해보려는 시도도 있지만...
그 규모가 전체에 비해 축소될 뿐, 여전히 "타인의 취향"은 "나"와는 괴리되기 마련. 의심스럽다면, DCInside의 아무 갤러리나 들어가서 글들을 읽어보시길. 비록 내가 좋아하는 주제의 갤러리더라도 전체 글 중에 10%정도나 나한테 가치있고 의미있을까, 나머지 90%는 타인에게는 어떤 가치일 지언정, 나 자신에게는 특별한 가치가 되지 못한다. 또다른 예를 들자면, 내가 아무리 "경제"에 관심있다 해서 네이버 뉴스의 "경제"면 기사를 전부 다 읽어야 하는가?(읽을 수 있는가? 또는 읽어봐야 할까?)
국내에 많은 메타블로그들이 고만고만한 형태를 가지고 있고, 앞으로 등장할 메타블로그들 역시 그저 고만고만한 수준이라면... 메타블로그들이 늘어나봤자 별로 큰 가치는 못될 듯.
뭐, 뒤집어 말하자면, 그런 한계를 멋지게 깨부셔줄 수 있는 서비스가 나온다면 나름 대박일 수도 있겠다.
블코랑 직간접적으로 인연이 있는지라 관심있게 보지 않을 수 없는데....
메타블로그는 여전히 유효한가? 처음 블코가 세상에 나왔을 때와 지금은 시간이 흐르고 상황도 바뀌었다. 내 생각은 그저 그렇다 쯤.
여전히 메타블로그에 대한 관심들을 가지는 건, 미디어의 소통채널로써의 메타블로그의 영향력을 무시할 수 없을 뿐더러, 컨텐츠 어그리게이팅의 좋은 수단이기 때문...
한편으로는 여전히 메타블로그에 뛰어드는 플레이어들이 있다는 것은 그만큼 기존의 메타블로그가 부족한 점이 있어서라는 반증일 수도 있고...
그런데 도대체 메타블로그의 용도는 무엇이란 말인가...
서비스 벤더 입장으로서는 트래픽과 컨텐츠 수집, 그리고 영향력이 직접적인 이유가 될 것이다.
허나 사용자 입장으로서는 고만고만한 메타블로그들이 늘어나봤자 무슨 이득이 있을까?
자신의 글이 유통되는 채널은 분명 메타블로그를 이용함으로써 얻는 가장 직접적인 이유이겠으나...
메타블로그의 딜레마는, 사용자가 늘어나고 영향력이 많아질 수록 개개 블로거의 위상은 점점 축소되어 마침내 메타블로그에 가입하든 말든 별 차이 없는, 오히려 검색엔진 쪽의 유입량이 더 많아지는 상태가 되곤 한다.
양질의 블로그와 컨텐트를 획득할 수 있다는 취지 역시, 사용자 pool이 많아지고 대중성이 넓어질 수록, 개개인에게 관심있고 유의미한 가치있는 블로그와 컨텐트를 찾기 더 어려워진다. 그도 그럴 것이, 대중의 선택은 늘 보편타당한 가치를 지향하게 되고, 집단 전체의 평균에게는 의미있을지는 몰라도, 개별 개인의 특화된 욕구에는 미흡한 것이 선택되기 마련. 그런데 도대체 "평균"과 일치하는 개인이라는 것이 어디에 있던가.
특화된 주제에 관련된 미니-메타블로그로 이 문제를 돌파해보려는 시도도 있지만...
그 규모가 전체에 비해 축소될 뿐, 여전히 "타인의 취향"은 "나"와는 괴리되기 마련. 의심스럽다면, DCInside의 아무 갤러리나 들어가서 글들을 읽어보시길. 비록 내가 좋아하는 주제의 갤러리더라도 전체 글 중에 10%정도나 나한테 가치있고 의미있을까, 나머지 90%는 타인에게는 어떤 가치일 지언정, 나 자신에게는 특별한 가치가 되지 못한다. 또다른 예를 들자면, 내가 아무리 "경제"에 관심있다 해서 네이버 뉴스의 "경제"면 기사를 전부 다 읽어야 하는가?(읽을 수 있는가? 또는 읽어봐야 할까?)
국내에 많은 메타블로그들이 고만고만한 형태를 가지고 있고, 앞으로 등장할 메타블로그들 역시 그저 고만고만한 수준이라면... 메타블로그들이 늘어나봤자 별로 큰 가치는 못될 듯.
뭐, 뒤집어 말하자면, 그런 한계를 멋지게 깨부셔줄 수 있는 서비스가 나온다면 나름 대박일 수도 있겠다.
2007년 4월 21일 토요일
마이크로포맷을 웹페이지에 적용시 주의점
슬슬, 마이크로포맷도 수면위로 올라오는 듯 하다.
마이크로포맷을 웹페이지에 적용할 때 주의해야 할 몇가지.
1. AJAX나 DHTML로 마이크로포맷을 만들지 말 것.
물론, 웹브라우저나, OS단에서는 AJAX등으로 만들어지는 마이크로포맷도 충분히 처리할 수 있지만, 여전히 마이크로포맷의 목표는 (Human Readable) Machine Feed이기 때문에 AJAX등을 해석할 수 없는 기계에서도 읽을 수 있도록 JavaScript와 무관하게 HTML안에 마이크로포맷이 들어있어야 한다.
2. 당연한 이야기지만 표준 마크업을 준수해야 한다.
마이크로포맷은 상당히 플렉서블한 구조이긴 하나 어디까지나 표준 HTML을 준수해야만 한다. 마이크로포맷파서는 기본적으로 표준HTML을 파싱할 것을 가정하기 때문에, 마이크로포맷자체가 표준HTML 마크업을 따르지 않을 경우 파싱이 잘못될 수 있다.
3. 보이는 것이 전부는 아닐 수 있다.
CSS를 잘 이용하면, 마이크로포맷을 웹페이지에 적용했을 때, 사람의 눈에 보이는 부분외에도 숨겨진 정보를 제공할 수 있다. 당연히 시맨틱한 마크업이 우선되어야 하며, CSS로 제어가능해야한다.
4. WYSIWYG는 쥐약.
현존하는 WYSIWYG HTML에디터들은 마이크로포맷을 제대로 반영할 수 없다. 마이크로포맷이 필요한 컨텐트는 아직까지 손으로, 혹은 별도의 템플릿을 이용해서 마크업해야 한다.
일단 만들어진 마이크로포맷도 WYSIWYG 에디터를 이용하게 되면 포맷이 깨질 수 있다.
아마도 마이크로포맷을 위한 진화된 WYSIWYG - 이정도라면 이미 WYSIWYM이겠지만 - 을 만들어내면 대박... :)
마이크로포맷을 웹페이지에 적용할 때 주의해야 할 몇가지.
1. AJAX나 DHTML로 마이크로포맷을 만들지 말 것.
물론, 웹브라우저나, OS단에서는 AJAX등으로 만들어지는 마이크로포맷도 충분히 처리할 수 있지만, 여전히 마이크로포맷의 목표는 (Human Readable) Machine Feed이기 때문에 AJAX등을 해석할 수 없는 기계에서도 읽을 수 있도록 JavaScript와 무관하게 HTML안에 마이크로포맷이 들어있어야 한다.
2. 당연한 이야기지만 표준 마크업을 준수해야 한다.
마이크로포맷은 상당히 플렉서블한 구조이긴 하나 어디까지나 표준 HTML을 준수해야만 한다. 마이크로포맷파서는 기본적으로 표준HTML을 파싱할 것을 가정하기 때문에, 마이크로포맷자체가 표준HTML 마크업을 따르지 않을 경우 파싱이 잘못될 수 있다.
3. 보이는 것이 전부는 아닐 수 있다.
CSS를 잘 이용하면, 마이크로포맷을 웹페이지에 적용했을 때, 사람의 눈에 보이는 부분외에도 숨겨진 정보를 제공할 수 있다. 당연히 시맨틱한 마크업이 우선되어야 하며, CSS로 제어가능해야한다.
4. WYSIWYG는 쥐약.
현존하는 WYSIWYG HTML에디터들은 마이크로포맷을 제대로 반영할 수 없다. 마이크로포맷이 필요한 컨텐트는 아직까지 손으로, 혹은 별도의 템플릿을 이용해서 마크업해야 한다.
일단 만들어진 마이크로포맷도 WYSIWYG 에디터를 이용하게 되면 포맷이 깨질 수 있다.
아마도 마이크로포맷을 위한 진화된 WYSIWYG - 이정도라면 이미 WYSIWYM이겠지만 - 을 만들어내면 대박... :)
2007년 4월 20일 금요일
전화위복?
MBP에 Apple BT Wireless키보드와 BT 마이티마우스를 쓰다가, 아무래도 작업효율이 좋지 않아서 UltraNav 키보드로 바꾼지 한달.
노파심에 첨언하자면 BT Wireless 애플 키보드와 BT 마이티마우스 모두 나쁘지 않고 좋은 물건이긴 하다.
문제는, 내가 IBM의 빨간콩에 너무 길들여 졌다는 것. ThinkPad에서 MBP로 바꾸고 나서 가장 불편했던 것이 ThinkPad의 잊을 수 없는 그 키감과, 제다이 포스에 필적하는 상상만으로 움직이는 포인트스틱이랄까. 게다가 자칫잘못하면 엄지손가락뿌리부분의 살집에 눌려 제멋대로 움직이는 터치패드에 조심스러워할 필요도 없고.
한번 키보드에 손을 올리면 손목 움직일 필요도 없는 그 에르고노믹스에 반해서 늘 다른 솔루션에 대해 불만이었던 것.
MBP로 바꾸고 나서 MBP의 미끄러지는 키감이 싫어 일부러 BT 무선 키보드, 마우스를 샀지만, 번거롭게 팔뚝을 움직여야 하는 행위는 나처럼 게으른 사람에게는 쥐약.
그래서 시험삼아 UltraNav 키보드를 붙여보니 잘 붙는다. 심지어 볼륨조절버튼도 먹는다.
그런데 한가지 아쉬운 점은 전용드라이버가 없다보니, TouchPad를 끌 수가 없다는 점. TrackPoint를 사용할 때에는 UltraNav의 TouchPad를 꺼야 하는데, OSX에서는 방법이 없다.
좀 알아본 바, MS의 마우스드라이버를 구해서 해킹을 하라던데, info.plist 파일을 아무리 뒤져봐도 적절히 고쳐야할 부분을 알 수가 없더라...
그래서 포기하고 있던 차에...
사설이 길었다.
오늘 사무실 책상에서 커피마시다 흘렸는데, 공교롭게도 UltraNav 키보드에 직격. 부랴부랴 키 뽑고 분해해서 대충 훔쳐낸 뒤 재조립했는데...
TouchPad가 죽었다. 못꺼서 안달이었는데, 이렇게 죽어주다니 고마울 뿐.
노파심에 첨언하자면 BT Wireless 애플 키보드와 BT 마이티마우스 모두 나쁘지 않고 좋은 물건이긴 하다.
문제는, 내가 IBM의 빨간콩에 너무 길들여 졌다는 것. ThinkPad에서 MBP로 바꾸고 나서 가장 불편했던 것이 ThinkPad의 잊을 수 없는 그 키감과, 제다이 포스에 필적하는 상상만으로 움직이는 포인트스틱이랄까. 게다가 자칫잘못하면 엄지손가락뿌리부분의 살집에 눌려 제멋대로 움직이는 터치패드에 조심스러워할 필요도 없고.
한번 키보드에 손을 올리면 손목 움직일 필요도 없는 그 에르고노믹스에 반해서 늘 다른 솔루션에 대해 불만이었던 것.
MBP로 바꾸고 나서 MBP의 미끄러지는 키감이 싫어 일부러 BT 무선 키보드, 마우스를 샀지만, 번거롭게 팔뚝을 움직여야 하는 행위는 나처럼 게으른 사람에게는 쥐약.
그래서 시험삼아 UltraNav 키보드를 붙여보니 잘 붙는다. 심지어 볼륨조절버튼도 먹는다.
그런데 한가지 아쉬운 점은 전용드라이버가 없다보니, TouchPad를 끌 수가 없다는 점. TrackPoint를 사용할 때에는 UltraNav의 TouchPad를 꺼야 하는데, OSX에서는 방법이 없다.
좀 알아본 바, MS의 마우스드라이버를 구해서 해킹을 하라던데, info.plist 파일을 아무리 뒤져봐도 적절히 고쳐야할 부분을 알 수가 없더라...
그래서 포기하고 있던 차에...
사설이 길었다.
오늘 사무실 책상에서 커피마시다 흘렸는데, 공교롭게도 UltraNav 키보드에 직격. 부랴부랴 키 뽑고 분해해서 대충 훔쳐낸 뒤 재조립했는데...
TouchPad가 죽었다. 못꺼서 안달이었는데, 이렇게 죽어주다니 고마울 뿐.
2007년 4월 18일 수요일
삽질
1. 5시간 동안 이유없는 버그에 시달리다가 결국 소스 코드를 한 줄씩 쫓아가며 찾아본 결과 디렉토리의 퍼미션 문제로 판명. 이런 제길...
교훈 : 타인에게 배포할 라이브러리에는 친절한 Assertion이 반드시 필요하다. 에러가 나는 것을 감추려 들지 말 것. 어디가 문제인지 알아야 고치지...
2. timezone관련 루틴이 필요해서 뒤져보다가 php를 판올림해야 함을 알았다. 그러나 php 판올림 대신 관련 라이브러리를 직접 제작하려다 보니...
한시간이면 판올림했을 것을, 서너시간 걸려도 필요한 기능의 반도 못 구현했다.
교훈 : 결정은 빨리 내려야 한다.
어제오늘의 삽질목록...
교훈 : 타인에게 배포할 라이브러리에는 친절한 Assertion이 반드시 필요하다. 에러가 나는 것을 감추려 들지 말 것. 어디가 문제인지 알아야 고치지...
2. timezone관련 루틴이 필요해서 뒤져보다가 php를 판올림해야 함을 알았다. 그러나 php 판올림 대신 관련 라이브러리를 직접 제작하려다 보니...
한시간이면 판올림했을 것을, 서너시간 걸려도 필요한 기능의 반도 못 구현했다.
교훈 : 결정은 빨리 내려야 한다.
어제오늘의 삽질목록...
2007년 4월 12일 목요일
대체재
거창한 제목이긴 한데, 포스팅은 짧다.
대체재가 없는 서비스는 개발자로서 유혹적이긴 하지만 소비자로서는 쉽사리 질린다.
그러나 더 나쁜 것은, 대체재라는 것들이 실제로 별 차이 없는 워너비들뿐일 때.
내가 A라는 것에 대해 a라는 불만을 가졌을 때, 대체재 B는 a에 대한 불만을 해소할 수 있는 장치가 준비되어 있어야 한다. 그렇지 않다면 애초에 대체재가 될 수도 없겠지.
문제는, 불만이라는 것은 지극히 개인적인 경험이라는 것. 따라서 그 불만을 공유하지 못한다면 대체재의 수요자체도 없는 셈이다. 무늬만 다른, 그러나 실제로는 똑같은 서비스들을 보고 있노라면 웹2.0이 가져다 준 것은 화려한 미사여구와 라운드 디자인, 그리고 달콤하면서도 뻔뻔한, 사용자들의 노동력 착취 포장법 뿐인 것 같다.
대체재가 없는 서비스는 개발자로서 유혹적이긴 하지만 소비자로서는 쉽사리 질린다.
그러나 더 나쁜 것은, 대체재라는 것들이 실제로 별 차이 없는 워너비들뿐일 때.
내가 A라는 것에 대해 a라는 불만을 가졌을 때, 대체재 B는 a에 대한 불만을 해소할 수 있는 장치가 준비되어 있어야 한다. 그렇지 않다면 애초에 대체재가 될 수도 없겠지.
문제는, 불만이라는 것은 지극히 개인적인 경험이라는 것. 따라서 그 불만을 공유하지 못한다면 대체재의 수요자체도 없는 셈이다. 무늬만 다른, 그러나 실제로는 똑같은 서비스들을 보고 있노라면 웹2.0이 가져다 준 것은 화려한 미사여구와 라운드 디자인, 그리고 달콤하면서도 뻔뻔한, 사용자들의 노동력 착취 포장법 뿐인 것 같다.
2007년 4월 9일 월요일
웹사이트의 단축키
웹사이트의 단축키를 위한 조언.
1. 사용하지 마라.
웹사이트의 단축키는 접근성과 편의성을 올려줄 수도 있지만, 그 반대일 경우도 많다.
가장 좋은 것은 단축키를 제공하지 않는 것이다. 표준 인터페이스만을 지키는 것이 좋다. accesskey는 계륵이나 마찬가지.
2. 사용자의 환경을 가정하지 마라.
사용자는 Windows XP + IE6만을 쓰는 것은 아니다. 대놓고, "우리는 Windows XP + IE6만 지원해요"라고 써놓지 않았다면, 사용자의 환경을 마음대로 추측해서 가정하면 안된다.
이것은 단지, "OSX와 FF도 고려해주세요.." 라는 뜻은 아니다.
예를 들어 어떤 사용자는 당신이 한번도 경험해보지 못했던 스크린리더를 이용하는 시각장애인일 수도 있다.
또 어떤 사용자는, 손에 익은 개발환경을 위해 수많은 단축키로 구동되는 어플리케이션을 사용하는 하드코어 개발자일 수도 있다.
당신이 이정도면 IE와 FF에서 무리없이 돌아갈 거라고 설정해놓은 단축키들은 사용자가 이미 다른 용도로 사용하고 있었던 단축키일 수도 있다.
3. 단축키에만 의존하지 마라.
애플아이폰에서 사파리로 웹서핑하는 사용자도 있을 수 있고, Wibro용 카PC에서 웹서핑하는 사용자도 있을 수 있다. 터치스크린에서 단축키를 쓴다거나, 운전중에 단축키를 사용할 수 있을까? 핵심기능이 단축키로 제공된다는 것은 접근성면에 심각한 장애를 준다.
4. 사용자를 시험에 들게 하지 마라.
제 아무리 편리한 단축키라 해도 단축키를 외우는 것은 사용자에게 쉬운 일은 아니다.
정말 우리 서비스는 겨우 7개의 단축키만 알고 있으면 되는데... 라고 할지라도, 사용자는 당신의 서비스만 쓰는 것은 아니다. 이 서비스에서는 이 단축키, 저 서비스에서는 저 단축키... 사용자가 편리하라고 제공하는 단축키인가? 아니면, 개발자인 당신이 편리하라고 제공하는 단축키인가?
5. 단축키를 사용자가 지정할 수 있도록 하라.
꼭 단축키를 제공하고 싶다면, 사용자가 지정할 수 있게 하라. default 키 조합을 제공하되, 키 조합을 바꿀 수 있는 수단을 제공하라. 그래야 사용자가 자신이 진짜로 손에 익은 단축키를 설정해서 사용할 수 있다. 그렇지 않은 단축키들은 모두 나름 UX 제고를 가장한 기획자와 개발자의 자기만족일 뿐이다.
1. 사용하지 마라.
웹사이트의 단축키는 접근성과 편의성을 올려줄 수도 있지만, 그 반대일 경우도 많다.
가장 좋은 것은 단축키를 제공하지 않는 것이다. 표준 인터페이스만을 지키는 것이 좋다. accesskey는 계륵이나 마찬가지.
2. 사용자의 환경을 가정하지 마라.
사용자는 Windows XP + IE6만을 쓰는 것은 아니다. 대놓고, "우리는 Windows XP + IE6만 지원해요"라고 써놓지 않았다면, 사용자의 환경을 마음대로 추측해서 가정하면 안된다.
이것은 단지, "OSX와 FF도 고려해주세요.." 라는 뜻은 아니다.
예를 들어 어떤 사용자는 당신이 한번도 경험해보지 못했던 스크린리더를 이용하는 시각장애인일 수도 있다.
또 어떤 사용자는, 손에 익은 개발환경을 위해 수많은 단축키로 구동되는 어플리케이션을 사용하는 하드코어 개발자일 수도 있다.
당신이 이정도면 IE와 FF에서 무리없이 돌아갈 거라고 설정해놓은 단축키들은 사용자가 이미 다른 용도로 사용하고 있었던 단축키일 수도 있다.
3. 단축키에만 의존하지 마라.
애플아이폰에서 사파리로 웹서핑하는 사용자도 있을 수 있고, Wibro용 카PC에서 웹서핑하는 사용자도 있을 수 있다. 터치스크린에서 단축키를 쓴다거나, 운전중에 단축키를 사용할 수 있을까? 핵심기능이 단축키로 제공된다는 것은 접근성면에 심각한 장애를 준다.
4. 사용자를 시험에 들게 하지 마라.
제 아무리 편리한 단축키라 해도 단축키를 외우는 것은 사용자에게 쉬운 일은 아니다.
정말 우리 서비스는 겨우 7개의 단축키만 알고 있으면 되는데... 라고 할지라도, 사용자는 당신의 서비스만 쓰는 것은 아니다. 이 서비스에서는 이 단축키, 저 서비스에서는 저 단축키... 사용자가 편리하라고 제공하는 단축키인가? 아니면, 개발자인 당신이 편리하라고 제공하는 단축키인가?
5. 단축키를 사용자가 지정할 수 있도록 하라.
꼭 단축키를 제공하고 싶다면, 사용자가 지정할 수 있게 하라. default 키 조합을 제공하되, 키 조합을 바꿀 수 있는 수단을 제공하라. 그래야 사용자가 자신이 진짜로 손에 익은 단축키를 설정해서 사용할 수 있다. 그렇지 않은 단축키들은 모두 나름 UX 제고를 가장한 기획자와 개발자의 자기만족일 뿐이다.
피드 구독하기:
글 (Atom)