Recent Changes토론

FrontPage|FindPage|TitleIndex|RecentChanges| UserPreferences P RSS
위키위키를 익숙하게 다루는 사람은 거의 누구나가 RecentChanges를 통하여 그 위키를 접근하려 한다. 그리하여 RecentChanges에 대한 사용자의 불만 및 여러가지 요구가 있다. (See UnifiedRecentChanges, RecentChangesPersonalization)

그런데, 정작 RecentChanges는 위키위키여행을 방해하는 요소라고 말하기도 한다. OriginalWiki를 들어가면 이상하게도 RecentChanges로 향하는 링크가 없는 것을 볼 수 있다. WardCunningham이 의도적으로 RecentChanges를 드러나지 않도록 만든 것임을 짐작할 수 있다.

여러가지 얘기를 할 수 있을텐데 일단 단편적인 물음을 적어봅니다 --무신
  1. RecentChanges가 위키여행의 방해가 되는가 ?
  2. RecentChanges를 사용하지 않는 위키도 있는가 ? (LovolNet은 근래에 RecentChanges를 아예 없앴습니다.)
  3. RecentChanges를 의도적으로 드러내지 않은 위키의 장점/단점은 ?
    사전류나 LovolNet같이 다루는 대상이 뚜렷한 사이트에 적합하다. 그러나 노스모크와 같은 커뮤너티에는 적합하지 않아 보인다. 가령 어떤 문제의 '이슈화'가 자연발생적으로 이루어지기가 힘들고 누군가의 의도에 의존하게 될 것만 같다. --맑은

RecentChanges를 살펴보다 보면 노스모크의 특정한 주제에 대하여만 보게되는 단점이 있습니다. 이럴 때는 ChronologicalTitleIndex를 맨 마지막에서 부터 거슬러 올라가며 살펴보면 재밌습니다. --무신

"ChronologicalTitleIndex 의 인터페이스를 RecentChanges와 같게 하면 안되나?"라는 생각을 참 자주 했었는데... --맑은

약간 딴 이야기 인듯 하긴 합니다만 노스모키안들은 왜 노스모크에 오는 걸까요? 그것이 명확하지 않은 이상 현재에 위키에 대한 개선(?)에 관한 이야기도 의미가 없지 않나 라는 그런 생각이 불현듯 듭니다. --잡종

이 주제가 노스모크에 대한 이야기만으로 한정되어야 할 이유는 없습니다. 여기서 나오는 토론이 노스모크RecentChanges를 바꾸어야 한다는 이야기도 아니구요. RecentChanges의 변동이 거의 없을수도 있는 개인위키페이지 혹은 위키를 홈페이지의 대용으로 꾸미는 분들이 고민할 만한 이야기를 하고자 하는 것입니다. 물론, 현재 노스모크RecentChanges에 대한 문제점에 대한 이야기로 풀어갈 수도 있지만요. --무신

그렇군요.의도를 오해 했습니다.--잡종

제가 노스모크RecentChanges가 문제점이 있다고 딱 부러지게 지적하지는 않았으나, 대부분의 위키위키가 그렇듯이, RecentChanges에 대한 집중도가 크기 때문에 노스모크의 전체를 제대로 못보고 있는 것은 아닌가 하는 저의 숨은 의도가 없다고 말할 수는 없겠지요. :p --무신

스토킹 같다.필명 없이 쓴 글이 있었는데. 누군가 필명을 달아놨는지.. 자동으로 달어진 것 같진 않고.. 놀랬다. RecentChanges를 본걸까?
그런데. 좋은 점도 있는 것 같다. 보통 웹에서는 어떤 사람이 뭘하고 있는지 실시간으로 알 수가 없는데. 여기서는 행동을 보는 것 같아서.
우엑. 3D안경도 있군.
-- buffun


RecentChanges가 위키위키의 발전을 저해하는 요소는 아무래도 페이지온도의 편향성이 아닐까. RecentChanges에 올라온 글은 결국은 뜨거운페이지가 주종을 이루게 된다. 결국 RecentChanges는 위키위키의 맥스웰의악마인 셈이다.

그러나

뜨거운페이지는 그만큼 페이지의 업데이트가 자주되며 노스모키안들의 이목이 집중되고 자주 찾는 페이지라는 말이다. 그리고 그런 뜨거운페이지를 쉽게 찾을 수 있는 툴인 RecentChanges는 위키위키에는 없어서는 안되는 편한 기능이 아닐까.



사소한 변화와 RecentChanges

두어달 가까이 주로 노스모크를 지켜보면서 생각한 건데, 수시로 보게 되는 페이지가 RecentChanges 입니다. 그런데 점점 RecentChanges 중에서 최근에 수정된 페이지를 보는 경우가 적어진다는 것이지요. 이유는 지난번에 A 라는 페이지를 보았을 때와 이번에 수정된 A 페이지를 보았을 때 실제로 글 내용이 바뀐 것이 거의 없는 경우가 많기 때문입니다. minor 한 변화는 RecentChanges 에 나타나지 말았으면 좋겠다는 생각이 들 때가 있습니다. Bookmark 를 사용해도 마찬가지. 하나하나 update 를 클릭해서 뭐가 바뀌었는지 확인하고 다시 뒤로 되돌아와서 다를 update 를 클릭하게 되죠. 아, 이건 제가 주로 사용하는 게시판의 기능에 너무 익숙해져 있기 때문일 수도 있습니다. 로긴한 상태에서 읽은 글과 읽지 않은 글을 기억하고 있다가 읽지 않은 글은 '새글읽기' 라는 링크를 한 번 클릭하는 것으로 모두 볼 수가 있거든요. 다섯 개의 게시판에 각각 10 개 씩의 새 글들이 있다면 클릭 다섯 번으로 (back 할 필요도 없이) 새 글을 모두 볼 수 있습니다. -- JikhanJung
문제는 이게 minor한 변화이냐 아니냐를 누가 결정하냐는 것이죠. 컴퓨터가? 불가능하죠. 그럼 글 쓴 사람이? 이걸 도입한 곳이 OriginalWiki입니다. 글을 수정할 때 이게 RecentChanges에 올라오냐 아니냐를 선택할 수 있죠. 하지만 감춰진 것들도 QuickChanges에서는 모두 볼 수 있죠. RecentChanges에 올라오는 게 선택적이라는 사실에서 또 많은 문제점이 양산되거든요. 그런데, 새글 읽기로 새 글을 모두 읽는 것은 전 별로 끌리지 않네요. 어차피 하루에 올라오는 글이 한두개도 아니고, 대충 관심있는 것만 살펴보거든요. 모든 사람이 봐야할 중요한 내용이라면 공지 페이지를 이용하거나 AttentionPages를 쓰거나 하면 될테고..
사실 제가 느끼는 불편은 여러 페이지의 diff 를 한꺼번에 보여주고 bookmark 까지 업데이트 해주는 기능이 있으면 간단히 해결되는 거긴 하죠. :) minor change 에 대한 판단을 할 수 있게 해주는 기능이 TWiki 에도 있었던 것 같은데, 위키 시스템 자체가 '선의의 사용자' 에 의해서 이용된다는 가정에 기초하고 있기 때문에 그 가정대로라면 큰 문제가 생길 것 같진 않군요.


"; if (isset($options[timer])) print $menu.$banner."
".$options[timer]->Write()."
"; else print $menu.$banner."
".$timer; ?> # # ?>