Strona szkolna umarła. Niech żyje szkolna aplikacja.

Otwórzcie dziesięć losowych stron polskich szkół. Znajdziecie aktualności sprzed trzech miesięcy, rządek ministerialnych logotypów i zakładkę „dokumenty”, która jest ścianą zeskanowanych PDF-ów. Czasem licznik odwiedzin, wiernie liczący od 2009 roku.

To nie jest tak, że szkołom nie zależy. To my wszyscy zbiorowo uznaliśmy, że strona szkolna jest tablicą ogłoszeń — artefaktem istniejącym po to, żeby nikt nie mógł powiedzieć, że go nie ma. A tablica ogłoszeń nie ma użytkowników. Ma przechodniów.

Teza

Strona szkoły powinna być aplikacją.

Nie „responsywna”. Nie „nowocześnie wyglądająca”. Aplikacją: czymś, co rodzic instaluje na telefonie, co powiadamia go, gdy coś się dzieje, co odpowiada na jego pytania, gdy sekretariat jest zamknięty, i co jest zawsze — nie zazwyczaj, zawsze — aktualne.

To zdanie brzmi drogo. Nie jest. Przebudowaliśmy stronę naszej szkoły dokładnie na tym założeniu, a miesięczny koszt utrzymania wynosi zero. Nie „niewiele”. Zero. To nie jest hasło promocyjne, tylko decyzja architektoniczna — wyjaśniam ją niżej.

Jak to wygląda od strony rodzica

Najpierw efekty, bo efekty są sednem.

Rodzic wchodzi na stronę raz i dostaje propozycję instalacji. Od tej pory strona mieszka na jego ekranie głównym jak każda inna aplikacja. Gdy szkoła publikuje aktualność — zmianę planu, przypomnienie o wycieczce, wyniki egzaminów — powiadomienie push ląduje na telefonie kilka sekund po tym, jak redaktor nacisnął „opublikuj”. Bez newslettera, który wpada do spamu. Bez zewnętrznej aplikacji do komunikacji z rodzicami, z kontem, hasłem i abonamentem.

O 22:00 rodzic rozważający zapisanie dziecka pyta asystenta na stronie, jak wygląda rekrutacja do pierwszej klasy. Dostaje odpowiedź opartą na prawdziwych dokumentach szkoły — z prawdziwymi terminami i wymaganiami — bo asystent jest ugruntowany w pielęgnowanej przez szkołę bazie wiedzy, a nie w tym, co model językowy akurat ma ochotę zaimprowizować. Jeśli odpowiedzi nie ma w bazie, mówi to wprost i odsyła do sekretariatu.

Babcia ze słabym wzrokiem otwiera panel dostępności i dostaje większy tekst, wyższy kontrast i czytanie na głos. Cała strona ładuje się niemal natychmiast, ma komplet setek we wszystkich kategoriach Lighthouse i działa offline dla odwiedzonych już treści.

Nic z tego nie jest science fiction. Wszystko to nudna, sprawdzona technologia — tyle że strony szkolne uznały, że nie jest dla nich.

Jak to wygląda od środka

Stos technologiczny, na wysokości, która ma znaczenie: framework static-first (Astro) generujący szybkie strony; Firebase jako hosting, dane i ta garść funkcji serwerowych, które naprawdę muszą istnieć; Gemini napędzający asystenta; całość wewnątrz ekosystemu Google, w którym szkoła — jako Google for Education Reference School — i tak żyje na co dzień.

Zerowy koszt opiera się na trzech decyzjach. Po pierwsze, statyczność domyślnie: prawie każda podstrona jest zbudowana z góry i serwowana z CDN, co przy ruchu szkolnej skali nie kosztuje nic. Po drugie, serverless dla reszty: funkcje uruchamiają się tylko na żądanie — wysyłka pusha, odpowiedź chatbota — a szkolne wolumeny mieszczą się wygodnie w darmowych limitach. Po trzecie, zero pośredników: bez abonamentu za CMS, bez SaaS-a do komunikacji z rodzicami, bez chatbota w modelu usługowym. Każdy element należy do szkoły.

Świadomie nie publikuję tu przewodnika po architekturze. Trochę dlatego, że strona szkoły to infrastruktura publiczna i dyskrecja jest elementem higieny bezpieczeństwa; przede wszystkim dlatego, że architektura nie jest tu najciekawsza. Najciekawsze jest to, że szkoła — uczciwie: jedna osoba w szkole — może dziś złożyć to z komponentów, które nie kosztują nic i są udokumentowane na śmierć.

Co się zepsuło i co jest trudne

Sekcja praktyka, bo teksty bez niej są reklamą.

Powiadomienia push na urządzeniach Apple to największe pojedyncze źródło tarcia. iOS wymaga zainstalowania strony na ekranie głównym, zanim powiadomienia w ogóle zadziałają, a macOS po cichu wymaga włączenia ich w Ustawieniach systemowych. Technologia niczym nie ostrzega; rodzice po prostu zgłaszają, że „powiadomienia nie działają”, i boleśnie uczysz się, że instrukcja onboardingu znaczy tyle samo co kod.

Współistnienie PWA i powiadomień push oznacza dwa service workery działające obok siebie — a one nie przepadają za sobą z natury. Doprowadzenie do tego, żeby cache i messaging przestały ze sobą walczyć, zajęło więcej czasu niż jakakolwiek funkcja na stronie. Jeśli się za to zabierasz, zaplanuj na to realny czas.

I ta niewygodnie szczera: wąskim gardłem jest redakcja, nie technologia. Push o niczym to spam. Chatbot z nieaktualną bazą wiedzy to kłamca o dobrych manierach. Strona klasy aplikacji wymaga opieki nad treścią klasy aplikacji — kogoś, kto aktualizuje bazę wiedzy, gdy zmieniają się zasady rekrutacji, i kto dwa razy pomyśli, zanim naciśnie przycisk dzwoniący na czterysta telefonów. Ten problem organizacyjny rozwiążcie najpierw; jest trudniejszy od kodu.

Czy Wasza szkoła może to zrobić?

Niewygodna odpowiedź: dziś tylko wtedy, gdy ktoś w zespole umie to zbudować albo szkoła zatrudni kogoś, kto umie. Uczciwa przeciwwaga: ta bariera właśnie się zawala. Każdy komponent jest darmowy, udokumentowany i coraz częściej składany z pomocą AI, a nie pisany linijka po linijce. Przygotowuję zgeneralizowany, niezależny od konkretnej szkoły tutorial dokładnie tego stosu — pojawi się na tej stronie.

Paradygmat możecie natomiast przyjąć od dziś, w każdej szkole, niezależnie od technologii: przestańcie traktować stronę jak tablicę ogłoszeń. Zapytajcie, czego rodzic potrzebuje we wtorek o 22:00 — i oceńcie każdy element swojej cyfrowej obecności względem tego pytania.

Żywy przykład jest tutaj: podstawowa.piwoni.pl. Zainstalujcie. Pomęczcie asystenta. Zepsujcie coś i dajcie mi znać.

Pytanie do prowadzących komunikację szkolną: czego potrzeba, żeby rodzice traktowali własny kanał szkoły — nie grupę na Facebooku, nie płatny komunikator — jako miejsce, w którym mieszkają szkolne informacje? Mam swoją hipotezę. Chętnie poznam Wasze.