Milyen alternatívák vannak a “ kifejezésre? Biztosan XYZ ” -t szeretne a megerősítő párbeszédablakokban?

Ennek oka, hogy az emberek átugorják a hosszú üzeneteket, az olvasási sebességnek köszönhető.

Tegyük fel, hogy a vita kedvéért valaki átlagos olvasási sebességgel – körülbelül 200 szó / perc. (*)

Ha csak 20 szót használ egy párbeszédablakban, akkor ezt kéri a felhasználó 6 másodpercet fordítson arra, hogy elolvassa és megértse, amit írt.

Bár ez nem hangzik olyan soknak, egy hat másodperces szünet, amikor valamit megpróbál végrehajtani, borzasztóan hosszú időnek tűnhet .

(*) És ne kövesse el azt a hibát, hogy azt feltételezi, hogy az alacsony olvasási sebesség alacsony intelligenciát jelent.

Tehát három javaslat az Ön számára, amelyek mindegyike a maximális egyértelműségre és minimális felhajtásra irányul.

1. Legyen a lehető legtömörebb
2. Azonosítsa a veszélyeztetett tételt
3. Nevezze el a gombokat a műveletekhez

Itt található egy egyszerű törlési párbeszédpanel:

Csökkentsük a szavak számát a minimumra, hogy megkönnyítsék az olvasást:

Most azonosítsuk a veszélyeztetett tételt, és jelöljük meg a művelet gombjait:

Sokkal jobb – könnyebben olvasható és tisztább.

Egy másik példa – folytatódási párbeszédpanel.

Egyszerűsítse a megfogalmazást.

Ismét hagyja, hogy “s azonosítsák, mi folyik, és jelöljék meg a gombokat a műveletek.

Határozott javulás.

Itt a végső gondolat. Kerülje a negatívumokat , especia lly kettős negatívumok. Egyes angol anyanyelvűek dupla negatívumokat találnak trükkösnek, és sokan, akik az angolt második nyelvként tanulják, zavarónak találják őket (különösen, ha anyanyelvük kettős negatívokat használ a hangsúlyozáshoz az inverzió helyett).

Megjegyzések

• Vagy elolvashatja a Windows UX irányelveit msdn.microsoft.com/en-us/library/aa511258.aspx ahol valójában erről írnak 🙂
• Úgy gondolom, hogy Ön valóban mutat néhány rossz példát: 1. ” OK “, nem ” Ok “. 2. Ha igen / nem kérdést tesz fel, a lehetséges válaszoknak igennek vagy nemnek kell lenniük, természetesen nem OK és Mégsem. 3. Ha azonosítja a művelethez tartozó gombokat, akkor ezt mindkét gombbal kell megtennie, nem csak egyikkel (pl. Törlés / Tartás, nem Törlés / Mégse). Ezen kívül úgy gondolom, hogy minden mondatnak tartalmaznia kell legalább egy tárgyat és egy igét , de ez személyes.
• @BaGi – Úgy gondolom, hogy rosszul olvashatta a válaszomat: Én ‘ m mutatom a szegényből a jobb felé haladást. Ha van egy Igen / Nem kérdésem az Ok / Mégse opcióval, mivel a gombok biztosan gyengék, de túlságosan komikusak, erre rámutattam. Pontjainak kezelése … Ahol egyszerű inverz van, annak van értelme használni a Mégse gomb használatát – tehát a Törlés / Tartás jobb, mint a Törlés / Mégse, de ez nem ‘ t mindig lehetséges – mi ‘ s a Post fordítottja? Post / Don ‘ t A poszt ügyetlennek tűnik. És azt hiszem, hogy az összes példám teljes mondat. Az utolsó felvétele: ” Folytatás “: ige; ” Tranzakció feldolgozása “: tárgy.
• @Bevan: Nem ‘ nem gondolod, hogy Post? Post / Don ‘ t A poszt ügyetlen. Mentés / ne ‘ A mentés az, amit folyamatosan lát. Az utolsó mondatban ” a tranzakció feldolgozása ” egyáltalán nem téma, hanem közvetett objektum (lásd: hu.wikipedia.org / wiki / Object_% 28grammar% 29 ). Megértettem, hogy példái fokozatos javulást mutatnak, szerintem a végeredmény még mindig tartalmaz néhány kisebb hibát.
• @BartGijssens: Én ‘ d mindig jobban szeretem a Cancel bármi másra … mert egyetlen idegsejt égése nélkül tudom, hogy nem csinál semmit (gyakorlatilag egy szóval kevesebbet kell olvasni). Az a probléma, hogy ” ne ‘ ne mentse el “, hogy használhatja a ” Dobja el az ” elemeket valamilyen más (rossz) kontextusban.

Mindig pontot teszek, hogy megmutassam a felhasználónak, hogy melyik elem törlésre kerül (különösen azért, mert a párbeszédablak elhomályosíthatja a kérdéses elemet, de azért is, mert azonosíthatónak látom a párbeszéd szövege felhívja a figyelmet):

