Jakie błędy popełniają Twoi użytkownicy i jak możesz zaktualizować aplikację, aby sobie z nimi poradziła? [Zamknięte]


12

W rzeczywistości to pytanie dotyczy środków ostrożności, które należy podjąć w celu poprawy jakości obsługi użytkowników i ograniczenia możliwych do uniknięcia wezwań pomocy.


2
Zastanów się nad tym tytułem: „Jakie błędy popełniają Twoi użytkownicy i jak możesz zaktualizować aplikację, aby sobie z nimi poradziła?”
Peter Boughton,

Odpowiedzi:


25

Brak prawidłowego sprawdzania poprawności danych wejściowych jest jedną z tych rzeczy, które prowadzą dość szybko do użytkowników, którzy robią „złe” rzeczy z twoją aplikacją, kiedy programista naprawdę powinien to zrobić.

Widziałem starsze aplikacje, w których użytkownicy zostali przeszkoleni w zakresie:

  • nie wpisuj apostrofów w nazwach
  • nie wpisuj żadnego symbolu innego niż a-z0-9,
  • upewnij się, że nie ma spacji przed wprowadzonym tekstem ani po nim
  • sprawdź, czy w emailpolu wpisano poprawnie sformatowany adres e-mail , w przeciwnym razie kolejne mailingi do tego użytkownika będą wykorzystywać wszystko, co jest w polu i nie powiedzie się
  • upewnij się, że „ http://” jest umieszczone przed adresami internetowymi

itd itd

Wszystkie powyższe problemy powinny być rozwiązywane przez programistę aplikacji. Kiedy weryfikacja danych wejściowych jest zasadniczo „upewnij się, że użytkownik wie, w jakim formacie powinno być to pole, i zaufaj temu, co wpisał, że jest poprawny”, wtedy nieoczekiwane rzeczy z pewnością znajdą drogę do aplikacji. Oprócz oczywistych konsekwencji dla bezpieczeństwa użytkownicy popełniają błędy. Jako programiści często produkujemy nasze najlepsze produkty, pochylając się do tyłu, aby upewnić się, że użytkownik nie może się pomylić, niezależnie od tego, jak bardzo się starają!


Jest to często pomijane ... Nie mogę uwierzyć, że wciąż napotykamy na te problemy! @
mpeterson

2
+1, ponieważ to widziałem. ALE: A „poprawnie sformatowany adres e-mail” jest bardzo trudne do sprawdzania fightingforalostcause.net/misc/2006/compare-email-regex.php upewnij się, że wiesz, co robisz. Jeśli masz tylko do czynienia z podzbiorem e-maili, z których korzysta Twoja firma wewnętrznie, to powinno być w porządku, w przeciwnym razie jest więcej złożoności, niż większość się spodziewa. Ta sama historia dla http://punktu weryfikacji. Na przykład ASDFrobi to w naiwny sposób, w wyniku czego nie można hostować pakietów w domenach, które z nich korzystają https://.
Inaimathi

To nie działa ... nie przyjmuje wiadomości e-mail ze ścieżkami huku (tak, wiem, kogo to obchodzi, ale mimo to sprawdzanie poprawności wiadomości e-mail na RFC jest trudne)
Spudd86,

7

Kiedyś dostałem telefon do działu obsługi klienta, ponieważ moja aplikacja właśnie zniknęła. Okazało się, że otworzyli na nim kolejną aplikację.

... postanowiłem nie dopilnować, aby to się nie powtórzyło, ponieważ przyczyną problemu był analfabetyzm użytkowników, a nie aplikacja. Wszystko, co mogłem zrobić, aby to naprawić, doprowadziłoby do pogorszenia komfortu użytkowania dla innych.


1
Prześlij ten post wszystkim deweloperom, którzy wdrożyli wymuszoną funkcję „bądź na bieżąco” w swojej aplikacji. Nawet jeśli poprosi o to CEO, powinniśmy mieć prawo powiedzieć „nie”.

7

Prawie każdy program, który piszę, jest wywoływany ściśle z wiersza poleceń. Napisałem też kilka bardziej wymyślnych rzeczy, które zaczęły się jako interfejsy CLI i szybko przerodziły się w coś bardziej przypominającego powłokę niż cokolwiek innego.

Mogę mówić tylko o tym, co wiem. Oto kilka typowych problemów z programami wiersza poleceń:

O wiele za dużo opcji

O ile nie piszesz kompilatora lub edytora wierszy, staraj się, aby opcje były ograniczone do jednego ekranu pełnego w buforze klatek 80x25, gdy --helplub /?zostanie przekazany. Jest całkiem dobrze mieć więcej opcji, ale podzielić je na podkategorie. Na przykład

