Webshark Blog

Mindenki találkozott már az optimista felhasználói felülettel, legfeljebb csak a fogalom ismeretlen számára, és hogy pontosan hogyan működik. Pedig elég jól meghatározható és könnyen megérthető a dolog. Amiből az is kiderül persze, hogy milyen előnyei vannak a felhasználók számára.

Az optimista felhasználói felület nem egy dolog, hanem egy gondolati modell, mely alkalmazható egy felhasználói felületen. A Smashing Magazine nemrég bemutatta egy bejegyzésben, hogy miről is van szó. Érdemes abból kiindulni, hogy mi előzte meg az optimista UI megjelenését, mert ezáltal még könnyebben megérthető miről is van szó.

Az előzmények

Sokan talán emlékeznek még arra, hogy annak idején – amikor az Apple a csőd szélén állt és az emberek névjegykártyájukon feltüntették a faxszámot – a weboldalak még kicsit nehezen használhatók voltak. Ehhez illeszkedett a gombok működése is, mely így nézett ki:

1. A felhasználó kattintott egy gombra.
2. A gomb átváltott egy inaktív, másik állapotba.
3. Egy kérés indult a szerver számára.
4. Visszaérkezett a válasz a szervertől.
5. Az oldal frissült a válasznak megfelelően.

Ezt a megoldást még mindig nagyon sokan használják weboldalakon, applikációkban, illetve sok termék esetében része az interakciós folyamatnak. Előnye, hogy többé-kevésbé hibamentes a működése: a felhasználó tudja, hogy lekérés történik a szerverről, hiszen jelzi azt számára a gomb, majd egyszer csak a szerver válaszol és a frissített oldalból kiderül, hogy sikeresen véget ért az interakciós folyamat. Vannak azonban problémák a dologgal:

• A felhasználónak várnia kell. Különösen akkor gond ez, ha a szerver válaszideje nagy.
• Akárhányszor választ kap a felhasználó, egy új oldal töltődik be, mely kiragadja a felhasználót a feladat kontextusából, ami nem feltétlenül szerencsés megoldás.

A web 2.0 megérkezésével változtak az interakciók a weboldalakon az XMLHttpRequest és az AJAX révén. Ez azonban csak annyit jelentett, hogy megjelentek változás-jelzők, melyek mutatták a felhasználónak, hogy a rendszer dolgozik. Emellett nem volt már szükség a teljes weboldal újratöltésére, elég volt a betöltött oldal egy részének frissítése. Ez javuló felhasználói élményt jelentett, ahol a folyamat így nézett ki:

1. A felhasználó kattintott.
2. A gomb váltott, és megjelent a folyamatjelző.
3. A kérés elküldésre került a szerverhez.
4. Válasz érkezett a szerverre.
5. A válasznak megfelelően frissült az oldal és a gomb.

Itt tehát már a felhasználót nem ragadta ki az oldal frissítése a feladat kontextusából. Ugyanakkor az embereknek továbbra is várniuk kellett a szerver válaszára. Az emberek pedig továbbra sem szerettek várni, annak ellenére, hogy a szerverek egyre gyorsabban válaszoltak. A folyamatjelzők nem sokat segítettek, mert a felhasználók a várakozással, a rendszer lassúságával azonosították őket. Hiszen miközben nézik őket nem tudnak mit tenni, csak passzívan várakozni, esetleg becsukni az oldalt vagy alkalmazást.

Mit tud az optimista felhasználói felület?

Az optimista felhasználói felület nem más, mint egyfajta módja az ember és a számítógép közötti interakció kezelésének. Arról szól, amit az “optimizmus” szó is jelent: bizakodó a jövőt tekintve.

Hányszor fordul elő, hogy a szerver válasza egy hibaüzenet? Általában nem túl sűrűn, hiszen jellemzően a gomb vagy a link működni szokott. Az esetek mintegy 1-3 százalékában jelez hibát a szerver, vagyis 97-99 százalékban, amikor a felhasználó rákattint egy gombra, akkor eredményes lesz a cselekvés. Ez pedig azt jelenti, hogy az interakciónak így kell kinéznie:

1. A felhasználó kattint a gombra.
2. A gomb pedig azonnal jelzi számára, hogy sikeres volt az akció.

Ennyi. Ez elegendő is, hiszen a felhasználó megtette, amit akart, más dolga nincs. Nem kell várnia, és közben néznie egy folyamatjelzőt. Természetesen a fejlesztő szempontjából a folyamat egy kicsit másként néz ki:

