Aplikacja multimedialna w muzeum: lista przed startem

Zanim pierwszy zwiedzający uruchomi aplikację przy eksponacie, gotowych musi być kilka warstw: zgodność z przepisami o dostępności cyfrowej, uporządkowane i zdigitalizowane zbiory, system CMS obsługujący wiele języków oraz scenariusze interakcji przetestowane z realnymi użytkownikami. Sam interfejs jest dopiero widoczną częścią przedsięwzięcia. Jeśli zaplecze nie działa, nawet dobrze zaprojektowana aplikacja szybko zamienia się w kosztowny ekran startowy i zbiór nieaktualnych treści.

Przy projekcie multimediów w muzeum warto więc myśleć nie o jednej aplikacji, lecz o całym systemie: prawie, zasobach, redakcji, infrastrukturze i doświadczeniu zwiedzającego. Każda z tych warstw ma własne ryzyka. Co więcej, problemy odkryte po otwarciu wystawy są zwykle znacznie droższe do usunięcia niż decyzje podjęte na etapie briefu.

Fundamenty prawne i standardy dostępności cyfrowej

Polskie muzea jako instytucje publiczne podlegają Ustawie z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych, w zakresie określonym przez przepisy. W praktyce oznacza to obowiązek uwzględnienia dostępności cyfrowej w projekcie, zamówieniu, testach i późniejszym utrzymaniu rozwiązania. Technicznym punktem odniesienia pozostaje standard WCAG 2.1.

To nie jest dodatek dla ambitnych projektów ani etap, który można dopisać po zakończeniu prac graficznych. Zgodność z ustawą i WCAG 2.1 jest obowiązkiem instytucji publicznej, ale sama obecność aplikacji w muzeum nie oznacza automatycznie, że każdy element ekspozycji został w pełni oceniony pod kątem dostępności. Zakres obowiązków, sposób publikacji informacji i dokumentowanie stanu dostępności trzeba ustalić dla konkretnej instytucji oraz konkretnego rozwiązania. Nie ma podstaw, by sprowadzać ten wymóg do automatycznego zakazu udostępnienia aplikacji. Jest natomiast bardzo dobry powód, by dostępność traktować jako warunek jakości i odpowiedzialnego wdrożenia.

Co to oznacza dla zespołu projektowego?

• Kontrast, skalowanie i czytelność tekstu. Użytkownik powinien móc odczytać treść bez walki z tłem, dekoracją i zbyt małym stopniem pisma. Dotyczy to również przycisków, etykiet, komunikatów o błędach i elementów pojawiających się tylko w określonym stanie aplikacji.
• Obsługa technologii asystujących. Interfejs musi mieć logiczną kolejność elementów, poprawne nazwy kontrolek i komunikaty, które mogą zostać odczytane przez czytnik ekranu. W aplikacji mobilnej trzeba sprawdzić także gesty, fokus i zachowanie po zmianie orientacji urządzenia.
• Alternatywa dla treści dźwiękowych i wizualnych. Materiały wideo powinny mieć napisy, a treści istotne dla odbioru dzieła nie mogą być dostępne wyłącznie za pośrednictwem obrazu. Audiodeskrypcja, tekst alternatywny, transkrypcja i napisy nie są zamiennymi nazwami tego samego rozwiązania — każda forma odpowiada na inną potrzebę.
• Zrozumiała nawigacja. Zwiedzający powinien wiedzieć, gdzie jest, jak wrócić do poprzedniego ekranu i co stanie się po wybraniu konkretnej opcji. W muzeum ma to szczególne znaczenie, bo użytkownik często korzysta z aplikacji w ruchu, w tłumie i przy ograniczonej uwadze.
• Dostępność językowa i redakcyjna. Prosty język, konsekwentne nazwy funkcji oraz dobrze oznaczone wersje językowe pomagają nie tylko osobom z niepełnosprawnościami. Ułatwiają korzystanie także dzieciom, seniorom, osobom uczącym się języka i zwiedzającym, którzy pierwszy raz mają kontakt z daną kolekcją.

