Amiről olvashatsz

A felhasználói élmény nem titkos összetevői, egy ritka szakma érdekességei.

Tippek és trükkök, hogyan teheted különösen kedveltté termékedet, weboldaladat, vállalkozásodat.

Bővíz László használhatósági specialista

Bővíz László, használhatósági specialista (szoftver ergonómus) vagyok, a Webergonómia könyv egyik kommentátora.
Felület- és használhatósági-tervezéssel foglalkozom.
Email nekem

Usability - Magyar szótár

Élő könyvjelző

Friss hozzászólások

Használhatóság, szoftverergonómia

2010.05.11. 15:37 Bővíz László - JUEX

Fél milliárdos utalás. Véletlen?

Mennyibe kerül a rossszul használható szoftver?
Irtó sokba, csak nehéz kiszámolni.

Friss esemény, hogy a BKV háromezer dolgozójának duplán utalta a fizetését. Az egyik gépen elindították az átutalást, az még nem fejeződött be, mire elindították a másikon is. Dilettáns hiba, ha egy szoftverrendszer normális körülmények között képes ilyen működésre. Anélkül, hogy ismerném a pontos körülményeket, nézzük milyen ablakok felbukkanása vezethet ilyen kellemetlen helyzethez.

Várjunk, várjunk,... de meddig? Mikor kezdődött egyáltalán? Lehet, hogy műszakváltás volt közben és a délutánosnak fogalma sincs róla, hogy a délelőttös reggel nyolckor, vagy délben indította az utalásokat. Állítólag az egyik gépen még ment a homokóra. A homokóra kurzor külön megérne egy fejezetet, de most ne firtassuk.

Van egy súlyosabb változat is, az oké gombbal felturbózott:

OK-ra eltűnik az ablak és a folyamat szépen csendesen megy tovább. Ritkán találkozom ilyennel, de néha előfordul.

A fejlettebbek folyamat jelző csíkot alkalmaznak, bár nem mindíg jól.

Helytelen megoldás, ha a csík túl nagy lépésközökkel változik (pl: 33%-66%-100%) ugyanis akkor sokáig nem mozdul két lépés között és a felhasználónak nincsen információja róla, hogy működik vagy befagyott.

Nézzünk egy jó megoldást:

Megállítás után lehessen folytatni valahogy így:

Ha végzett akkor:

Miért jobb ez a változat a felhasználóknak, mint a legelső?

  • Több információt nyújt arról, hogy hol tart
  • Biztonságosnak érzi a használatot, ha tudja, hogy a megállított folyamatot folytathatja
  • Egyértelmű üzenetet kap, ha sikerült a végrehajtás. Természetesen arra is kell üzenet, ha valami hiba lép fel.

Tegyük lehetővé számára, hogy Ő irányítsa a rendszert, nem pedig fordítva. Ne várjuk el, hogy gondolkodnia kelljen azon, hogy éppen mi a fene történik.

Józan paraszti ész kell hozzá, mégis telis tele vannak a szoftvereink hasonló buktatókkal. Vajon miért?

Gyakran maga a projekt vezetés nem ismeri a használati érték jelentőségét, egyszerűen a fejlesztőkre bízza a felhasználói felület és a munkafolyamatok kialakítását. Amikor arról kell dönteni, hogy megcsinálják a kis lépésközű, megállítható és újraindítható vezérlésére alkalmas ablakot 5-10-szer annyi idő alatt mint az egyszerű, egy mondatos üzenetet, akkor könnyen az utóbbira szavaznak, hiszen szorít a határidő. Az a határidő, amiben nincs felület és interakció tervezés mindig is szorítani fog, hiszen tele van ismeretlen elemekkel. Az ismeretlen feladat elvégzésére időt becsülni a jóslás kategóriája. Garantált a bukta és az is biztos, hogy a felhasználónak fájni fog.

A BKV-nál fél milliárd forintot vándoroltatott meg oda-vissza a baki. Máskor, máshol ennél sokkal rosszabbul is elsülhet.

Címkék: bkv használhatóság sap felhasználó felhasználói felület synergon folyamat jelző projekt vezetés

9 komment

A bejegyzés trackback címe:

http://juex.blog.hu/api/trackback/id/tr471992608

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

lajthabalazs · http://lajthabalazs.com 2010.06.09. 12:18:04

Tényleg ennyire egyszerű progressbar-t elhelyezni egy eseményvezérelt, többrétegű rendszerben? Egy tranzakció alapú rendszerben?

Ugyan még sosem csináltam kötegelt átutalást, de gondolom olyan, mint a szimpla ami a következőképpen alakul: összerakom az adatokat, (több ezer adat esetben a listát a szerver tárolja). Eztán rányomok a nagy zöld gombra, aztán megerősítem, és kapok egy üzenetet, hogy "feladat feldolgozás alatt". Ha aggódom, hogy mi a helyzet, akkor az elküldött megbízásokat listázom, amire kiváncsi vagyok, annak státuszát lekérdezem.

Szerintem itt elsősorban nem usability problémáról lehetett szó, főleg, hogy a felhasználó évek óta ismeri a felületet, és nem egy mindennapos unalmas rutinfeladatról van szó, hanem ahogy említetted, félmillió forintról.

Bővíz László - JUEX · http://juex.blog.hu 2010.06.09. 21:40:30

