Wikipedysta:Gżdacz/Esej o wikikodzie

English version

Ten esej zawiera poglądy jednego lub więcej wikipedystów. Eseje nie są zasadami ani zaleceniami edycyjnymi Wikipedii. Niektóre mogą odpowiadać powszechnie uznanym normom, inne – jedynie punktowi widzenia mniejszości.

Żeby uniknąć dwuznaczności, edytor będzie poniżej oznaczał program do pisania, a edytora-Wikipedystę będę nazywał autorem.

Treść artykułów (i wielu innych tekstów) Wikipedii jest składowana w postaci wikikodu.

Z jednej strony ten wikikod trzeba prezentować odbiorcom na różne sposoby:

• Wyświetlać w pełni funkcjonalnie na komputerach typu PC z dużymi ekranami, klawiaturami i myszkami
• Wyświetlać w pełni funkcjonalnie na komórkach z małymi ekranami, bez klawiatury i myszki, ale z wielodotykiem
• Przekazywać w postaci gotowej do wydrukowania na papierze
• Odczytywać głosowo użytkownikom źle widzącym
• Pokazywać w postaci gotowego do edycji wikikodu
• ... (wszystko o czym ja nie wiem, ale już jest albo będzie w przyszłości)

Prezentacja jest ważna dla czytelników, którzy stanowią ogromną większość odbiorców i są bardzo różni, ale bez nich Wikipedia nie ma sensu. Przy tym prezentacja ma być uniwersalnie dobra, czyli ten sam wikikod ma się dobrze prezentować i przekazywać pełny zakres dostępnej w artykule wiedzy wszystkimi tymi metodami. Zauważmy, że powyższe rozróżnienia można ciągnąć dalej: użytkownicy komputerów i komórek mogą źle widzieć i używać trybu silnego kontrastu, być daltonistami i nie rozróżniać kolorów; podobnie czytelnicy drukujący mogą chcieć drukować w kolorze albo czarno-biało.

Przedostatni punkt w wyliczeniu jest bardzo ważny: to perspektywa odbiorcy który sam jest autorem i chce podjąć próbę modyfikacji artykułu ręcznie albo automatycznie, z pomocą bota. Nie jesteśmy wiki-nieśmiertelni i kiedyś na pewno stąd odejdziemy, a opiekę nad naszymi artykułami przejmą nasi następcy (oby!), więc o nich też należy myśleć. Więcej na ten temat napisałem w eseju o standardach i przyszłości naszych artykułów w Wikipedii.

Z drugiej strony wikikod piszą autorzy, którzy stosują przy tym różne metody:

• W edytorze wikikodu, w którym wszystko jest dozwolone, najwyżej okazuje się, że próba prezentacji w niektórych postaciach daje fatalne efekty
• W edytorze wizualnym, który utrudnia zrobienie wielu rzeczy, ale jak na coś pozwoli, to będzie się jako-tako prezentować
• W edytorze sprawdzającym składnię (na razie nie ma takiego), w którym na pierwszy rzut oka wszystko jest dozwolone, ale przy próbie zapisania można dostać komunikat tego nie przyjmę, bo (i tu jakieś automatycznie generowane wyjaśnienie)
• ... (wszystko o czym ja nie wiem, ale już jest albo będzie w przyszłości)

Sposób pisania jest ważny dla autorów, bez których Wikipedia nie będzie się rozwijać.

Istnieje fundamentalny konflikt interesów pomiędzy autorami i czytelnikami, bo zagwarantowanie uniwersalnej dobrej jakości prezentacji wymaga od autorów więcej pracy i narzuca ograniczenia na wikikod, co jest niewygodne.

Czasem daje się też zauważyć konflikty na tym tle między autorem i odbiorcą będącym innym autorem. Tarcia dotyczą zwyczajów edycyjnych i zdarzają się, gdy jeden artykuł staje się obiektem edycji dwóch autorów o silnie przeciwstawnych preferencjach.

WMF w tym obrazie jest pośrednikiem pomiędzy autorami i odbiorcami: autorzy piszą artykuły korzystając z infrastruktury i oprogramowania WMF, a czytelnicy czytają artykuły także korzystając z infrastruktury i oprogramowania WMF. Dodatkowo WMF musi jeszcze zbierać pieniądze, żeby mieć środki na realizowanie tych zadań.

Jest to pozycja niezmiernie trudna, bo do WMF trafiają zarówno pretensje czytelników gdy artykuły źle się prezentują jak i pretensje autorów, że pisanie jest zbyt pracochłonne i/lub niewygodne. Każde ustępstwo wobec jednej strony powoduje potencjalnie zwiększone niezadowolenie tej drugiej. Obawiam się, że niezadowolenie czytelników może manifestować się w wysokości donacji na działalność WMF.

Podobne sytuacje zdarzały się w innych dziedzinach.

• W początkowym okresie istnienia komputerów programiści mieli pełną dowolność programowania w kodzie maszynowym i mogli napisać każdy ciąg instrukcji i go uruchomić, dostając program który działał dobrze, działał źle albo wywalał maszynę, potencjalnie nawet nieodwracalnie. Z czasem, gdy programy miały działać bezproblemowo na licznych niekoniecznie identycznych maszynach i być tworzone przez coraz większe zespoły programistów, pojawiły się coraz silniejsze tendencje ograniczana swobody.