Dostępność aplikacji muzealnej nie kończy się na pozytywnym wyniku audytu. Standard pokazuje, czy rozwiązanie spełnia wymagania, a użytkownik pokazuje, czy rzeczywiście da się z niego korzystać.

Realna lista zadań na tym etapie obejmuje przede wszystkim:

• audyt projektu graficznego, w tym kontrastu, typografii, wielkości pól aktywnych i komunikatów;
• sprawdzenie technologii pod kątem współpracy z czytnikami ekranu oraz systemowymi ustawieniami dostępności;
• opisanie alternatywnych sposobów dotarcia do każdej istotnej treści;
• zaplanowanie testów z osobami korzystającymi na co dzień z technologii asystujących;
• ustalenie, kto w instytucji odpowiada za informacje o dostępności, aktualizację deklaracji i kontakt w sprawie problemów;
• określenie, które elementy będą działały na własnym urządzeniu zwiedzającego, a które na sprzęcie udostępnianym przez muzeum;
• przygotowanie procedury reagowania na zgłoszenia, bo dostępność jest także kwestią utrzymania, a nie wyłącznie premiery.

Już tutaj trzeba rozstrzygnąć, czy aplikacja będzie działała w modelu własnego urządzenia zwiedzającego, czy na sprzęcie muzealnym: tabletach wypożyczanych przy kasie, infokioskach albo ekranach zamontowanych w salach. W pierwszym wariancie instytucja musi uwzględnić różne systemy operacyjne, rozmiary ekranów, ustawienia powiększenia i jakość połączenia. W drugim można ujednolicić konfigurację, ale odpowiedzialność za aktualizacje, ładowanie, czyszczenie i sprawność urządzeń pozostaje po stronie muzeum.

Dostępność nie powinna być osobnym dokumentem przekazanym zespołowi programistycznemu. Lepiej wpisać ją w kryteria odbioru każdego modułu: nawigacji, odtwarzacza audio, galerii, mapy, formularza i mechanizmu wyszukiwania.

Digitalizacja zasobów jako baza dla interaktywnych treści

Aplikacja bez treści jest pustym menu, ale sama obecność plików cyfrowych również nie wystarczy. Interaktywna wystawa potrzebuje zasobów przygotowanych tak, aby można było je wyszukiwać, łączyć, tłumaczyć i prezentować w różnych kontekstach. Zdjęcie obiektu, opis kuratorski, nagranie audio i informacja o prawach do publikacji muszą być częścią jednego, uporządkowanego modelu danych.

Digitalizacja ma własny cykl pracy. Nie warto traktować jej jako technicznego wstępu do właściwego projektu, ponieważ często to właśnie ona decyduje o tym, co aplikacja będzie mogła pokazać.

Przed rozpoczęciem prac trzeba ustalić:

• które obiekty są priorytetowe dla planowanej wystawy lub ścieżki zwiedzania;
• czy potrzebne są fotografie dokumentacyjne, skany, modele trójwymiarowe, nagrania czy reprodukcje detali;
• jakie będą formaty plików roboczych i plików przeznaczonych do publikacji;
• kto opisuje obiekty i zatwierdza opisy;
• jakie metadane są niezbędne do wyszukiwania i filtrowania;
• czy muzeum ma prawa do publikacji wizerunku obiektu, nagrania, tekstu i materiałów dodatkowych;
• w jaki sposób będą oznaczane zmiany statusu obiektu, lokalizacji oraz dostępności reprodukcji.

Wąskim gardłem rzadko jest sam skan. Znacznie więcej czasu może zająć przygotowanie opisu merytorycznego, weryfikacja proweniencji, ustalenie autorstwa, wybór nazewnictwa i decyzja, która wersja tekstu jest przeznaczona dla początkującego zwiedzającego, a która dla odbiorcy specjalistycznego. Aplikacja może wyświetlić obraz w wysokiej rozdzielczości, ale bez kontekstu niekoniecznie pomoże go zrozumieć.

