Ktoś właśnie zmienił ten rekord: jak pokazać konflikt edycji

„Nie udało się zapisać. Spróbuj ponownie”. Użytkowniczka posłusznie próbuje. Po drugim kliknięciu znika poprawka kolegi, a pojawia się jej starszy opis wejścia do budynku. Komunikat potraktował konflikt jak chwilową niedyspozycję internetu.

Konflikt edycji powstaje wtedy, gdy ktoś chce zapisać zmiany oparte na stanie, który w międzyczasie zmieniła inna osoba lub proces. Interfejs powinien pomóc rozpoznać różnicę, zachować własną pracę i świadomie wybrać dalszy krok. Projekt komunikatu musi odpowiadać działaniu zapisu. Samo ostrzeżenie narysowane w makiecie nie powstrzyma nadpisania danych.

Najpierw ocal to, co użytkownik już zrobił

Przyjmijmy fikcyjny serwis pracowni Otwarte Miejsce. Dwie osoby redagują opis placówki. Ewa poprawia godziny odbioru, a Jan opis wejścia od dziedzińca. Oboje zaczęli od tej samej wersji. Jan zapisuje pierwszy. Ewa nadal ogląda dawny formularz i naciska „Zapisz”. W tym momencie system powinien rozpoznać sytuację zgodnie z uzgodnionym mechanizmem kontroli wersji.

Podobny przypadek może powstać bez drugiej osoby: Ewa otworzyła tę samą placówkę w dwóch kartach i w jednej zapisała nowszą informację. Komunikat „inny użytkownik zmienił rekord” byłby wtedy mylący. Treść ostrzeżenia powinna opisywać potwierdzoną zmianę stanu, a autora wskazywać tylko wtedy, gdy system rzeczywiście go rozpoznaje.

Ewa potrzebuje odpowiedzi na trzy pytania: czy jej zmiany zapisano, czyja praca znajduje się obecnie w systemie i jak dokończyć zadanie. Sam czerwony pasek „Konflikt” nie odpowiada na żadne z nich. Równie mało pomaga identyczny komunikat używany przy braku uprawnienia, zerwanym połączeniu i błędnym formacie godziny.

Po wykryciu konfliktu zachowaj widoczną treść wprowadzoną przez Ewę. Nie zastępuj formularza nowym odczytem bez uprzedzenia, bo usunięcie niezapisanej pracy staje się drugim problemem. W projekcie ustal, czy własny wariant pozostaje w formularzu, w oddzielnym szkicu czy w widoku porównania. Nazwij miejsce i jego trwałość zgodnie z rzeczywistym wdrożeniem.

Samo „Odśwież” też wymaga określenia skutku. Czy odczytuje nowszy rekord, zachowując własne pola obok, czy zastępuje nimi cały formularz? Jeżeli powoduje utratę niezapisanej treści, pokaż to przed wykonaniem i zapewnij uzgodnioną drogę jej zachowania. Przycisk służący rozwiązaniu konfliktu nie powinien być ukrytym poleceniem porzucenia pracy.

Opis nagłówka If-Match w MDN przedstawia mechanizm żądania warunkowego, w którym serwer porównuje wskazane oznaczenie wersji ETag. Przy niespełnionym warunku zwraca 412 Precondition Failed. To przykład technicznej podstawy kontroli zapisu, nie automatyczna funkcja każdego formularza ani projekt gotowego komunikatu.

Dla użytkownika numer 412 zwykle nie jest najważniejszą informacją. Przydatniejszy będzie opis: „Opis placówki zmienił się od czasu otwarcia formularza. Twoje poprawki nie zostały zapisane. Porównaj wersje”. Każde zdanie musi jednak odpowiadać temu, co aplikacja rzeczywiście potwierdziła. Nie pokazuj „nie zapisano”, jeżeli wynik operacji jest nieznany i wymaga sprawdzenia.

Zachowanie szkicu odróżnij od zapisu rekordu. Jeśli aplikacja przechowuje roboczą treść tylko w bieżącej karcie, nie obiecuj odzyskania jej po zamknięciu przeglądarki. Formularz z zapisem i powrotem wymaga własnej reguły trwałości. Tutaj redaktor powinien wiedzieć, co może bezpiecznie zamknąć i gdzie wróci do swojej poprawki.

W przypadku długiego formularza pokaż, które części wymagają uwagi. Ewa nie powinna ponownie czytać całego opisu placówki, jeżeli różnica dotyczy tylko wejścia. Nie ukrywaj jednak powiązanych pól. Zmieniony opis wejścia może wymagać sprawdzenia wskazówki dojazdu albo wersji językowej; sposób prezentacji powinien wspierać tę ocenę.

