Ładny panel, wczorajsze dane. Jak pokazać aktualność bez udawania czasu rzeczywistego

Daria naciska „Odśwież”. W fikcyjnym panelu odbioru przesyłek pojawia się napis „Dane sprzed chwili”, ale liczba paczek nadal pochodzi z porannego zestawienia. Zmieniła się godzina pobrania widoku. Zegar na ekranie jest punktualny; informacja potrzebna do zaplanowania odbioru nie zrobiła się od tego młodsza.

Projekt panelu powinien rozdzielać czas danych, czas ich dotarcia i stan ostatniej próby odświeżenia. Nie każdy szczegół musi stale zajmować nagłówek. Użytkownik powinien jednak wiedzieć, na jaki stan patrzy i czy wolno na nim oprzeć następny krok. Animowana strzałka nie potwierdza nowego pomiaru.

Jedna liczba ma więcej niż jeden czas

Daria koordynuje odbiór gotowych paczek z kilku pracowni. W naszym wymyślonym obiegu jedna z nich przekazuje zestawienie stanu z dziewiątej. System przyjmuje je dwanaście minut później, a Daria otwiera panel o 9:40. Każda godzina opisuje inne zdarzenie. Etykieta „aktualizacja 9:40” nie daje odpowiedzi, ile paczek było gotowych właśnie wtedy.

Podstawowy opis wartości może brzmieć: „7 paczek gotowych według stanu na 9:00”. W szczegółach pojawia się informacja o przyjęciu zestawienia o 9:12. Jeśli o 9:41 ponownie odczytamy tę samą wersję, można pokazać „Ostatnie sprawdzenie 9:41; bez nowszego zestawienia”. Daria widzi, co się udało i czego nadal nie potwierdzono. To propozycja zachowania interfejsu, nie opis istniejącej integracji.

Najpierw ustal z osobą odpowiedzialną za dane, jakie czasy są rzeczywiście dostępne. Nie projektuj etykiety „stan na” z wartości, która oznacza jedynie moment importu. Jeżeli nie znamy czasu przygotowania zestawienia, trzeba pokazać tę granicę. Można opisać odebrany plik i jego datę dostarczenia, ale nie dopisywać nieznanej chwili obserwacji.

Różnice między etapami występują także w gotowych narzędziach. Microsoft opisuje model Power BI w trybie Import jako kopię danych z określonego momentu. Zapytania raportu korzystają z zaimportowanych tabel, a pobranie zmian ze źródła wymaga odświeżenia modelu. Odczytanie widoku i odświeżenie modelu są zatem różnymi czynnościami.

Nie trzeba przenosić tej architektury do projektu każdego panelu. Własny wykonawca powinien wyjaśnić drogę danych, a projektant przełożyć ją na uczciwą obietnicę na ekranie. Jeśli przycisk tylko ponawia odczyt dostępnego zestawienia, jego komunikat nie może oznajmiać sprawdzenia całego źródła. Jeśli uruchamia dłuższe przygotowanie nowego zestawu, użytkownik powinien rozpoznać trwającą czynność.

W przewodniku Grafany po pulpitach integracji odświeżenie ponawia zapytania, a pojawienie się danych zależy od ich zbierania. To dwa etapy. Wniosek projektowy dla Darii jest prosty: częstsze pytanie o ten sam dostępny stan nie musi dostarczyć nowszej obserwacji. Interfejs powinien umieć pokazać udany odczyt bez nowej wartości.

Sama niezmieniona liczba również nie oznacza nieudanego odświeżenia. Pracownia mogła rzeczywiście nadal mieć siedem paczek. Potrzebny jest stan operacji i oznaczenie zestawienia, a nie próba zgadywania po różnicy liczb. Gdy nowe dane mają taką samą wartość, czas ich przygotowania może się zmienić zgodnie z rzeczywistym zdarzeniem. Gdy ponownie odczytano starą kopię, nie zmieniaj jej czasu.

Zaprojektuj nazwę okresu osobno od chwili aktualności. „Dzisiaj” może oznaczać sumę paczek przygotowanych od północy, a nie liczbę aktualnie oczekujących na odbiór. Wtedy odebranie części paczek nie musi zmniejszać tego wskaźnika. Daria potrzebuje określonej informacji do planu trasy. Jeśli panel pokazuje inną miarę, trzeba zmienić opis lub dobrać właściwy wynik, zamiast dopracowywać samą datę.

Przy projektowaniu wykresów marki podobnie ustala się miarę i podpisy. Tutaj dochodzi ruchomy stan ich podstawy. Etykieta czasu powinna należeć do tej samej reguły komponentu co liczba, jednostka i status. Nie może być dekoracją aktualizowaną zawsze przy odmalowaniu ekranu.

