Osoby nieco dłużej śledzące moją internetową aktywność mogły zauważyć pewną zmianę mojego podejścia do tematów webdevowych. W mojej dawnej webkrytykowej twórczości, ale i w początkach istnienia tego bloga, o wiele więcej było, hm, emocjonalnych wstawek. Niczym dekadencki poeta z bujną i rozwichrzoną czupryną zdecydowanie stawiałem formę wyżej od treści. w tej chwili moje podejście jest zdecydowanie bardziej naukowe. I to bynajmniej nie z powodu nagłego braku bujnej czupryny!
Podejście naukowe
Co to jednak znaczy, iż traktuję webdev naukowo? Tak naprawdę wyróżniłbym tutaj trzy główne elementy:
- formę treści,
- obecność źródeł,
- empiryczność.
Forma treści
Artykuły naukowe mają ściśle określoną strukturę. Bardzo często opisuje się ją akronimem IMRaD:
- Introduction (wprowadzenie) – wyjaśnienie celu badania, postawienie hipotezy,
- Methods (metody badawcze) – w jaki sposób badanie zostało wykonane, kto w nim uczestniczył,
- Results (wyniki) – omówienie wyników badania, sprawdzenie, czy wyniki zgadzają się z postawioną hipotezą,
- Discussion (polemika) – próba interpretacji wyników, porównanie ich z innymi badaniami z tego zakresu, zaproponowanie możliwych przyszłych kierunków badań.
Tak tworzone artykuły powinny zachowywać jak największą obiektywność, skupiając się przede wszystkim na opisie faktów, z pominięciem opinii osób autorskich.
Ja nie jestem naukowcem i siłą mojego bloga jest jednak to, iż umieszczam na nim materiały o webdevie okraszone moją opinią. Więc bardziej nazwałbym swoją radosną twórczość esejami hipertekstowymi. To nic innego jak eseje, które są opublikowane w formie hipertekstu. Czyli: mogą linkować do innych esejów lub bezpośrednio do źródeł, Równocześnie jednak – raz luźniej, raz ściślej – trzymam się struktury IMRaD. Weźmy taki artykuł o Cookie Store API. Na samym początku jest wprowadzenie, w którym zaznaczam problem (relacja Sieci z ciasteczkami od zawsze była skomplikowana). Następnie następuje omówienie wyników badania (w tym wypadku: organoleptycznego sprawdzenia, jak się obsługuje ciasteczka w przeglądarkach). W przypadku artykułów z eksperymentów (jak np. jednoplikowych komponentów czy ASCSS-a) pojawiają się też sekcje z metodami (opis inspiracji i narzędzi użytych do stworzenia danego projektu) oraz polemika (w jaki sposób go dalej rozwijać, czy moje pierwotne założenia udało się spełnić, itd.).
Źródła
Niemniej to nie forma jest głównym wyznacznikiem “naukowości”. Według mnie o wiele ważniejszym jest odwoływanie się do źródeł. W końcu szansa, iż opisałem coś jako pierwszy w Internecie, jest niemalże zerowa. choćby jeżeli w swoim zakątku Sieci jestem faktycznie pierwszy, to przecież o jakimś standardzie sieciowym napisała przede mną choćby… osoba pisząca jego specyfikację. choćby jeżeli już wymyślę coś absolutnie swojego (jak Headings First Principle (HFP)), to przecież to nie istnieje w próżni. Żeby mogło powstać HFP, musiał powstać HTML, a w nim nagłówki. Niezbędnymi elementami były też wszelkie dobre praktyki wokół dzielenia treści stron WWW na sekcje oraz sposób nawigowania przy pomocy nagłówków przez osoby korzystające z czytników ekranowych. Słowem: musiał istnieć cały skomplikowany ekosystem Sieci, żebym ja mógł do niego dodać swoją małą cegiełkę.
Chyba najdobitniej widać to w przypadku mojego, jak dotąd najambitniejszego, projektu, GWD. W każdym “rozdziale” na końcu znajdują się listy źródeł oraz dodatkowych materiałów. Nazbierało się ich około tysiąca. A i tak była to mocno okrojona lista. Zwłaszcza, iż sporo tematów ostatecznie wypadło z tego eseju.
Niemniej samo odesłanie do źródeł to za mało. Prawdziwa praca polega na odpowiednim ich dobraniu. Bo można opisać np. element HTML bdo i odesłać do jakiejś strony-krzak czy popularnej, acz słabej jakości witryny. Zamiast tego wypada jednak dokładnie zapoznać się, do czego linkujemy, czy nie ma tam błędów merytorycznych, czy poruszone są wszystkie kwestie ważne poruszenia, itd. I tak jak w świecie nauki, w którym mamy tytuły godne zaufania (Science, Nature), tak i w webdevie jedne źródła są bezpieczniejsze od innych. Najbezpieczniejsze są, rzecz jasna, specyfikacje i standardy. Nie ma pewniejszych źródeł od nich. jeżeli chcę opisać element bdo, to specyfikacja HTML jest Kanonicznym Źródłem Prawdy™. Ale standardy często są pisane w sposób całkowicie hermetyczny i niezrozumiały dla dowolnej osoby, która nie czyta sobie RFC do poduszki. Wtedy warto sięgnąć po drugie najlepsze źródło – dokumentację MDN. jeżeli coś można by nazwać oficjalną dokumentacją platformy sieciowej, to byłoby to właśnie MDN.
Dobrej jakości źródeł jest oczywiście więcej – jak choćby Smashing Magazine, A List Apart czy blogi znanych osób ze światka webdevu. I często na tych stronach, oderwanych od “oficjalnego obiegu”, dzieją się rzeczy ciekawsze. To w końcu na łamach A List Apart powstał termin Responsive Web Design! Często też wyłuskać można na jakiejś stronie jakąś perełkę wśród całej reszty meh artykułów (hej, to zupełnie jak na moim blogu!). Tylko no właśnie – wyłuskać…
Sprawne posługiwanie się źródłami wymaga mimo wszystko wprawy i pewnego doświadczenia. Ja w swoim życiu przerobiłem już tysiące artykułów o webdevie i jestem w stanie oddzielić te faktycznie interesujące od tych, które takie nie są. I właśnie tę umiejętność selekcji uważam za kluczową w bardziej naukowym podejściu do webdevu. Żeby ją zdobyć, to nie ma innej rady – trzeba spędzić swoje na czytaniu. Na początku będzie się czytać wszystko, jak leci, by z czasem odrzucać te najgorsze z najgorszych, aż w końcu nadejdzie moment, w którym się Po Prostu Wie™, co jest warte poświęcenia czasu, a co nie.
Niemniej z selekcją źródeł pozostało jeden mały haczyk: ryzyko wpadnięcia w bańkę. Każda osoba ma jakieś poglądy i przekonania. Choćby tak błahe, jak nielubienie Reacta czy skłonność do wybierania mniej popularnych rozwiązań. I takie przekonania będą – bardziej lub mniej świadomie – wpływać na to, które źródła się dobiera. Nie sądzę, by dało się od tego całkowicie uciec, ale im bardziej się jest tego świadomym, tym mniejszy ma to wpływ na proces selekcji. Bo czasami warto wręcz sięgać po źródła, z którymi się nie zgadzamy – choćby po to, by wejść z nimi w polemikę.
Empiryczność
Wreszcie ostatni element, który widać w większości moich artykułów – zarówno tutaj, jak i na WebKrytyku. Empiryczność, czyli mówiąc inaczej: eksperymentowanie. Kiedy opisuję nowe API, fajnie byłoby, gdybym przygotował choćby krótkie demko, w którym bym zademonstrował jego podstawowe ficzery. Tym prostym sposobem można być jak Longinus Podbipięta i ściąć trzy gł odhaczyć trzy rzeczy:
- pokazujemy osobom czytającym, iż opisywane przez nas rzeczy faktycznie istnieją i działają,
- tworzymy dla siebie samych z przyszłości źródło do linkowania, jeżeli kiedyś wspomnimy znowu o tym API,
- zapamiętujemy całą rzecz lepiej, niż gdybyśmy naskrobali jedynie teoretyczny opis.
Poza tym – ostatecznie piszę ten blog dla przyjemności. A gdzie byłby cały fun z tego, gdybym się nie bawił kodem?
Tylko po co?
Odpowiedziałem już na pytanie, jak traktować webdev bardziej naukowo. Pora zatem pochylić się nad drugim, równie ważnym – jeżeli choćby nie ważniejszym – pytaniem: po co?
Bo uważam, iż tego wymaga uczciwość intelektualna. Webdev nie jest jakąś bliżej niezdefiniowaną sztuką okultystyczną (mimo iż czasami tak się jawi!). Wbrew pozorom zdecydowana większość platformy sieciowej jest oparta na konkretnych standardach i specyfikacjach. Bo gdyby nie była, strony WWW działałyby w jednych przeglądarkach i nie działały w innych. Te czasy już przerabialiśmy i to właśnie dzięki nim dzisiaj mamy otwarte standardy sieciowe. Jasne, nie jest idealnie, ale inicjatywy takie jak Web Platform Tests czy Interop dają nadzieję, ze będzie lepiej. A skoro Sieć oparta jest na fundamentach, które są skodyfikowane (spisane “na papierze”, z przybitą pieczątką) i możliwe do empirycznej weryfikacji (w każdej chwili mogę odpalić przeglądarkę i sprawdzić, jak ten HTML czy CSS działają), to nie widzę powodu, by moje artykuły się do tego nie odwoływały.
Uczciwość intelektualna wymaga też, by istniała pewna ciągłość między tym, co tworzymy, a tym, co zostało stworzone. Tak jak artykuł naukowy nie może istnieć bez źródeł, tak trudno stworzyć artykuł o hipertekście bez… hipertekstu. W webdevie nie ma self-made men, wszyscy budujemy na fundamentach postawionych przez innych. choćby jeżeli nasze budowanie polega na niezgadzaniu się z już istniejącymi dobrymi praktykami i proponowaniu czegoś nowego. Bo ostatecznie nie byłoby tej propozycji, gdyby nie ta praktyka! Żeby się z czymś nie zgadzać, trzeba najpierw zauważyć istnienie tego czegoś. Inaczej nasza krytyka będzie całkowicie jałowa.
Wreszcie: webdev najzwyczajniej w świecie zasługuje na bardziej naukowe – czy też po prostu merytoryczne – traktowanie. Choćby dlatego, iż Sieć stanowi coraz większą część naszego codziennego życia. To wszechobecna technologia, do której dostęp ma ok. 6 miliardów ludzi. W innych dziedzinach nauki i technologii, które często dotykają mniejszej liczby osób (jak np. projekt nowego skafandra astronautycznego), zachowujemy niezwykłą precyzję i naukową rygorystyczność. Natomiast w dziedzinie, która w taki czy inny sposób zahacza o jakieś ¾ światowej populacji, mam wrażenie, iż często wychodzimy z założenia, iż to tylko technologia. A to przecież nieprawda. Ludzie mają różne powody, by korzystać z Internetu. jeżeli – jako osoby tworzące strony WWW – nie traktujemy Sieci wystarczająco poważnie, ostatecznie szkodzimy osobom, które z tych stron WWW następnie korzystają. I myślę, iż przestawienie myślenia z to tylko technologia w kierunku webdev to nauka jest mało bolesnym sposobem na stworzenie lepszej Sieci.
I tym optymistycznym akcentem życzę Wszystkim wesołych świąt 🎄🎄🎄!