Hva er noen alternativer til uttrykket “ Er du sikker på at du vil XYZ ” i bekreftelsesdialoger?

En del av årsaken til at folk hopper over lange meldinger skyldes lesehastighet.

Anta for diskusjonens skyld noen med en gjennomsnittlig lesehastighet – rundt 200 ord per minutt. (*)

Hvis du bare bruker 20 ord i en dialog, ber du om brukeren skal bruke 6 sekunder på å lese og forstå hva du skrev.

Selv om det ikke høres ut som mye, kan en seks sekunders pålagt pause når du prøver å få gjort noe, synes å være veldig lang tid .

(*) Og gjør ikke feilen ved å anta at lav lesehastighet betyr lav intelligens.

Så tre forslag til deg, alle rettet mot maksimal klarhet med minimalt oppstyr.

1. Vær så kortfattet som mulig
2. Identifiser gjenstanden i fare
3. Navngi knappene dine for handlingene

Her er en enkel slettingsdialog:

La oss redusere antall ord til et minimum for å gjøre det lettere å lese:

La oss nå identifisere elementet i fare, og merk knappene for handlingen:

Mye bedre – lettere å lese og tydeligere.

Et annet eksempel – en fortsettelsesdialog.

Forenkle ordlyden.

Igjen, la oss identifisere hva som skjer og merke knappene for handlinger.

En klar forbedring.

Her «er en siste tanke. Unngå negative , especia lly doble negativer. Noen morsmåls engelsktalende synes at dobbeltnegativer er vanskelige, og mange som lærer engelsk som andrespråk, synes de er forvirrende (spesielt hvis morsmålet deres bruker dobbeltnegativer for vekt i stedet for inversjon).

• Eller du kan bare lese Windows UX-retningslinjene msdn.microsoft.com/en-us/library/aa511258.aspx hvor de faktisk skriver om dette 🙂
• Jeg tror du faktisk setter noen dårlige eksempler: 1. Det er » OK «, ikke » Ok «. 2. Hvis du stiller et ja / nei-spørsmål, må de mulige svarene være ja eller nei, absolutt ikke OK og Avbryt. 3. Hvis du identifiserer knappene for handlingen, må du gjøre dette med begge knappene, ikke bare med en (dvs. Slett / Behold ikke Slett / Avbryt) Bortsett fra det, tror jeg også at enhver setning i det minste må inneholde et emne og et verb , men det er personlig.
• @BaGi – Jeg tror du kan ha lest feil svaret mitt: Jeg ‘ viser en progresjon fra dårlig til bedre. Å ha et Ja / Nei-spørsmål med Ok / Avbryt da knappene absolutt er dårlige, men er altfor vanlige, og dette var det jeg påpekte. For å adressere poengene dine … Hvor det er en enkel invers, er det fornuftig å bruke den til Avbryt-knappen – så Slett / Behold er bedre enn Slett / Avbryt, men dette er ikke ‘ t alltid mulig – hva ‘ er det omvendte av Post? Innlegg / Don ‘ t Innlegg virker klønete. Og jeg tror alle eksemplene mine er fulle setninger. For å ta den siste: » Fortsett «: verb; » Transaksjonsbehandling «: emne.
• @Bevan: Jeg don ‘ t think Post? Post / Don ‘ t Innlegg er klønete. Lagre / ikke ‘ t lagre er det du ser hele tiden. I din siste setning er » prosesseringsbehandling » slett ikke et emne, men et indirekte objekt (se no.wikipedia.org / wiki / Object_% 28grammar% 29 ). Jeg forsto eksemplene dine viser en gradvis forbedring. Jeg tror bare det endelige resultatet fortsatt inneholder noen mindre feil.
• @BartGijssens: Jeg ‘ Jeg foretrekker alltid Cancel til noe annet … for uten en eneste nevronskyting vet jeg at det ikke gjør noe (faktisk ett ord mindre å lese). Problemet med » Don ‘ t lagre » er at den kan bruke » Kast » i en annen (dårlig) sammenheng.

Jeg gjør alltid et poeng av å vise brukeren hvilket element som blir slettet (spesielt siden dialogen kan skjule det aktuelle elementet, men også fordi det ser identifiserbart tekst i dialogen vil vekke oppmerksomhet):

Slette «favorittelementet ditt»?

