Számítógép használat másképpen

A héten bukkant fel a neten egy videó, R. Clayton Millertől 10/GUI címmel. Röviden bemutat egy koncepciót arról, hogyan lehetne használni a jövő számítógépeit.

Azok kedvéért, akik még nem látták, itt a videó:

Először is szeretném leszögezni, hogy a koncepció alapvetően tetszik. Konzisztens, motorikus reflexekre épít a felület használata (az gyorsan tanulható), az asztalra kirakott néhány widget koncepció az, ami nekem a KDE4-ben is nagyon tetszett, stb.

Az kérdéses, hogy a 2D helyett 1D ablakelhelyezés mennyire használható. Átlátni bizonyosan könnyebb, ugyanakkor kérdés, mit csinál akkor, ha egyszerre sok ablakot/alkalmazást szeretnék egyszerre használni. Megvan a kockázata, hogy arra nem annyira jól használható.

További lehetséges probléma, hogy mennyire lehet finom műveleteket végezni úgy, hogy a többi ujjunk bezavar(hat). Ez persze csak finomhangolása a rendszernek, mindez megtörténhet a mostani billentyűzet + egér/touchpad/trackpoint kombinációkkal, vagy a touchscreenekkel is.

Amit meg végképp nem látok, hogy a rendszer hogyan működne adatcentrikus alkalmazásokkal. Amikből van egy pár: különböző űrlapok kitöltése, megjelenítése, adattáblák áttekintése gyakori feladat a különböző enterprise alkalmazásokban. Persze, ezt is lehet jobban és rosszabbul csinálni, de ha egy rendszer használatához minden meglevő alkalmazást át kell írni, akkor sokáig élni fog a régi… Látjuk ezt IE6 kapcsán is, de ez most off volt. 😀

Mindenesetre ötletnek jó a folytatást tekintve – sőt, szerves folytatása az eddigi trendeknek. Kérdés, hogy mi lesz belőle, ha ténylegesen bekerül a mindennapokba.

Update: amit kihagytam az előző értékelésből.

A legtöbb interakciónál nem használjuk az ujjainkat külön-külön, hanem csak valami közös, motorikus reflex alakul ki. Persze, vannak esetek, amikor kivételek vannak, de ez ritkaság. Sokan nem tudnak 10 ujjal gépelni, kevesen zongorázak/hegedülnek/játszanak hangszeren, ami efféle problémákat vet fel.Megtanulható, de nem mindenki veszi rá a fáradtságot.

Persze az egy interakciós pont sávszélessége kérdéses, de ha jobban belegondolunk, amikor papírra írunk, akkor is egy pont az interakció, mégis egész gyorsan tudnak egyesek írni.

Kapcsolódó probléma, hogy mi történik, ha úgy próbálok többujjas gesztusokat végrehajtani, hogy az ujjaim különböző ablakok felett vannak?

És a legvégső problémám a rendszerrel: az emberek többsége nem képes egyszerre több mindent végezni – és itt a többujjas gesztusokat muszáj egyszerre csinálni. Nem biztos, hogy könnyű.

Most a frissítés hatására a kritikák abszolút túlsúlyba kerültek a pozitív tartalom mellett, ezért fontosnak tartom még egyszer megjegyezni, hogy szerintem érdekes koncepció, esetleg ki is próbálnám, ha lenne rá lehetőségem. De amire biztosan jó, az az, hogy végiggondoljuk, mire jó, és levonjuk a konzekvenciákat.

Web usability kérdés

Nemrég olvastam Krugtól a Don’t make me think (magyarul Ne törd a fejem címen elérhető). Nekem határozottan tetszett, noha  egy Szoftverergonómia kurzus után sok újat nem mondott.

A könyv példákon mutatja meg, hogy mit is jelent a használhatóság a weblapok tervezése közben, nagyon olvasmányos módon, sokféle példával. Kifejezetten dícsérte például az Amazont (amivel személy szerint kevés használat után egyet kell, hogy értsek, jól megtervezték).

Hogy miért is jutott eszembe? Mert egy fárasztó nap után apukám ismét szembesített a magyar web egy igazi gyöngyszemével. Január óta havi program, hogy apukámnak gondja van a villanyóraállás bejelentésével. Korábban telefonon próbálkozott, de ott kb. 50 jegynyi értelmetlen számsort újra és újra betölteni finoman szólva is kellemetlen feladat.