foo --help

foo --help option_name

Bez długich opcji

O wiele łatwiej jest pamiętać foo --attach_to [argument] --volatile --verboseniż pamiętać foo -a [arg] -v +V. Nie zawsze jest to możliwe, ale w większości przypadków tak jest.

Brak sprawdzania poprawności danych wejściowych

Prawie każda platforma ma wiele bibliotek, które są wypróbowane, przetestowane i prawdziwe, jeśli chodzi o parsowanie i sprawdzanie poprawności argumentów. Prawie każda platforma ma wypróbowany, przetestowany i prawdziwy leksykon, który weryfikuje dane wejściowe z interfejsu CLI. Użyj jednego, drugiego lub obu. Jeśli Twój program segreguje się lub dzieli przez zero z powodu czegoś, co podał użytkownik, to tylko zawstydzające.

Być może nie potrzebujesz czegoś tak skomplikowanego jak leksykon, być może możesz po prostu tokenizować ciąg, jeśli oczekujesz rzeczy w określonej kolejności z pewnymi rzeczami w niektórych miejscach.

Dostałem raport o błędzie, gdy oczekiwano liczby całkowitej i ktoś wpisał f*** my lifecudzysłowy. Nie napisałem tego programu, miałem nieszczęście go odziedziczyć.

Brak pokrętła „gadatliwości”

Pozwól doświadczonym użytkownikom łatwo odkryć, w jaki sposób uzyskać znacznie więcej hałasu z twojego programu, niż większość ludzi tolerowałaby, ale domyślnie drukuje tylko poważne i krytyczne rzeczy. Nie mogę Wam powiedzieć, ile razy musiałem odpalać, straceżeby zdać sobie sprawę, że coś się nie udało, bo działało na strumieniu plików NULL.

Możesz także owijać twierdzenia, tak aby wyłączenie ich za pomocą NDEBUG lub w inny sposób nadal skutkowało wydrukowaniem lub zalogowaniem przez użytkownika do znalezienia.

Mówiąc o plikach dziennika, postaraj się upewnić, że wszystko, co w nich umieścisz, ma sens (przynajmniej trochę) dla kogoś innego niż ty. Jeśli początek każdego wpisu jest datą epoki UNIX, spotęgujesz frustrację u kogoś, kto naprawdę chce pomóc w odtworzeniu błędu.

W trybie debugowania nie ma „kumpla błędów”

Wiele programów oferuje pewien rodzaj przełącznika „debugowania”, który oferuje dodatkową gadkę na temat tego, co się dzieje z programem, ale bardzo niewiele oferuje następujące opcje:

  • Sposób na automatyczne wysłanie raportu przez HTTP / HTTPS i uzyskanie jakiegoś numeru referencyjnego usługi
  • Sposób na zrzucenie użytecznych informacji do pliku, który można wysłać jako załącznik do zgłoszenia do pomocy technicznej

A może lubisz słyszeć, jak ludzie czytają przez telefon:

Mówi nieoczekiwany stan przy zero eff oh cztery zero oh .... OK, daj mi przeczytać to z powrotem ...

Zbyt skomplikowane pliki konfiguracyjne

Nie usprawiedliwiaj potrzeby analizowania konfiguracji jako pretekstu, aby uzyskać gwarancję dużej ilości cukru syntaktycznego. Spróbuj użyć formatu, który ludzie znają, nawet jeśli oznacza to dodatkową pracę podczas analizowania. Staram się używać formatu INI, gdy tylko jest to możliwe. Zdziwiłbyś się, co możesz zrobić za pomocą prostego słownika klucz-> wartość.

Brak plików konfiguracyjnych

Nie zmuszaj ludzi do pisania skryptów powłoki lub plików wsadowych tylko w celu korzystania z programu, chyba że miał on być narzędziem do któregoś z zadań. Daj mi sposób, aby wskazać plik zawierający moje zwykłe opcje i podać tylko kilka dodatkowych argumentów.

Brak oznak „mokrej podłogi”

Jeśli jakaś funkcja może wpędzić użytkownika w kłopoty (być może jest dostępna dla zaawansowanych użytkowników), wyraźnie to zaznacz. Dodatkowo, jeśli ktoś gruby palec wprowadzi coś lub zapomni coś, program wydrukuje bardzo przyjazny link do dokumentacji on-line. Być może masz do czynienia z kimś, kto używa twojego programu przez KVM i nie może wycinać i wklejać.

Jeśli to możliwe, (zbiega się to z weryfikacją danych wejściowych) użyj apletu Google:

