http://www.sinpodo.com/archives/1

수정 : 워드프레스 openid 플러그인에서 *기존의* 방식으로 표시하고 있네요.

홈페이지 필드를 받아서 판별하려면 그런 문제가 생기겠지요. delegate하지 않는 이용자의 경우 실제 홈페이지 주소를 따로 표시할 수 없는 문제도 있고.

그런데 이름 필드를 이용한다면, 오픈아이디도 아니면서 굳이 이름 필드에 url을 넣는 이용형태란 현실적으로 거의 존재할 것 같지 않습니다.

그리고 '아이디 하면 알파뉴메릭과 언더바'라는 온라인 불문률 때문인지, 이름 중간에 마침표를 넣어서 쓰는 이용자를 거의 본 적이 없는 것 같습니다.

각각의 개인의 입장에서는 나와 있는 툴을 선택하는 것이지만, 툴을 중심에 놓고 생각할 때는 위키 방식을 지원하는 것으로 더 다양한 사용성을 부가하게 되는 것이 아닐까요.
블로그에 위키가 상충된다고 생각하지 않습니다. 없는 부분을 더해준다고 생각합니다. 이를테면 자신의 글에 하이퍼링크를 손쉽게 걸 수 있다는 점은 글간의 연결성과 짜임새를 향상시킬 것이고 전체적인 포스팅의 일관성을 촉진할 수도 있지요.

제가 처음에 적은 게 그런 내용입니다. 하이퍼링크에 키워드만 기재하고 실제 검색은 링크가 호출되었을 때 이뤄지는 그런. 그런데 페이지가 존재하는지 안 하는지를 클릭하기 전에는 전혀 예상할 수 없다는 문제가 생깁니다. "아직 공사중입니다." 수준으로 사용성이 나쁘고, 위키의 '없는 페이지를 채워넣으려는 동기유발'도 안 됩니다. 그런 문제가 있으니까 어쨌든 페이지를 출력할 때 제목을 검색할 수밖에 없지 않을까 싶습니다.

그리고 기존 위키(특히 노스모크모인모인, 모니위키 계열의)에 익숙한 사람이라면 [wiki:PageName]의 형식은 인터위키로, 내부 페이지는 [PageName]과 PageName의 형식으로 쓰는 것을 이왕이면 선호할 겁니다.

위키에서 텍스트는 저장할 때마다 불어나지만 (전통적인 방식에서는 맞춤법 수정으로 저장을 9번 하면 용량이 10배로 불어버립니다, 그래서 rcs를 쓰거나 합니다) 정작 diff를 들여다볼 일은 사실 최근에 수정된 것 밖에 없거든요. diff 호출은 RecentChanges 범위에 완전히 집중되어 있습니다. (만일 diff가 유용할 일이 있다면 그건 diff로 남겨놓을 게 아니라 본문에 반영해놓아야 하는 것이죠.) 나머지는 순전히 낭비입니다. 그 오래된 구버전들을 정리할 때 언급하신 방식으로는 매번 본문 테이블 전체를 긁어야 합니다. 그리고 diff 작업이 빈도가 높은 게 아닌데 본문에다 모두 모아놓는 건 다른 작업에서 손해겠죠. (특히 본문검색은)

모인모인 문법(특히 테이블 만들기)이면 릴리즈해주세요~

[ ] 로 묶은 글은 그 안의 내용으로 제목 검색을 하게 하는 하이퍼링크 적용. 클릭하면 해당 제목의 포스트로 바로 이동. 해당 제목의 포스트가 없을 때는 어드민일 때 '이 제목으로 포스트 생성, 비슷한 제목의 포스트들...' 등등 출력. 그런데 이렇게 하면 부하가 줄더라도 아직 포스트가 없는 제목을 구별해서 표시할 수 없으니까 문제가 되는군요. -_-
제목 충돌이 있을 경우에는 최선의(제 생각에는 최초의) 포스트로 이동하게 하고 제목 하단에 여타 포스트들 링크를 표시(위키피디아처럼).
제목 충돌이 있을 때 포스트를 특정할 수 있도록 [] 안에서 구별 접미사같은 것도 가능하겠지만.. 문법이 복잡해지는 것도 그렇고, 가능한 제목 충돌을 피하게끔 유도하도록 일부러 제공하지 않는 편이 좋다고 생각합니다.
역링크는 포스트 제목 옆에 출력시키도록 해야겠고요.
버전관리와 RecentChanges는 있으면 좋을텐데 개인적으로는 변경점을 개별 포스트에 물려서 저장해서 하는 것보다, 포스트번호와 diff를 한 데 저장해서 처리하는 게 낫지 않나 싶어요. RecentChanges가 적당히 길다면, 그보다 이전에 있었던 변경사항은 사실 잘 들여다보지 않으니까요.

안내메시지 vs 영구적인 로그인의 개념이 아니라, 타임아웃이 있다면, 로그인이 풀릴 때 그 때 쓰이도록 하자는 것이지요.
아무 말도 없이 세션이 끊어지는 것이 미리 안내팝업이 나오는 것보다 더 편리하거나 직관적이지는 않은 것 같습니다..

그리고 영구적인 로그인은 공식지원이 없을 거라고 합니다.
http://www.tattertools.com/ko/forum/vie … php?id=280

더 자세하고 더 친절하게 만들 수는 있겠지만, 알기 쉽게 만드는 건 대단히 어려운 일일 것 같습니다.

그게... 요즘 0.9x 버전 사용자수를 보고 느낀 건데, 대단히 보수적인 (관심이 없거나, 유지보수를 매우 어려워하거나, 어지간해서는 굳이 손대고 싶어하지 않는) 사용자들이 생각보다 훨씬 많더군요. 절대적인 수로 보면 적은 수가 되겠지만요. 0.961 뿐만 아니라 0.95 사용자도 많았고 심지어는 0.93 유저도 있는 것을 보았습니다. 최근 스팸이 커다란 문제가 되면서야 비로소 사용중인 도구에 관심을 갖게 되신 분들이지요.
제가 말한 '사람들'은 그런 분들입니다. 플러그인 설치와 유지보수에 별 수고를 느끼지 못하시는 분들이야 CAPTCHA를 쓰다가도 주저없이 EAS로 바꾸시겠지만, 아주 큰 문제가 생겼을 때가 아니고서는 유지보수에 관심을 갖지 않는 분들께선 일단 CAPTCHA가 스팸차단을 잘 해내기 시작하면 이후에는 다시 스팸차단솔루션에 관심을 갖거나 혹은 굳이 손을 대어 EAS로 바꾸는 일 없이 그대로 머무르시는 경우가 많을 겁니다. graphittie님께서 말씀하시는 불편함은 그것이 불완전한 구현임을 알지 못하는 분들께는 스팸을 막기 위해서는 어쩔 수 없이 감수해야 하는 (원래 그러한) 불편으로 받아들여질 가능성이 높을 것 같습니다.
이상한 이야기 같습니다만 그런 생각이 들어서 문득 적어본 가벼운 감상이었습니다.

(스팸처리하기 클릭)

이렇게 하면 단순하게 되지 않을까요.