Usuń, cofnij, odzyskaj: trzy różne chwile w interfejsie

„Cofnij” potrafi zmieścić w sześciu literach dość duże zobowiązanie. Czy przywróci ten sam plik, jego dawny folder, powiązania z projektem i dostęp współpracowników? Czy tylko ponownie pokaże wiersz na ekranie? Przed zaprojektowaniem małego przycisku trzeba wybrać odpowiedź. Etykieta nie może być bardziej odwracalna od działania aplikacji.

W fikcyjnej bibliotece materiałów usuwamy jeden szkic instrukcji. Po chwili okazuje się, że był potrzebny. To prosty początek, ale dalsza droga może obejmować cofnięcie ostatniej czynności, odnalezienie elementu w koszu albo odtworzenie go z pomocą odpowiedniej osoby. Każdy wariant ma inną granicę i inny sposób rozpoznania wyniku.

Nie ustalamy tu, jak długo firma powinna przechowywać dane ani kiedy ma je prawnie usuwać. Projekt interakcji musi odpowiadać uzgodnionemu działaniu systemu. Jego zadaniem jest jasno pokazać możliwy następny krok i tożsamość odzyskanego elementu. Krótkie „Gotowe” nie powinno przykrywać tej różnicy.

Cofnięcie ma odwrócić określoną czynność

Zacznijmy od słowa „usuń”. W jednym miejscu oznacza skasowanie pliku, w drugim zabranie go z kolekcji, w trzecim ukrycie kolumny. Jeśli aplikacja używa tej samej etykiety, odbiorca może oczekiwać niewłaściwego skutku. Powrót elementu na listę i odzyskanie jego treści to nie to samo.

Dla listy zapisanych produktów wystarczy czasem „Usuń z listy”. Nie kasuje to produktu z katalogu. Dla zapisanych widoków tabeli usuwamy konfigurację prezentacji, nie rekordy. Rzeczownik przy czasowniku oszczędza człowiekowi zgadywania, którą warstwę aplikacji właśnie zmienia.

W bibliotece szkic po usunięciu może trafić do kosza, a chwilowy przycisk cofa tę konkretną operację. Przykładowy komunikat brzmi: „Przeniesiono szkic «Montaż półki» do kosza”. Obok widnieje „Cofnij”. Użytkownik rozpoznaje przedmiot oraz skutek bez otwierania osobnego dziennika zmian.

GNOME wskazuje przycisk cofnięcia po destrukcyjnej czynności jako jedno z zastosowań toastu, czyli krótkiego komunikatu w oknie aplikacji. Odróżnia przy tym informację o pojedynczym zdarzeniu od trwającego stanu. To użyteczny wzorzec, ale nie definicja mechanizmu odzyskiwania.

Cofnięcie potrzebuje powiązania z właściwą operacją. Jeśli użytkownik usunął kolejno dwa szkice, samotne „Cofnij” nie powinno wymagać pamiętania, którego dotyczy. Można pokazać dwa rozpoznawalne komunikaty albo wspólny zakres, jeśli aplikacja rzeczywiście potrafi go odwrócić. Nowa czynność nie powinna bez wyjaśnienia zmieniać przedmiotu wcześniej widocznego przycisku.

Rozróżnij także cofnięcie wykonanej czynności od anulowania zamiaru. Jeśli usunięcie dopiero czeka na zapis, „Anuluj” może wycofać oczekującą zmianę. Jeżeli serwer już ją wykonał, potrzebujemy operacji przywracającej. Na ekranie oba warianty mogą wyglądać podobnie, ale komunikat ma odpowiadać rzeczywistemu stanowi. W specyfikacji pokaż, co dzieje się po utracie połączenia, aby zniknięcie wiersza nie zostało automatycznie uznane za potwierdzone usunięcie.

Tak samo nie należy utożsamiać cofnięcia z utworzeniem nowego podobnego pliku. Jeżeli aplikacja przywraca inny rekord pod tą samą nazwą, mogą nie wrócić jego wcześniejsze odsyłacze lub powiązania. Ustal, co ma zachować tożsamość. Dla odbiorcy prosty test brzmi: czy wcześniej zapisany link prowadzi do odzyskanego szkicu zgodnie z przyjętą regułą?

Współdzielona biblioteka dodaje jeszcze pracę innych osób. Po usunięciu szkicu ktoś mógł dołączyć nowy materiał do tego samego projektu. Cofnięcie usunięcia nie powinno przez przypadek przywracać całej biblioteki do starszego stanu i kasować tej późniejszej pracy. Oczekiwanie dotyczy wybranej czynności oraz jej skutków. Szersze odtworzenie wymaga innej decyzji i wyraźnie opisanego zakresu. W próbie warto zachować ten dodatkowy nowy materiał jako punkt kontrolny, który ma pozostać nienaruszony.