Czy chodziło Ci o foo --bar FILENME, wpisałeś tylko foo --bar

Oferuj wyjście z destrukcyjnych instrukcji

Celem jest poinformowanie użytkownika, dlaczego to nie zadziałało, i poproszenie go jeszcze kilka razy, przy jednoczesnym zapewnieniu, że nie zrobisz nic potencjalnie destrukcyjnego, chyba że wydaje się, że użytkownik naprawdę tego chce. Zezwól na przełącznik, który wyłącza „dokuczanie”, na przykład -Ylub w /Yinny sposób umożliwi wyjście dla kogoś, kto po prostu ma „grube palce”.

Prawdopodobnie zapominam o kilku wskazówkach. Radzę sobie z tym często, ponieważ bardzo, bardzo trudno jest stworzyć interfejs „niskiego poziomu” dla czegoś wystarczająco intuicyjnego, aby większość ludzi unikała błędów.


3

„Czy na pewno chcesz usunąć ten plik / rekord? Tak / Nie”. Kliknąłem tak, a następnie dostałem telefon, że „omyłkowo” kliknął czerwony przycisk usuwania i potrzebuje tych danych z powrotem :)


7
Dlaczego „cytaty”. Czy sugerujesz, aby celowo kliknęli przycisk tak, aby mogli do Ciebie zadzwonić?
Peter Boughton,

1
Łatwo rozwiązany za pomocą „miękkich usunięć”, które można cofnąć.
Robert Harvey,

1
tak, można je cofnąć, ale po co je usuwać? Dlatego umieściłem tam to ostrzeżenie, prosząc ich dwukrotnie, aby potwierdzili, że chcą je usunąć :)
Quamis

2
@Quamis: Okna dialogowe stały się tak irytujące dla wielu użytkowników, że po prostu kliknęli OK, Tak, cokolwiek, aby przejść przez okno dialogowe. Dlatego wiele nowych systemów używa miękkiego usuwania bez potwierdzenia i umożliwia użytkownikowi cofnięcie. Na przykład większość systemów pocztowych działa teraz w ten sposób.
Robert Harvey

1
@Robert Harvey - Rozumiem i tak, to jest konkretny powód, dla którego konieczne było wdrożenie twardego usuwania. Ten konkretny przykład można rozwiązać, śledząc zasady przechowywania, ale prawdopodobnie zdarzają się przypadki, gdy ludzie naciskają „Usuń” słusznie oczekując, że konsekwencją tej operacji będzie prawdziwe usunięcie. Sam wolę trasę miękkiego usuwania, ale miałem na myśli, że czasami nie jest to opcja.
Inaimathi,

3

Nie wydaje mi się, że uzyskanie konkretnych przykładów break / fix jest tak ważne, jak uświadomienie sobie tego:

  • Użytkownicy nie czytają twojego podręcznika ani nie oglądają twoich samouczków. Poznają twoje oprogramowanie poprzez eksplorację.

Jeśli podczas tej eksploracji coś zepsują, jako programista Twoim zadaniem jest albo ostrzec ich przed niebezpieczeństwem, albo przede wszystkim zapobiec jego wystąpieniu. Nie pamiętam, gdzie to teraz widziałem, ale w myślach zawsze staram się „ ułatwiać robienie właściwych rzeczy ” użytkownikom mojego oprogramowania.

Jeśli nalegasz na przykłady:

  • Użytkownik był w stanie wprowadzić małą literę, która złamała kod integracji / naprawiono, wykonując weryfikację wejścia
  • Użytkownik był w stanie kliknąć niewłaściwy przycisk po wykonaniu czynności / naprawiono, pokazując tylko prawidłowe przyciski.
  • Użytkownik był w stanie wykonać X przypadkowo / naprawić, ostrzegając go, że ma zamiar zrobić X.

Widzisz dokąd to zmierza? :)


2
Ostrzeżenia powinny być zarezerwowane tylko dla najbardziej destrukcyjnych operacji, i powinieneś unikać takich, cofnij to DUŻO DUŻO DUŻO lepiej, ludzie zostali teraz przeszkoleni, aby klikali „OK” nawet nie czytając pola, teraz pamięć mięśni, unikaj dla każdej operacji, którą użytkownik może wykonywać regularnie, aby uniknąć tego efektu.
Spudd86,

3

