24 września 2008

KISS psa w nos...

Na blogu Radomila pojawił się wpis o trudności w edycji Wikipedii. Zauważono, że powinna być stosowana reguła KISS, która sprowadza się do tego, że jak najwięcej rzeczy powinno być maksymalnie uproszczonych. Na Wikipedii jest zbyt dużo zasad, zbyt dużo szablonów i szablono-maniaków.

Zastanawiam się, jak to odnieść do Wikisłownika. Chyba moje obawy są słuszne, że Wikisłownik dogoni Wikipedię w trudności edycji już niedługo. Co może być tego przyczyną?

1. brak struktur specjalnie dla słownika; Wikisłownik i pozostałe projekty mają taki sam system edycji jak Wikipedia; musimy dostosowywać się do zastanych struktur; brak nowych rozwiązań

2. powoli, ale rośnie liczba szablonów; na początku pisało się ''[[rzeczownik|rzecz.]]'' ''[[czasownik|czas.]]'', ''z łac. [[hypothēca]]'', zobacz też: [[w:Prostota|prostota]] w Wikipedii, zobacz też: [[musika]] (i od razu wszystko było jasne). Teraz pisze się {{rzecz}}, {{czas}}, {{etym|łac|hypothēca}}, {{wikipedia}}, {{zobteż}}, {{zobteż2}} i inne... Że już nie wspomnę o ilości parametrów do spamiętania... Boję się myśleć, ile tego jest na Wikipedii...

Być może na Wikipedii ze strony zwolenników szablonów padał argument, że kod strony jest dla edytorów, a efekt jest ważniejszy, to właśnie efekt końcowy oglądają czytelnicy. Ha! Taki wał! Powiem szczerze - wolę edytować strony pełne HTMLa niż hasła Wikipedii. Wróćmy jednak na nasz poczciwy Wikisłownik...

Zastanawiam się nad pomysłem powrotu do starych zasad. Co by było, gdyby nie było szablonu {{wikipedia}}, a zamiast niego pisali jak powyżej? Albo zamiast {{zobteż}} i {{zobteż2}} pisać także jak powyżej?

Tylko proszę, nie piszcie mi, że szablony są dla dobra serwerów, albo że szablony to krótszy zapis i mniej znaków jest zapisywanych... Jakoś gdy boty edytują setki tysięcy znaków w ciągu minuty to nikt nie mówi o serwerach, a gdy my chcemy uprościć edycję do pełnego widoku hasła, to zasłaniacie się serwerami albo - o zgrozo - prostotą edycji. Pisząc "pełny widok" mam na myśli, żeby jak najwięcej tego, co widzi czytelnik było w kodzie strony. I tak mamy już szablony w szkielecie hasła. Ja nie chcę więcej! Do czego to doszło, żeby na zlocie uczyć ludzi z Wikipedii jak tworzyć proste hasła słownika?!

6 komentarzy:

Daniel pisze...

Szablony prócz tych zalet, o których nie chcesz słyszeć mają jeszcze jedną, fundamentalną i wyznaczającą cel ich istnienia. Zaletą tą jest hermetyzacja i strukturalizacja zmian. Chodzi pokrótce o to, że jeśli jakieś wyrażenie, zalecenie edycyjne, często stosowana struktura może w przyszłości zmienić swą formę to zmiana taka jest dużo prostsza gdy zmienia się jeden szablon, niż gdy trzeba wyszukać milion wystąpień takiej samej lub co gorsza stada podobnych sekwencji znaków. Hermetyzacja polega tu na oddzieleniu formy pewnego fragmentu od jej treści lub funkcji. Piszemy {{rzecz}} i wiemy, że chcemy podać czytelnikowi informację, że coś jest rzeczownikiem, a to czy szablon ten zostanie rozwinięty do skrótu "rzecz.", do pełnego słowa "rzeczownik" czy nawet do zdania "Opisywane słowo jest rzeczownikiem" nie ma dla nas w tym miejscu znaczenia. To oczywiście tylko przykład ale ilustruje on fundamentalną cechę współczesnych języków w porównaniu z językami starszymi. Takie oddzielenie formy od treści logicznej występuje w LaTeX-u (w TeX-u nie), w XHTML-u (w HTML-u nie). Stosowanie szablonów nie dziwi mnie i generalnie je popieram. Powinno ono oczywiście jednak być przemyślane. Pozdrawiam

Derbeth pisze...

Jak piszę w odpowiedzi w Barze, dla mnie bardzo ważną rzeczą w szablonach jest, że ułatwiają utrzymanie jednolitego wyglądu haseł. Jeśli założymy, że nie chcemy wolnej amerykanki w pisaniu np. "zobacz też w Wikipedii" ("patrz też", "zobacz także", "zob. też" i paręnaście innych), to do czego mamy przymusić użytkowników: żeby nauczyli się na pamięć, że trzeba wpisać "wikipedia", czy że trzeba wpisać "zobacz też [nieoczywisty link w wikikodzie] w Wikipedii"? W którym tekście jest łatwiej popełnić literówkę?

Jeśli byś nie znał HTML-a, to co byś obstawił jako kod produkujący pochyły napis "rzecz.": {{rzecz}} czy też ''[[rzeczownik|rzecz.]]''?

