Najpierw ustal, co naprawdę zostało zaznaczone
Przycisk zaznaczający wszystkie wiersze może znaczyć „te dwadzieścia na ekranie” albo „wszystkich klientów pasujących do filtra”. Różnica jest ogromna, lecz często ukryta w małym liczniku. Interfejs powinien jasno pokazać zakres i pozwolić go sprawdzić przed wykonaniem. W przykładzie zmiany opiekuna wybór całej bazy zamiast jednej strony wyników może zakłócić pracę wielu osób. Nie pozostawiaj znaczenia zaznaczenia domysłom użytkownika.
Filtr także może zmieniać wynik w czasie. Jeżeli między podglądem a wykonaniem doszli nowi klienci, czy operacja ma ich objąć? Dla korekty konkretnych rekordów rozsądna bywa utrwalona lista identyfikatorów. Dla świadomie zdefiniowanej reguły cyklicznej właściwy może być zakres dynamiczny. Nazwij te tryby inaczej. Operator powinien wiedzieć, czy zatwierdza konkretny zbiór, czy polecenie wykonywane wobec zmieniających się danych.
Podgląd musi opisywać skutek, nie tylko liczbę
Przed zmianą pokaż obecne i przyszłe wartości, liczbę kwalifikujących się rekordów oraz wyłączenia. Jeżeli część spraw jest zamknięta lub należy do innego zespołu, wyjaśnij, czy zostaną pominięte. Lista przykładowych pozycji pomaga rozpoznać pomyłkę w filtrze, ale nie powinna udawać pełnego audytu. Przy większych operacjach warto umożliwić pobranie zakresu do wewnętrznej kontroli, z zachowaniem uprawnień do eksportowanych informacji.
Zatwierdzenie powinno dotyczyć konkretnego planu operacji. Zmiana parametru po wyświetleniu podglądu wymaga ponownego przeliczenia. Dla usuwania danych stosuj wyraźnie mocniejsze potwierdzenie niż dla dodania neutralnej etykiety. Nie przyzwyczajaj pracownika do identycznego okna przy każdej drobnej czynności, bo przestanie je czytać. Treść ostrzeżenia powinna wskazywać skutek nieodwracalny, powiązane zasoby i możliwość późniejszej korekty.
Dużą operację potraktuj jak osobne zadanie
Długie przetwarzanie nie powinno zależeć od otwartej karty przeglądarki. Serwer może utworzyć zadanie z identyfikatorem, parametrami, autorem i utrwalonym zakresem. Pracownik otrzymuje ekran postępu, do którego wróci po przerwie. Zlecenie zadania nie oznacza jeszcze wykonania zmian. Rozdziel stan oczekiwania, działania, zakończenia i błędu, tak aby komunikat sukcesu nie pojawiał się już w chwili umieszczenia pracy w kolejce.
Przetwarzanie partiami ułatwia kontrolę obciążenia i wznowienie po awarii. Każda partia musi mieć jednoznaczny wynik, a ponowienie nie powinno przypadkowo powtarzać skutków. Sprawdzenie uprawnień wyłącznie podczas tworzenia zadania może być niewystarczające, gdy realizacja trwa długo. Ustal zachowanie po odebraniu dostępu autorowi lub zmianie właściciela rekordu. Takie sytuacje wymagają jawnej polityki, nie przypadkowego wyniku zależnego od chwili uruchomienia kolejki.
Anulowanie zatrzymuje przyszłość, nie cofa przeszłości
Przycisk „Anuluj” zwykle może zatrzymać niewykonaną część pracy. Nie oznacza automatycznie przywrócenia już zmienionych rekordów. Wyjaśnij to przed kliknięciem oraz w końcowym raporcie. Jeśli zadanie zmieniło część opiekunów, a pozostałych nie ruszyło, pokaż dokładne liczby i listę rezultatów. Nie przedstawiaj częściowego zakończenia jako jednolitej porażki, po której bezpiecznie można zacząć od nowa bez sprawdzania skutków.
Cofnięcie wymaga odrębnego planu. Przywrócenie starej wartości może nadpisać nową decyzję innego pracownika, podjętą już po operacji masowej. Weryfikuj więc, czy rekord nadal znajduje się w stanie pozostawionym przez zadanie. Przypadki konfliktowe kieruj do oceny, zamiast wymuszać pełny powrót. Nie każda czynność ma sensowną operację odwrotną: wysłanej wiadomości nie da się odzyskać z cudzej skrzynki przez cofnięcie wpisu w bazie.
Wynik powinien prowadzić do poprawienia wyjątków
Raport rozdziel na zmienione, pominięte, odrzucone i oczekujące pozycje. Podaj przyczynę zrozumiałą dla pracownika, a szczegóły techniczne zachowaj w odpowiednio chronionych logach. „Błąd 17” bez dalszego kroku nie pomaga. Przy ponowieniu domyślnie wybieraj tylko te rekordy, dla których nie potwierdzono skutku, i ponownie sprawdzaj aktualny stan. Nie zlecaj jeszcze raz całej operacji tylko dlatego, że kilka pozycji wymagało ręcznej decyzji.
Postęp powinien mieć także formę tekstową dostępną dla technologii asystujących. Nie odświeżaj komunikatu co kilka milisekund i nie przenoś fokusu przy każdej partii. Użytkownik ma móc wykonywać inne zadania, zachowując dostęp do aktualnego stanu. Procent jest uczciwy tylko wtedy, gdy znasz mianownik. Przy nieustalonym zakresie lepiej pokazać liczbę przetworzonych pozycji i etap niż pozornie dokładne „99%”, które trwa przez większość operacji.
Próba odbiorowa powinna zawierać przerwę w połowie
W środowisku testowym przerwij wykonawcę zadania między partiami i uruchom go ponownie. Sprawdź brak podwójnych skutków oraz zgodność raportu z bazą. Zmień uprawnienia autora, usuń jeden rekord i zmodyfikuj drugi po podglądzie. Przetestuj też szybkie dwukrotne zatwierdzenie. Operacja masowa jest szczególnie wrażliwa na małe błędy, bo zwielokrotnia je na wielu obiektach. Warto wykazać poprawność na niewielkim, dobrze znanym zbiorze, zanim dopuścisz całą bazę.
Ustal limity, osoby uprawnione oraz moment wymagający dodatkowej akceptacji. Granice powinny zależeć od skutku, nie tylko liczby wierszy. Sto neutralnych etykiet i sto nieodwracalnych usunięć to różne ryzyka. Zachowaj identyfikator operacji w historii zmienionych rekordów. Dzięki temu obsługa może odtworzyć zakres bez ręcznego porównywania dat. Dobry mechanizm masowy przyspiesza powtarzalną pracę, nie odbierając zespołowi możliwości kontroli jej rezultatów.