Odwiedzający otwiera niewielkie okno, aby sprawdzić jeden szczegół. Nagle strona w tle jest niedostępna, przycisk zamknięcia trudno znaleźć, a pisana wiadomość zniknęła. Przerwa może wyglądać elegancko, lecz doświadczenie stało się kruche. Użyteczne okno dialogowe potrzebuje powodu, by przerwać pracę, oczywistego wyjścia i przemyślanego powrotu do już rozpoczętego zadania.
Najpierw zapytaj, czy okno jest potrzebne
Zanim narysujesz nakładkę, zapisz, jaką decyzję pomaga podjąć. Jeśli odpowiedź brzmi jedynie „przeczytać trochę więcej”, spróbuj umieścić informację obok odpowiedniej opcji. Szczegóły dostawy mogą znaleźć się przy jej wyborze. Krótkie wyjaśnienie może rozwinąć się pod etykietą. Takie rozwiązania pozwalają jednocześnie widzieć pytanie i odpowiedź.
Okno dialogowe warto rozważyć wtedy, gdy krótka, odrębna decyzja rzeczywiście wymaga uwagi przed kontynuacją bieżącego zadania. Dłuższe wyjaśnienia, porównania i formularze wieloetapowe zasługują na własną stronę. Podczas przeglądu projektu porównaj oba rozwiązania z treścią o rzeczywistej długości, a nie z pustym prostokątem.
Nadaj przerwie jasny cel i zapewnij wyjście
Użyj nagłówka nazywającego zadanie oraz przycisków opisujących rezultat. „Odrzuć wiadomość” jest jaśniejsze niż „Tak”, gdy ktoś ryzykuje utratę szkicu. Zachowaj zrozumiałość drugorzędnych opcji, zamiast powiększać preferowane działanie i przygaszać wszystkie alternatywy. Zamknięcie zaproszenia powinno być zwyczajnym gestem, nie odmową negocjacji.
MDN rozróżnia modalne showModal(), które dezaktywuje tło, od niemodalnych show() lub open. Wzorzec modalny WAI utrzymuje fokus wewnątrz, cyklicznie obsługuje Tab, zamyka okno klawiszem Escape i zwykle przywraca fokus elementowi otwierającemu. Wymaga też dostępnej nazwy i zaleca widoczny przycisk zamknięcia.
Nasz poradnik o nawigacji klawiaturą i widocznym fokusie daje szerszy kontekst do oceny drogi otaczającej tę przerwę.
Chroń już wykonaną pracę
Wyobraź sobie fikcyjne zapytanie o projekt. Ktoś napisał akapit, otwiera notatkę o przygotowaniu briefu, a następnie wraca do wiadomości. Przed implementacją ustal, co stanie się z tym akapitem po zamknięciu notatki, zamknięciu głównego formularza lub próbie opuszczenia strony. To różne zdarzenia i nie muszą usuwać tych samych informacji.
Preferuj zachowanie szkicu podczas bieżącej interakcji. Jeżeli wyjście go usunie, wyjaśnij konsekwencję i daj jasny wybór. Nie informuj „zapisano”, jeśli zapis faktycznie się nie udał. Gdy wysłanie zawiedzie, zachowaj użyteczne dane i pomóż osobie wrócić do zadania, jak opisujemy w artykule o błędach formularzy, które pomagają kontynuować.
Sprawdź telefon z otwartą klawiaturą
Wyśrodkowana makieta desktopowa nie odpowie na pytania dotyczące telefonu. Otwórz najdłuższą wersję na małym telefonie, aktywuj ostatnie pole i wyświetl klawiaturę. Czy użytkownik widzi, co edytuje, i może dotrzeć do następnego działania bez niewygodnego szukania podczas przewijania?
Sprawdź także dłuższe przetłumaczone etykiety i powiększony tekst. Ustal, który obszar powinien się przewijać, i upewnij się, że po zamknięciu strona nie przeskakuje w niezwiązane miejsce. Jeśli kompaktowe okno zamienia się w ciasną stronę wewnątrz strony, przemyśl format zamiast zmniejszać wszystko, by się zmieściło.
Przetestuj pełną drogę, także niedokończoną
Zacznij w połowie strony. Otwórz okno, przeczytaj jego cel, wpisz realistyczny szkic, zajrzyj do dodatkowej notatki i wróć. Następnie wyjdź bez wysyłania i otwórz je ponownie. Powtórz na telefonie i z klawiaturą. Poproś osobę nieznającą projektu, by przed wybraniem każdego wyjścia wyjaśniła, jakiego działania się po nim spodziewa.
Zapisz rozbieżności między oczekiwaniem a wynikiem. Niezawodne okno dialogowe uzasadnia swoją obecność, pomagając wykonać małe zadanie bez naruszania szerszej drogi użytkownika.