W chwili naciśnięcia „Cofnij” pokaż także trwającą czynność, jeżeli wynik nie jest natychmiastowy. Dopiero potwierdzone odzyskanie uzasadnia komunikat sukcesu. Gdy nie ma potwierdzenia, użytkownik musi móc sprawdzić stan. Ponowne kliknięcie nie powinno przypadkiem tworzyć kolejnego elementu ani zmieniać innej operacji.

Nie zakładaj, że każda krótka możliwość reakcji wystarcza każdemu odbiorcy. Osoba może pracować klawiaturą, czytać dłuższą nazwę albo patrzeć akurat na drugą część ekranu. Jeśli przycisk znika, projekt powinien wyjaśniać, jaka droga pozostaje później. Czas widoczności komunikatu oraz czas dostępności odzyskania to odrębne decyzje.

Fluent 2 odradza używanie toastów do koniecznych działań i wskazuje trwalszą powierzchnię, na przykład pasek komunikatu lub okno dialogowe. Nie wynika z tego uniwersalna liczba sekund na cofnięcie. Wybór komponentu musi odpowiadać znaczeniu informacji i sposobowi dotarcia do dalszej czynności.

W projekcie biblioteki kosz może być taką dalszą drogą. Wtedy zniknięcie chwilowego komunikatu nie kończy możliwości odzyskania. Jeśli system nie ma kosza i naprawdę zamyka tę możliwość po określonym czasie, nie opisuj go jak pełnego modelu przywracania. Granica powinna być znana przed działaniem, gdy wpływa na decyzję użytkownika.

W koszu szukamy właściwego obiektu, nie tylko znajomego tytułu

Po przerwie osoba wraca do biblioteki. W koszu znajdują się trzy pliki o nazwie „Montaż półki”. Musi rozpoznać projekt, datę usunięcia, autora albo wersję — zależnie od rzeczywistej pracy. Sama nazwa nie wystarcza do odpowiedzialnego wyboru, choć w demonstracyjnych danych wszystkie tytuły mogły być pięknie unikalne.

Widok kosza powinien pokazać informacje potrzebne do identyfikacji, z zachowaniem uprawnień. Nie trzeba przy tym ujawniać pełnej treści każdego dokumentu. Przydatny bywa podgląd lub rozpoznawalny opis kontekstu. Decyzję o zakresie takich informacji trzeba połączyć z działaniem aplikacji, a nie dodawać dowolne dane wyłącznie dla ułatwienia rozpoznania.

Po wybraniu elementu ustal miejsce przywrócenia. Może to być poprzedni folder albo wskazany cel, jeśli rozwiązanie oferuje taki wybór. Co jednak zrobić, gdy poprzedni folder już nie istnieje? To pytanie o relację elementu z otoczeniem, nie kosmetykę potwierdzenia.

Dokumentacja SharePoint opisuje odtworzenie usuniętego folderu przy przywracaniu znajdującego się w nim elementu. Taki odtworzony folder zawiera przywrócony element. Przywrócenie samego folderu może natomiast objąć jego dawną zawartość. Zakres zależy więc od wybranej czynności.

Nie przenosimy tego zachowania automatycznie do własnej biblioteki. Źródło pokazuje, dlaczego trzeba rozstrzygnąć zależności. Odzyskanie jednej instrukcji nie powinno niejawnie przywracać całego zestawu materiałów, jeśli użytkownik właśnie tego nie zamówił. Jeżeli szerszy skutek jest wymagany przez system, interfejs powinien go wyjaśnić.

W Aeneia Design można zaprojektować tę drogę od wyboru elementu do potwierdzonego miejsca powrotu. Materiałem do pracy są faktyczne reguły aplikacji, przykłady podobnych nazw i zależności. Projekt ekranów oraz komunikatów musi odzwierciedlać mechanizm przywracania uzgodniony z wykonawcą.

Przy przenoszeniu plików między folderami również trzeba nazwać cel i skutek dla współdzielenia. Odzyskanie może zetknąć się z podobną decyzją, ale nie musi być zwykłym przeniesieniem. Nie zakładaj, że obecność pliku w dawnym miejscu samodzielnie potwierdza powrót właściwego dostępu dla wszystkich wcześniejszych współpracowników.

Do ustalenia pozostaje konflikt nazwy. W miejscu docelowym może już istnieć nowy plik o takim samym tytule. Użytkownik potrzebuje rozpoznać obie pozycje i skutek wyboru: zachowanie obu, inna nazwa lub odmowa zgodna z regułą aplikacji. Automatyczne nadpisanie bieżącej pracy byłoby poważnym rozszerzeniem znaczenia „Przywróć”.

