Hibák, visszajelzés és állapotok

Célok

A lecke végére egy fő feladat állapotait (normál, betöltő, üres, hiba-, siker- és tiltott állapot) meg tudod tervezni. Érted, hogy a hibaüzenet nem technikai napló, hanem a felhasználó következő döntését segítő tartalom.

Miért az „ideális út” nem elég?

Egy tervezési munka legkönnyebb része az, amikor mindenki tudja a dolgát és minden működik. A legtöbb valódi bizonytalanság viszont a nem ideális pillanatokban keletkezik: amikor lassú a hálózat, elfogyott a hely, hibás adatot írtak be, vagy az eredmény üres. Ha a tervben ezek nem szerepelnek, a fejlesztő vagy a felhasználó talál ki valamit, és az ritkán lesz jó. A tervező egyik legfontosabb feladata, hogy ezeket előre végiggondolja.

Nem csak a „normál” képernyő létezik

Minden fő képernyőhöz gondold végig legalább az alábbi UI-állapotokat (a felület egy adott pillanatbeli megjelenését és viselkedését):

Állapot	Mikor áll elő?	Mit kell megmondani?
Normál	Minden adat elérhető	A fő információ és a fő művelet
Betöltő	Folyamatban van valami	Hogy a rendszer dolgozik, és (ha lehet) meddig
Üres	Nincs még tartalom, vagy a szűrő nem ad találatot	Miért üres, és mi a következő lépés
Hiba	A művelet nem sikerült	Mi történt, mi maradt meg, mit tegyen
Siker	A művelet sikerült	Mi lett meg, és mi a következő lépés
Tiltott	A művelet most nem elérhető	Miért, és mi kell hozzá

A pusztán szürke gomb nem feltétlenül érthető, különösen akkor, ha a felhasználó nem látja, milyen feltétel hiányzik.

Betöltés és várakozás

A betöltő állapot a folyamatban lévő műveletet jelző felületi állapot. A várakozás akkor bizonytalanító, ha a felhasználó nem tudja, történt-e valami, mennyi időre számíthat, vagy szabad-e újra próbálkoznia. Rövid várakozásnál elég lehet az azonnali vizuális visszajelzés (például a gomb betöltő állapota); hosszabb folyamatnál a rendszernek meg kell mondania, min dolgozik, és lehetőség szerint meg kell tartania a már bevitt adatot. Kerüld a megtévesztő előrehaladást: ne mutass 90%-on megálló sávot, ha nincs valós kapcsolat a folyamat állapotával.

Üres állapot

Az üres állapot olyan állapot, amikor még nincs vagy a szűrés miatt nincs megjeleníthető tartalom. Az üres lista nem egyenlő a hibával. Lehet, hogy új fiókban még nincs foglalás, vagy a szűrés nem ad találatot. A jó üres állapot megnevezi a helyzetet, röviden elmondja az okot, és ad egy következő lépést. „Még nincs mentett eseményed. Böngéssz a mai programok között.” Sokkal hasznosabb, mint az üres fehér terület vagy a „Nincs adat” rendszerüzenet.

Hibaüzenet mint segítség

A hibaállapot a feladat sikeres folytatását akadályozó vagy bizonytalanná tevő helyzet kommunikációja. Egy jó hibaüzenet három kérdésre válaszol:

1. Mi történt? (érthetően, felhasználói nyelven)
2. Mi a következmény? (mi veszett el, mi maradt meg)
3. Mit tehet most a felhasználó? (konkrét következő lépés)

Példa: „Nem sikerült menteni. A módosításaid nem vesztek el; próbáld újra, vagy töltsd le piszkozatként.” A szövegnek nem kell feltárnia belső hibakódot, de ha az ügyfélszolgálatnak szüksége van rá, külön, másolható formában megjeleníthető.