Oto jedna, którą usłyszałem w tym tygodniu. Użytkownik prosi o funkcję „wyślij mi powiadomienie, gdy wystąpi zdarzenie”. Dość proste, a programista kontynuuje i wdraża go. Jasne, pierwsze pytanie powinno brzmieć „co próbujemy rozwiązać za pomocą tego powiadomienia?”. Nie wejdę w to. Kilka dni później użytkownik zatrzymuje się przed deweloperem i pyta: „Otrzymałem to powiadomienie. Co mam z tym zrobić?”.

Przypomniałem sobie ten komiks Dilberta i zasugerowałem programistom „napisanie aplikacji, aby dowiedzieć się, co użytkownik powinien zrobić z tym powiadomieniem”.

Jak powiedział mpeterson, użytkownik jest bardzo konkurencyjny w swojej dziedzinie. Po prostu nie myślą jak programista lub projektant.


2

Nie sądzę, że użytkownicy są głupi. Nie chcą w ogóle używać Twojego ani żadnego programu. Wszystko, czego chcą, to załatwić swoje sprawy. Pomóż im i nie dopuść do krzywdy, która im się przydarzy po drodze.


1
Nie rozumiesz pytania. Powtórz to, co napisałem innymi słowami. To nie jest odpowiedź na pytanie. Jakie praktyki możemy zrobić, aby zapobiec szkodom?
Maniero,

1
Dobrze rozumiem pytanie, dziękuję. Pytanie zawiera coś, co nie jest prawdą: „użytkownik jest głupi”.
LennyProgrammers,

1
Nie, nie ma. To twoje niezrozumienie. Twój cytat nie istnieje!
Maniero

1
Ok, ludzie nie robią głupich rzeczy, świat jest idealny :-) To jest moje zdanie na temat tych opinii.
Maniero,

1
Żadnych ciężkich uczuć, dobrze? ;)
LennyProgrammers

1

Posiadanie dobrego interfejsu użytkownika i zapewnianie odpowiedniego doświadczenia edukacyjnego znacznie przyczynia się do powstrzymania użytkowników od robienia złych rzeczy.

  • Dobre interfejsy użytkownika powinny być beztarciowe.

    Zamiast wyskoczyć okno dialogowe (kosztowna operacja, którą użytkownicy ignorują po pewnym czasie), aby potwierdzić usunięcie, wykonać usunięcie i zaoferować sposób cofnięcia.

  • Dobre interfejsy użytkownika powinny być możliwe do wykrycia.

    Chociaż wstążka w pakiecie Microsoft Office jest bardzo luźna, ponieważ zmusza starych użytkowników programu Word do zmiany sposobu działania, wstążka jest świetnym przykładem tego, w jaki sposób można uczynić interfejs wykrywalnym (tj. Łatwym do wykrycia).

  • Dobre interfejsy użytkownika, podobnie jak dobry kod, powinny być zrozumiałe.

    Nikt nie czyta instrukcji. Jedyną instrukcją, jaką kiedykolwiek przeczytałem dla moich użytkowników, była prezentacja PowerPoint zawierająca szczegółowe instrukcje oprogramowania. Widziałem to przy użyciu narzędzi wideo, takich jak Camtasia, ale PowerPoints są lepsze, ponieważ możesz łatwo przewijać w przód i w tył przez kolejne kroki.


-1

Użytkownik nie popełnia błędów. Błędy leżą po stronie programisty, który nie stworzył użytecznego interfejsu.

Wykonaj testy użyteczności przy każdym wydaniu!


2
Kiedy mieszkałem z rodzicami, tata pytał mnie, dlaczego był odłączony od Internetu za każdym razem, gdy sprawdzał pocztę elektroniczną (tak, to było z powrotem w epoce kamienia łupanego, kiedy mieliśmy połączenie telefoniczne - jestem po prostu stary ). Poprosiłem go, żeby mi pokazał - zgadnij, co widziałem? Gdy pojawiło się okno dialogowe „Wyślij i odbierz” programu Outlook Express, zaznaczono opcję rozłączenia po wysłaniu i odebraniu. Myślę, że wszystko
zależy

3
Niezupełnie John ... Gdyby programiści z perspektywy zastanowili się nad tym, nie umieściliby tam CheckBoxa ani nie nadali mu bardziej znaczącej etykiety. Twój tata nie jest idiotą: ta funkcja nie została przemyślana ani nie przeszła testów przydatności. Nie ma oprogramowania, które sprawi, że poczujemy się głupio! :)
Arcturus,

1
-1: Użytkownicy zrobić popełniają błędy, nawet jeśli mogą one być unikane z rzeczy, jak lepszego oznakowania. Chodzi o to, że pytanie to dotyczy konkretnych problemów, które mają określone rozwiązania. Samo powiedzenie „przetestuj” to po prostu zła odpowiedź.
Maks.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.