Du kan også injisere litt humor her og der, avhengig av hva slags app du lager:

Du vet sikkert ikke vil fortsette uten å lagre? [Ja jeg gjør det, la meg være i fred] [Åh, takk for at du påminner meg om det]

Hvis du bruker det, vil du legge merke til at humoristiske meldinger får la merke til litt oftere rett og slett fordi de skiller seg ut fra mengden med generiske meldinger og (hvis de faktisk er søte nok) får et smil om munnen på brukeren. Hva mer kan du ønske deg?

Kommentarer

• Eller du kan bare følge min tommelfingerregel: Alle dialogknappene må være merket » D ‘ oh! «, selv om det er flere knapper.
• @ VirtuosiMedia Hvis det er to knapper, skal bare én merkes » D ‘ oh! » Den andre skal merkes » Hvorfor er du liten …! »
• » … 14 brukere klikket på Do ‘ h, 5 brukere klikket på Nut, og en bruker trykkte M-tasten gjentatte ganger. » – Jakob Nielsen
• » … Alle de 20 brukerne uttrykte overraskelse over de påfølgende røde nødlys, sirener og advarsler om å evakuere før kjernefysisk nedsmelting. De som overlevde, nevnte senere at de var revet mellom å flykte for sikkerhet og se hva som var i kjøleskapet. Rystet av opplevelsen så de ut til å lure på om de hadde tatt det riktige valget. »
• Det ville vært mer humoristisk om det sto » Shirley » i stedet for » Sikkert «.

Google foreslår to forskjellige måter, og begge fjerner deg «helt.

Retningslinjer for Googles designskriving foreslår følgende:

Utelat unødvendige setninger

Du kan hoppe over mange vanlige innledende setninger og komme rett til poenget.

Videre Varslingsdialoger for materialdesign foreslår omformulering av spørsmålet for å fjerne «er du sikker?»

Varsler med tittellinjer

Bruk kun tittellinjevarsler i høyrisikosituasjoner, for eksempel potensielt tap av tilkobling. Brukere skal kunne forstå valgene basert på tittel og knappetekst alene.

Hvis det kreves en tittel:

• Bruk et klart spørsmål eller utsagn med en forklaring i innholdsområdet, for eksempel «Slett USB-lagring?».
• Unngå unnskyldninger, tvetydighet eller spørsmål, for eksempel «Advarsel!» eller “Er du sikker?”

Det er bedre å ikke ha slike dialoger, i stedet , implementer angre funksjonalitet.

Dialogen er ubrukelig 95% av tiden, så hvorfor tvinge den til folk? Prøver du å hjelpe folk? eller prøver du å legge skylden på brukeren «hei, du bekreftet at du ønsket å slette det viktige elementet, ikke skyld på meg! «.

Gjett hva, folk lærer å ignorere disse dialogene, de bekrefter alltid ubevisst hvilken handling de nettopp gjorde.

Slik at det er feil tilnærming for å løse problemet.

Problemet her er: brukerhandling kan ha uønskede effekter hvis det gjøres ved en feiltakelse.

En bedre løsning for det problemet ville være å tillate brukeren å tilbakestille endringen.

Hvis du tillot dem å angre sletting, får du to gode ting:

• Du trenger ikke å irritere brukeren med bruk mindre dialoger.
• Brukere kan komme seg fra utilsiktede slettinger.

Å implementere angre er mye vanskeligere enn å vise en bekreftelsesrute.

Slett dette elementet?

Fortsett?

Rett til punktet.

En viktig ting å huske er at folk ignorerer «Er du sikker» -meldingene. Du må tvinge dem til å tenke på avgjørelsen. Her er en av favorittene mine.

Kommentarer