Törli a “kedvenc elemét”?

Itt-ott is adhat egy kis humort, attól függően, hogy milyen alkalmazást készít:

Biztosan nem ” mentés nélkül akarja folytatni? [Igen, igen, hagyj békén] [Na jó, köszönöm, hogy emlékeztettél]

Ha felhasználó teszteled, észreveszed, hogy humoros üzenetek érkeznek kissé gyakrabban vették észre, egyszerűen azért, mert valamennyire kitűnnek a generikus üzenetek tömegéből, és (ha valóban elég aranyosak) mosolyt csalnak a felhasználó arcára. Mit akarhat még?

Megjegyzések

• Vagy követheti az ökölszabályomat: Minden párbeszédgombot fel kell tüntetni ” D ‘ ó! “, még akkor is, ha több gomb van.
• @ VirtuosiMedia Ha két gomb van, akkor csak egyet kell címkézni ” D ‘ oh! ” A másikat fel kell tüntetni ” Miért keveset …! ”
• ” … 14 felhasználó kattintott a Do ‘ h gombra, 5 felhasználó a Nut gombra, és egy felhasználó többször megnyomta az M gombot. ” – Jakob Nielsen
• ” … Mind a 20 felhasználó meglepetését fejezte ki az ezt követő piros vészjelző lámpák, szirénák és evakuálási figyelmeztetések miatt a nukleáris olvadás előtt. A túlélők később megemlítették, hogy szakadtak a biztonság elől való menekülés és a hűtőben található dolgok között. A tapasztalattól megrendülve látszott, hogy vajon jól döntöttek-e. ”
• Humorikusabb lenne, ha a következőt írnák: ” Shirley ” ” biztosan “.

A Google kétféle módot javasol, és mindkettő eltávolítja Önt “teljesen.

A Google tervezési írási irányelvei a következőket javasolja:

Felesleges kifejezések kihagyása

Számos általános bevezető kifejezést kihagyhat, és rögtön a lényegre térhet.

További Anyagtervezési riasztási párbeszédpanelek javasolják a kérdés újrafogalmazását a “biztos vagy benne?”

Címsorokkal ellátott riasztások

A címsor riasztásait csak nagy kockázatú helyzetekhez használja, például a kapcsolat elvesztéséhez. A felhasználóknak meg kell tudniuk érteni a választásokat csak a cím és a gomb szövege alapján.

Ha címre van szükség:

• Használjon világos kérdést vagy állítást, magyarázattal együtt a tartalmi terület, például “Törli az USB-háttértárat?”.
• Kerülje a bocsánatkérést, a kétértelműséget vagy a kérdéseket, például a „Figyelem!” vagy „Biztos vagy benne?”

Jobb, ha nincsenek ilyen párbeszédpanelek , hajtsa végre a visszavonási funkciókat.

A párbeszédpanel az esetek 95% -ában haszontalan, akkor miért kényszerítené rá az embereket? Segíteni próbál az embereknek? vagy a felhasználó hibájára akarja helyezni “hé, megerősítette, hogy törölni kívánja ezt a fontos elemet, ne hibáztasson engem!

Találd ki, az emberek megtanulják figyelmen kívül hagyni ezeket a párbeszédeket, tudat alatt mindig megerősítik az imént végrehajtott műveleteket.

Tehát ez a probléma megoldásának helytelen megközelítése.

A probléma itt áll: a felhasználói műveletek nem kívánt hatásokkal járhatnak, ha tévedésből történnek.

Erre jobb megoldás A probléma az lenne, ha lehetővé tenné a felhasználó számára, hogy visszavonja a változtatásokat.

Ha megengedted nekik a törlések visszavonását, két jó dolog lesz:

• Nem kell bosszantanod a felhasználót kevesebb párbeszédpanel.
• A felhasználók felépülhetnek akaratlan törlésekből.

A visszavonás végrehajtása sokkal nehezebb, mint egy megerősítő mező megjelenítése.

Törli ezt az elemet?

Folytatja?

Egyenesen a lényegre.

Fontos megjegyezni, hogy az emberek figyelmen kívül hagyják a “Biztosak benne” üzeneteket. Kényszeríteni kell őket, hogy gondolkodjanak el a döntésen. Itt van az egyik előnyöm.

Megjegyzések