Természetes ötlet, hogy akkor használjuk az internetes kitöltést. Ma megnéztem, hogy apukám hogy csinálja. A Firefox kezdőoldalán a google-be beírja, hogy elmu.hu (ez is megér egy misét, de ezen tegyük túl magunkat), majd pár kattintáson és rövid időn belül a keresett oldalra kerül.

Oldal közepén link, hogy Mérőállás bejelentése. Rákattint (elvégre ezt akarja csinálni). Ki látja, hogy mi volt a gond az oldallal? (Élőben látható itt 2009. 09. 01. este: http://ugyfelkapu.elmu.hu/meroallas_rogzites )

A mérőállás bejelentő oldal - Bejelentkezés szükségeshttps://i0.wp.com/cubussapiens.hu/wp-content/uploads/2009/09/elmu1.png?w=925 925w" sizes="(max-width: 300px) 85vw, 300px" />
A mérőállás bejelentő oldal - Bejelentkezés szükséges

A helyes megfejtést hozzászólásban várom. További minősítést majd akkor adok az oldalról, ha már lenyugodtam.

Soha ne figyelmeztess, ha a visszavonás is elegendő!

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Tapasztaltad már azt a lehangoló érzést, ami akkor tölt el, amikor rájöttél – egy másodperccel később a kelleténél – hogy nem kellett volna OK-t válaszolnod a „Biztosan ki akar lépni?” kérdésre?

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Tapasztaltad már azt a lehangoló érzést, ami akkor tölt el, amikor rájöttél – egy másodperccel később a kelleténél – hogy nem kellett volna OK-t válaszolnod a „Biztosan ki akar lépni?” kérdésre?

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.

Soha ne figyelmeztess, ha a visszavonás is elegendő!
Miért? Mert a szoftvernek tudnia kellene, hogy szokásokat veszünk fel. Tudnia kellene, hogy azután, hogy számtalanszor válaszolunk OK-val a kérdésre, feltehetőleg akkor is az OK-t választjuk, ha nem arra gondoltunk. És azt is tudnia kellene, hogy nem lesz lehetőségünk gondolkodni, mielőtt véletlenül eldobjuk az egész munkánkat.

Miért kellene tudnia a szoftvernek ezeket a dolgokat? Mert a szoftvertervezőknek is tudniuk kellene, hogy szokásokat veszünk fel, akár akarjuk, akár nem.

A szokások felvétele tulajdonképpen egy jó dolog: segít megkímélni minket annak a gondjától, hogy gondolkodni kelljen, amikor az interfész bosszantó apróságaival találkozunk és csökkenti a valószínűségét, hogy a gondolatmenetünk eltérül. A „Biztosan ki akar lépni?” kérdésre a kezünkben van egy memorizált kattints-és-zárd-be folytonos folyamat. Ez jó, mert a legtöbb esetben nem akarunk gondolkodni a kérdésről – csak a jó dolgot csináljuk. Szerencsétlen módon, a szokásaink időnként félrevezetnek: nem lesz időnk rájönni a hibánkra, amíg meg nem csináltuk.

Így a tervezők számára egyenes út vezet az általános felhasználói felülettervezési elvhez: Ahhoz, hogy egy felhasználói felület emberi legyen, figyelembe kell vennie a szokások kialakulását.

Lehetséges megoldások

Mi lenne, ha a figyelmeztetést nehezebb lenne figyelmen kívül hagyni? Egy diszkrét figyelmeztetés felett könnyű átugrani, így vegyük elő a teljes eszköztárat: villogtatjuk a képernyőt és egy hangos, idegesítő zajt játszunk le annak érdekében, hogy biztosítsuk a felhasználói figyelmet. Próbálkozhatunk, ahogy tetszik, továbbra sem fog működni. Minél tolakodóbb a figyelmeztetés, annál gyorsabban meg akarunk szabadulni tőle (az OK-ra kattintva) és annál többször fogunk hibázni. A gond az, nem számít, mennyire tolja a képünk elé a figyelmeztetést a szmítógép, mi ugyanazt a hibát fogjuk elkövetni: akkor is az OK-ra kattintunk, ha nem azt akartuk. De ez még mindig nem a mi hibánk: addig, amíg szokások felvételével figyelmen kívül lehet hagyni a hibaüzenetet, felvesszük a szokásokat, azután pedig hibázni fogunk.

Mi lenne, ha a figyelmeztetést lehetetlen lenne figyelmen kívül hagyni? Ha a szokások okozzák a problémát, miért nem tervezzük úgy meg a felületet, hogy ne lehessen szokásokat felvenni? Így mindig rá leszünk kényszerítve, hogy gondolkodjunk a válaszadás előtt, és így mindig azt válaszoljuk, ami választ mi szeretnénk. Ez megoldja a problémát, nem?

Ez a fajta gondolkodás nem új: ez az írd-be-az-n-edik-szót-ebből-a-mondatból-a-folytatáshoz megközelítés. Például a Guild Wars játékban ahhoz, hogy egy karaktert töröljünk, először a „Törlés” gombra kell kattintani, majd a karakter nevét be kell írni megerősítésként. Sajnálatos módon ez nem mindig működik. Pontosabban:

  1. Arra kényszerít minket, hogy koncentráljunk a szokatlan feladatra és nem arra, hogy tényleg el akarjuk-e dobni a munkánkat. Így a nem figyelmen kívül hagyható figyelmeztetés se sokkal jobb, mint a teljesen átlagos: mindkét esetben végeredményben elveszik a munkánk. Ez (a munka elvesztése) az elképzelhető legnagyobb bűn a szoftver világában.
  2. Figyelemre méltóan idegesítő, és mert mindig szükséges a figyelem, szükségszerűen elterel minket a munkánkról (ami a második legnagyobb szoftver-bűn).
  3. Mindig lassabb és több munkát igényel, mint egy egyszerű figyelmeztetés. Ezzel elköveti a harmadik legnagyobb bűnt – azzal, hogy több munkát igényel tőlünk, mint az szükséges.

A Guild Wars-os példánkban a második és harmadik pont nem túl lényeges, mert a karakterek törlése elég ritka esemény. De ha be kellene írni a dokumentum nevét, mielőtt mentés nélkül kiléphetnénk, nagyon megterhelőnek éreznénk.

Mit tanultunk? Azok a felületek, amik nem veszik figyelembe a megszokást, nagyon rosszak. A figyelmeztetés nagyobbá, hangosabbá és nem-figyelmen-kívül-hagyhatóvá tétele nem működik; akárhogy is nézzük, a figyelmeztetések egy nagy, sötét csapdát jelentenek az interfészben. Inkább szabaduljunk meg a figyelmeztetésektől.

A mentőöv: visszavonás

Ha csak simán eltávolítjuk a figyelmeztetéseket, nem mentjük meg a munkánkat a végzettől, de ha egy „visszavonási” lehetőséget beteszünk, akkor már igen. Hadd ismételjem meg: a figyelmeztetéses nyomorúságunkra a visszavonás a megoldás. Egy kellően robosztus visszavonással akár nemtörődöm módon is bezárhatjuk a munkánkat tudva, hogy mindig visszanyerhetjük. A visszavonással ezt a szörnyű „Hoppá!” érzést eltüntethetjük a munka visszaszerzésévelA „Hoppá!”-tényező egy Laura Creighton-nal folytatott megbeszélés alapján született meg..

Mivel szokásokat veszünk fel, soha nem fogjuk tudni garantálni, hogy nem lesz ilyen „Hoppá!” pillanatunk. Ezzel szemben a tervezőknek tudomásul kell venniük, hogy meg fog történni, és ennek megfelelően tervezni. Ahányszor csak megvan a lehetősége, hogy eldobjuk a munkánkat, a számítógépnek lehetővé kell tennie, hogy visszacsináljuk a dolgokat.

Ez elvezet minket az egyik legalapvetőbb és legfontosabb felülettervezési mantrához: Soha ne figyelmeztess, ha a visszavonás is elegendő!

A Google Mail egy jó példája ennek a mantrának. Ha törölsz egy e-mailt, azonnal ad lehetőséget arra, hogy visszavond ezt a lépést. Milyen felhasználóbarát! Ezzel ügyesen kikerüli a figyelmeztetések kérdését (csakúgy, mint a visszavonás láthatóságát). Ha hibázunk (ami elő fog fordulni), nem kerül túl sokba, mert egyszerűen visszavonhatjuk. A visszavonással kevesebbet aggódunk és több időt dolgozunk.

Gmail visszavonás: Ezt a beszélgetést áthelyeztem a kukába. Link a Visszavonás opcióra.
1. ábra: Még nincs túl késő. A Gmail lehetővé teszi, hogy visszavonjuk a törlést.

Természetesen ez csak egy rétege a visszavonhatóságnak – és Gmail ennél tovább megy. Ha törölsz egy levelet, az nem veszik el örökre… ott van a kukában, hogy visszaállíthasd, ha később úgy döntesz, mégsem akartad törölni.

Sajnos, ezt a leckét a Google Calendar még nem tanulta meg. És, ahogy megjósolható volt, töröltem már olyan eseményeket, amit nem akartam. Sokszor a rossz eseményt töröltem, ami különösen rossz, mert ekkor abban sem vagyok biztos, hogy mit töröltem. Visszavonás nélkül nincs is rá mód, hogy kitaláljam.

Google Calendar figyelmeztetőablaka: Biztos, hogy törölni akarod az
2. ábra: Légy óvatos! A Google Calendar nem engedi a téves törlések visszavonását.

Tulajdonképpen még Google Mail sem mindig használja ezt a módszert. Ha egy címkét törölsz, már jön is egy ilyen figyelmeztetés. Miért van az, hogy Google ilyen jól megcsinálja egy helyen, és alig néhány kattintással arrébb meg ilyen rosszul? Talán mert ez a figyelmeztetés alapú gondolkodás annyira beágyazódott, hogy hősies erőfeszítéseket igényel a meghaladása. Még olyan cégek is, amelyek egyébként a jó tervezés védőbástyái (ilyen a 37Signals), ezt nagyon rosszul csinálják.

Highrise figyelmeztetés: Biztos, hogy törölni akarod ezt a feladatot?
3. ábra: A Highrise, a 37Signals alkalmazása is figyelmeztet visszavonási lehetőség nélkül

Figyelmeztetések használata a visszavonás helyett a legkisebb ellenállás felé mozdulás útja a programozó szemszögéből, és nem igényel különösebben újító gondolkozást a tervező nézőpontjából. De ez nem mentség a számítógépeink számára, hogy nem emberi módon gondolkodnak.

Következtetés

A figyelmeztetések miatt elveszíthetjük a munkánkat, bizalmatlanok leszünk a számítógépekkel szemben és magunkat hibáztatjuk. Egy egyszerű, de bolondbiztos tervezési módszertan megoldja a problémát: „Soha ne figyelmeztess, ha a visszavonás is elegendő!” És ha a felhasználó törli a munkáját, mindig elegendő.

Ó, és a következő alkalommal, amikor azt látod, hogy figyelmeztetnek a visszavonás helyett, küldj az alkalmazás/weboldal tervezőjének egy kedves e-mailt, amiben javaslod, hogy inkább implementáljanak egy „visszavonás” funkciót. Küldj nekik egy linket erről a cikkről. Nézzük meg, meg tudjuk-e változtatni annak a módját, ahogy az emberek a webre terveznek – és ebben a folyamatban mindenki számítógépes életét egy kissé emberközelibbé és kevésbé frusztrálóvá tegyük. Kezdődjön a háború a figyelmeztetések ellen!

Illusztráció: Kevin Cornell

A szerzőről

Aza először 10 éves korában a SIGCHI helyi, san franciscoi székházában beszélt a felhasználói felületekről, és a rabjukká lett. 17 évesen nemzetközi megbeszéléseken és konzultációkon vett rész; 19 évesen egy fizikakönyv társszerzője lett, mert túl fiatal volt, hogy alkoholt vegyen; 21 évesen elkezdett inni, és társalapítója a Humanized-nek. Aza szeret játszani a kürtjén és a laborjában tenni-venni, ha az ideje engedi.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.