Wybór daty na stronie: kalendarz nie zawsze pomaga

Chcesz wpisać datę z protokołu: 18 lutego 2021. Strona otwiera kalendarz na październiku 2026. Przed tobą kilkadziesiąt kliknięć w strzałkę, chyba że odkryjesz ukryty wybór roku. Kalendarz wygląda schludnie. Podróż do przeszłości ma już mniej uroku.

Ta sama kontrolka może świetnie pomóc komuś, kto wybiera wolny wtorek na wizytę w pracowni. Różnica wynika z zadania: pierwsza osoba zna odpowiedź, druga dopiero jej szuka. Wybór sposobu podawania daty zacznij od tego rozróżnienia, zanim powstanie projekt małego okienka z trzydziestoma numerami.

Trzy pytania, które przypadkiem wyglądają tak samo

W fikcyjnym serwisie wyposażenia do pracowni klient zgłasza niesprawny stół roboczy. Podaje dzień zauważenia usterki, orientacyjny okres zakupu i proponowany termin odbioru. Projektant mógłby użyć trzech identycznych pól. Każde ma przecież zawierać datę. Tyle że odpowiedzi powstają w zupełnie inny sposób.

Dzień zauważenia problemu klient pamięta albo sprawdza w notatce. Okres zakupu zna z grubsza: wiosna ubiegłego roku. Termin odbioru musi dopasować do dostępności serwisu i własnego planu. Jedno narzędzie może zmusić go kolejno do zbędnego szukania, wymyślenia dokładności oraz zgadywania, czy kliknięty dzień jest rzeczywiście dostępny.

GOV.UK zaleca komponent Date input do dat już znanych lub łatwych do sprawdzenia. Jego przykład rozdziela dzień, miesiąc i rok. To użyteczny punkt odniesienia przy przepisywaniu informacji; sama obecność daty w formularzu nie przesądza jeszcze o potrzebie kalendarza.

Zapytaj właściciela procesu, jakiej dokładności potrzebuje do następnej decyzji. Jeśli orientacyjny okres wystarcza do skierowania zgłoszenia do odpowiedniej osoby, żądanie konkretnego dnia wytworzy pozornie precyzyjne dane. Pierwszy stycznia może wtedy oznaczać po prostu „musiałem coś wybrać”. W zestawieniu zostanie dokładna data; zniknie informacja, że klient ją zgadywał.

Ułóż osobne przykłady odpowiedzi dla każdego pytania. Dla pierwszego: „18 lutego 2021”. Dla drugiego: „około wiosny 2025”. Dla trzeciego: „wtorek 3 listopada, odbiór między 10 a 12”. Zobaczysz od razu, że trzeci wybór zawiera także przedział czasu i obietnicę organizacyjną. Nie da się jej uczciwie zamknąć w samym numerze dnia.

Dla przybliżonego okresu zaprojektuj osobną odpowiedź, na przykład rok z możliwością wskazania, że miesiąc jest nieznany. Nie zapisuj jej wewnętrznie jako dokładnego pierwszego dnia miesiąca, jeśli później ktoś odczyta tę wartość jako fakt. W podsumowaniu nadal powinno być widoczne „około”, a osoba obsługująca zgłoszenie powinna znać tę samą granicę dokładności.

Takie rozpoznanie jest częścią projektowania formularza z jasnym celem pól. Etykieta ma wyjaśniać, o którą datę chodzi. „Data” przy trzech podobnych kontrolkach pozostawia klientowi rozstrzygnięcie, które powinno należeć do projektu.

Znana data powinna dać się po prostu wpisać

Przy przepisywaniu daty z dokumentu liczy się krótka droga od zapisu do poprawnej wartości. Możesz zaprojektować osobne pola albo jedno pole z czytelną podpowiedzią. Sprawdź konkretne próby z klawiaturą, wklejaniem i poprawianiem środka wartości. Nie oceniaj wygody wyłącznie po tym, jak szybko autor interfejsu wpisuje własny przykład.

Podpowiedź formatu pokaż przed popełnieniem błędu i pozostaw ją przy polu podczas wpisywania. Zapis „03/04/2026” nie dla każdego oznacza ten sam dzień. Jeśli serwis obsługuje kilka języków, uzgodnij kolejność części, nazwy miesięcy i przykład dla każdej wersji. Odbiór wersji językowych strony powinien objąć też ten mały fragment działania.

Po poprawnym przyjęciu wartości możesz pokazać ją słownie, na przykład „4 marca 2026”, jeśli taki jest uzgodniony sens wpisu. Człowiek ma wtedy szansę zauważyć pomyłkę przed wysłaniem. Nie zamieniaj jednak części daty w trakcie pisania w sposób, który utrudnia poprawienie poprzedniego znaku.