Trzy punkty odniesienia w porównaniu

Dwie kolumny „Twoja wersja” i „Aktualna wersja” pokazują różnicę, ale nie zawsze wyjaśniają jej pochodzenie. Przydatny bywa także stan, od którego rozpoczęto edycję. Bez niego Ewa widzi dwa różne opisy, lecz nie wie, czy obie osoby zmieniły to samo zdanie, czy Jan poprawił fragment, którego ona nie dotykała.

W naszym przykładzie stan początkowy zawiera odbiór do godziny siedemnastej i wejście od ulicy. Ewa zmienia godzinę na szesnastą, Jan wejście na dziedziniec. To dwie zmiany w różnych polach. Projekt może pokazać propozycję zachowania obu, jeśli używany mechanizm potrafi je poprawnie połączyć. Nie należy nazywać takiej możliwości gotową funkcją wyłącznie na podstawie atrakcyjnej makiety.

Druga próbka jest trudniejsza: oboje zmieniają godzinę odbioru, ale na inne wartości. Teraz sama różnica wersji nie rozstrzyga, która informacja jest prawdziwa. Potrzebna jest decyzja osoby znającej uzgodnienia placówki. Najpóźniejsza data zapisu nie nadaje automatycznie wartościom pierwszeństwa przy ustalaniu poprawnej treści.

Zmiany w różnych polach również mogą się ze sobą wiązać. Jeśli jedna osoba wyłączyła odbiór osobisty, a druga zmieniła jego godziny, połączenie obu wymaga ustalenia sensu całego rekordu. Przygotuj taki przypadek obok prostych, niezależnych poprawek. Reguła technicznego łączenia nie powinna po cichu tworzyć sprzecznej informacji dla gościa.

W widoku porównania pokaż nazwę pola, stan początkowy, stan obecny i propozycję użytkownika. Można ograniczyć początkowy zakres do zmienionych pól, z dostępem do pełnego kontekstu. Jeżeli narzędzie nie przechowuje stanu początkowego, opisz możliwe porównanie uczciwie. Nie odtwarzaj dawnej wartości z pamięci użytkownika jako pewnego elementu historii.

Po rozstrzygnięciu poszczególnych pól pokaż spójny wynik do zapisu. Zestaw wyborów dokonanych w kilku rozwiniętych panelach jest trudniejszy do oceny niż gotowy opis placówki. Użytkownik powinien móc sprawdzić, czy godziny, wejście i dodatkowa uwaga składają się w jedną zrozumiałą informację. Dopiero ten stan będzie podstawą następnej próby zapisu.

Przy dłuższym tekście kolorowe oznaczenie zmiany nie wystarcza. Dodaj czytelne etykiety i pozwól odczytać usunięty oraz dodany fragment. Osoba korzystająca z klawiatury albo czytnika ekranu powinna móc przejść po różnicach i wskazać decyzję. Układ dwóch wąskich kolumn może wymagać innego przedstawienia na telefonie, zachowującego te same informacje.

Przy porównaniu godzin pokaż również dzień lub okres, którego dotyczą. Dwie identyczne wartości mogą należeć do innego dnia tygodnia. W dłuższej treści pozostaw otoczenie zmienionego fragmentu, tak aby usunięcie jednego warunku nie wyglądało jak drobna kosmetyka. Widok różnic ma wspierać rozumienie, a nie tylko policzyć zmienione znaki.

Przewodnik MDN o żądaniach warunkowych opisuje problem utraconej aktualizacji i pozostawia obsługę odrzuconej zmiany aplikacji klienckiej. Wśród możliwości wskazuje powiadomienie użytkownika oraz pokazanie różnic. Rozpoznanie konfliktu i pomoc w jego rozwiązaniu są więc odrębnymi częściami tego samego procesu.

Nie zamieniaj porównania w automatyczny konkurs autorów. Nazwa osoby i czas zmiany pomagają ustalić kontekst, jeśli system je udostępnia. Nie określają poprawności informacji. Zamiast wielkiego „Jan zmienił twoją treść” lepiej pokazać neutralnie, co się zmieniło oraz jaka decyzja pozostaje do podjęcia.

Jeżeli różnice przygotowuje AI, porównywanie wersji dokumentu wymaga osobnej kontroli kompletności i znaczenia. Pominięte słowo „nie” może zmienić sens decyzji mimo niewielkiej objętości różnicy. Użytkownik powinien mieć możliwość sprawdzenia oryginalnych wartości, z których powstało podsumowanie.

Dalszy krok musi nazywać swój skutek