Brak, opóźnienie i błąd potrzebują różnych odpowiedzi

Załóżmy, że pracownia ma przekazywać zestawienie co pół godziny, ale o 10:15 panel nadal pokazuje stan z dziewiątej. To reguła przyjęta wyłącznie w przykładzie. Sama starsza wartość nie mówi jeszcze, czy nic się nie zmieniło, dostawa się opóźnia, czy system nie zdołał jej odczytać. Projekt powinien zachować rozpoznane fakty i wskazać właściwy stan.

Jeśli źródło potwierdziło nowe zestawienie z zerem paczek, pokaż zero z jego czasem. Jeśli nie otrzymano zestawienia, nie podstawiaj zera. Jeżeli pobranie się nie udało, komunikat powinien opisać błąd odczytu. Można pozostawić poprzednią wartość jako ostatni znany stan, ale z widocznym ostrzeżeniem i właściwą godziną. Liczba bez tego kontekstu mogłaby skłonić Darię do wysłania auta pod niewłaściwy adres.

Rozróżnij pierwsze otwarcie i kolejne nieudane pobranie. Przy pierwszym nie mamy jeszcze wartości do pokazania. Przy następnym możemy mieć wcześniejszy potwierdzony stan. Ten sam pusty prostokąt nie wyjaśnia obu sytuacji. Projekt komponentu powinien przewidzieć je osobno, wraz z dostępną czynnością: ponowienie odczytu, wskazanie źródła problemu albo kontakt zgodny z rzeczywistym procesem.

Nie usuwaj poprawnej liczby z sąsiedniej karty dlatego, że inna pracownia nie przekazała danych. Jednocześnie nie pokazuj sumy jako kompletnej, gdy obejmuje tylko część pracowni. W nagłówku można oznaczyć zakres, a przy nieaktualnej karcie podać jej stan. Daria powinna rozpoznać, którą część planu może przygotować i który punkt wymaga potwierdzenia inną drogą.

Szczególny przypadek to dane częściowe. System odebrał zestawienie dwóch pracowni z trzech, ale nie zna wyniku trzeciej. Liczba „14 paczek” może być poprawną sumą odebranych pozycji, lecz nie pełną sumą dla całej trasy. Etykieta „14 paczek; dane z 2 spośród 3 pracowni” wyjaśnia więcej niż mały symbol informacji przy nagłówku. Użytkownik nie powinien odkrywać niekompletności dopiero po rozpoczęciu działania.

Jeśli na takim wejściu pracuje model, kontrola alertów i braków danych jest osobnym zadaniem. Projektant panelu powinien poznać możliwe stany i nadać im czytelną postać. Nie potwierdzi jakości pomiaru samym doborem ostrzegawczej barwy. Informacja o zakresie i czasie musi pozostać dostępna także bez rozpoznania koloru.

Dla starzenia się danych ustal regułę odpowiadającą zadaniu. Dzienna statystyka nie musi ostrzegać po minucie. Stan paczek do pilnego odbioru może wymagać częstszego potwierdzenia. Projektant nie powinien wybierać granicy na podstawie miejsca, jakie zostało na etykietę. Potrzebne są oczekiwania właściciela procesu i faktyczna możliwość dostarczania danych.

PatternFly w wytycznych znacznika czasu uwzględnia lokalny format, strefę i dokładniejszy zapis przy czasie względnym. Dla panelu warto przełożyć to na regułę: „15 minut temu” daje szybki obraz wieku, a konkretna data i godzina pozwalają odnieść wartość do zdarzenia. Zapis powinien opisywać właściwy etap obiegu, nie przypadkowo wybraną datę.

Czas względny musi starzeć się razem z pozostawionym otwartym widokiem. Etykieta „przed chwilą” nie może pozostać taka przez całe przedpołudnie. Gdy użytkownik wraca do karty po przerwie, potrzebuje widocznego stanu aktualności. Samo ponowne wyświetlenie panelu nie daje podstawy do przestawienia czasu danych na bieżący.

Dokładny czas powinien być dostępny także osobie, która nie używa myszy. Nie chowaj jedynej daty w opisie widocznym wyłącznie po najechaniu. Przy dłuższej przerwie godzina potrzebuje dnia, bo samo „9:00” nie rozróżnia dzisiejszego i wczorajszego zestawienia. W obiegu obejmującym różne strefy pokaż, której dotyczy zapis. Nie porównuj dwóch lokalnych godzin tak, jakby miały wspólny punkt odniesienia.

