Care sunt câteva alternative la expresia “ Sigur doriți să XYZ ” în dialogurile de confirmare?

O parte din motivul pentru care oamenii trec peste mesajele lungi se datorează vitezei de citire.

Să presupunem, de dragul discuției, pe cineva cu o viteză medie de citire – aproximativ 200 de cuvinte pe minut. (*)

Dacă folosiți doar 20 de cuvinte într-o casetă de dialog, veți cere acest lucru utilizatorul să petreacă 6 secunde citind și înțelegând ceea ce ați scris.

În timp ce acest lucru nu sună prea mult, o pauză impusă de șase secunde când încercați să faceți ceva poate părea să fie o perioadă foarte lungă de timp .

(*) Și nu faceți greșeala presupunând că viteza redusă de citire înseamnă inteligență scăzută.

Deci, trei sugestii pentru dvs., toate vizând o claritate maximă, cu o agitație minimă.

1. Fiți cât mai concis posibil
2. Identificați elementul în pericol
3. Denumiți butoanele pentru acțiuni

Iată un dialog simplu de ștergere:

Să reducem numărul de cuvinte la minimum pentru a ușura citirea:

Acum, să identificăm elementul în pericol și etichetăm butoanele acțiunii:

Mult mai bine – mai ușor de citit și mai clar.

Un alt exemplu – un dialog de continuare.

Simplificați formularea.

Din nou, să identificăm ce se întâmplă și etichetați butoanele pentru actions.

O îmbunătățire definitivă.

Aici este un gând final. Evitați negativele , specia negativ dublu. Unii vorbitori nativi de engleză consideră că negativele duble sunt dificile, iar mulți care învață engleza ca a doua limbă le consideră confuze (mai ales dacă limba lor maternă folosește dublu-negative pentru accentuare în loc de inversare).

Comentarii

• Sau, puteți citi doar instrucțiunile Windows UX msdn.microsoft.com/en-us/library/aa511258.aspx unde scriu de fapt despre asta 🙂
• Cred că dați de fapt câteva exemple rele: 1. Este ” OK „, nu ” Ok „. 2. Dacă puneți o întrebare da / nu, răspunsurile posibile trebuie să fie da sau nu, cu siguranță nu sunt OK și Anulați. 3. Dacă identificați butoanele pentru acțiune, trebuie să faceți acest lucru cu ambele butoane, nu doar cu unul (adică Ștergeți / Păstrați nu Ștergeți / Anulați) În afară de asta, cred că orice propoziție trebuie să conțină cel puțin un subiect și un verb , dar asta este personal.
• @BaGi – Cred că ați citit greșit răspunsul meu: ‘ arăt o progresie de la sărac la mai bun. Având o întrebare Da / Nu cu Ok / Anulare, deoarece butoanele sunt cu siguranță slabe, dar sunt prea comune și asta am subliniat. Pentru a vă aborda punctele … În cazul în care există un invers invers, este logic să îl utilizați pentru butonul Anulare – deci Ștergere / Păstrare este mai bună decât Ștergere / Anulare, dar acest lucru nu este ‘ t întotdeauna posibil – ce ‘ este inversul Postului? Post / Don ‘ t Postarea pare stângace. Și, cred că toate exemplele mele sunt propoziții complete. Pentru a lua ultima: ” Continuați „: verb; ” Procesarea tranzacției „: subiect.
• @Bevan: Nu ‘ t think Post? Post / Don ‘ t Postarea este neîndemânatică. Salvare / nu ‘ salvarea este ceea ce vedeți în mod constant. În ultima teză ” procesarea tranzacțiilor ” nu este deloc un subiect, ci un obiect indirect (vezi en.wikipedia.org / wiki / Object_% 28grammar% 29 ). Am înțeles că exemplele dvs. arată o îmbunătățire treptată, cred că rezultatul final conține încă câteva defecte minore.
• @BartGijssens: Prefer ‘ întotdeauna prefer Cancel la orice altceva … pentru că fără ca un singur neuron să tragă știu că nu face nimic (efectiv un cuvânt mai puțin de citit). Problema cu ” Nu ‘ nu salvați ” este că poate utiliza ” Aruncă ” într-un alt context (slab).

Întotdeauna îmi propun să arăt utilizatorului care element este șters (mai ales că dialogul ar putea ascunde elementul în cauză, dar și pentru că este identificabil textul din dialog va atrage atenția):

Ștergeți „elementul dvs. preferat”?

De asemenea, poți injecta puțin umor ici și colo, în funcție de ce tip de aplicație faci:

Sigur nu vrei să continui fără a salva? [Da, da, lasă-mă în pace] [Oh, bine, mulțumesc că mi-ai reamintit]

Dacă îl testezi, vei observa că mesajele pline de umor primesc observat un pic mai frecvent, pur și simplu pentru că se deosebesc din mulțimea de mesaje generice și (dacă sunt de fapt destul de drăguți) primesc un zâmbet pe fața utilizatorului. Ce ați mai putea dori?

Comentarii

• Sau ați putea urma regulile mele generale: Toate butoanele de dialog trebuie să fie etichetate ” D ‘ oh! „, chiar dacă există mai multe butoane.
• @ VirtuosiMedia Dacă există două butoane, numai unul ar trebui să fie etichetat ” D ‘ oh! ” Celălalt ar trebui să fie etichetat ” De ce ești mic …! ”
• ” … 14 utilizatori au dat clic pe Do ‘ h, 5 utilizatori au dat clic pe Nut și un utilizator a apăsat tasta M. în mod repetat. ” – Jakob Nielsen
• ” … Toți cei 20 de utilizatori și-au exprimat surprinderea față de luminile roșii de urgență, sirenele și avertismentele de evacuare care au urmat înainte de topirea nucleară. Cei care au supraviețuit au menționat mai târziu că au fost împărțiți între a fugi pentru siguranță și a vedea ce era în frigider. Zguduiti de experiență, ei păreau să se întrebe dacă au făcut alegerea corectă. ”
• Ar fi mai plin de umor dacă ar spune ” Shirley ” în loc de ” Cu siguranță „.

Google sugerează două moduri diferite și ambele te elimină „în întregime.

Ghidul Google privind scrierea designului sugerează următoarele:

Omiteți expresiile inutile

Puteți sări peste multe fraze introductive obișnuite și să ajungeți direct la subiect.

Mai departe Dialogurile de alertă pentru proiectarea materialelor sugerează reformularea întrebării pentru a elimina „sunteți sigur?”

Alerte cu bare de titlu

Utilizați alerte cu bare de titlu numai pentru situații cu risc ridicat, cum ar fi pierderea potențială a conectivității. Utilizatorii ar trebui să poată înțelege opțiunile bazate doar pe titlu și pe textul butonului.

Dacă este necesar un titlu:

• Utilizați o întrebare sau o afirmație clară cu o explicație în zona de conținut, cum ar fi „Ștergeți stocarea USB?”.
• Evitați scuzele, ambiguitatea sau întrebările, cum ar fi „Atenție!” sau „Ești sigur?”

Este mai bine să nu aveți astfel de dialoguri , implementați funcționalitatea de anulare.

Dialogul este inutil 95% din timp, deci de ce îl forțați pe oameni? Încercați să ajutați oamenii? sau încercați să dați vina utilizatorului „hei, ați confirmat că doriți să ștergeți acel element important, nu mă învinovățiți! „.

Ghiciți ce, oamenii învață să ignore aceste dialoguri, întotdeauna subconștient confirmă orice acțiune tocmai au făcut.

Deci, aceasta este abordarea greșită pentru a rezolva problema.

Problema aici este: acțiunea utilizatorului poate avea efecte nedorite dacă este făcută din greșeală.

O soluție mai bună pentru asta problema ar fi aceea de a permite utilizatorului să revină la modificările sale.

Dacă le-ați permis să anuleze ștergerile, veți obține două lucruri bune:

• Nu trebuie să vă deranjați utilizatorul cu utilizare mai puține dialoguri.
• Utilizatorii se pot recupera după ștergerile neintenționate.

Implementarea anulării este mult mai dificilă decât afișarea unei casete de confirmare.

Ștergeți acest articol?

Continuați?

Chiar la obiect.

Un lucru critic de reținut este că oamenii ignoră mesajele „Ești sigur”. Trebuie să-i forțezi să se gândească la decizie. Iată una dintre favoritățile mele.

Comentarii