Rozróżnij błąd zapisu od daty niemożliwej i od daty niedozwolonej w danej usłudze. „31 kwietnia” wymaga poprawienia dnia. Poprawna data sprzed rozpoczęcia obsługi wymaga wyjaśnienia zakresu. Ogólne „nieprawidłowa wartość” zmusza do eksperymentowania, chociaż system zna przyczynę odrzucenia.

Po odrzuceniu daty zachowaj wpisaną wartość, aby można było poprawić jeden element. Jeśli rozdzielasz ją na części, komunikat powinien dotyczyć całego pytania, a wskazanie poprawki prowadzić do właściwej części. Przy błędzie dnia nie każ ponownie wybierać roku.

W próbie użyj daty z końca miesiąca, popraw sam miesiąc i sprawdź wynik: zmiana z marca na kwiecień może pozostawić niemożliwy trzydziesty pierwszy dzień. System powinien umożliwić świadomą korektę, zamiast bez pytania przesunąć zgłoszenie na inny termin.

Nie wymagaj zera przed jednocyfrowym dniem tylko dla wyglądu, jeżeli rozwiązanie może przyjąć oba zapisy. Podobne drobiazgi ustala się w projekcie i w odbiorze. Grafik widzi równy układ, klient widzi kolejną przeszkodę między sobą a zgłoszeniem, które miał już wysłać.

Gdy człowiek szuka dnia, pokaż powody wyboru

Przy umawianiu odbioru klient potrzebuje zestawić terminy. Kalendarz może pomóc zobaczyć dni tygodnia i odległość między datami. Przy kilku dostępnych możliwościach prostsza może być krótka lista: wtorek rano, czwartek po południu, następny poniedziałek. Nie ukrywaj trzech odpowiedzi w narzędziu do przeglądania całego roku.

Zaznaczenie daty powinno mieć inne znaczenie niż wskazanie dzisiejszego dnia. Oddziel też dzień niedostępny od dnia, którego jeszcze nie sprawdzono. Szary kolor sam nie wyjaśnia, czy termin jest zajęty, poza zakresem usługi czy dopiero czeka na pobranie informacji. Gdy po zmianie miesiąca trwa pobieranie dostępności, pokaż oczekiwanie zamiast pozostawiać stare dni jako aktualną ofertę.

Dostępność dnia i rezerwacja miejsca są osobnymi etapami. Wybór wtorku może dopiero otwierać godziny, a wybór godziny nadal wymagać potwierdzenia. Przy rejestracji grupy na warsztat dochodzi jeszcze liczba uczestników. Wolny termin dla jednej osoby nie przesądza, czy zmieści się cała grupa.

W podsumowaniu nazwij dokładnie wybrany wariant. „3 listopada, 10:00–12:00, odbiór w pracowni przy ulicy Słonecznej” daje możliwość kontroli. Samo „3 listopada” pozostawia kilka niewidocznych ustaleń. Jeśli zmiana daty usuwa wybraną godzinę, pokaż tę konsekwencję i pozwól wybrać ją ponownie.

Przy braku wolnych dni określ dalszą drogę. Klient może zobaczyć pierwszy późniejszy termin, zmienić rodzaj usługi albo wysłać pytanie do obsługi — zależnie od rzeczywistej oferty. Sam pusty kalendarz nie wyjaśnia, czy skończyły się miejsca, wybrano zły okres czy dane chwilowo się nie wczytały. To trzy różne komunikaty i trzy różne działania.

W usługach obejmujących kilka stref czasowych dopisz, według jakiego miejsca podano godzinę. Nie wprowadzaj takiego objaśnienia do każdego lokalnego formularza z przyzwyczajenia. Ma rozwiązywać rzeczywistą niepewność, na przykład przy zdalnym spotkaniu z osobą za granicą, a nie dekorować ekran terminologią.

Podgląd dnia nie musi jeszcze oznaczać wyboru

Ustal, co robi otwarcie kalendarza bez wcześniejszej wartości. Można pokazać bieżący miesiąc albo pierwszy okres z dostępnymi terminami. To różne decyzje. Pusta kontrolka po samym otwarciu nie powinna cichaczem przyjmować dzisiejszej daty, jeśli człowiek niczego nie zatwierdził.

Podobnie potraktuj anulowanie. Kto otwiera kalendarz, zagląda do następnego miesiąca i naciska „anuluj”, powinien rozpoznać wcześniejszy wybór po powrocie. Jeśli wybór obowiązuje od razu, pokaż tę regułę w działaniu interfejsu i nazwij przycisk zamykający okno zgodnie z jego rolą. „Zatwierdź” sugeruje, że wcześniejsze wskazanie można jeszcze odrzucić.

To ten sam rodzaj rozróżnienia, który pojawia się przy podpowiedziach prowadzących do wyboru konkretnego rekordu. Zobaczenie propozycji, wskazanie jej klawiaturą oraz ostateczne przyjęcie wartości nie muszą być jednym zdarzeniem. Projekt powinien określić każdy z tych momentów.