Przy projekcie panelu w Aeneia Design można opracować takie stany kart, treść komunikatów i zachowanie odświeżenia. Punktem wyjścia jest wyjaśniona droga danych oraz zadanie odbiorcy. Makieta powinna pokazywać również niepełny i opóźniony wynik, bo właśnie wtedy etykiety przestają być drobnym detalem pod dużą liczbą.

Przy odświeżeniu zachowaj sens całego widoku

Przycisk powinien pokazać, czy odczyt trwa i jaki był wynik. Jeśli ponowne kliknięcie niczego nie przyspiesza, nie pozostawiaj użytkownika z wrażeniem, że kolejne naciśnięcia są potrzebne. Przy dłuższym przygotowaniu zestawienia zastosuj zachowanie właściwe dla zadania, do którego można wrócić. Krótka animacja nie powinna bez końca udawać kilku sekund oczekiwania.

Po udanym odświeżeniu zachowaj wybór użytkownika, jeśli nadal ma sens. Daria może oglądać jedną pracownię albo określoną trasę. Powrót do wszystkich danych pod niezmienionym nagłówkiem wprowadzi inną pomyłkę niż nieaktualność. Filtr, wartości i oznaczenie czasu muszą odpowiadać temu samemu zakresowi, także w komunikacie podsumowującym operację.

Sprawdź w projekcie powrót odpowiedzi po szybkiej zmianie pracowni. Daria najpierw wybiera jedną, a przed zakończeniem pobrania przechodzi do drugiej. Jeśli wcześniejsza odpowiedź dotrze później, nie może pojawić się pod nagłówkiem nowego wyboru. Przy błędzie również nie zostawiaj dawnych siedmiu paczek jako wartości nowej pracowni. Zachowanie ostatniego znanego stanu ma sens tylko wtedy, gdy odbiorca widzi, do którego obiektu on należy.

Gdy odświeżenie zmienia kolejność pozycji, zadbaj o punkt powrotu. Po przestawieniu kart wybrana pracownia powinna pozostać rozpoznawalna. Nowa pozycja w rankingu nie może po cichu zmienić obiektu, którego szczegóły użytkownik ogląda. Użytkownik ma rozpoznać zmianę danych, a nie ponownie odszukiwać obiekt, z którym pracował. Potrzeba zachowania kontekstu może uzasadniać stabilną kolejność lub widoczne oznaczenie wybranego elementu.

Otwarty szczegół oraz karta zbiorcza również potrzebują uzgodnionej relacji. Jeżeli szczegół pozostał na starej wersji, pokaż ten stan albo odśwież go zgodnie z zaprojektowaną regułą. Nie porównuj na ekranie liczby siedem z nowym zestawieniem pozycji sumującym się do dziewięciu tak, jakby oba widoki opisywały ten sam moment. Znaczenie czasu powinno pozostać widoczne także po przejściu do interaktywnego wykresu.

Przy udostępnieniu widoku trzeba podjąć osobną decyzję: czy odbiorca dostaje bieżący panel, czy zapisany stan? Zrzut ekranu powinien zawierać zakres i właściwą datę, bo nie odświeży się razem ze źródłem. Link może natomiast otworzyć już nowszą wersję. Oba materiały mają inne zastosowanie, choć można nadać im ten sam tytuł.

Podobnie działa eksport danych. Pobierany plik powinien odpowiadać wybranemu zakresowi i mieć zrozumiałe oznaczenie stanu. Jeśli eksport jest przygotowywany później niż widok, wyjaśnij, czy utrwala wcześniejszy zestaw, czy pobiera nowy. Napis „pobrano o 10:20” nie zastępuje informacji, do jakiego czasu odnoszą się liczby.

Do odbioru przygotuj kilka odmiennych stanów tego samego zadania Darii: nowy kompletny wynik, udany odczyt bez nowszej wersji oraz brak jednej pracowni. Osoba przechodząca przez projekt powinna umieć rozpoznać stan danych i następny krok. Nie wystarczy, że znajdzie przycisk z okrągłą strzałką. Zapisz także, jak rozumie etykietę czasu — to właśnie jej znaczenie próbujemy sprawdzić.

W naszym scenariuszu Daria potrafi teraz oddzielić siedem paczek potwierdzonych rano od nieznanego bieżącego stanu. Może zaplanować część trasy i uzyskać brakujące potwierdzenie według zasad obsługi. Panel nie przyspieszył dostawy danych. Przestał natomiast przedstawiać niepewny stan jako świeży fakt, a to pozwala zacząć właściwą pracę.