Trzeba też rozdzielić kilka pojęć, które w projektach bywają używane zamiennie. Plik przeznaczony do archiwizacji nie musi być tym samym plikiem, który zostanie pobrany przez telefon. Materiał do projekcji na dużym ekranie będzie miał inne wymagania niż miniatura na liście obiektów. Nagranie przeznaczone do odsłuchu przy eksponacie powinno być przygotowane inaczej niż długi wykład dostępny w osobnej sekcji.

Najbezpieczniej zbudować dla każdego obiektu kartę zawierającą przynajmniej:

1. identyfikator i nazwę używaną wewnętrznie;

2. tytuł przeznaczony dla zwiedzających;

3. podstawowy opis oraz ewentualną wersję rozszerzoną;

4. informacje o autorze, czasie powstania, technice i pochodzeniu, jeśli są ustalone;

5. lokalizację obiektu lub przypisanie do konkretnej ścieżki;

6. pliki multimedialne wraz z opisem ich przeznaczenia;

7. wersje językowe i status tłumaczenia;

8. informacje o prawach, licencjach i ograniczeniach publikacji;

9. datę ostatniej redakcji oraz osobę odpowiedzialną za zatwierdzenie.

Tak przygotowana baza ułatwia późniejsze tworzenie treści nie tylko w aplikacji. Te same dane mogą zasilić stronę internetową, katalog wystawy, infokiosk, audioprzewodnik albo materiały edukacyjne. To ważne, bo projekt multimediów w muzeum nie powinien kończyć się na jednym kanale publikacji, jeśli instytucja ponosi koszt opracowania materiału.

Cyfrowe repozytorium nie jest dodatkiem do aplikacji. To infrastruktura treści, bez której interaktywność szybko staje się efektowną, ale płytką warstwą prezentacji.

Budżet i harmonogram aplikacji warto planować równolegle z digitalizacją. Jeżeli fotografie, opisy lub tłumaczenia powstają dopiero po zakończeniu prac programistycznych, zespół może testować wyłącznie zastępcze materiały. Wtedy nie sprawdzi długości tekstów, proporcji obrazu, napisów, obciążenia plikami ani zachowania interfejsu przy realnej liczbie obiektów.

Architektura systemu: CMS i zarządzanie wielojęzycznością

Drugą warstwą, obok treści, jest system, który nimi zarządza. CMS w muzeum nie powinien być wyłącznie panelem do wpisywania opisów. To miejsce, w którym spotykają się praca kuratorska, edukacyjna, tłumaczeniowa, techniczna i administracyjna.

Nie ma jednego obowiązującego systemu odpowiedniego dla każdej instytucji. Można wykorzystać rozwiązanie komercyjne, platformę open source albo system przygotowany na zamówienie. Ważniejsze od samej etykiety jest to, czy architektura odpowiada skali zbiorów i sposobowi pracy zespołu.

CMS powinien obsługiwać między innymi:

• wiele wersji językowych bez kopiowania całej struktury treści przy każdej zmianie;
• role i uprawnienia dopasowane do odpowiedzialności kuratora, edukatora, tłumacza, redaktora oraz administratora;
• wersjonowanie i historię zmian;
• proces zatwierdzania treści przed publikacją;
• planowanie publikacji i wycofywania materiałów;
• relacje między obiektem, salą, wystawą, ścieżką tematyczną i materiałem dodatkowym;
• integrację z audioprzewodnikiem, mapą oraz aplikacją mobilną;
• eksport danych do strony internetowej, infokiosków i innych kanałów;
• kopie zapasowe, logowanie operacji i możliwość odtworzenia wcześniejszej wersji.

Wielojęzyczność jest tu czymś więcej niż przełącznikiem w prawym górnym rogu. Trzeba ustalić, co dzieje się wtedy, gdy opis polski zostaje zmieniony, a tłumaczenie nie jest jeszcze gotowe. Czy użytkownik zobaczy poprzednią wersję, informację o braku tłumaczenia, czy może język domyślny? Kto otrzyma zadanie przekładu? Czy zmiana jednego zdania unieważnia cały materiał, czy tylko wybrany fragment?