radomil pisze...

Co do pytania - "{{rzecz}} czy też ''[[rzeczownik|rzecz.]]''". Z doświadczenia wiem (bo zaczynając pracę na Wikipedii nie znałem HTMLa) powiem, że łatwiej zrozumieć składnię HTML. Dlaczego? Bo widać co jak działa. Człowiek po prostu przyglądając się istniejącemu kodowi hasła i po jednej czy dwóch próbach zazwyczaj dochodzi do tego, że ''...'' daje kursywę, [[]] to link, w pierwszym polu wpisujemy nazwę hasła, a w drugim to co ma się wyświetlać. To system uniwersalny i prosty. Owa prostota wynika właśnie z tej uniwersalności.

Wadą szablonów jest to, że wbrew temu co twierdzą ich zwolennicy nie są one w najmniejszym stopniu intuicyjne. Bo jak spamiętać te wszystkie dziwne skróty? Dlaczego w {{rzecz}} jest "rzecz", a nie "rzeczownik" czy "rzecz."? Im dłuższa lista szablonów tym więcej takich zaśmiecających pamięć szczegółów o których należy pamiętać.

Co do łatwości zmian w wyglądzie - przecie nie o to chodzi by zmieniać łatwo wygląd! Wygląd powinien być jak najbardziej stabilny i jego zmiany wcale nie powinny być łatwe.

Jedynym niepodważalnym plusem szablonów jest unifikacja wyglądu, jednak moim zdaniem nie przeważa ona nad ich wadami. Wszyscy przecież się zgodzimy, że forma nie może przeważać nad treścią, a treść tworzą edytorzy i to dla nich kod powinien być przyjazny.

Daniel pisze...

Mamy tu chyba do czynienia z pewnym nieporozumieniem w zakresie łatwości zmian. Czym innym jest łatwość wykonania zmian a czym innym łatwość podejmowania decyzji o zmianach. Łatwość wykonania zmian jest rzeczą dobrą i należy ją promować. Co do obciążania pamięci to niestety konieczność pamiętania o tym by w HTML-u, wikikodzie zrobić coś dokładnie identycznie (standardowo) z dokładnością co do jednego znaku jest równie (o ile nie bardziej) obciążajaca pamięć.

Ludzie, którzy mają cokolwiek do czynienia z programowaniem wiedzą, że należy kodować tak aby później zmian dokonywać w jak najmniejszej liczbie miejsć. Wiedzą też jak wielką rewolucją (porównywaną z rewolucją kopernikańską) było przejście od programowania strukturalnego ("komputerocentrycznego") do programowania obiektowego ("danocentrycznego"). Analogiczną rewolucją jest przechodzenie od języków "formatocentrycznych" do języków "treściowocentrycznych". Podawałem na to przykłady we wcześniejszym komentarzu na różnicę między XHTML-em a HTML-em. To jest ogólna tendencja i co ważniejsze tendencja słuszna i nie sposób jej zawrócić.

radomil pisze...

I to jest właśnie problem z technicznymi. Nie pamiętają o tym, że nie są oni jedynymi, ba... głównymi autorami projektów z rodziny "wiki".

Łatwość z jaką zapominają, że kod przyjazny edytorowi nie znającemu zasad programowania nie jest tym samym co kod przyjazny programiście może kiedyś zabić te projekty.

Obawiam się, że przy takim podejściu jak prezentują techniczni w krótkim czasie tylko oni będą potrafili edytować wiki.

Daniel pisze...

Kod nastawiony na treść jest również przyjazny tylko trzeba porzucić stare nawyki i zapomnieć o formatowaniu kodu a skupić się na logice treści. Nie na tym jak coś ma wyglądać tylko na tym co chcemy przedstawić.

Poza tym bardzo, ale to bardzo nie podoba mi się klasyfikowanie ludzi na technicznych i nietechnicznych. Takie szufladkowanie to jakby próba powiedzenia "Ty jesteś taki a taki i nas nie zrozumiesz więc nie możesz się na te tematy wypowiadać". To właśnie takie negatywne nastawienie i niepartnerskie postępowanie może zniechęcać ludzi. Podkreślanie, że ktoś "nie jest głównym autorem" w zakresie wiki i w związku z tym nie może wypowiadać się o łatwości edycji uważam wręcz za haniebną próbę deprecjonowania czyjegoś wkładu. Tak być nie powinno. Każdy wnosi taki wkład na jaki może sobie pozwolić i ma prawo się wypowiedzieć oraz przedstawić swój punkt widzenia, a znajomość różnych języków i dostrzeganie między nimi analogii świadczy tylko pozytywnie a nie negatywnie.

Derbeth słusznie zauważył, że szablony jednak ułatwiają edycję i utrudniają pomyłki.

Wikipedia (Wikisłownik) jest projektem realizowanym przez społeczność. Zasady które są słuszne w przypadku zespołowego wytwarzania oprogramowania znajdują świetne zastosowanie również w tym projekcie. Nie odrzucajmy tego co sprawdziło się na tym polu tylko dlatego, że czegoś nie rozumiemy.