• Acestea devin iritante dacă trebuie să ștergeți o mulțime de lucruri (” conduce „, în acest caz), dar acest lucru funcționează bine când ‘ efectuați o acțiune ” fără a merge înapoi ” (bineînțeles, tu ar putea programa doar astfel încât să nu existe ‘ nici un tip de acțiune)
• Nu ‘ nu sunt sigur ce caseta de selectare ” nu poate anula „. Dacă nu ‘ o verific, voi putea anula? Sau butonul ” Nu va reveni ” butonul nu se va activa până când nu îl verific? Acest dialog se simte aproape ca o formă în sine, incluzând gestionarea erorilor și gestionarea stării elementelor UI. Dacă fac o greșeală în acest dialog, va apărea un dialog care îmi spune ce am greșit? 😉
• @Rahul: Sunt de acord cu dvs. Conceptul de aici este frumos (dacă nu poți ‘ t accepta Anularea), însă etichetarea este foarte ciudată. Chiar și butonul ” Fără revenire „. Cred că Can Not Undo este un fel de ” Sunt de acord cu termenii ” fel de confirmare, dar ‘ cred că
• Acest lucru este absolut îngrozitor.
• @Bennett, clienților le-a plăcut. Groaznic pentru tine este minunat pentru altcineva. Ceea ce contează sunt clienții. Toți ceilalți, puncte bune asupra frazării de anulare.

Ceea ce aveți este corect din punct de vedere gramatical, dar vă înțeleg.

Ați putea încerca să împărțiți mesajul în două fraze:

Acest element va fi șters, nu sigur?

Aceasta mută partea importantă a întrebării în față, unde (sperăm) că este mai probabil să fie citită.

Aș avea, de asemenea, tendința de a evita mesajele pentru acțiuni care pot fi anulate și de a reduce numărul acțiunilor care nu pot fi anulate la un nivel absolut.

Comentarii

• Și, desigur, înlocuiți this item cu numele real al articolului!
• @Jared – da – faceți-l explicit ce veți face.

Pentru mesajele critice doriți să fiți cât mai clar posibil și asigurați-vă că utilizatorul citește mesajul.

Mesaje precum

Făcând clic aici sunteți de acord că …

Sigur doriți să ….

Vă pierdeți pe utilizator, utilizatorul îl citește ca yada, yada, yada, orice … și face clic pe da fără să caute.

Pentru a determina utilizatorul să citească mesajul în care trebuie să fie ordinea corectă.

• Denumiți acțiunea care va avea loc
• apoi avertismentul
• apoi întrebarea
• apoi acțiunea de luat.

Sunteți pe cale să vă trimiteți cererea, această acțiune nu poate fi anulată, doriți să continuați, faceți clic pe da pentru a continua sau faceți clic pe anulați

Acest lucru este puțin lung, dar dacă aveți nevoie ca utilizatorul să citească mesajul, acesta este cel mai sigur mod de parcurs. p>

Comentarii

• Mesajul dvs., deși este mai bun decât yadayada , are totuși o problemă – de ce fac clic pe ” da ” pentru a continua, în loc de ” continua ” buton? Ceva de genul acesta ar fi mai bun: Your application is ready to submit. If you continue, this can not be undone. Would you like to continue? [Continue] [Cancel]
• @Jared, punct bun, sună mai bine și ar fi mai scurt.
• Ce zici de un punchier versiune? ” Trimiți cererea? Acest lucru nu poate fi anulat. [Continuare] [Anulare] ” (De fapt, în multe cazuri, afirmarea că acțiunea nu poate fi anulată nu este utilă oricum.)

Regulamentul Apple Human Interface pentru Mac OS X are multe de spus casete de mesaje (panouri de alertă).

Numele butoanelor trebuie să corespundă acțiunii pe care utilizatorul o efectuează atunci când apasă butonul – de exemplu, Șterge, Salvează sau Șterge . Butonul din dreapta din dialog, butonul de acțiune, este butonul care confirmă textul mesajului de alertă. Butonul de acțiune este, de obicei, dar nu întotdeauna, butonul implicit.(Rețineți că în metodele Cocoa, butonul din dreapta este întotdeauna denumit butonul implicit, chiar dacă s-ar putea să nu fie.) Pentru mai multe informații, consultați „Respingerea dialogurilor”. div>

Problema cu API-ul Windows Message Box este că nu vă permite să specificați efectiv numele butoanelor pe care le doriți, ci vă cere să vă rulați propria casetă de mesaje sau să folosiți Da / Nu încorporat / OK / Butoane Cancel.

Pentru mai multe informații, iată un articol interesant despre problemele cu casetele de mesaje în general: De ce sunt casetele de mesaje Rău .

Comentarii

• Problemele din API-ul Windows Message Box sunt abordate de Task Dialog API. (Nou în Windows Vista)

Nu este întotdeauna vorba despre aceste acțiuni explicite precum ștergerea, ștergerea, save..etc .. Pot exista anumite scenarii în care utilizatorul poate ieși, fără să știe, dintr-un proces critic în desfășurare.

De exemplu: utilizatorul se află în mijlocul plății și apasă butonul Înapoi.

În acest scenariu, utilizatorul trebuie să fie alertat.