Warto również przewidzieć, że różne wersje językowe nie zawsze mają tę samą długość. Tekst mieszczący się na jednym ekranie po polsku może po tłumaczeniu wymagać przewijania, innego podziału akapitów albo zmiany rozmiaru elementów. Dotyczy to także napisów, przycisków, menu i komunikatów systemowych.

Pojawia się również dylemat między gotowym systemem komercyjnym a rozwiązaniem open source. Pierwsze może skrócić czas uruchomienia i zapewnić wsparcie, ale bywa mniej elastyczne przy nietypowych typach obiektów, rozbudowanych relacjach i niestandardowych kanałach publikacji. Drugie daje większą kontrolę, lecz wymaga kompetencji do aktualizacji, zabezpieczania i rozwijania systemu. Sama możliwość modyfikacji nie jest jeszcze korzyścią, jeśli po zakończeniu projektu w muzeum nie ma osoby ani zespołu, który potrafi z niej skorzystać.

Decyzja o CMS-ie powinna zapaść przed rozpoczęciem szczegółowych prac nad scenariuszami. Wybór platformy wpływa na to, jak szybko redaktor zmieni opis, doda nagranie lub wycofa obiekt z trasy. Jeśli każda korekta wymaga udziału programisty, muzeum zyskuje aplikację, ale traci samodzielność redakcyjną. To przekłada się na koszty utrzymania w kolejnych latach — aspekt, który przy budżecie wdrożeniowym często schodzi na dalszy plan.

Infrastruktura techniczna: od beaconów po ekrany dotykowe

Decyzja o kanale dostarczania treści to osobna warstwa projektu. W praktyce muzea korzystają z kilku uzupełniających się rozwiązań, ponieważ różne grupy odbiorców mają różne potrzeby. Własny smartfon może być wygodny dla jednego zwiedzającego, ale dla innego oznacza konieczność instalowania aplikacji, używania własnych słuchawek i korzystania z transmisji danych. Ekran stacjonarny jest łatwiejszy do znalezienia, lecz nie zapewnia prywatności ani swobody poruszania się po wystawie.

Kody QR są tanie i łatwe do zastąpienia, ale wymagają dobrego oznaczenia oraz odpowiedniej wielkości pola do zeskanowania. Beacony mogą uruchamiać treści zależnie od położenia urządzenia, jednak ich działanie zależy od układu sali, materiałów konstrukcyjnych, zakłóceń i ustawień telefonu. Nie należy zakładać, że lokalizacja oparta na sygnale będzie zawsze precyzyjna. Warto przygotować również ręczny sposób znalezienia obiektu, na przykład przez numer, mapę lub wyszukiwarkę.

Przed zakupem sprzętu multimedialnego do muzeum trzeba sprawdzić nie tylko parametry ekranu. Równie ważne są:

• sposób montażu i możliwość bezpiecznego prowadzenia przewodów;
• odporność na intensywne użytkowanie;
• dostęp do zasilania i możliwość awaryjnego restartu;
• warunki temperaturowe, nasłonecznienie oraz poziom hałasu;
• możliwość aktualizacji oprogramowania bez demontażu urządzenia;
• dostępność części zamiennych i czas reakcji serwisu;
• zabezpieczenie urządzenia przed kradzieżą i przypadkowym uszkodzeniem;
• możliwość korzystania z urządzenia przez osobę na wózku lub o ograniczonym zasięgu ruchu;
• sposób czyszczenia powierzchni dotykowych bez pogarszania ich działania.

W przypadku własnych urządzeń zwiedzających trzeba dodatkowo uwzględnić różnorodność telefonów. Aplikacja może działać poprawnie na urządzeniu zespołu projektowego, a mimo to mieć problemy z mniej wydajnym modelem, starszą wersją systemu, inną proporcją ekranu lub ograniczoną pamięcią. Nie trzeba obsługiwać każdej możliwej konfiguracji, ale trzeba jasno określić zakres wsparcia i przetestować urządzenia reprezentujące najważniejsze grupy.

