신년인사
29일부터 1월 4일까지 신정연휴입니다. (5일마저 휴가를 내버려? -.,-)
사무실의 초고속 인터넷과는 멀어집니다. 집에 인터넷은 너무 느려서. -_-a 또, 연휴기간 동안 가까운 요코하마나 치바현쪽으로도 여행다녀올 생각이구요.
그런 관계로 포스팅, 답변, 스팸 처리등이 미비할 걸로 예상됩니다.
조금 이르긴 하지만, 새해 복 많이 받으세요. 새해에도 잘 부탁드리겠습니다.
이바닥이 원래 그래
EBADAC - OOPARTS : Out Of Place Articles.Archive for December, 2006
openID 자료
저한테 openID 자료가 없냐고 메일로 여쭤보신 분이 계시던데…
저도 없습니다… 를 떠나서 정말 자료 찾기가 너무 힘들어요.
일단 개발하시는 분들은
http://www.lifewiki.net/openid/OpenIDLibraries
에 가시면 본인의 사용언어에 맞는 것으로 개발라이브러리 코드를 구하실 수 있습니다.
몇가지 용어를 이해하시면 더 쉽게 접근하실 수 있으실 겁니다.
Consumer : OpenID로 로그인, 가입, 정보가져오기… 등을 수행하는 서비스/사이트 를 말합니다. 다른 openID 사용자들을 자신의 서비스에 참여시키기 원하시는 분들은 Consumer관련된 코드를 활용하시면 됩니다.
Provider : OpenID를 사용자에게 발급해주고, Consumer의 요청이 있을 때 그에 대한 정보를 제공해주는 서비스/사이트를 말합니다.
반드시 하나의 서비스, 사이트에서 Provider와 Consumer 두가지 역할을 다 할 필요가 없습니다. (OpenID에 대해 좀 더 연구해보면 두가지 역할을 다 떠맡는게 좀 바보스러운 일임을 아시게 될겁니다.) 대개의 경우는 Consumer부분만 연구하시면 충분할 겁니다.
개인적으로는 OpenID를 SSO(Single Sign On) 대용으로 사용하는 것은 재고할 필요가 있다고 봅니다. 한국에서의 RSS의 오용(?)과 마찬가지로 주의깊게 준비하지 않고 OpenID 대응 서비스를 열 경우, 개인정보보호문제에 대해 상당히 시끄러울테니까요.
조삼모사 - Web Standards
이벤트는 마감되었지만… 갑자기 생각나서.
- 저공
- 오늘부터 Structured Markup을 이용하도록 합시다.
- 원숭이들
- 그게 뭔데! table도 충분히 편하다!
- 저공
- 그럼 계속 야근하든가…
- 원숭이들
- microformat도 적용할까요?
매일 해야지… 하다가 기껏 생각나니 이벤트는 끝… 내가 그렇지 모… 
아무 생각없는 인터페이스
StandardMag에 올라온 질문에 대한 답변을 정리해봅니다.
관습적인 인터페이스는 사용자에게 익숙함을 주긴 하지만, 관습에 매몰되어 매너리즘에 빠지게 되는 경우도 많지요.
회원가입페이지 제작시 가장 쉽게 보이는 매너리즘 인터페이스 두가지에 대해 이야기해보렵니다.
1. 3칸으로 나뉘어진 전화번호.
사실 핸드폰 번호 따로 집전화 번호 따로 입력받는 것도 무의미하긴 하지만.(’기분존’같은 서비스도 나온 마당에 말이지요.)
습관적으로 우리는 전화번호 입력 필드를 3칸으로 나누어 놓습니다.
이것은 결코 UX적으로 좋은 인터페이스라 할 수 없습니다.
우선 손이 많이 갑니다.
016 타이핑하고, tab키 누르고, 9447 타이핑하고, tab키 누르고, 8022 타이핑하고.
tab키를 이용할 줄 아는 사용자라면 이정도입니다만, 나이드신 분들은 필드간 이동을 하기 위해 다시 마우스를 잡고 해당 필드를 클릭해야 합니다.
이러다보니 이 불편함을 없애보자고 JavaScript를 써서 앞에 세자리, 입력하면 자동으로 다음 필드로 포커스를 옮겨보기도 하지만, 이러면 원래 tab키 이동이라는 표준 인터페이스에 익숙한 사용자에게는 오히려 잘못된 입력을 유도하게 됩니다.
게다가 이왕 JavaScript를 사용하는 김에 입력값 검사까지 해버립니다. 마지막 필드가 네자리 숫자가 아니면 틀렸다고 한다거나…
그러면 이제는 우리 회사 대표번호는 02-2424-825로 알려져 있는데, 굳이 02-242-4825로 입력해야만 합니다. 신경쓰지 않으면 타이핑 미스 생기지요.
그나마 무슨 이유로든간에 JavaScript 사용이 불가능하면 입력도 먹통이 되는 경우까지 생기기도 하지요.
애초에 그냥 한칸의 입력필드에 022424825로 입력하든, 02)2424-825로 입력하든, 02 2424 825 로 입력하든 사용자 맘대로 입력하게 해도 충분할 일입니다.
일단 그렇게 Form을 submit한 후, 간단한 정규식으로 전화번호를 추출하고, 그것이 전화번호 형식에 맞는지 안맞는지 판단하는 것은 어려운 일이 아니죠. 만약 전화번호가 틀린 포맷이라면 다시 이전 입력Form페이지로 돌리고 에러메시지(’전화번호가 틀렸습니다. 다시 입력해주세요.’)를 보이면 될 일입니다.
이전 페이지로 돌아가는 게 사용자에게 오히려 번거롭지 않냐구요?
전화번호 입력이 틀리는 경우는 거의 없습니다. 눈감고도 입력할 수 있는게 전화번호라구요. 오히려 세칸에 나누어 적고 JavaScript를 따라 널뛰는 조작보다는 훨씬 더 정확하게 입력할 수 있습니다.
물론 JavaScript가 안되는 환경에서도 문제없이 사용할 수 있구요.
2. 우편번호 팝업
도대체 왜 우편번호와 정확한 주소를 수집해가는지 모르겠습니다. 그거 가지고 인구센서스 통계내나요? 우리 사이트의 주 사용자는 서울에 살고 있어.. 같은?
그런 CRM 자료를 제대로 분석해서 사용하는 기획자나 운영자가 있는지는 모르겠습니다. 아마 오히려 접속 IP 위치를 통계내는 쪽이 좀 더 정확할텐데 말이지요.
우편번호나 주소를 수집하는 이유가 상품 배송이나 우편물 발송때문이라고도 하는데, 실제로 이런 서비스를 할 때에는 사용자에게 정확한 배송주소를 다시 물어보는 것이 정석입니다. 대부분의 업체에서도 그렇게 하고 있구요.
어쨌거나 그래서 정확한 우편번호나 주소가 필요하다 치더라도…
그래도 우편번호 팝업 입력은 아닙니다.
그럼 대안이 있을까요?
제가 전에 살던 집주소는…
“서울특별시 서대문구 대현동 56-38번지 5층”
입니다.
아무리 타이핑이 느린 분이더라도, 자기 집 주소를 한 줄에 입력하는 건 “버튼 눌러 팝업 뜨고 동이름 넣고 검색하고 후보들 나오면 목록에서 위아래로 오르내리며 찾아 선택하고 팝업이 닫긴 후 부모창의 다음 필드에서 번지이하 주소를 다시 입력하는 것”보다는 빠릅니다. 물론 훨씬 더 직관적이고 쉽기도 하지요.
주소가 정확한지는 어떻게 아냐구요? 우편번호는 어떻게 하냐구요?
저 위에 쓴 주소를 정규식 돌려서 도/시, 군/구, 읍/동 을 뽑아내는 것은 일도 아니지요. 그리고 그걸로 DB에서 매치되는 우편번호를 찾아내는 것도 어렵지 않지요. 굳이 AJAX같은 것을 쓰지 않더라도, 그냥 Form Submit한 후 서버사이드에서 매치시켜보고, 정확하지 않거나 매치되는 후보가 너무 많다면 다시 이전 페이지로 돌려 재입력 받게 하거나, 매치되는 후보들 중에서 선택하게 하면 됩니다.
JavaScript도 필요없고, 정상적인 사용자들에게 불편함도 없지요.
생각해보면 이런 관습적인 멍청한 인터페이스야 말로 UX의 가장 큰 적입니다. JavaScript나 AJAX가 없어서 사용성이 제한되는 게 아니라, 단지 상상력과 배려심이 없는 기획자 때문이지요. 아, 어쩌면 정규식을 다룰 줄 모르는 개발자 때문일 수도 있긴 하겠습니다.
Worst Mistakes…
이것저것 뒤지던 중에 우연히 보게 된 imakemistakes.com. 한 십분간 정신없이 웃었다.
다음은 worst mistakes 중에서 몇개 발췌.
* 그녀가 ‘사랑해’라고 말했을 때 웃어버렸어.
* 다리미를 놔두고 일하러 가는 바람에 아파트를 홀랑 태워먹었어.
* 헤어진 여자친구와 기회가 있었을 때 했어야 했는데…
* 내 아이팟 미니에 리눅스를 설치해보려 했어!
영예의 1위 (?)는,
“나 아직도 이 사이트를 보는 중이야.”
openID 만지작거리기
php로 openID 1.1 spec대로 프로그래밍해서 만지작거리고 있는데, 어떤 consumer에서는 제대로 인증이 되고, 어떤 consumer에서는 취소가 된다. 도대체 이유가 뭘까… 풀리지 않는 수수께끼. 로그를 읽어봐도 별거 없는데.
이런 오픈 규격을 내놓는 측에서는 이것저것 테스트해볼 수 있는 sandbox framework을 제공해야하지 않을까? 아니면 나만 못찾고 있는 걸까?
어쨌거나 일단은 openID 구현이 가능했다는 걸로 만족.
아, 한가지 더 풀리지 않는 수수께끼. provider와 account가 진짜로 reliable한지는 어떻게 알아내지? malicious한 provider라면 악의적인 목표로 fake user를 만들어 인증을 시도한다면 그것을 어떻게 구분하는거지? 도대체 알 수가 없네…
한국에는 마땅히 물어볼 만한 사람도 모르겠고. 끄응. 에라 모르겠다. 일단 gogo..
올블 프레임에 대한 마지막 부탁
* 이글을 마지막으로, 올블의 프레임에 대해 또 포스팅하는 일이 없었으면 합니다. 공연히 올블에 대해 나쁜 감정이 있는 것처럼 비추이는 것도 싫고, 실제로 개선되어서 불편함이 없어졌으면 하고 바라기 때문입니다.
1. 올블 프레임, 저작권.
파란의 블로그 스페이스에 대해 논란이 많았는데, 실상 그 메커니즘 자체는 올블이라고 크게 다를 바 없습니다. (지난 포스팅 참조)
개인이 자신의 블로그에 대해 올블 프레임을 다는 것을 허용했다한들 타인의 웹사이트에까지 그 프레임을 따라가게 하는 것을 허용했을리는 없습니다.
애초에, 아무리 올블이 블로거들에게 친화적이고 좋은 서비스라 하여도 그렇게 쉽게 자신의 컨텐츠를 특정 서비스의 프레임안에 가둬두어도 좋다고 허가하는 개인들도 선듯 이해되지 않기는 합니다.
2. 실질적인 불편함
굳이 올블 프레임에 대해 문제를 제기하는 이유는 저작권 등의 남의 다리 긁는 이유때문만이 아니라, 실제로 웹서핑이 불편해지기 때문입니다.
1) 실제 주소를 가립니다.
제가 링크하고 싶은 주소는, 북마크하고 싶은 주소는, machine-feed로 쓰고 싶은 주소는 link.allblog.net이 아닙니다. 아마 여러분들도 그럴 겁니다.
헌데, google에서 “link.allblog.net” (따옴표 포함)으로 검색해보세요. 저 검색결과에 자신의 블로그 주소가 link.allblog.net으로 걸린 블로그 주인들은 자신들의 링크가 저런 식으로 유통되도 좋다는 것을 자각하고 프레임을 허가했을까요?
어쨌거나, 수고스럽지만 클릭한번이면 프레임을 없앨 수 있으니 그 정도 수고쯤은 감수해야 할까요?
2) 프레임은 따라다닌다.
링크마다 새창띄우기(접근성때문에 하지 말라는), JavaScript로 최상위에서 리프레쉬하기(복잡하게 프레임과 AJAX로 얽혀있는 N,D모 블로그)인 블로그들도 있습니다만, 고지식하게 표준문법만으로 만들어진 블로그들이 있습니다. 이런 블로그들은 올블 프레임이 한번 뜨고 나면, 그 블로그 안에는 물론, 바깥으로 연결되는 다른 페이지까지 프레임은 따라다니게 됩니다. 웹서핑의 본질대로 링크따라 흘러다니다가, 아, 이 페이지 적어둬야지 하고 URL주소창을 보면 link.allblog.net/… 아까 출발했던 페이지. 이제 와서 프레임닫기 눌러봤자 최초 출발 페이지로 돌아가버리게 됩니다. 한번 이런 일을 겪으면 심신이 다 피폐해지죠.
[틀린그림찾기… :)]
3) 로그인안하면 무용지물…
어차피 올블 프레임의 많은 기능들은 로그인하지 않은 사용자에게는 무용지물입니다. 강제로 로그인을 유도해서 추천과 이슈의 활성화를 노리는지는 모르겠으나 어차피 대부분의 사용자는 로그인하지 않은 상태로 들어와, 로그인하지 않은 채로 올블을 이용하고, 앞으로도 계속 그럴 겁니다.
애초에, 로그인과 버튼 클릭이라는 사용자의 의도적 액션을 요구하는 자체가 집단지성이 될리도 없거니와, 그런 시도를 모든 사용자에게 요구한다 해서 달성될 리도 없겠지요.
애당초 올블 이용자가 올블 가입자 뿐일리도 없고, 그런 식으로 제한을 둔다는 건 오히려 전략 미스에 가까운 생각일테구요.
하여간에, 저같은 비로그인 사용자한테는 올블 프레임은 백해무익할 뿐. 차라리 자발적이고 적극적인 로그인 사용자한테만 올블 프레임을 보이게 한다거나,
혹은 올블 페이지에서 각 블로그로 창이 뜰 때 링크를 두개 줘서(하나는 작은 아이콘 형태라 하더라도) 프레임이 있는 창과 프레임이 없는 창을 선택할 수 있는 수단이라도 제공해주면 오죽 좋겠습니까.
올블에서 낚시성 포스트라도 하나 낚여볼라쳐도, 제일 먼저 하는 건 창이 뜨자마자 올블 프레임 닫기 행위입니다. 가끔 제대로 닫겨지지도 않는 프레임의 닫기 버튼을 클릭하기 위해 트랙패드를 긁어대고 있노라면 이 무슨 무의미한 짓을 반복하고 있나하는 회의감만 드네요.
부디… 로그인한 사용자에게만, 추천 버튼 누르겠다는 열의있는 사용자에게만 올블 프레임을 보여주면 안되겠습니까?
5W1H
“누가”, “언제”, “어디서”, “무엇을”, “왜”, “어떻게” 를 분석해낼 수 있다면 시맨틱/온톨로지는 그다지 뜬구름 같은 이야기가 아닐 수도 있다.
- who : openID, hCard, VCARD, hResume, Identification 2.0, Reputation, Relationship, XFN …
- when : VEVENT, hCalendar, iCalendar, dc:datetime…
- where : VEVENT, address, long-lat, map …
- what : URI, ISBN, bar-code, hReview, vocabulary, collabulary …
- why : ???
- how : ???
why와 how는 irregular text-context이지만, 나머지는 regularized unique-context로 구현 가능. 네가지는 객관적이지만, 두가지는 주관적. 따라서 사용자에게 두가지 가려운 부분을 손쉽게 긁어줄 수 있는 긁개만 제공해준다면 되는 것 아닌가? 결국은 인터페이스의 문제?
ps. 생각해보니, why와 how가 해당하는 서비스의 개성이 될 수 있겠다. 흠흠. just a memo.
딴죽
어쩌다 보니 이 블로그는 “딴지전문” 블로그가 된 것 같네요.
앞으로는 딴지는 좀 줄이고, tagline에 적혀있는 대로 web technical issue에 대해 집중할 생각입니다.
(그런데, “Issue”에 대해 이야기 하다보니 자꾸 딴지로 흐르게 되는군요. 반성.)
- 불친절하다는 소리를 몇번 듣다보니 생긴 노파심 포스팅
* 딴지는 딴죽의 잘못된 말이라지요.
파란과 올블로그
그냥 끄적끄적.
1) 주소창 바꾸는 건 파란이나 올블이나 그게 그거 아닌가?
2) 프레임안에 가두는 건 파란이나 올블이나 똑같은 거 아닌가? 한쪽은 프레임처럼 생기지 않아서? 한쪽은 없애는 버튼이 없어서?
3) 추천 등의 기능으로 마치 자사 서비스인 것 처럼 하는 것도 파란이나 올블이나 똑같은 거 아닌가?
4) RSS를 본인이 등록하건 타인이 등록하건 그게 무슨 상관인가? 그럼 hanrss같은 웹RSS도 주인장이 직접 등록을 해야하고, 개인이 만들어 쓰는 RSS 리더기도 블로그 주인들이 와서 등록해줘야 하는건가?
—
이 글은 파란을 옹호하는 글은 아니다. 파란의 블로그스페이스 서비스는 문제가 좀 있긴 한데 -
- 무분별하게 이미지등을 직접 링크하고 있어서 트래픽 누수를 일으키고,
- (robot.txt 같은)규칙을 지키지 않고,
- 서비스 운영이 세련되지 못하다는 점.
- 그리고 지금 없어졌지만 무책임한 스크랩기능.
그정도를 제외하고는 글쎄….
처음 네오비스님의 문제제기는 그런가보다 했는데, 그 후에 들불처럼 퍼지는 파란 때리기는 뭐랄까, 촛점을 일탈하고 있는 듯 하다.
하늘보고 침뱉는다고나 할 정도로, 문제점이라고 짚는 게 그들이 사용하는 올블로그에도 해당되는걸…
저 위에 질문으로 적어놓은 것들은 진짜로, 1) ~ 3)은 모두 올블로그도 저작권법을 매우 ‘심각하게’ 위반하고 있는 사항들이다. 다만, 파란과 다른 점은, 사용자들에게 ‘허가’를 받았다는 점.
그런데 올블로그 사용자들이 가입시 이것저것 과연 제대로 알고 ‘허가’를 한걸까? 그리고 과연 그 ‘허가’로 충분한 것일까?
예를 들어 자신은 올블로그에 가입하면서 올블로그 프레임(?)을 허용했으니, 자신의 블로그에 올블프레임이 떠도 괜찮다고 생각할 지도 모르겠지만,
그렇게 올블을 타고 들어온 사람들이 그 블로그에 링크되어있는 다른 URL을 타고 갈 때, 올블프레임도 따라 간다는 걸 알까? 다행히 목적지도 올블에 가입한 블로거고 그 역시 올블프레임을 허용했다면 모를까, 전혀 관계없는 다른 외부 URL로 갈 때 올블프레임도 따라온다는 것, 그래서 전혀 상관없는 제 3자의 홈페이지가 올블주소 아래에 띄어지고 있다는 것… 그 제 3 자의 저작권을 결과적으로 올블이 침해하는데 방조하고 있다는 사실을 인지하고는 있을까?
* 직접적인 예를 들기 위해 올블을 들먹였으나, 사실 콜콜넷이니 윙버스 같은 서비스들 모두 이 저작권 문제에서 전혀 자유롭지 못함을 노파심에 밝혀둔다.
RSS를 모아서 서비스하는 그 자체에 문제가 있는가? 그럴지도 모른다. 어쩌면 이미 사라진 컨텐트를 가리키는 아이템이 있을지도 모르고, 아이템 url을 참고로 본문을 직접 가져왔을 수도 있다.(봇이 안다닌다니 그건 아닐지도.) 어쨌거나 심지어 본문 자체가 검색엔진에 노출된다 해서 우리가 저작권에 대해 뭐라하지 않는 것처럼, RSS역시 RSS에 전문을 싣지 않는다해도 아이템URL을 통해 봇을 보내 본문을 긁어왔다면 그냥 검색이라 우기고 차라리 뭐라하지도 못했을 텐데… 파란 기획자는 좀 반성을 해야하겠다.
검색엔진의 룰을 준수하지 못하고, 서비스 운영이 미숙한 점은 욕먹어 지당하지만 그외에는 흠…
개인이 모은 RSS를 타인에게 제공하는 게 문제일까? hanrss의 ‘관련 RSS’도 개인이 모은 RSS를 프로파일링해서 타인에게 필터링해 보여주는 서비스인데, 과연 껍데기의 문제인 것인가?
왜이렇게 RSS는 타국에 와서 생고생을 해야하는가. RSS가 이정도이니 hCard나 openID같은 서비스라도 할라치면 아주 볼만하겠구나.