mylące nazwy przycisków (np. „Wyślij” zamiast „Zapisz jako szkic”)

Mylące nazwy przycisków to błąd projektowy, w którym etykieta nie odpowiada faktycznemu skutkowi kliknięcia.

Gdy etykieta przycisku rozmija się ze skutkiem operacji

Myląca nazwa przycisku występuje wtedy, gdy tekst widoczny dla użytkownika opisuje inną czynność niż ta, którą rzeczywiście wykonuje interfejs. Przycisk „Wyślij” powinien przekazywać dane do odbiorcy albo do usługi sieciowej, natomiast nie powinien jedynie zapisywać niedokończonego formularza w lokalnym profilu użytkownika. Jeżeli kliknięcie etykiety „Zapisz” publikuje wpis, wysyła wiadomość lub uruchamia płatność, użytkownik może podjąć decyzję na podstawie fałszywej informacji o skutku działania.

Problem nie ogranicza się do warstwy językowej. Nazwa przycisku jest częścią kontraktu między aplikacją a użytkownikiem: wskazuje intencję, zakres operacji i zwykle także jej odwracalność. „Zapisz jako szkic” sugeruje zachowanie danych bez publikacji, „Opublikuj” oznacza udostępnienie treści, a „Anuluj” powinno przerwać bieżący proces bez zatwierdzania zmian. Jeśli kod obsługi zdarzenia wykonuje inną operację niż wynika z tekstu, interfejs staje się źródłem błędów, nawet gdy sama funkcja działa zgodnie z implementacją.

Różnica między zapisem, wysłaniem i publikacją

W aplikacji internetowej przycisk formularza może wywołać różne ścieżki przetwarzania. Formularz może zostać zapisany w bazie jako rekord roboczy, przesłany metodą HTTP do endpointu, przekazany do kolejki zadań albo od razu wyświetlony publicznie. Te operacje mogą korzystać z podobnych pól formularza, ale mają inne skutki dla stanu danych. Sama zmiana napisu na przycisku nie naprawia błędu, jeżeli handler po stronie klienta lub serwera nadal uruchamia niewłaściwy endpoint.

Przykładowo aplikacja może mieć osobne akcje: saveDraft zapisującą status „draft”, sendMessage przekazującą wiadomość do odbiorcy oraz publishPost zmieniającą status na „published”. Każdy przycisk powinien być powiązany z właściwą akcją, komunikatem potwierdzającym i stanem interfejsu. Po zapisie szkicu użytkownik powinien zobaczyć informację o zachowaniu wersji roboczej, a po wysłaniu — rezultat transmisji lub czytelny komunikat o błędzie. Wspólny napis „Zapisz” dla wszystkich tych operacji zaciera różnice w przepływie danych.

Jak rozpoznać błąd w działaniu interfejsu

Weryfikację należy rozpocząć od porównania tekstu, atrybutu dostępnej nazwy i kodu wywoływanego po kliknięciu. W aplikacji webowej warto sprawdzić element HTML, jego typ, obsługę zdarzenia oraz żądanie widoczne w narzędziach deweloperskich przeglądarki. Istotne są metoda HTTP, adres żądania, przekazywane pola i odpowiedź serwera. Kliknięcie „Zapisz jako szkic” nie powinno wywoływać endpointu odpowiedzialnego za wysyłkę wiadomości ani zmieniać rekordu na stan opublikowany.

Test powinien obejmować także sytuacje graniczne: brak połączenia z siecią, podwójne kliknięcie, odświeżenie strony po operacji oraz powrót przyciskiem przeglądarki. Jeżeli użytkownik nie wie, czy dane zostały zapisane, może ponownie uruchomić akcję i utworzyć duplikat albo wysłać tę samą wiadomość kilka razy. Pomocne są jednoznaczne komunikaty po wykonaniu czynności, blokada przycisku na czas trwania żądania oraz rozdzielenie akcji o różnym ryzyku. Przycisk uruchamiający nieodwracalną operację powinien mieć nazwę opisującą właśnie tę operację, a nie ogólny czasownik.

Naprawa etykiet i kontrola przepływu danych

Poprawa wymaga ustalenia rzeczywistego modelu procesu, a następnie dopasowania do niego nazw, kolejności i stanów przycisków. W formularzu redagowania dokumentu można użyć osobnych akcji „Zapisz szkic”, „Podgląd” i „Opublikuj”. Jeśli „Wyślij” oznacza przekazanie formularza do dalszego etapu, należy wskazać odbiorcę lub rezultat, na przykład „Przekaż do akceptacji”. Nazwa powinna być krótka, ale nie może pomijać informacji potrzebnej do odróżnienia zapisu lokalnego, zapisu na serwerze, wysyłki i publikacji.

Po zmianie interfejsu trzeba sprawdzić spójność tłumaczeń, skrótów klawiaturowych, etykiet dla czytników ekranu i komunikatów błędów. Należy również wykonać test od początku do końca: wprowadzić dane, uruchomić każdą dostępną akcję, potwierdzić zmianę stanu w aplikacji i sprawdzić, czy odbiorca otrzymał dokładnie to, co powinien. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich oprogramowania, dlatego przy problemach z mylącymi przyciskami można zlecić analizę ustawień aplikacji, działania formularzy oraz podstawowej komunikacji programu z usługą sieciową.