„Kontynuuj” może oznaczać powrót do własnego formularza, przejęcie nowszej wersji albo nadpisanie rekordu. Tak różne działania nie powinny dzielić jednej nieokreślonej etykiety. W projekcie wybierz rzeczywiście dostępne drogi i nazwij je zgodnie ze skutkiem.

„Wróć do swojej poprawki” zachowuje pracę do dalszej edycji. Polecenie „Użyj aktualnej wersji” odrzuca własne zmiany w uzgodnionym zakresie. „Zapisz połączone zmiany” wymaga pokazania wyniku połączenia. Nie trzeba oferować każdego wariantu w każdym narzędziu. Redaktor ma rozumieć wybór i zachować kontrolę nad tym, które poprawki porzuca.

Możliwość nadpisania wymaga osobnej decyzji dotyczącej uprawnień i procesu. Jeśli istnieje, pokaż jej zakres oraz konsekwencję. Nie umieszczaj jej jako jedynego wyraźnego przycisku obok dyskretnego wyjścia. Osoba próbująca usunąć błąd komunikatu nie powinna przypadkiem otrzymać najszybszej drogi do usunięcia cudzej pracy.

Po porównaniu rekord może zmienić się ponownie. Ewa przez kilka minut rozstrzyga różnicę, a w tym czasie ktoś dopisuje nową wskazówkę odbioru. Dlatego kontrola wersji musi obejmować również kolejny zapis, zgodnie z mechanizmem wdrożenia. Projekt powinien przewidywać powtórne ostrzeżenie, zachowując już przygotowane rozstrzygnięcia tam, gdzie jest to możliwe i uzgodnione.

W kolejnym porównaniu pokaż, która nowa zmiana wymaga uwagi. Nie przedstawiaj całej dawnej listy jako nierozstrzygniętej bez wskazania przyczyny. Jeśli wcześniejszy wybór pozostaje aktualny, można go zachować; jeśli nowe dane zmieniły jego znaczenie, trzeba pokazać tę różnicę. Warunki takiego działania należą do ustalonej reguły, a próba powinna je sprawdzić.

Ten sam problem występuje, gdy drugą stroną jest automatyzacja. Równoczesna zmiana rekordu przez AI i człowieka wymaga ustalenia, do której wersji odnosiła się praca. Interfejs powinien przedstawiać wynik według tej samej reguły, zamiast traktować zmianę automatu jak uprzywilejowaną prawdę.

Odróżnij też zapis od publikacji. Jan mógł poprawić szkic, podczas gdy goście nadal widzą starszy opis placówki. Ewa powinna wiedzieć, czy porównuje treści robocze, czy obowiązujący widok. Proces publikacji w CMS określa dalszą drogę zatwierdzania; rozstrzygnięcie konfliktu nie musi jej automatycznie kończyć.

Przed wdrożeniem przygotuj próbę z dwiema osobami lub kontrolowanymi sesjami. Najpierw zmieniają różne pola, potem to samo pole, a następnie zapisują po kolejnej zmianie źródła. Sprawdź zachowanie pracy, porównanie i końcowy odczyt rekordu. Samo wyświetlenie ostrzeżenia nie potwierdza, że właściwa wersja została zachowana.

Do odbioru dodaj brak dostępu oraz usunięty rekord. To inne zdarzenia niż nowsza wersja istniejącego opisu i mogą wymagać innej drogi działania. Nie pokazuj możliwości porównania z „aktualną treścią”, jeśli aplikacja jej nie otrzymała. Własna poprawka powinna pozostać rozpoznawalna, ale jej zapis musi respektować aktualny stan i zakres uprawnień.

Gdy użytkownik nie może rozstrzygnąć różnicy samodzielnie, pokaż uzgodnioną drogę przekazania jej odpowiedzialnej osobie. Zachowana propozycja powinna mieć czytelny stan oczekiwania, odróżniony od zatwierdzonego opisu. Po powrocie redaktor musi wiedzieć, czy decyzja już zapadła oraz czy jego roboczy tekst nadal wymaga działania. Nie zostawiaj tej części obiegu wyłącznie w niepowiązanej rozmowie.

Uzgodnioną regułę zapisz w rejestrze decyzji projektowych, razem z przykładem, który ją wyjaśnia. Dzięki temu kolejna zmiana panelu nie sprowadzi całej obsługi z powrotem do „spróbuj ponownie”. Do rozmowy z Aeneia Design wystarczy przynieść jedno takie zderzenie dwóch poprawek. Na nim można zaprojektować drogę od niezapisanego formularza do świadomie uzgodnionej wersji.