• Ezek irritálóvá válnak, ha sok mindent törölnie kell (ebben az esetben ” vezet “), de ez jól működik amikor ‘ egy ” nem megy vissza ” művelet (természetesen Ön programozhatná úgy, hogy ne legyen ‘ t bármilyen típusú művelet is)
• Nem vagyok biztos benne, mi a ” nem vonhatja vissza a ” jelölőnégyzetet. Ha nem ellenőrzem ‘, akkor visszavonhatom? Vagy a ” Nincs visszaút ” gomb csak akkor aktiválódik, ha megnézem? Ez a párbeszéd szinte úgy érzi magát, mint egy űrlap, beleértve a hibakezelést és a felhasználói felület elemállapot-kezelését. Ha hibát követek el ebben a párbeszédben, megjelenik-e egy párbeszéd, amely elmondja, mit tettem rosszul? 😉
• @Rahul: Egyetért veled. A koncepció itt szép (ha ‘ nem tudja visszavonni), de a címkézés nagyon furcsa. Még a ” Nincs visszaút ” gomb. Úgy gondolom, hogy a Nem lehet visszavonni olyan, mint egy ” egyetértek a ” megerősítés feltételeivel, de a ‘ csak az a tippem,
• Ez egyszerűen szörnyű.
• @Bennett, az ügyfelek szerették. Szörnyű neked, nagyszerű másnak. Ami számít az ügyfeleknek. Mindenki más, jó pontok a megfogalmazás visszavonásához.

Amit kapott, nyelvtanilag helyes, de elfogadom a véleményed.

Megpróbálhatod két mondatra bontani az üzenetet:

Ez az elem törlődik, ugye biztos?

Ez a kérdés fontos részét előtérbe mozgatja, ahol (remélhetőleg) nagyobb valószínűséggel olvassák.

Én is hajlamos vagyok kerülni a visszavonható műveletek üzeneteit, és a visszavonhatatlan műveletek számát abszolút minimumra csökkenteni.

Megjegyzések

• És természetesen cserélje le az this item elemet az elem tényleges nevével!
• @Jared – igen – tegye egyértelművé, hogy mit fog tenni.

A kritikus üzeneteknél a lehető legtisztábbnak kell lennie, és ellenőrizze, hogy a felhasználó elolvasta-e az üzenetet.

Olyan üzenetek, mint

Ide kattintva elfogadja, hogy …

Biztos benne, hogy …

Tévedjen el a felhasználó: A felhasználó yada, yada, yada, bármi … néven olvassa el, és anélkül kattint, hogy megnézné.

Ahhoz, hogy a felhasználó elolvassa azt az üzenetet, amelyben szerepelnie kell a megfelelő sorrend.

• Nevezze meg a bekövetkező műveletet
• majd a figyelmeztetést
• majd a kérdést
• majd a műveletet megteszi.

Jelentkezés benyújtására készül, Ezt a műveletet nem lehet visszavonni, Folytatja, kattintson igen a folytatáshoz, vagy kattintson a Mégse gombra.

Ez egy kicsit hosszú, de ha a felhasználónak el kell olvasnia az üzenetet, ez a legbiztonságosabb lépés.

Megjegyzések

• Bár az üzenetének jobb, mint a yadayada nak, mégis van problémája – miért kattintok a igen ” a folytatáshoz ” folytatás ” gomb? Valami ilyesmi jobb lenne: Your application is ready to submit. If you continue, this can not be undone. Would you like to continue? [Continue] [Cancel]
• @Jared, Jó pont, jobban szól, és rövidebb lenne.
• Mit szólna egy lyukasztóhoz változat? ” Elküldi jelentkezését? Ezt nem lehet visszacsinálni. [Folytatás] [Mégse] ” (Valójában sok esetben az sem mond hasznosat, ha azt mondják, hogy a műveletet nem lehet visszavonni.)

Az Apple Mac felhasználói felületre vonatkozó emberi irányelvei sok mindent el tudnak mondani üzenetdobozok (riasztási panelek).

A gombneveknek meg kell felelniük a felhasználó által a gomb megnyomásakor végrehajtott műveletnek – például Törlés, Mentés vagy Törlés . A párbeszédablak jobb szélső gombja, a műveletgomb az a gomb, amely megerősíti a figyelmeztető üzenet szövegét. A művelet gomb általában, de nem mindig az alapértelmezett gomb.(Ne feledje, hogy a Kakaó módszereknél a jobb szélső gombot mindig alapértelmezett gombnak nevezzük, bár lehet, hogy nem az.) További információ: „Párbeszédek elvetése”.

A Windows Message Box API problémája az, hogy nem teszi lehetővé a kívánt gombok nevének tényleges megadását, ehelyett a saját üzenetdobozának tekercselésére vagy a beépített Igen / Nem használatára van szükség. / OK / Mégse gombok.

További olvasnivalókért itt talál egy érdekes cikket, amely az üzenetsorok problémáival foglalkozik általában: Miért vannak az üzenetsorok Gonosz .

Megjegyzések

• A Windows Message Box API problémáit a Feladat párbeszédpanel API. (Új a Windows Vista rendszerben)

Nem mindig ezekről a kifejezett műveletekről van szó, például törlés, törlés, save..stb .. Vannak bizonyos esetek, amikor a felhasználó öntudatlanul kiléphet egy folyamatban lévő kritikus folyamatból.

Például: A felhasználó a fizetés közepén van, és megnyomja a Vissza gombot.

Ebben a forgatókönyvben a felhasználót figyelmeztetni kell.