Przykład okna wyboru daty W3C WAI jest materiałem ilustracyjnym, a nie gotowym komponentem produkcyjnym. Autorzy wskazują potrzebę testów z technologiami asystującymi przed użyciem. Skopiowanie wyglądu przykładu nie potwierdza, że własna kontrolka działa z klawiaturą i czytnikiem ekranu.

Na małym ekranie otwórz kalendarz po przewinięciu formularza. Sprawdź, czy nadal widać pytanie i sposób zamknięcia. Klawiatura ekranowa, podpowiedź błędu i rozwinięta kontrolka mogą razem zasłonić wynik. Próba na samym pustym polu nie pokaże tego stanu, więc przygotuj także formularz z zachowanymi odpowiedziami i błędem obok daty.

W próbie bez myszy sprawdź wejście do kontrolki, przejście między dniami, zmianę miesiąca, zatwierdzenie i zamknięcie. Po wyjściu człowiek powinien odnaleźć pole z wynikiem. Samo doprowadzenie do wybranego kwadracika nie kończy zadania: trzeba jeszcze wiedzieć, jaka wartość została przyjęta i gdzie można ją poprawić.

Czas upływa także poza ekranem

Słowo „jutro” jest wygodne w chwili wyboru. Po otwarciu szkicu następnego dnia oznacza już coś innego. Jeśli klient wybrał konkretny termin, zachowaj jego rzeczywistą datę i pokaż ją po powrocie. Etykieta względna może ją uzupełniać, ale nie powinna samodzielnie określać zobowiązania.

Zakres wymaga jeszcze jednego ustalenia. Przy wyborze kilku dni wyjaśnij, czy ostatni dzień jest objęty usługą, czy oznacza moment zakończenia i zwrotu. Zaznaczony pas kalendarza wygląda jednoznacznie, dopóki dwie strony nie spróbują przyjechać tego samego ranka po ten sam sprzęt. W podsumowaniu można pokazać datę rozpoczęcia i zakończenia z nazwą ich roli.

Gdy początek zakresu przesunie się za jego koniec, pokaż zależność między obiema wartościami. Możesz poprosić o ponowny wybór zakończenia albo zaproponować zachowanie poprzedniej długości, jeśli taki sposób ma sens w usłudze. Nie ukrywaj automatycznej zmiany w drugim polu: klient powinien ją zauważyć przed zatwierdzeniem.

W dłuższym procesie dostępność może się zmienić między wyborem a wysłaniem formularza. Projekt potrzebuje komunikatu dla konkretnego wyniku ponownego sprawdzenia. Jeśli wybrana godzina zniknęła, zachowaj pozostałe dane i poproś o nową godzinę. Nie odsyłaj do pustego formularza, jakby cała wcześniejsza praca była tylko rozgrzewką.

Jeżeli serwis proponuje termin automatycznie, sprawdź również źródło i aktualność ograniczeń. Sam wygodny kalendarz nie naprawi propozycji sprzecznej z godzinami pracy. To osobny temat oceny wykonalności planowania kalendarza przez AI: propozycja ma wynikać z rzeczywistych reguł i danych.

Oddaj do odbioru daty, które ktoś naprawdę poda

Do projektu dołącz kilka krótkich zadań: przepisanie starej daty, wybranie pierwszego wolnego terminu, poprawienie miesiąca oraz powrót do szkicu kolejnego dnia. Zamiast prowadzić osobę po przyciskach, podaj jej sytuację i oczekiwany rezultat. Zobaczysz, czy rozumie pytanie, a nie tylko potrafi obsłużyć pokazany mechanizm.

Sprawdź też brak dokładnej odpowiedzi. Klient, który pamięta wyłącznie rok, powinien mieć drogę odpowiadającą wymaganej dokładności. Jeśli proces rzeczywiście wymaga dnia, wyjaśnij, skąd może go ustalić lub jak uzyskać pomoc. Nie oceniaj formularza tylko na podstawie przykładów, w których wszystkie dane idealnie pasują do pól.

W projekcie strony i jej interakcji w Aeneia Design takie przypadki pomagają ustalić zakres pracy przed wdrożeniem. Rezultatem powinien być wybór kontrolki wraz z zachowaniem po błędzie i po powrocie. Obraz kalendarza bez tych ustaleń pokazuje jedynie najbardziej fotogeniczną chwilę całego procesu.

Na końcu zapytaj osobę testującą, jaki termin właśnie wybrała i co ma się w nim wydarzyć. Powinna umieć odpowiedzieć na podstawie widoku, który otrzymała. Jeśli pamięta tylko, że kliknęła niebieską środę, projekt potrzebuje jeszcze jednej korekty.