Edycja w miejscu: kiedy poprawka jest naprawdę zapisana?

„Magazyn północny” zmienił się w „Studio przy Młyńskiej”. Karolina kliknęła następny wiersz. Nowa nazwa została na ekranie. Czy można już zamknąć komputer? Niektóre interfejsy zapisują tak dyskretnie, że nawet serwerowi nic o tym nie mówią.

To fikcyjny panel wypożyczalni sprzętu filmowego. Karolina porządkuje nazwy miejsc odbioru. Nie chce otwierać osobnej podstrony dla każdej literówki, ale musi wiedzieć, które poprawki będą widoczne dla zespołu. Edycja w miejscu, nazywana też inline edit, pozwala poprawić pojedynczą wartość tam, gdzie właśnie ją czytamy. Jej największa zaleta znika, gdy człowiek po każdej zmianie sprawdza, czy cokolwiek zapisał.

Projekt zaczyna się więc od ustalenia granicy czynności. Wejście w pole, zmiana znaków, polecenie zapisu i potwierdzony zapis mogą wyglądać podobnie. Dla każdego z tych momentów trzeba ustalić osobny sygnał w interfejsie. Jeżeli panel ma otrzymać taką funkcję w ramach projektu Aeneia Design, do rozmowy potrzebny jest konkretny przebieg poprawki, również tej odrzuconej. Sam ołówek w makiecie nie opisuje zachowania.

Najpierw rozpoznaj, co można poprawić

Karolina widzi listę miejsc odbioru, nazwę opiekuna i krótką wskazówkę dojazdu. Zmiana nazwy jest częstą, niewielką poprawką. Gdyby każde dotknięcie dowolnego tekstu uruchamiało edycję, próba zaznaczenia adresu do skopiowania mogłaby nagle otworzyć formularz. Dlatego ustal, jaki element rozpoczyna zmianę: cała wartość, osobny przycisk czy oba. Niech sposób użycia będzie rozpoznawalny przed pierwszą pomyłką.

W wytycznych Atlassian dla edytowalnego pola tekstowego ten wzorzec służy drobnym zmianom istniejącej treści. Dokument odradza go, gdy głównym zadaniem całego ekranu jest pisanie. To użyteczna granica: poprawienie nazwy miejsca i redakcja obszernej instrukcji odbioru potrzebują innego miejsca pracy.

W naszej liście przycisk może mieć dostępną nazwę „Zmień nazwę: Magazyn północny”. Dzięki temu kilka ołówków nie staje się kilkoma identycznymi poleceniami bez przedmiotu. Po uruchomieniu pole powinno dostać czytelną etykietę. Znikający podpowiadany tekst nie zastąpi informacji o tym, co Karolina właśnie poprawia.

Użytkownik powinien też rozpoznać, które dane wolno mu zmieniać. Opiekun planu filmowego może widzieć miejsce odbioru, ale prawo zmiany jego nazwy może należeć do wypożyczalni. Nie pokazuj aktywnego ołówka tylko dlatego, że wiersz jest widoczny. Jeśli stan tylko do odczytu wymaga wyjaśnienia, podaj właściwą drogę zgłoszenia poprawki. Nie każ odbiorcy najpierw wpisywać nowej nazwy, żeby dopiero po zapisie dowiedział się, że nie może jej zmienić.

Wykonawca musi osobno potwierdzić, że system rzeczywiście sprawdza uprawnienia podczas zapisu. Ukryty przycisk załatwia tylko część widoczną na ekranie. Dla Karoliny istotny jest widoczny skutek: ma móc poprawiać dozwolone pola, a pozostałe rozpoznawać jako informacje do odczytu, zamiast podejrzewać usterkę interfejsu.

Ustal również początkowe zaznaczenie. Przy krótkiej nazwie zaznaczenie całej wartości ułatwia jej zastąpienie. Przy instrukcji dojazdu może skasować tekst po pierwszym znaku, choć człowiek chciał poprawić końcówkę. Tę decyzję sprawdzisz na rzeczywistym zadaniu. Nie trzeba narzucać wszystkim polom tego samego zachowania tylko dlatego, że korzystają z jednego komponentu.

Przejście do edycji powinno zachować czytelne otoczenie. Karolina nadal potrzebuje wiedzieć, którego miejsca dotyczy poprawka. Jeśli tabela przesuwa się po pojawieniu się przycisków, sprawdź, czy nie przestawia innych wierszy pod kursorem. Przy powiększonym tekście nazwa może zajmować więcej miejsca, ale nie powinna znikać pod kontrolkami zapisu.

Kliknięcie obok też jest decyzją projektową

