Po co nam CMS-y?

Archived under Design, Usability on August 21st, 2005 with 3 comments

Parę tygodni temu byłem świadkiem prezentacji pewnej aplikacji działającej w przeglądarce. System ma ułatwiać dostęp do informacji zgromadzonej w różnych dokumentach z określonej dziedziny. Mówiąc bardziej ogólnie: ma ułatwiać dzielenie się wiedzą. Po obejrzeniu prezentacji menedżer, który był głównym adresatem (na wszelki wypadek dodam, że nie byłem to ja :) ), zapytał, czy to coś w rodzaju wiki.

Odpowiedź brzmiała “nie”, ale pytanie mnie zastanowiło: właściwie po co tworzyć skomplikowany system, skoro można by było po prostu skorzystać z wiki?

Jedną z największych zalet wiki jest to, że sama ich natura zachęca do pisania. Mnóstwo razy zdarzyło mi się znaleźć jakiś błąd na cudzej na stronie (bo oczywiście oczywiście moje strony są bezbłędne…) i miałem ochotę go poprawić. Najczęściej wymaga to skontaktowania się z autorem, opisania problemu i czekania na reakcję. Nawet jeśli strona jest wartościowa i często na nią wracam, rzadko kiedy korzyści są w stanie zmusić mnie do takiego wysiłku.

Zupełnie inaczej jest z wiki. Największą przeszkodą jest tu na ogół konieczność rejestracji, a potem zalogowania się. Mimo wszystko jest to mniej uciążliwe niż napisanie maila do autora strony. Właśnie w taki sposób po raz pierwszy dorzuciłem swoje trzy grosze do Wikipedii: znalazłem jakiś drobny błąd językowy i już po niecałej minucie mogłem samemu go poprawić. Wiki zachęcają do pisania również dlatego, że są bardzo tolerancyjne na błędy. Można je łatwo poprawić samemu lub zrobi to ktoś inny.

Aplikacje tego rodzaju mogą nawet służyć jako ekwiwalent notatnika. Zespół, w którym pracuję, wykorzystuje wiki do tworzenia wewnętrznej dokumentacji. “Mój pierwszy raz” polegał na tym, że zamiast zapisywać sobie pewien świeży pomysł na kartce, po prostu utworzyłem nową stronę w wiki.

Jedną z największych zalet pracy w zespole programistów jest możliwość wymiany wiedzy. Problem w tym, że wiedza jest tworem płynnym i efemerycznym. Z kolei pisanie oficjalnej dokumentacji potrafi skutecznie odstraszać programistów, którzy są w stanie znaleźć milion powodów, dla których w danej chwili powinni robić coś innego. Wiki pomagają rozwiązać ten problem. Są, podobnie jak wiedza, żywym tworem, który ciągle się rozwija. Łatwość dodania informacji i stosunkowo niezobowiązująca formuła sprawiają, że programiści są bardziej skłonni napisać coś za pomocą wiki.

W ten sposób dochodzimy do wniosku, że wiki są świetnym narzędziem do zarządzania wiedzą. Ich główną zaletą jest łatwość dzielenia się informacjami, dużo większa niż w wypadku wyrafinowanych narzędzi do zarządzania dokumentami, jak to wspomniane przeze mnie na początku tego wpisu. Czemu nie wykorzystać tej łatwości również gdzie indziej: do zarządzania stroną internetową, powiedzmy: blogiem?

Narzędzia do prowadzenia blogów to podzbiór CMS-ów, czyli systemów zarządzania treścią. Wspólną cechą tych aplikacji jest to, że tworzą one określony model zarządzanego serwisu. Użytkownik CMS-a nie operuje bezpośrednio na treści zawartej w serwisie, ale na reprezentacji tej treści w modelu udostępnianym przez aplikację. Dopiero po publikacji treść trafia bezpośrednio na stronę. Mówiąc inaczej, większość CMS-ów na nowo wymyśla strukturę serwisu. Daje dostęp dostęp do takich jej elementów jak artykuły, newsy, sondy czy komentarze gości. Interfejs systemu zarządzania treścią jest na ogół niezależny od tego używanego na stronie. Im większa jest wewnętrzna heterogeniczność i złożoność serwisu, tym bardziej skomplikowane narzędzie jest potrzebne do zarządzania nim. Praca z CMS-ami z górnej półki może czasem być wyzwaniem samym w sobie, bo wymaga nie tylko dobrej znajomości samego serwisu, ale również wiedzy o jego modelu w CMS-ie i używanych przez system metafor, takich jak ikony, czy pojęcia w rodzaju “moduł” albo “węzeł”.