1. A felhasználó kattint a gombra.
2. A gomb visszajelzi a sikert.
3. A kérés elindul a szerver felé.
4. Megérkezik a válasz.
5. Az esetek 97-99 százalékában tudjuk, hogy nem lesz gond, így már nem zavarjuk a felhasználót.
6. Ha hiba van, a rendszer jelez a felhasználónak.

Így működik a Facebook lájk-gombja is, amit mindenki ismer. A Facebook nem vár a szerver válaszára a visszajelzéssel, hanem azt mutatja a felhasználónak, hogy sikerrel járt a kattintás, a lájkszámlálót pedig lépteti eggyel. A Facebook és más közösségi oldalak gombjainak ezen működésére nem nagyon van panasz, tehát az optimista felhasználói felület a gyakorlatban is működik, mert az emberek nem szeretnek várni. Na, de mégis mi van akkor, ha valami hiba következik be?

Hogyan jelzi az optimista IU, ha hiba van?

Az optimista felhasználói felület tehát bizonyos nézőpontból hazugságot, más nézőpontból viszont előrejelzést jelent. Hogy melyikről van szó, azt az dönti el, hogy a hibákat miként kezeljük. A problémát ugyanis kommunikálni kell, mégpedig lehetőleg 2 másodpercen belül, amíg a felhasználó még benne van a folyamatban. A Twitter például azt teszi, hogy egyszerűen visszaállítja a gombot az eredeti állapotába, ha a válasz hiba.

Nyilván akad olyan, aki szerint ez nem elég, hiszen a felhasználó számára kifejezetten jelezni kellene, hogy hiba történt. Ezáltal válna a rendszer teljesen átláthatóvá. Ugyanakkor ez mégsem olyan jó ötlet:

• Bármilyen üzenet, ami megjelenik a kijelzőn, megzavarja a felhasználót, aki azzal kezd foglalkozni, hogy elemezze a hiba mögött megbújó okot. Ez az ok vélhetően a hibaüzenetben szerepelne.
• Ennek a hibaüzenetnek vezetnie kellene a felhasználót, végrehajtható információkat adva számára.
• A végrehajtható információk azonban már egy új kontextusba helyezik a felhasználót, tehát kikerül az eredeti feladat kontextusából.

A hiba kommunikációjának igazodnia kell a helyzethez. Egy visszaváltozó gomb erre éppen megfelelő. Felmerül azonban egy újabb kérdés: mi van, ha a felhasználó még azt megelőzően bezárja a böngészőjét, hogy a rendszer vissza tudná jelezni számára a hibát. A legrosszabb esetben még azelőtt bezárhatja, hogy a kérés egyáltalán elküldésre kerülhetne a szerver felé. Ez azonban aligha valószínű. Még az sem nagyon, hogy azt megelőzően bezárná, hogy a rendszer vissza tudná jelezni a hibát. Ugyanakkor, ha ez valamiért a Te esetedben valódi gondot jelent, akkor az optimista interakciókat csak a kevésbé fontos elemeknél vedd használatba!

A lényeg

Ha belevágnál Te is az optimista felhasználói felület kialakításába, akkor az alábbiakat vedd figyelembe:

• Alapfeltétel, hogy az API megbízhatóan működjön.
• A felületnek azt megelőzően látnia kell a hibákat, mielőtt egy kérés elküldésre kerül a szerver felé. A legjobb, ha minden el van távolítva, ami hibát okozhat az API-ban. Minél egyszerűbb egy UI-elem, annál könnyebb optimistává tenni.
• Az optimista megoldást csak olyan elemeknél alkalmazd, melyektől nem várható több, mint siker vagy hiba visszajelzése. Tehát, ha egy kattintás eredményeként a szerver válasza lehet igen, nem vagy lehet (melyek mindegyike sikeres visszajelzés), akkor jobb lenne, ha nem az optimista minta alapján működne.
• Legyél tisztában az API válaszidejével! Az optimista felhasználói felület akkor működik igazán jól, ha a szerver válaszideje 2 másodperc alatt marad. Ha ennél több, akkor az váratlan eredményekhez és csalódott felhasználókhoz vezet.
• Egy optimista UI nem csak gombokra való kattintásoknál működhet. Alkalmazható más interakciók esetén is, beleértve a weboldal betöltődését. Az ún. skeleton screen is hasonló megoldás: megjósolod, hogy a szerver válaszolni fog, így amint képes rá, kitölti az üres helyeket a felhasználói számára.

Mint látható, az optimista felhasználói felület nem egy újdonság a weben, sem pedig egy különösen bonyolult megoldás. Ez csak egy megközelítés, egy gondolati modell, mely segít az észlelt teljesítmény javításában. Ha okosan használod, akkor jobb felhasználói élményt alakíthatsz ki általa kis befektetéssel.