W jednym panelu kliknięcie poza polem zapisuje zmianę. W drugim ją porzuca. W trzecim zostawia niezapisany tekst, który wygląda jak zwykła wartość. Użytkownik nie ma obowiązku odgadnąć, który obyczaj obowiązuje dzisiaj. Regułę trzeba wybrać, pokazać i utrzymać w porównywalnych miejscach.

Dokumentacja zdarzenia blur w MDN opisuje utratę fokusu, czyli przeniesienie aktywnego miejsca obsługi z danego elementu. Samo zdarzenie nie jest potwierdzeniem zapisu danych. Aplikacja może wykorzystać je do własnej obsługi, ale kliknięcie w następną komórkę nie dowodzi, że serwer przyjął poprzednią wartość.

Karolina może kliknąć obok, bo chce skopiować numer telefonu opiekuna. Na telefonie może dotknąć miejsca poza klawiaturą, żeby ją schować. Jeśli każde takie zachowanie kończy edycję, sprawdź je na tych właśnie sytuacjach. Projekt oparty wyłącznie na spokojnym klikaniu myszą przy biurku pominie część powodów utraty aktywnego pola.

Dla nazwy miejsca wybierzmy jawne „Zapisz” i „Anuluj”, dostępne również z klawiatury zgodnie z uzgodnionym zachowaniem. Przy opisie zawierającym kilka wierszy trzeba jeszcze rozróżnić nowy akapit od zatwierdzenia całości. Ten sam Enter nie powinien raz dodawać wiersza, a chwilę później wysyłać niedokończonej instrukcji bez zrozumiałego powodu.

Po zatwierdzeniu określ miejsce dalszej obsługi klawiaturą. Karolina może wrócić do przycisku zmiany nazwy albo przejść do następnego logicznego pola, zależnie od uzgodnionej pracy. Nie powinna nagle znaleźć się na początku całej strony. Przy błędzie pozostaw jej dostęp do poprawki i wyjaśnienia, zamiast zamykać edycję. Potwierdzenie powinno dać się odebrać także bez wypatrywania zmiany koloru. Nie wymaga to odczytywania komunikatu po każdym wpisanym znaku; chodzi o wynik konkretnej próby.

Atlassian w zasadach użycia inline edit zaleca pozostawianie widocznych przycisków działania tam, gdzie to możliwe. Dla większych obszarów tekstu rekomenduje zachowanie trybu edycji po utracie fokusu. Są to wskazówki tego komponentu, które pomagają rozważyć ryzyko przypadkowego zakończenia poprawki.

Jeśli zespół wybierze automatyczny zapis po wyjściu z krótkiego pola, potrzebuje równie jasnego potwierdzenia i drogi poprawienia wyniku. Oszczędzony przycisk nie usuwa pracy nad stanami. Trzeba pokazać oczekiwanie, odrzucenie wartości i brak potwierdzenia. To nadal ten sam zapis, tylko uruchamiany mniej wyraźnym gestem.

Nowa nazwa na ekranie musi mieć określony status

Po wybraniu „Zapisz” Karolina może od razu zobaczyć nową nazwę, zanim przyjdzie odpowiedź. Projekt może pokazywać poprawkę już podczas wysyłania, z oznaczeniem, że nadal czeka ona na potwierdzenie. Dyskretne „Zapisujemy…” obok właściwego miejsca daje więcej informacji niż krótki błysk zieleni nad całą tabelą.

Ustal, czy w tym czasie wolno ponownie otworzyć to samo pole. Można na chwilę zamknąć jego edycję albo obsłużyć następną poprawkę jako osobną zmianę. Jeśli Karolina wpisze trzecią nazwę, odpowiedź dotycząca drugiej nie może po cichu zamknąć nowszej edycji i pokazać „Zapisano”. Trzeba określić, do której wartości odnosi się potwierdzenie.

Sprawdź również, jak pole porządkuje wprowadzony zapis. Karolina może wkleić nazwę ze spacją na końcu. Usunięcie zbędnego odstępu może być uzgodnionym porządkiem, ale zamiana całej nazwy na wielkie litery byłaby już widoczną zmianą zapisu. Nie przekształcaj jej po cichu dopiero po zamknięciu edycji. Jeżeli system zwraca przyjętą postać wartości, to ona powinna znaleźć się w potwierdzonym widoku. Własny tekst pozostawiony w komórce nie wystarczy, jeśli serwer zapisał inną postać.

W próbie użyj nazwy z polskimi znakami i celowym odstępem. Odbierający powinien zobaczyć, co ostatecznie zachowano. Taka nazwa ujawni sytuację, w której ekran i system przechowują różne wersje pod wspólnym komunikatem „Zapisano”.