Sprawdź, co dzieje się po zmianie uprawnień między usunięciem a odzyskiwaniem. Osoba mogła utracić prawo zapisu do dawnego folderu. Interfejs nie powinien obiecywać skutecznego przywrócenia do miejsca, którego system nie pozwala jej zmienić. Potrzebna jest dostępna droga wyjaśnienia albo wyboru celu, jeśli rzeczywiście ją przewidziano.

Po odmowie odzyskania wskaż właściwą drogę dalszej obsługi. Jeśli potrzebna jest inna rola, użytkownik powinien móc przekazać rozpoznawalny identyfikator elementu i opis przeszkody. Nie musi wysyłać komuś hasła do swojego konta ani ponownie szukać pliku wyłącznie po tytule. Projekt może pomóc przygotować takie zgłoszenie, o ile odpowiada rzeczywistej obsłudze aplikacji.

Podczas przywracania kilku pozycji możliwy jest także wynik częściowy. Jeżeli wróciły dwa szkice z trzech, podsumowanie powinno pokazać właśnie dwa i wskazać pozostały element. Dalsze ponowienie ma dotyczyć brakującego zakresu. Jeśli rozwiązanie zamiast tego cofa całą operację, pokaż taki wynik. Użytkownik nie powinien sam liczyć plików, aby zgadnąć, czy przycisk spełnił obietnicę.

Gdy odzyskany szkic nadal nie pojawia się na zwykłej liście, przyczyną może być aktywny filtr. Zamiast kolejnego komunikatu „Przywrócono”, pokaż możliwość przejścia do właściwego elementu lub miejsca. Odbiorca powinien zobaczyć wynik bez ręcznego odtwarzania wszystkich ustawień. Wtedy odzyskanie ma sprawdzalny skutek, a nie wyłącznie zielony kolor.

Ostatnie potwierdzenie powinno mówić, co stanie się nieodwracalne

Gdy zadanie obejmuje trwałe zakończenie możliwości odzyskania, nie kopiuj automatycznie modelu szybkiego cofnięcia. Przed czynnością pokaż przedmiot i skutek. Jeżeli czynność kończy możliwość przywrócenia z kosza, podaj właśnie ten skutek przy konkretnym elemencie. Osoba powinna rozpoznać, że po zatwierdzeniu nie wróci już tą samą drogą, którą wcześniej odnalazła szkic.

Przy wyborze zbiorczym potwierdzenie ma obejmować te same elementy, które użytkownik rzeczywiście wybrał. „Usuń wybrane” nie wyjaśnia, czy chodzi o widoczną stronę, czy cały zakres. Jeśli część pozycji jest niedostępna do zmiany, pokaż rzeczywisty zakres działania zamiast potwierdzać wyobrażoną całość.

Nie każ wpisywać długiej formułki tylko po to, żeby okno wyglądało poważniej. Dodatkowy wysiłek potrzebuje uzasadnienia w konkretnym ryzyku pomyłki. Najpierw uporządkuj nazwę obiektu, liczbę elementów i następstwo działania. Etykiety „Usuń trwale” oraz „Zachowaj” mówią więcej niż para „Tak” i „Nie” pod niejasnym pytaniem.

Zgodnie z zasadami głosu marki w komunikatach żart nie powinien zasłaniać skutku usunięcia. Osoba ma rozstrzygnąć czynność, a nie sprawdzać, co autor miał na myśli przez „Pożegnaj na zawsze”. Konkretny język nie odbiera marce charakteru. W tej chwili okazuje szacunek dla pracy użytkownika.

Próbę odzyskiwania przeprowadź na kontrolowanych materiałach. W pierwszym przypadku cofnij usunięcie jednego szkicu. W drugim wróć po zniknięciu komunikatu i odnajdź go w koszu. W trzecim przygotuj brak dawnego folderu albo konflikt nazwy. Wynik powinien wskazywać tożsamość elementu, miejsce oraz zależności, które rzeczywiście przywrócono.

Sprawdź także drogę klawiaturą i odczyt komunikatu przy użyciu odpowiednich technologii. Przycisk obecny przez chwilę na ekranie nie potwierdza, że użytkownik go rozpoznał i może go obsłużyć. W razie błędu zachowaj informację o wybranym elemencie, aby ponowienie nie wymagało odgadnięcia, którego z podobnych tytułów dotyczyła poprzednia próba.

Dla naszej biblioteki poprawny wynik jest konkretny: wrócił ten szkic, pod właściwą tożsamością, do uzgodnionego miejsca i z potwierdzonym zakresem powiązań. Jeśli wrócił tylko tytuł wiersza, zadanie pozostaje otwarte. Sześć liter na przycisku powinno prowadzić do dokładnie tego odzyskania, które aplikacja potrafi wykonać.