Strony internetowe dla muzeów, teatrów, galerii i domów kultury
Większość odwiedzających szuka na stronie instytucji kultury trzech rzeczy: co jest grane, ile kosztuje bilet i do której jest otwarte. Często sprawdza to na telefonie, stojąc już pod budynkiem. Robię strony, na których te informacje są na wierzchu, a kuratorzy, edukatorzy i dział promocji publikują treści bez programisty. Nazywam się Mariusz Szatkowski, programuję w WordPressie od 2006 roku i pracuję sam.
Projekt graficzny i makietę dostarcza instytucja albo jej grafik. Jeśli makiety jeszcze nie ma, wysyłam arkusz, w którym zaznaczasz, co ma się znaleźć na każdej podstronie.
Repertuar, wydarzenia i bilety
Kalendarz to rdzeń strony teatru czy domu kultury. Wydarzenia mają kategorie (spektakl, koncert, warsztat, wykład), filtr po dacie i miejscu, terminy cykliczne generowane automatycznie i widok listy, który dobrze wygląda na telefonie.
Przycisk zakupu biletu stoi przy każdym terminie. Jeśli system biletowy instytucji udostępnia API albo widżet, podłączam go bezpośrednio; dokumentację sprawdzam przed wyceną. Mniejszą sprzedaż, na przykład warsztaty, katalogi wystaw czy reprodukcje, można prowadzić w WooCommerce, z płatnościami przez operatora, z którym instytucja ma umowę. Darowizny od mecenasów działają tak samo.
Dział edukacji dostaje formularz rezerwacji lekcji muzealnych dla grup i strefę nauczyciela z kartami pracy do pobrania.
Zbiory online i metadane obiektów
Obiekt cyfrowy to coś więcej niż zdjęcie z tytułem. Przed migracją ustalam minimalny zestaw pól: identyfikator, twórca, datowanie, materiał i technika, status praw, tekst alternatywny i źródło. Relacje między obiektami, wystawami i osobami zapisuję jako powiązania w bazie, a nie jako tekst w opisie, dzięki czemu wyszukiwarka zbiorów działa po autorze, epoce i technice.
Status praw decyduje o tym, co strona pokazuje. Własność obiektu to co innego niż prawo do publikacji jego fotografii, więc CMS wyświetla wymagane podpisy i blokuje pobieranie plików w wysokiej rozdzielczości, jeśli licencja na to nie pozwala. Do oglądania detali w dużym powiększeniu nadaje się standard IIIF.
Jeśli instytucja prowadzi katalog w systemie muzealnym, na przykład MUSNET albo MONA, import zależy od tego, jakie eksporty ten system oferuje. Sprawdzam to na próbce rekordów, zanim podam zakres.
Przed startem testuję stronę na reprezentatywnych rekordach: krótkie i bardzo długie opisy, obiekt bez zdjęcia, kilka wersji językowych, wydarzenie wyprzedane i odwołane.
Dostępność cyfrowa: instytucja kultury jest podmiotem publicznym
Państwowe i samorządowe instytucje kultury należą do sektora finansów publicznych (art. 9 pkt 13 ustawy o finansach publicznych). Ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (tekst jednolity Dz.U. 2023 poz. 1440) obejmuje jednostki tego sektora w art. 2 pkt 1. W praktyce oznacza to:
- wymagania z załącznika do ustawy, uznawane za spełnione przy zgodności z normą EN 301 549 V3.2.1 (art. 5 ust. 3), czyli WCAG 2.1 na poziomie AA,
- deklarację dostępności dla każdej wersji językowej strony (art. 10).
Ustawa przewiduje wyłączenia ważne dla muzeów i bibliotek. Art. 3 ust. 2 pkt 7 nie wymaga dostępności treści prezentujących dzieła sztuki, zabytki, muzealia i materiały biblioteczne, jeśli dostępna prezentacja oznaczałaby utratę autentyczności, byłaby technicznie niemożliwa albo wiązałaby się z nadmiernymi kosztami. Pkt 1 wyłącza multimedia nadawane na żywo. Opis obiektu, nawigacja, kalendarz i formularz zakupu biletu nadal muszą być dostępne.
W kodzie oznacza to etykiety przy polach, pełną obsługę klawiaturą z widocznym fokusem, kontrast co najmniej 4,5:1, napisy do nagrań i sprawdzenie axe-core przed każdym wdrożeniem, a przed startem test z NVDA i VoiceOver.
Kilka oddziałów, jedna instalacja
Muzeum z kilkoma oddziałami albo teatr z osobnym festiwalem może prowadzić wszystkie strony na WordPress Multisite. Każdy oddział ma swoich redaktorów, którzy widzą tylko swoją stronę, biblioteka mediów może być wspólna, a aktualizacje robię raz dla całej sieci.
Wersje językowe zakładam w Polylang albo WPML. Tłumaczenia przygotowuje instytucja; ja pilnuję adresów, znaczników hreflang i tego, żeby żadna wersja nie prowadziła do pustej strony.
Bezpieczeństwo, szybkość i opieka
Strona instytucji kultury zbiera dane z newslettera, rezerwacji grupowych i sprzedaży. Zanim dostanę dostęp do takiej strony, podpisuję umowę powierzenia przetwarzania z art. 28 RODO. Nie korzystam z podwykonawców.
Zdjęcia zbiorów są duże, więc strona serwuje je w formacie AVIF i w rozmiarach dopasowanych do ekranu, a skrypty zewnętrzne ładują się dopiero po zgodzie. Szybkość mierzę na danych od prawdziwych odwiedzających, nie na pojedynczym teście Lighthouse.
Po starcie mogę prowadzić stronę dalej: monitoring dostępności co 1 do 5 minut, kopie zapasowe przechowywane minimum 30 dni w krajach UE, aktualizacje testowane najpierw na stagingu. Dyżurów 24/7 nie prowadzę. Hostingu nie sprzedaję: instytucja wybiera dostawcę, ja konfiguruję WordPressa u niego.
Jak pracuję
- Brief: opisujesz potrzeby przez formularz kontaktowy. Pytania zadaję mailowo.
- Oferta: zakres, założenia i harmonogram dostajesz na piśmie, zanim powstanie kod. Jeśli strona ma wejść do wniosku o dofinansowanie, opisuję zakres tak, żeby dało się go potem rozliczyć.
- Wdrożenie: kod trzymam w prywatnym repozytorium Git, każda zmiana trafia najpierw na staging.
- Odbiór: sprawdzasz stronę na stagingu i dostajesz pisemny opis każdej zmiany oraz instrukcję dla redaktorów.
Umowę zawieram według prawa polskiego, fakturę wystawiam z numerem NIP 7393037445.
Kontakt
Wyślij przez formularz kontaktowy adres obecnej strony, opis zmian i nazwę systemu biletowego, jeśli go używasz. Odpiszę z pytaniami albo z ofertą opartą na zapisanych założeniach. Większe wdrożenia opisuję w dziale rozwiązania enterprise WordPress.
Podobne wymagania dotyczące dostępności i ochrony danych opisuję też dla urzędów, szpitali i fundacji.