Dziś programuje się w językach wysokiego poziomu (w porównaniu do kodu maszynowego), które bardzo ograniczają programiście zakres możliwych do stworzenia sekwencji instrukcji maszynowych, jednak gwarantują szybsze, bardziej modularne pisanie programów i nieporównanie większą kontrolę możliwych do popełnienia błędów. Ceną jest to, że po napisaniu programu kompilator może powiedzieć tego nie przyjmę, bo (i tu jakieś automatycznie generowane wyjaśnienie). Jeszcze bardziej ograniczające i zarazem odporne na błędy jest programowanie wizualne, gdy programista układa program z klocków, praktycznie mogąc w ogóle nie oglądać kodu który tworzy. Wszystko to powoduje, że tak napisane programy można automatycznie przetwarzać do postaci wykonywalnej na praktycznie dowolnym sprzęcie (np. casus arkusza kalkulacyjnego). Dodatkowo istnieją standardy dotyczące formy programów, narzucane nie przez sam język programowania, ale przez zwyczaj, presję społeczną, kodeksy dobrych praktyk, wymagania pracodawców wobec pracowników.

• W początkach komputerowego składu tekstów naukowych powstał TeX, napisany przez Donalda Knutha. W nim można było prawie wszystko, łącznie z napisaniem w nim interpretera języka Basic oraz wytwarzaniem własnych czcionek w programie Metafont. Dziś chyba żadne czasopismo naukowe na świecie nie przyjmuje artykułów złożonych w gołym systemie TeX. Większość z nich wymaga użycia nakładki LaTeX2e, która z jednej strony bardzo ogranicza swobodę piszącego, ale z drugiej strony oferuje mu predefiniowane, gotowe do użycia elementy składowe: nagłówki sekcji, środowiska do składania różnych typów wzorów matematycznych, tworzenia bibliografii, strony tytułowej, itp., wszystko zgodne albo łatwe do automatycznego uzgodnienia ze stylem typograficznym czasopisma. Dla chętnych są nawet edytory wizualne pozwalające edytować kod LaTeX w trybie WYSIWYG albo narzędzia do półautomatycznego tworzenia go z dokumentów Worda.

Widzę analogię z poprzednią sekcją, tyle że my jesteśmy nadal na etapie asemblera albo gołego systemu TeX. Piszemy w wikikodzie, używając pewnej liczby szablonów, które jednak nie są obowiązkowe i w zasadzie każdy może robić jak chce, a kontrolowany jest zazwyczaj tylko wizualny efekt finalny na PC, jeżeli w ogóle.

Tymczasem problemy czytelników powodują, że potrzebna jest możliwość poprawnej prezentacji artykułów w bardzo różnych postaciach we w pełni automatyczny sposób. Zarazem będziemy coraz bardziej odczuwali ciężar opieki nad artykułami autorów, którzy już odeszli i zaczniemy rozumieć, jak dobrą rzeczą jest standaryzacja i przewidywalność tego, co w ich dziełach znajdziemy.

Sądzę, że te potrzeby spowodują powtórzenie się schematu dotyczącego programowania i składu tekstów. W efekcie wkrótce nie będzie odwrotu od narzucenia sobie samym pewnych rygorów na wikikod który wytwarzamy, żeby uzyskać stan poprawnej prezentacji na wszystkich docelowych platformach oraz bezproblemowego przekazywania artykułów w ręce następców. A to generalnie osiąga się albo przez edytor wizualny, albo edytor kontrolujący składnię.

Z tego powodu popieram przemyślane i dobrze wykonane działania służące standaryzacji, WP:SK, ujednolicanie szablonów, itp. oraz prace nad nowymi edytorami artykułów i dyskusji.

Mój pogląd, że trzeba będzie się zgodzić na nałożenie ograniczeń na dotychczasową swobodę edytowania (w warstwie technicznej) i zgodzić się na jakieś warianty edytora wizualnego albo edytora kontrolującego składnię nie oznaczają automatycznego poparcia dla aktualnego stanu VE i Flow (od czasu napisania tych słów, ten pierwszy ogromnie się poprawił, ten drugi w zasadzie umarł, pojawiły się też nowe narzędzia typu "Odpowiedz" w dyskusjach). To dwa narzędzia edycyjne, które zapewne są w stanie zapewnić wymuszenie niezbędnych ograniczeń. Jednak muszą jednocześnie być wygodne, niezawodne i intuicyjne w stosowaniu, żeby autorzy się do nich przekonali. Mam wrażenie, że w tej chwili tych wymagań nie realizują jeszcze w dostatecznym stopniu.

Gżdacz (dyskusja) 20:53, 5 mar 2018 (CET)

Poprawki Gżdacz (dyskusja) 11:36, 11 mar 2018 (CET)

Poprawki Gżdacz (dyskusja) 08:33, 3 mar 2019 (CET)

Poprawki Gżdacz (dyskusja) 12:13, 30 mar 2021 (CEST)