W wypadku wiki edycja treści przebiega bezpośrednio na żywej stronie internetowej. Autor przegląda ją jak zwykły użytkownik i jeśli widzi taką potrzebę, po prostu wybiera przycisk edycji na danej stronie. Wiki nie muszą tworzyć sztucznego modelu strony, bo dają do niej praktycznie bezpośredni dostęp. Można się też pokusić o wykorzystanie Ajaksa i dodatkowe zmniejszenie dystansu między stroną do przeglądania a wersją do edycji. Na blogu Marcoosa można znaleźć demonstrację bezpośredniej edycji strony po dwukrotnym kliknięciu wybranego fragmentu. Dodajmy jeszcze tryb WYSIWYG i funkcję do zapisu zmienionych danych na serwerze, a otrzymamy chyba najbardziej intuicyjne z możliwych narzędzie do zarządzania stroną.

Współczesne aplikacje typu wiki pozwalają na łatwe wersjonowanie i śledzenie historii zmian, zatem nie jest trudne cofnięcie pomyłki czy wprowadzenie kontroli treści przed opublikowaniem jej w publicznej dostępnej części serwisu.

Oczywiście rozwiązania idealne nie istnieją i użycie wiki zamiast CMS-a ma swoje wady. Przede wszystkim należy zadbać o uniemożliwienie edycji osobom z zewnątrz. Najprostsze rozwiązanie to standardowy formularz logowania do serwisu. Ciekawym pomysłem wydaje się też uzależnienie uprawnień od numeru IP odwiedzającego. Jeśli gość został on zidentyfikowany jako autor, można byłoby pominąć procedurę logowania i pozwolić na bezpośredni dostęp do funkcji edycji. Metoda tam ma swoje wady, ale w pewnych warunkach (przede wszystkim przy stałych numerach IP) mogłaby jeszcze bardziej ułatwić życie użytkownikom.

Inny problem, który w tej chwili przychodzi mi do głowy, to trudności z tworzeniem przejrzystej hierarchii informacji. Wiki są chyba idealnym wcieleniem idei hipertekstu. Strony nie są uporządkowane w obrębie narzuconej z góry hierarchii, ale wzajemnie powiązane za pomocą związków o charakterze merytorycznym. Taka struktura jest płaska i nawigowanie w niej wymaga wymaga sprawnej wyszukiwarki i przemyślanego używania hiperłączy w obrębie tekstu. Hierarchia natomiast daje użytkownikowi poczucie bezpieczeństwa i punkt odniesienia. Krótko mówiąc: łatwiej zaplatąć się w sieć niż zgubić na (w?) drzewie. Wikipedia ma się jednak dobrze, zatem problem ten nie musi być szczególnie dotkliwy dla użytkowników.

Opisany tu pomysł nie jest nowy i w sieci można już znaleźć blogi napędzane przez silnik wiki zamiast specjalizowanego systemu zarządzania stroną. Może właśnie to jest droga, którą powinny podążać serwisy internetowe? Zamiast tworzyć coraz bardziej wymyślne i abstrakcyjne CMS-y, czy nie lepiej ułatwić sobie życie i skorzystać z filozofii wiki, która ze swojej natury zachęca i ułatwia dzielenia się informacją? Pożyjemy, zobaczymy.

Comments

  1. czesc, pewnie juz wiesz, socialtext oferuje teraz WYSIWYG w swoim komercyjnym silniku wiki; a na ’43 folders’ pisano niedawno o kims, kto zamiast wszelkich kalendarzy i outlookow przerzucil sie na pojedynczy plik tekstowy, co wydaje mi sie podobnym posunieciem, co zastapienie cmsa wiki.

    a

  2. Jednak nie stawiałbym znaku równości między wiki a pojedynczym plikiem tekstowym :).

    Do tej pory nie interesowałem się Socialtextem — dzięki za namiary.

    Szafranek

  3. Z tego co pamiętam, gdzieś czystałem, że ‘związki o charakterze merytorycznym’ jak je nazwałeś, chce wykorzystać też w swoich przyszłych systemach Microsoft, koniec ze strukturą drzewa w katalogach, zawartość dysku ma być segregowana i wyświetlana wg. wybranych kryteriów.
    Jest to kwestia przyzywczajenia się i nowego spojrzenia na temat, myślę, że stoi przed tym przyszłość. Ważniejsze będzie szybkie odnalezienie konkretnej informacji/pliku i/lub powiązań, niż przedzieranie się przez setki katalogów.

    zły kapitalista

Comments are now closed