Ile system będzie kosztował za kilka lat
Szef odbiera nowy sklep internetowy. Rozmawia z wykonawcą o układzie strony, o kolorach i o tym, ile kliknięć dzieli klienta od zapłaty. Wszystko wygląda dobrze. O tym, ile sklep będzie kosztował za kilka lat, decyduje jednak coś, o czym w tej rozmowie nikt nie wspomniał. Może się okazać, że trzeba go przerabiać pod nowe przepisy, łatać po włamaniu albo przepisywać przy zmianie dostawcy.
Wystarczy wiedzieć, o co zapytać przy odbiorze. Odpowiedzi podsuwają otwarte standardy, przygotowane przez międzynarodowe organizacje i sprawdzone w wielu systemach.
Dostępność: czy każdy skorzysta ze strony
Dostępność kojarzy się z osobami z niepełnosprawnościami i dla nich jest najważniejsza. Korzysta na niej jednak każdy użytkownik.
Handlowiec sprawdza na telefonie status zamówienia, siedząc w samochodzie w pełnym słońcu. Jasnoszarego tekstu na białym tle nie odczyta, choć wzrok ma dobry. Księgowa cały dzień wprowadza dane i między polami przechodzi klawiszem Tab, bo tak jest szybciej niż myszą. Przypadkowa kolejność pól albo przycisk, który nie reaguje na klawiaturę, kosztuje ją kilka zbędnych ruchów przy każdej fakturze. Starszy klient sklepu powiększa tekst w przeglądarce, a jeśli strona się wtedy rozsypuje, nie dokończy zakupu.
Punktem odniesienia są międzynarodowe wytyczne dostępności (WCAG 2.2). Opracowało je W3C, organizacja tworząca standardy sieci. Wytyczne mają trzy poziomy zgodności: A, AA i AAA. Poziom AA to rozsądny środek. Obejmuje między innymi wystarczający kontrast tekstu, pełną obsługę klawiaturą, czytelne komunikaty o błędach w formularzach i działanie przy powiększonym tekście.
Co mówi prawo
Od 28 czerwca 2025 r. w zasadniczej części obowiązuje ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług, która wdraża europejski akt o dostępności. Dotyczy wybranych usług dla konsumentów, między innymi sprzedaży przez strony i aplikacje oraz bankowości detalicznej, a usług mikroprzedsiębiorców nie obejmuje. Pełny wykaz, wyjątki i kary są w tekście ustawy, a czy obejmuje ona konkretną firmę, rozstrzyga jej prawnik.
Co sprawdzić przy odbiorze
Każde pole formularza ma opis, który odczyta też program czytający ekran. Błąd w formularzu jest opisany słowami, bo sam czerwony kolor nie wystarczy. Zdjęcie, które coś znaczy, ma opis tekstowy. Przycisk wygląda jak przycisk i da się go nacisnąć klawiszem Enter.
Część tych rzeczy sprawdzają automatyczne testy dostępności, na przykład zbyt słaby kontrast, pola bez opisu i obrazy bez tekstu alternatywnego. Automat nie wychwyci wszystkiego, więc najważniejsze ścieżki warto przejść też ręcznie, samą klawiaturą i z powiększonym tekstem. Dopisanie dostępności do gotowego systemu kosztuje dużo więcej niż zadbanie o nią przy pierwszym szkicu. Jak może wyglądać deklaracja dostępności z datą przeglądu i znanymi ograniczeniami, widać na przykładzie tej strony.
Bezpieczeństwo: czy jeden błąd nie otworzy wszystkiego
Włamania do firmowych aplikacji rzadko zaczynają się od jednej wielkiej dziury. Częściej od drobiazgu, na przykład od formularza kontaktowego, którego treść strona pokazuje potem innym bez sprawdzenia. Ktoś wkleja tam zamiast wiadomości kawałek programu, a przeglądarki innych użytkowników go uruchamiają.
Najczęstsze takie błędy od lat zbiera uznana lista najczęstszych błędów bezpieczeństwa (OWASP), prowadzona przez otwartą społeczność. Dwie sprawy z tej listy łatwo sprawdzić w każdym systemie. Tekst wpisany przez klienta aplikacja pokazuje innym zawsze jako zwykły tekst. Strona mówi przeglądarce, skąd wolno brać programy, a obcych nie uruchamia. Trzecia sprawa to hasła, które nie powinny leżeć w kodzie. Piszemy o nich w artykule Hasła, które zostają po ludziach.
Formaty danych: czy firma może zmienić dostawcę
Chodzi o to, w jakiej postaci system przechowuje to, co firma w niego włożyła: formularze, procesy, reguły i obliczenia.
W wielu systemach ta wiedza jest zapisana w sposób znany tylko jednemu dostawcy. Działa, dopóki trwa współpraca. Gdy firma chce zmienić dostawcę, okazuje się, że formularze, obiegi dokumentów i reguły trzeba odtwarzać od zera, często z pamięci pracowników.
Tam, gdzie istnieje uznany otwarty standard, warto, żeby system go używał. Procesy, czyli kto co robi i w jakiej kolejności, opisuje na przykład BPMN, międzynarodowy standard rysowania procesów, który znają analitycy i wiele narzędzi. Reguły decyzyjne, takie jak rabat dla danego klienta, można zapisać według standardu DMN w tabelach decyzyjnych, które przeczyta też ktoś spoza IT.
Tak zapisujemy formularze, procesy i reguły zarówno na naszej platformie Applanter, jak i w aplikacjach na zamówienie, tam gdzie taki standard istnieje. Firma, która odchodzi, zabiera je razem z danymi.
Przy odbiorze warto zapytać, w jakim formacie zapisane są formularze, procesy i reguły i czy da się je odczytać bez systemu, w którym powstały. Zgodność ze standardem sprawdzają testy, które porównują zapis systemu z wymaganiami samego standardu. Jeśli standard ma oficjalne przykłady, dobrze, żeby testy z nich korzystały.
O tym, jak zabrać z systemu same dane, piszemy w artykule Twoje dane w cudzym formacie. Jak zbudować aplikację, żeby wymiana usługi zewnętrznej, na przykład bramki płatności, nie wymagała przeróbek w całym kodzie, opisujemy w artykule Zmiana dostawcy bez przepisywania aplikacji.