Bérátutalás volt, ezért része a havi rutinnak. Valószínűleg nem egy izgalmas feladat, esetleg, ha a saját számlájára utalta volna :)

Az egyik gépen ment az utalás, miközben a másikon is elindították, ezért történt meg duplán. Ez bizony használhatósági hiba, amit a felhasználói felület tervezésnél kell kiküszöbölni.

Létezik egy usability elv, ami az mondja: Ne a felhasználónak kelljen fejben tartania olyan információt, amit a gép is tudhat. Ezt sértette meg; de súlyosan. :)

lajthabalazs · http://lajthabalazs.com 2010.06.10. 06:14:58

@Bővíz László - JUEX:
De a te géped nem tudja, a banki rendszer tudja. Csak meg kellett volna kérdezni, hogy milyen átutalások mentek/mennek ki, ahelyett, hogy ráindítanak mégegyet.

Bővíz László - JUEX · http://juex.blog.hu 2010.06.10. 13:55:01

Fogalmazzunk úgy, hogy ez a szoftver nem tudta. Természetesen a banki rendszer is tudja, de az utaló rendszer is tudhatná. Egy ember egy hónapban egyszer kaphat alapfizetést. Általában.

kpista 2010.06.18. 09:31:56

Nem értem a problémát!
A bankok általában a MAC cím alapján azonosított egyedi gépektől fogadják az átutalásokat, amire ők a saját szoftverüket telepítik. Ha tehát a BKV és a bankja korrektül járt el, akkor ez a hír kacsa.

kpista 2010.06.18. 09:36:43

Folytatva a gondolatot, egy cégnél általában egy gép utal, ha az nem, akkor van egy másik a redundancia miatt. Ezt a második gépet általában csak akkor fogadja utalásra a bank servere, ha a fő utaló gép nem kapcsolódik. Mindezt a dupla utalások elkerülésére és az utalások biztonságos nyomonkövetésére találták ki.

Zs. 2011.10.09. 16:39:36

Ha jól emlékszem, mert egyszer valaki elmagyarázta, mi volt a hiba alapja (SAP rendszerbaki volt amúgy), valami technikai gubanc lehetett, nem UX. Persze ha egy szoftver nem biztonságos, esetleg nem jó a tranzakciókezelés netán a lokkolás, az is megkeseríti egy felhasználó életét, de ezekért a legritkább esetben felel a UX részleg.

Ami pedig a progress bart illeti... én próbáltam, hidd el, nagyon próbáltam jót írni, de minekutána eltöltöttem sokX annyi időt a fejlesztésével, mint a háttérben futó folyamat leprogramozásával, feladtam. :) Nem olyan egyszerű, mint látszik.
Tegyük fel, hogy 100 elemet törölsz minden hozzájuk tartozó adattal az adatbázisból. Az ehhez tartozó egyszerű progresszbár minden törölt elem után 1%-kal növeli a számlálót - logikus. Előfordulhat azonban, hogy van olyan elem, aminek 1 alrésze van, másoknak viszont többszáz. Így történik, hogy a kis elemek törlésénél elszalad a számláló 33%-ig pillanatok alatt, majd jön a többszáz alelemmel rendelkező, és ez jó sokáig eltart, majd megint jönnek a kisebb félék, és megint meglódul az egész... Ehhez jó progressbart írni azt jelentené, hogy előbb végigszaladsz több, egymásba ágyazott ciklussal a törölnivaló elemeken, és megszámolod a törlésben valóban szereplőket, és ezek alapján hajtod a folyamatjelzőt. De mivel így kétszer szaladsz végig az adatbázison, ezzel tulajdonképpen megdupláztad a műveletek számát, így bizonyos esetben (azokban is, amikor az elemek törlése nagyjából azonos időt vesz igénybe, így a fenti is tökéletesen működne) akár a törléshez szükséges időt is. És ez így összességében minden, csak nem a UX javítása, hiszen a műveletek gyorsasága is hatással van a felhasználói élményre.
Szerintem nem véletlen, hogy az utóbbi időben mindenki átállt a "még kb. X perc van hátra" információra a progressbarokról. Egy jól megtervezett tesztüzem során meg lehet nézni, hogy X elem törlésére átlagosan mennyi időre van szükség (ha a tesztben szerepel kis és nagy elem is, tehát jó a tesztadatbázis is), és a becsült időt kiírni. Ez egyrészt pontosabb infó, mint a 30%, másrészt pszichológiailag is jobb, mert én még egyszer sem kaptam elő a stoppert, mikor ilyet toltak az arcomba. Lehet, hogy ez sem sokkal pontosabb, mégis jobb tőle a közérzetem. :)

Ui.: I <3 Balsamiq. :)

Bővíz László - JUEX · http://juex.blog.hu 2011.10.10. 15:55:42

@Zs. : A hátralévő idő azért jobb, mert a felhasználónak az a leghasznosabb információ. Abból tudja, hogy hány percet kávézhat, Facebookolhat. Nem jobb a közérzetem az idő visszaszámlálástól, ha a mérőszáma növekedni kezd. Van rá példa. A ProgressBar lefutási idejének előbecslésének nyilván vannak ésszerű korlátai, ahogy írod is. Ha valahol eljutnak a korlátok felismerésére, abból már nagyon rossz eredmény nem születhet.