Sieć Wi-Fi również wymaga pomiarów w realnych warunkach. Nie wystarczy sprawdzenie zasięgu w pustej sali. Podczas otwarcia wystawy w jednym miejscu może znaleźć się wiele urządzeń, a ściany, gabloty i materiały ekspozycyjne mogą wpływać na jakość sygnału. Treści wideo i audio powinny mieć wariant awaryjny: pobieranie z wyprzedzeniem, niższą jakość, lokalny bufor albo wersję tekstową.

Najczęstszy błąd polega na projektowaniu infrastruktury dopiero po zamknięciu scenariusza. Jeśli aplikacja ma reagować na położenie zwiedzającego, trzeba zaplanować miejsce dla urządzeń lokalizacyjnych, ich zasilanie, dostęp serwisowy i sposób kalibracji. Jeśli centralnym elementem ma być ekran dotykowy, jego położenie powinno wynikać z przepływu zwiedzających, a nie z wolnego fragmentu ściany.

Optymalizacja pod użytkownika: scenariusze i testy interakcji

Ostatnia warstwa jest wcale nie mniej ważna. Sam montaż ekranów, dodanie animacji i podłączenie systemu zarządzania treścią nie gwarantują udanego wdrożenia. Aplikacja może zawierać wiele funkcji, a mimo to prowadzić zwiedzającego w ślepy zaułek już na pierwszym ekranie.

Scenariusz dla aplikacji muzealnej to decyzja o tym, jak użytkownik przechodzi przez ekspozycję: linearnie, według rekomendowanej ścieżki, czy nielinearnie, przez swobodną eksplorację. Trzeba ustalić, czy audio uruchamia się automatycznie, czy dopiero po wyborze, czy dzieci otrzymują osobną warstwę treści, a także co dzieje się po przerwaniu nagrania lub zamknięciu aplikacji.

Przed rozpoczęciem produkcji warto odpowiedzieć na kilka konkretnych pytań:

1. Ile czasu zwiedzający spędzi przy jednym obiekcie? Krótki opis przy przejściu wymaga innej konstrukcji niż kilku minut słuchania lub oglądania.

2. Czy aplikacja służy jednej osobie, czy grupie? Nauczyciel prowadzący klasę potrzebuje innego trybu pracy niż para zwiedzająca wystawę we własnym tempie.

3. Jakie poziomy treści są potrzebne? Podstawowy opis, komentarz kuratorski, materiał historyczny, nagranie, audiodeskrypcja, napisy i wersja dla dzieci nie powinny konkurować ze sobą na jednym ekranie.

4. Czy użytkownik musi mieć połączenie z internetem przez cały czas? Jeśli tak, awaria sieci staje się awarią całej ścieżki.

5. Co się dzieje, gdy zwiedzający pomija sale, cofa się albo wraca po dłuższej przerwie? System powinien tolerować rzeczywiste zachowanie, a nie wymuszać idealną kolejność.

6. Jak aplikacja działa w grupie? Dźwięk odtwarzany z głośnika telefonu może być nieczytelny, a kilka urządzeń uruchomionych jednocześnie może zakłócać odbiór.

7. Czy użytkownik może zapisać obiekt lub wrócić do niego później? Taka funkcja bywa bardziej użyteczna niż kolejny efekt wizualny.

Testy użyteczności powinny obejmować różne sposoby korzystania z wystawy. Warto zaprosić dorosłego zwiedzającego bez doświadczenia muzealnego, nauczyciela z grupą, seniora, rodzica z dzieckiem oraz osobę z niepełnosprawnością wzroku lub słuchu. Nie chodzi o stworzenie reprezentatywnego badania statystycznego, lecz o wychwycenie przeszkód, których zespół projektowy nie zauważa, bo zna system zbyt dobrze.

Każdy test powinien mieć konkretne zadanie. Zamiast pytać, czy aplikacja się podoba, lepiej poprosić o znalezienie określonego obiektu, zmianę języka, uruchomienie audiodeskrypcji, powrót do mapy albo odszukanie informacji o autorze. Obserwacja pokaże, w którym miejscu użytkownik się zatrzymuje, czego dotyka, co pomija i jak interpretuje nazwy przycisków.

Wynik testu warto zapisywać w sposób przydatny dla zespołu:

• problem powinien mieć opis zachowania, a nie tylko ocenę, że coś jest nieintuicyjne;
• należy wskazać, w jakim kontekście wystąpił;
• trzeba określić, czy blokuje dalsze korzystanie, czy tylko spowalnia wykonanie zadania;
• poprawka powinna mieć właściciela i termin;
• po wdrożeniu zmiany należy sprawdzić, czy nie pojawił się nowy problem.

Zgodność z WCAG 2.1 i użyteczność to dwa powiązane, ale różne obszary. Audyt może wykazać niewystarczający kontrast, brak etykiety albo błąd w kolejności fokusu. Test z użytkownikiem pokaże natomiast, że zwiedzający nie rozumie różnicy między ścieżką tematyczną a mapą, nie wie, że trzeba przewinąć ekran albo nie może wrócić do przerwanego nagrania. Oba rodzaje sprawdzenia są potrzebne.

W przypadku ekranów stacjonarnych, infokiosków, totemów i stołów multimedialnych scenariusz wygląda nieco inaczej niż przy aplikacji na telefon. Użytkownik może spędzić przy takim stanowisku więcej czasu, ale jednocześnie musi zrozumieć jego działanie bez instruktażu pracownika. Rozbudowany katalog skanów, gra edukacyjna czy możliwość porównywania obiektów wymagają wyraźnego początku, prostego powrotu i czytelnego zakończenia. Ekran nie powinien zatrzymywać zwiedzającego w nieskończonej pętli, jeśli sala jest zatłoczona i inni czekają na dostęp.

W briefie dla zespołu UX trzeba też opisać sytuacje brzegowe: brak sieci, rozładowanie urządzenia, przypadkowe zamknięcie aplikacji, przerwanie dźwięku, dotknięcie ekranu przez kilka osób oraz konieczność szybkiego wyczyszczenia stanowiska. To nie są scenariusze awaryjne w abstrakcyjnym sensie. W muzeum należą do zwykłego dnia pracy.

Co zostaje po odhaczeniu listy

Przygotowanie aplikacji multimedialnej w muzeum nie kończy się w dniu publikacji. Po otwarciu wystawy zaczyna się drugi etap: aktualizacja opisów, obsługa tłumaczeń, kontrola urządzeń, poprawki dostępności, analiza zgłoszeń i dodawanie kolejnych kolekcji. System, który nie ma właściciela po stronie instytucji, szybko traci wartość niezależnie od jakości pierwszego wdrożenia.

Dlatego przed startem trzeba ustalić nie tylko, kto zatwierdzi wersję produkcyjną, lecz także kto później:

• aktualizuje treści po zmianie ekspozycji;
• sprawdza działanie kodów, beaconów i ekranów;
• odbiera zgłoszenia od zwiedzających;
• zarządza kontami redakcyjnymi i uprawnieniami;
• pilnuje kopii zapasowych oraz aktualizacji systemu;
• monitoruje wersje językowe;
• wraca do testów dostępności po większych zmianach;
• decyduje, które dane o korzystaniu z aplikacji są potrzebne i jak można je gromadzić zgodnie z przepisami.

Dobrze zaplanowane wdrożenie aplikacji w muzeum nie polega na zebraniu jak największej liczby funkcji. Polega na zbudowaniu spójnej drogi od obiektu i jego opisu do konkretnego doświadczenia zwiedzającego. Prawo wyznacza odpowiedzialność instytucji, digitalizacja dostarcza wiarygodnych zasobów, CMS pozwala nimi zarządzać, infrastruktura zapewnia dostęp, a testy pokazują, czy całość działa poza prezentacją projektową.

Aplikacja muzealna nie jest produktem, który po premierze można odłożyć na półkę. To usługa związana z wystawą, kolekcją i codzienną pracą instytucji. Im wcześniej muzeum zaplanuje jej utrzymanie, dostępność i rozwój, tym mniejsze ryzyko, że po efektownym otwarciu zostanie z rozwiązaniem, którego nie da się łatwo zaktualizować, naprawić ani zrozumiale używać.