Układ menu wynika z podziału na obszary pracy, a nie z listy funkcji. Operator na bramie widzi dwie pozycje, dyspozytura kilkanaście, a administrator komplet - i wszyscy pracują na tej samej instalacji.
Cztery obszary pracy
Menu odwzorowuje podział na czynności, nie na tabele w bazie. Sekcja awizacji obsługuje bieżący ruch, kartoteki trzymają dane stałe, informacje zawierają zestawienia i raporty, administracja odpowiada za konta i uprawnienia.
Podział ten wygląda oczywiście i bywa łamany w aplikacjach rozwijanych latami, gdzie nowe funkcje trafiają tam, gdzie akurat było miejsce. Skutkiem jest menu, w którym operator szuka ustawienia kalendarza w trzech miejscach. Trzymanie się granic między obszarami jest tańsze niż późniejsze porządkowanie nawigacji.
| Sekcja | Co zawiera | Kto korzysta najczęściej |
|---|---|---|
| Awizacje | Zgłoszenia bieżące, kalendarze, transporty na bramie | Dyspozytura, ochrona, magazyn |
| Kartoteki | Kontrahenci, przewoźnicy, magazyny, skorowidze | Dyspozytura i administrator |
| Informacje | Zestawienia, raporty, historia wizyt | Kierownik i analityka |
| Administracja | Konta, role, uprawnienia, szablony powiadomień | Administrator |
Ten sam adres, inny widok
Zawartość menu buduje się z uprawnień roli, a nie z ukrywania pozycji po stronie przeglądarki. Operator na bramie po zalogowaniu widzi transporty oczekujące na wjazd i formularz rejestracji pojazdu nieplanowanego. Reszty sekcji nie ma w jego menu, bo nie ma do nich dostępu.
Rozwiązanie to ma konsekwencję przy wdrożeniu: nie trzeba przygotowywać osobnych instalacji dla różnych grup użytkowników. Jedna aplikacja obsługuje wszystkie role, a różnice sprowadzają się do konfiguracji. Zasady nadawania uprawnień opisuje strona o architekturze oprogramowania YMS.
Ukrycie pozycji menu nie jest ograniczeniem dostępu. Jeżeli zakres danych nie jest filtrowany po stronie serwera, użytkownik dotrze do nich inną drogą, a schowana pozycja daje wyłącznie złudzenie kontroli.
Sekcja kartotek jako podstawa pozostałych
Dane stałe zebrane w jednym obszarze obsługują wszystkie pozostałe. Kalendarz awizacji korzysta z definicji magazynu i jego godzin pracy. Formularz zgłoszenia korzysta ze skorowidzów rodzajów transportu i nośników logistycznych. Powiadomienia korzystają z szablonów i z danych kontaktowych kontrahenta.
- Kontrahenci i przewoźnicy - podmioty, do których odwołują się zgłoszenia identyfikatorem, nie nazwą.
- Magazyny i obiekty - lokalizacje z bramami, rampami i kalendarzem pracy.
- Kalendarze - definicje siatek okien wraz z algorytmem ich generowania.
- Skorowidze - słowniki rodzajów transportu, flag wizyt i nośników.
Zmiana w kartotece działa natychmiast we wszystkich obszarach, bo nie jest kopiowana. Nowy rodzaj transportu dopisany w skorowidzu pojawia się w formularzu zgłoszenia bez wdrażania nowej wersji aplikacji.
Wyszukiwanie zamiast klikania w menu
Przy kilkunastu pozycjach menu nawigacja przez kolejne poziomy przestaje być najszybszą drogą. Operator szukający konkretnego zgłoszenia korzysta z wyszukiwania po numerze rejestracyjnym albo po kontrahencie, a nie z przechodzenia przez sekcje.
Wyszukiwanie musi przy tym obsługiwać fragment, bo tablica bywa podana niepełnie, a nazwa firmy zapisana na kilka sposobów. Sposób pracy w module zgłoszeń opisuje strona o awizacji dostawy, a widoki kalendarza - materiał o kalendarzach awizacji.
Elementy obecne na każdym ekranie
Górny pasek niesie trzy informacje niezależne od otwartej sekcji: kto jest zalogowany, do którego obiektu ma dostęp oraz powiadomienia wymagające uwagi. Ostatni element bywa pomijany, a to on decyduje, czy dyspozytor zauważy zgłoszenie czekające na akceptację dłużej niż ustalony czas.
Drugim stałym elementem jest przycisk zapisu i anulowania w formularzach, umieszczony zawsze w tym samym miejscu. Brzmi to trywialnie, dopóki nie chodzi o operatora, który wykonuje tę czynność kilkadziesiąt razy na zmianie, czasem w rękawicach.
Praca na urządzeniu przenośnym
Ten sam interfejs obsługiwany z telefonu wymaga innego układu, a nie pomniejszonej wersji widoku biurowego. Zamiast pełnego menu wydziela się wąskie ścieżki dla zadań terenowych: potwierdzenia przyjazdu, okazania dokumentu i zgłoszenia opóźnienia.
Rozwiązanie na urządzenie przenośne opisuje strona o oprogramowaniu do awizacji na Android, a wariant bez logowania - materiał o przepustce elektronicznej z kodem QR. Obsługę bramy z poziomu aplikacji opisuje z kolei strona o stanowisku ochrony.
Praca na listach
Większość ekranów to zestawienia, a nie formularze. Sposób pracy z nimi przesądza o tym, ile czasu zajmuje codzienna obsługa, więc kilka zachowań powtarza się w całej aplikacji niezależnie od sekcji.
Sortowanie po kliknięciu nagłówka, filtrowanie nad kolumną i zapamiętanie ostatnio użytych ustawień dla danego użytkownika pokrywają większość potrzeb. Ostatni element bywa pomijany, a to on decyduje, czy operator wykonujący tę samą czynność trzydzieści razy dziennie ustawia widok od nowa przy każdym wejściu.
Operacje zbiorcze wykonywane na zaznaczonych wierszach zdejmują konieczność otwierania pojedynczych rekordów. Wydruk zestawienia, wysyłka powiadomień i zmiana statusu grupy transportów to czynności, które w wariancie pojedynczym zajmują kwadrans, a zbiorczo kilkanaście sekund.
Eksport do arkusza pozostaje przy tym potrzebny mimo istnienia raportów. Analityk przygotowujący zestawienie niestandardowe i tak będzie je filtrował po swojemu, więc wymuszanie pracy wyłącznie w gotowych widokach kończy się przepisywaniem danych ręcznie.
Formularze i sprawdzanie danych
Formularz zgłoszenia jest miejscem, w którym powstaje jakość całego rejestru. Pola wymagane oznaczone z góry, licznik uzupełnionych pozycji i podpowiedzi ze słowników skracają wypełnianie i zmniejszają liczbę zgłoszeń wracających do poprawy.
Podpowiedź ze słownika działa przy tym lepiej niż pole tekstowe nawet tam, gdzie wartości jest kilkadziesiąt. Kontrahent wybrany z listy niesie identyfikator, wpisany ręcznie niesie ciąg znaków, który po roku występuje w czterech wariantach zapisu i wymaga scalania.
Sprawdzanie danych w przeglądarce służy wygodzie użytkownika, a nie ochronie rejestru. Reguły przesądzające o spójności, jak dostępność okna czy limit jednostek ładunkowych, działają po stronie bazy, bo zgłoszenia przychodzą również z importu. Mechanizm ten opisuje strona o kalendarzu rezerwacji wobec arkusza.
Osobnym przypadkiem są pola uzupełniane później. Numer rejestracyjny bywa nieznany w chwili rezerwacji, więc formularz powinien dopuszczać jego dodanie do ustalonego progu przed oknem, zamiast blokować zapis całego zgłoszenia. Komplet wymaganych danych zbiera strona o danych do awizacji.