Űrlapnál a hiba legyen a mezőhöz kötve, lehetőleg a beküldés után összefoglalva is. Ne csak azt írd, hogy „kötelező mező”, hanem nevezd meg a hiányzó adatot és a várt formátumot. A hiba állapota maradjon észlelhető szín nélkül is (lásd az előző leckét).

Hasznos különbség: a megelőző és a javító hibakezelés. Megelőző: a mező már gépelés közben jelzi, ha a formátum rossz (de ne jelezzen hibát még gépelés előtt!). Javító: a beküldés után mondja meg, mit kell másképp csinálni.

Siker és következő lépés

A sikerállapot a művelet eredményét és lehetséges következő lépéseit megmutató állapot. A sikerállapot lezárja a jelenlegi feladatot, de gyakran megnyitja a következőt. Jelentkezés után például a felhasználónak tudnia kell a dátumot, helyszínt, módosítás lehetőségét és az értesítés módját. A „Sikeres!” önmagában nem ad elég bizalmat. Ha a folyamat késleltetett feldolgozású, ne ígérj végleges eredményt: mondd ki, hogy a kérés beérkezett, és mikor várható válasz.

Állapotdiagram: keresés a Mai programban

flowchart TD
    A["Keresés indítása"] --> B["Betöltés"]
    B --> C{"Érkezett válasz?"}
    C -->|Nem| D["Hiba: magyarázat és újrapróbálás"]
    C -->|Igen| E{"Van találat?"}
    E -->|Nem| F["Üres: segítség a szűrők módosításához"]
    E -->|Igen| G["Találatok: következő lépés kiválasztása"]
    D --> A
    F --> A

Az ábra azt mutatja, hogy egyetlen keresésnek legalább négy kimenete van, és mindegyikhez külön felületi állapot tartozik. Ha csak a „Találatok” képernyőt rajzoljuk meg, a másik három kimenetet a fejlesztőre bízzuk.

Végigvezetett példa: keresés nulla találattal

A Mai programban valaki beállítja a „ma este”, „ingyenes” és „angol nyelvű” szűrőket. A „Nincs találat” technikailag igaz, de nem segít. A jó állapot megmutathatja, melyik feltétel szűkít leginkább („A »ma este« és »ingyenes« együtt 0 találatot ad; csak az »ingyenes« 3-at.”), felajánlhatja a következő napot vagy a közeli helyszínt, és egy kattintással visszaállíthatóvá teheti a szűrőket. A rendszer nem erőltet másik választást, csak segít megérteni a jelenlegi eredményt.

Gyakori tévhitek

Állítás	Pontosítás
„A hibaoldal ritka, ezért nem kell tervezni.”	A ritka, de nagy következményű hibákban különösen fontos a világos kommunikáció.
„A spinner elegendő betöltési visszajelzés.”	Csak akkor, ha a várakozás rövid és a felhasználó tudja, mi változik majd.
„A sikerállapot dekoráció.”	A feladat lezárásának és a következő lépés megértésének kulcsa lehet.
„A hibaüzenet legyen minél rövidebb.”	Akkor jó, ha megmondja, mi történt, mi a következmény és mit tegyen a felhasználó; ehhez gyakran több szó kell.

Röviden

• Minden fő képernyőnek legalább hat állapota van: normál, betöltő, üres, hiba, siker, tiltott.
• A hibaüzenet három kérdésre válaszol: mi történt, mi a következmény, mit tegyek.
• Az üres állapot nem hiba; nevezze meg a helyzetet, és ajánljon következő lépést.
• A sikerállapot lezárja a feladatot, és tájékoztat a következményről.

Ellenőrző kérdések

1. Milyen állapotok hiányoznak a jelenlegi prototípusodból?
2. Egy hibaüzeneted megmondja-e, mi történt, mi maradt meg és mi a teendő?
3. Hogyan segítenéd a nulla találatos keresést anélkül, hogy elrejtenéd a valóságot?
4. Mit kell tudnia a felhasználónak közvetlenül a sikeres művelet után?