• Disse blir irriterende hvis du må slette mange ting (» fører «, i dette tilfellet), men dette fungerer bra når du ‘ tar en » ingen vei tilbake » handling (selvfølgelig kunne bare programmere slik at det ikke er ‘ t noen handling også)
• Jeg ‘ jeg er ikke sikker på hva » kan ikke angre » avmerkingsboksen. Hvis jeg ikke ‘ ikke sjekker det, vil jeg kunne angre? Eller vil » Ingen vei tilbake » -knappen ikke aktiveres før jeg sjekker den? Denne dialogen føles nesten som et skjema i seg selv, inkludert feilhåndtering og UI-elementtilstandsadministrasjon. Hvis jeg gjør en feil i denne dialogen, vil den dukke opp en dialog som forteller meg hva jeg gjorde galt? 😉
• @Rahul: Enig med deg. Konseptet her er fint (hvis du ikke kan ‘ t støtte Angre), men merkingen er veldig rar. Selv » No Going Back » -knappen. Jeg tror Kan ikke angre er som en » Jeg godtar vilkårene » slags bekreftelse, men at ‘ er bare min gjetning
• Dette er bare helt forferdelig.
• @Bennett, kundene elsket det. Forferdelig for deg er flott for noen andre. Det som betyr noe er kundene. Alle andre, gode poeng på angre formulering.

Det du har er grammatisk riktig, men jeg tar poenget ditt.

Du kan prøve å dele meldingen i to setninger:

Dette elementet blir slettet, er du sikker?

Dette flytter den viktige delen av spørsmålet til fronten der det (forhåpentligvis) er mer sannsynlig å bli lest.

Jeg vil også ha en tendens til å unngå meldinger om handlinger som kan angres og redusere antall angrebare handlinger til et absolutt minimum.

Kommentarer

• Og, selvfølgelig, erstatt this item med det faktiske navnet på varen!
• @Jared – ja – gjør det eksplisitt hva du skal gjøre.

For kritiske meldinger vil du være så tydelig som mulig og sørge for at brukeren leser meldingen.

Meldinger som

Ved å klikke her godtar du at …

Er du sikker på at du vil ….

Gå deg vill på bruker, brukeren leser det som yada, yada, yada, uansett … og klikker ja uten å se.

For å få brukeren til å lese meldingen den må være i riktig rekkefølge.

• Nevn handlingen som vil skje
• så advarselen
• så spørsmålet
• så handlingen å ta.

Du er i ferd med å sende inn søknaden din. Denne handlingen kan ikke fjernes. Vil du fortsette, klikk ja for å fortsette eller klikk avbryt

Dette er litt langt, men hvis du trenger at brukeren skal lese meldingen, er dette den tryggeste veien å gå.

Kommentarer

• Meldingen din, selv om den er bedre enn yadayada , har fortsatt et problem – hvorfor klikker jeg på » ja » for å fortsette, i stedet for en » fortsett » -knapp? Noe som dette ville vært bedre: Your application is ready to submit. If you continue, this can not be undone. Would you like to continue? [Continue] [Cancel]
• @Jared, Godt poeng, høres bedre ut og ville vært kortere.
• Hva med en punchier versjon? » Send inn søknaden din? Dette kan ikke angres. [Fortsett] [Avbryt] » (I virkeligheten er det i mange tilfeller ikke nyttig å si at handlingen kan angres.)

Apples retningslinjer for menneskelig grensesnitt for Mac OS X har en god del å si om meldingsfelt (varslingspaneler).

Knappnavn skal svare til handlingen brukeren utfører når du trykker på knappen – for eksempel Slett, Lagre eller Slett . Den høyre knappen i dialogboksen, handlingsknappen, er knappen som bekrefter teksten for varselmeldingen. Handlingsknappen er vanligvis, men ikke alltid, standardknappen.(Vær oppmerksom på at i kakao-metoder blir den høyre høyre knappen alltid referert til som standardknappen, selv om den kanskje ikke er det.) For mer informasjon, se “Avvise dialoger.”

Problemet med Windows Message Box API er at det ikke lar deg faktisk spesifisere navnene på knappene du vil ha, i stedet for at du enten må rulle din egen meldingsboks eller bruke den innebygde Ja / Nei / OK / Avbryt-knapper.

For litt mer lesing, her er en interessant artikkel som snakker om problemene med meldingsbokser generelt: Hvorfor meldingsbokser er Onde .

Kommentarer

• Problemene i Windows Message Box API løses av Oppgavedialog API. (Nytt i Windows Vista)

Det handler ikke alltid om disse eksplisitte handlingene som sletting, sletting, save..etc .. Det kan være visse scenarier der brukeren uvitende kan gå ut av en pågående kritisk prosess.

For eksempel: Brukeren er midt i betalingen og trykker på tilbakeknappen.

I dette scenariet må brukeren varsles.