Przy odrzuceniu za długiej nazwy zachowaj jej wpisany wariant i pokaż, co należy poprawić. Przy braku połączenia wyjaśnienie będzie inne. Karolina nie skróci nazwy tak skutecznie, żeby naprawić sieć. Głos marki w komunikatach interfejsu powinien uwzględniać tę różnicę, zanim ktoś dopisze uniwersalne „Ups, spróbuj jeszcze raz”.

Po przerwaniu odpowiedzi wynik może pozostać nieznany. Wtedy nie cofaj wartości z komunikatem „Nie zapisano”, jeżeli aplikacja nie umie tego potwierdzić. Zaprojektuj sprawdzenie aktualnego stanu albo inną uzgodnioną drogę wyjaśnienia. Widoczny szkic Karoliny i wartość obecna w systemie powinny zachować swoje nazwy, dopóki wynik nie zostanie ustalony.

Gdy problem wynika z cudzej zmiany tego samego rekordu, potrzebne jest rozstrzygnięcie konfliktu edycji. To osobna sytuacja. Tutaj pierwsze pytanie brzmi, czy własna poprawka w ogóle została zatwierdzona i przyjęta. Wspólny czerwony komunikat dla obu przypadków odeśle człowieka do niewłaściwego działania.

Anulowanie nie cofa tego, co już zapisano

Przycisk „Anuluj” podczas edycji może przywracać wartość, od której Karolina zaczęła. Po potwierdzonym zapisie ta sama etykieta nie powinna udawać cofnięcia operacji. Jeśli panel oferuje „Cofnij zmianę nazwy”, powinien pokazać, którą nazwę przywraca i w jakich warunkach może to wykonać. To kolejne działanie wobec aktualnego rekordu.

Rozróżnienie widać szczególnie przy pustej wartości. Usunięcie nazwy może być niedozwolone, a wyczyszczenie dodatkowej wskazówki może stanowić poprawną decyzję. „Anuluj”, „Wyczyść” i „Zapisz pustą wskazówkę” nie opisują tego samego zamiaru. W projekcie użyj odpowiedniej reguły dla danego pola. Dwa identyczne prostokąty nie nadają nazwie i uwadze jednakowych wymagań.

Przy wyjściu do innego miejsca panelu trzeba określić los rozpoczętej poprawki. Ostrzeżenie ma sens, gdy rzeczywiście chroni niezapisany tekst. Pokazywane po każdej zapisanej literówce szybko staje się odruchem do zamknięcia. Jeśli poprawka pozostaje tylko w bieżącej karcie, nie przedstawiaj jej jako trwałego szkicu dostępnego po ponownym zalogowaniu.

W dłuższej pracy pomocna może być paleta poleceń i skróty, lecz nie powinna omijać tej reguły. Polecenie przejścia do następnego miejsca nadal musi uwzględnić otwartą edycję. Skrót ma skracać drogę do działania, a nie do zgubienia wpisanego tekstu.

Jedno pole może zmienić znaczenie całego widoku

Nazwa „Studio przy Młyńskiej” pojawia się też w zestawieniu rezerwacji. W projekcie trzeba ustalić, czy po zapisie lista pokazuje nowy odczyt, lokalnie podmienioną wartość czy starszy stan wymagający odświeżenia. Oznaczenie aktualności panelu danych powinno odpowiadać rzeczywistej drodze informacji. Sam fakt zakończenia edycji nie aktualizuje każdego otwartego widoku.

Nie każde pole warto przy tym zmieniać niezależnie. Nazwa miejsca może być osobną poprawką, ale współrzędne i opis właściwego wejścia mogą wymagać wspólnego sprawdzenia. Jeśli pojedynczy zapis tworzy przejściowo sprzeczną informację, pełniejszy formularz bywa uczciwszym rozwiązaniem. Mniejsza liczba przycisków nie jest ważniejsza od sensu danych.

Podobnie nie trzeba wciskać rozbudowanej instrukcji w mały dymek. Edytor treści z podglądem pozwala ocenić strukturę dłuższego tekstu. Edycja w miejscu może pozostać przy nazwie i krótkiej uwadze. Zespół nie traci spójności, jeżeli różne zadania dostają odpowiednie warunki.

Do odbioru przygotuj tę samą poprawkę w kilku przebiegach: zwykły zapis, odrzucenie wartości, opóźniona odpowiedź i wyjście z otwartej edycji. Poproś osobę sprawdzającą, żeby wskazała nazwę obowiązującą w systemie oraz tekst, który nadal jest jej propozycją. Jeśli potrafi zrobić to bez ponownego otwierania pola na próbę, ołówek przestał być zagadką.