Gépélmény

Mint minden évben, idén is november második csütörtökje a használhatóság (világ) napja, amit itthon november 9-én tartunk meg (pl. a csütörtöki Rammstein koncertet elkerülendő...).

Az esemény oldala: https://www.facebook.com/event.php?eid=131653966937071, itt lehet olvasni a részletes programot, illetve jelentkezni is.

A tavalyi eseményhez hasonlóan idén is lesz pár rövidebb előadás, de nagyobb hangsúllyal lesz jelen a kapcsolatépítés, kötetlen beszélgetés ("sörözés") is, lévén ezek legalább annyira fontos és hasznos formái a használhatóság terjesztésének és a hazai közösség építésének.

A szerdai esemény ellenpólusaként péntek délután egy mélyebb, egyes témákat részletesebben feldolgozó workshop-ot is szervezünk: https://www.facebook.com/event.php?eid=155198714578954.

Én is ott leszek, találkozunk!

*EDIT Így a rendezvény után, tehát a legjobbkor. A használhatóság napja rendezvény nem jöhetett volna létre:

Fő támogató: FatDUX
Szakmai partner: MeetOFF

Támogatók

Wildom Kft, Gal6
HVG Könyvek, Typotex, L'Harmattan

Szervezők:

• Pónya Judit (UX specialista, FatDUX) (külön köszönet :)
• Rung András (http://ergomania.blog.hu)
• Polgár Péter Balázs (UX Researcher, Prezi)
• Herendy Csilla (Budapesti Corvinus Egyetem)
• Fehér Katalin (New Media Researcher, BGF)

A fogyasztói informatika, és ezen belül különösen a felhasználó központú gondolkozás jeles képviselője volt. Nem csak a hardverek, a szoftverek kialakításában alkotott maradandót, hanem megmutatta, hogy egy egész cég esetében hogyan lehet elérni a teljes felhasználói fókuszt.

Jó éjt Steve!

Egy barátom fényképezőgépének használatakor szembesültem az alábbi utasítással:

Elsőre úgy olvastam, hogy "Kattintson", annyira hihetetlennek tűnt az eredeti (ez szintén egy jó példa lehet az a külvilágból érkező információk torzítására), de a pontos megértés után is nehezen találtuk ki, hogy mit kell csinálni.

Az utasítás ragozásból adódóan a használónak, vagyis nekem kellett volna kacsintanom (bár a természetes felhasználói interfészek (NUI) már lennének itt) ténylegesen a tárgyon lévő embereknek kellett volna kacsintania.

(Rövid technikai magyarázat: a fényképezőgép arcfelismerős üzemmódban volt, aminek egyik beállítása, hogy nem fényképez csukott szemű embert. Ehhez az kell, hogy megállapítsa, a szem pozícióját, amit a pislogás detektálásával végez. Ha nincs pislogás, akkor kell kacsintani.)

A konkrét esetben persze az is lehet, hogy csak félrefordítás történt, és az eredetiben egyértelmű, mit kell tenni, a példából mégis levonhatunk néhány általánosabb következtetést.

• Amennyiben a felhasználónak valamit csinálni kell, igyekezzünk úgy megfogalmazni a neki szánt üzenetet, hogy az az ő szemszögéből legyen értelmezhető, különös tekintettel a használat kontextusára.
• Valamilyen szempontból limitált eszközön (pl. egy fényképezőgép kijelzője) az üzenetek megfogalmazására még kevesebb hely van, el kell gondolkozni alternatív módszereken (pl.: ábra).
• Ha a rendszer belső állapota jelentősen befolyásolja az elérhető funkciókat, vagy a felhasználó feladat végrehajtását (a fénykép készítése), akkor azt jól felismerhetően jelezzük ki, lehetőleg annak közelében, amit a felhasználó éppen néz.

Régi mondás, hogy egy (számítógépes) rendszer biztonságosságát a használhatatlanságig lehet fokozni. Csak sajnos ez így lényegében nem igaz (legalábbis nem úgy, ahogy érteni szokták).

A szerdai xkcd erre nagyon jó és egyben vicces példát mutat: 

Szerintem mindenki számára ismertek az olyan olyan kötelező jelszavak, amik kis és nagybetűket, számokat és írásjeleket tartalmaznak, illetve legalább 8 karakterből állnak. Nos egy valós környezetben a felhasználók többsége az ilyen jelszavakat nem fogja megjegyezni (mert például 10 másik ugyanilyen jelszót kell megjegyeznie), vagy ugyanazt a jelszót használja, vagy megy a post-it a monitor szélére. Nyilvánvaló, hogy ebben az esetben a rendszer biztonsága a felhasználókon lényegében megbukik, amire az adminisztrátorok még szigorúbb szabályokkal válaszolnak, amiket a felhasználók még kevésbé tudnak betartani stb. Pedig mint a fenti példa is mutatja erre nincs is szükség, ami biztonságosabb és egyben használhatóbb is.

A biztonságnak akkor van értelme, ha abban a felhasználók is aktív résztvevők, hiszen ez lehet a rendszer legsebezhetőbb része. Ennek egyrészről része lehet a felhasználók képzésem, másrészről viszont a biztonsági intézkedéseket úgy kell megtervezni, hogy a felhasználók a köznapi munkájuk során azokat használni és alkalmazni tudják.

Vagyis egy rendszer biztonsági beállításai közben is figyelni kell a felhasználói lehetőségekre és igényekre, illetve a környezetre (technikai és fizikai) ahol a rendszert használják - lényegében használhatósági tervezést kell alkalmazni.

Ma a Smartmobil'11 konferencián vettem részt, egy rövid beszámoló róla. Elsősorban trendekkel kapcsolatos információkra voltam kiváncsi, másodlagosan mobil használhatósággal, felhasználói élménnyel foglalkozó dolgokra.

Talán a nagy létszám miatt is (750 fő regisztrált), talán a meghívott előadók széles köre miatt is, kicsit több volt az általános, csekély információ tartalmú előadás (szakszóval: "bullshittelő"), de azért egy-egy elejtett félmondatból lehet tanulni, illetve ki lehetett nézni, hogy kivel érdemes a következőkben felvenni a kapcsolatot, ha már dedikált networking alkalom nem nagyon volt.

A twitter streamen elég jól lehet követni az általános hangulatot, úgyhogy az se hagyott ki sok mindent, aki végül nem tudott eljönni.

Gondolatok:

• Galántai Zoltán: míg az internet a sok-sok kapcsolatot hozta létre, addig a mobil az egy-bárhol kapcsolatot.
• Varga Tamás (Carnation) beszélt a multiplatform fejlesztésről, a technikájuk, hogy egy multi frameworkkel megcsinálják először az app-ot, aztán ha bejön, akkor átültetik natívba is. Mutatott egy érdekes képet, amin egy alkalmazás logikai rajza látszott, prototípus formájában, milyen interakcióra mi történik, aztán gyorsan le is vette, amikor mindenki elkezdte fényképezni.
• A BpMenetrend fejlesztője említette, hogy használnak folyósós teszteket, ez mobilok esetében különösen hatékonynak tünik.
• A multiplatformra több előadásból is az jött le, hogy az első platformra sok az idő, a többire nem, hiszen a kész alkalmazás már egy nagyon részletes rendszertervnek felel meg, és inkább csak kódolni kell, illetve a design-t átalakítani. Gondolom ebbe az is beleértendő, amikor a platformok logikai (pl gombok, notifications) különbségeit is figyelembe veszik.
• Dunder Krisztián volt az egyetlen, aki direktbe említette a "usability" szót, bár az előadásában aztán csak felületesen tért ki rá.
• Meglepő módon az "experience" nem lett bullshit szó, talán inkább a marketinges arcok használták a brand-ekkel kapcsolatban.
• A User experience a levegőben volt, de nem nagyon volt róla szó. A fejlesztők valamilyen formában többnyire említették, de inkább a platformokról, technológiákról volt szó, egyelőre még a technikai megközelítés dívik.

A mai Smartmobilon volt egy extra hasznos dia, a mobil használat indikátorairól. Mérések megtervezéséhez, komplex értékek összerakásához ideális. Nyílván az egyes indikátorokon belül is lehet tovább bontani, de ez ad egy jó összképet. (Nem tudom ki állította össze, egy gyors Google nem adott eredményt rá.) Usability szempontból ez a lista ad egy jó áttekintést a bemeneti tényezőkről (feladat, felhasználói és környezeti kontextusok).

Device

• Device features
• Applications
• Camera
• GPS
• Calendar usage
• Games
• App stores
• Application installations
• Maps and navigation
• User interface activity
• Keypresses
• Roaming
• Charging
• Battery
• Memory usage
• USB

Context

• Profile changes
• Locations
• In-building locations
• Nearby people

Life

• Meetings
• Movements
• Sleeping
• Wake-ups
• Travels

Socal

• Calls
• SMS
• MMS
• Email applications
• Social networking
• Webmails
• Instant messaging
• VoIP

Media

• Music
• Video
• Radio
• Gallery
• Youtube
• Imaging
• Search
• Mobile TV

Internet

• Data applications
• Streaming
• Wifi
• Web browsing
• URL click-streams
• Page facetime
• Throughputs
• Page visits
• Browsing content types
• Data volumes
• Network access technologies
• Session-level statistics

Van az eredeti fa és erdős verzió, de használhatóságra megfogalmazva is nagyon találó:

Ha egy program használó nélkül működik, létezik-e az?

Valójában persze vannak olyan szoftverek, amik nem közvetlenül a felhasználóknak szólnak, hanem más szoftvereknek, pl.: egy szerver oldali alkalmazás vagy egy webservice. Azonban ebben az esetben is van ember a láncban, legalább az a programozó, aki megalkotta az eredeti programot és az aki felhasználja azt. Ebben az esetben is beszélhetünk használhatóságról, a jól megírt osztályok, célratörő metódusok és a jó dokumentáció segíti a másik munkáját, és csökkenti a frusztrációt (ellenkező esetben van a WTF).

A közvetlen felhasználóknak írt szoftverek esetében sincs ez másként, csak azt kell belátni, hogy a felhasználó nem olyan mint a programozó: számára nem a jól megírt algoritmusok az érdekesek, mert a szoftver használatában nem az a fontos neki. Ő a saját céljait akarja megvalósítani a rendszerrel. Amikor idáig eljut a programozó, megtette az első lépést a használhatóság felé vezető úton.

Gyakran hozom fel példának a Google termékeit, amelyek használhatóság szempontból nagyon jók, és design szempontból kifejezetten a minimalista vonalat követik. Vagyis a használhatóság és a csili-vili design egymással nincs feltétlenül összefüggésben.

Most egy apróságot mutatok be a Gmail-ről, ami az átgondolt és megtervezett  használhatóságot mutatja. Konkrétan én is ma vettem észre (lehet, hogy már nagyon régen megvan ez a fícsör) de jól mutatja, hogy néha pont az apróságok segítik/nehezítik meg a felhasználó életét, illetve a jó használhatóságot a felhasználónak nem kell külön észre vennie, az csendben, összhatásában gondoskodik a pozitív élményről.

Ha új levelet kezdünk írni, akkor a levél szövegét tartalmazó mező az ablak méretéhez igazodik, és ez akkor is így marad, ha átméretezzük. Vagyis az alábbi ábrán a piros kerettel jelzett gördítősáv jelzés mindig ugyanakkora marad:

A gördítősáv alatti részen a felső gombsor megismétlése van, illetve további általános dolgok (pl.: információk, felhasznált tárhely), amire az embernek levél írás közben egyáltalán nincs szüksége.

Ezzel a megoldással a szöveg megírására mindig a lehető legtöbb hely áll rendelkezésre. Lehet hogy más nem így van vele, de engem frusztrál, ha egy négy soros levélnél már gördíteni kell, hogy lássam a levél elejét és a végét és az ablak nagyításával nem tudom megszüntetni a gördítősávot (ugyanez a probléma a blog.hu szerkesztőmezőjénél: ha egy bekezdésnél többet írok, már nem tudom áttekinteni a posztot, mert a szerkesztőmező nem átméretezhető).

A használhatóság egyik fontos céljának a definícióban is található hatékonyságot szoktuk mondani, amit többnyire a gyorsasággal, a felhasznált erőfeszítés minimalizálásával lehet azonosítani. Azonban ez nem feltétlenül jelenti pusztán a rendszer sebességének növelését. Erre szoktam azt a példát felhozni, hogy mindig a rendszer egésze tekintetében kell vizsgálni a felhasználó célját, például egy játék esetében sem az a legfontosabb, hogy minél gyorsabban végig lehessen játszani.

Nézem ezt a videót a placebo hatásról:

Két érdekes dolog következik:

1. Placebo gombok: Néha tényleg csak azért kell gomb a liftbe, hogy amikor megnyomja az ember, úgy érezze, hogy tett is valamit azért, hogy elinduljon a lift, és nem tétlenül várt amíg elindult magától.
   Bizonyos jól meghatározott esetekben a felületre is kellhetnek olyan gombok vagy más kontrollok, amik hatására olyan művelet hajtódik végre, ami a felhasználó nélkül is végrehajtódott volna. Ugyanígy hosszabb műveletek felbontása is értelmes lehet több kisebb lépésre néhány másodperces várakoztatás helyett. Hosszabb műveletek idő érzetét is lehet csökkenteni, ha a felület ténylegesen is "csinál valamit" közben.
2. Jobb a design, jobb a program: Ha két funkcionálisan egyforma program közül az egyik designja jobb, akkor a felhasználók azt a programot funkcionálisan is jobbnak, gyorsabbnak fogják érezni. Fontos, hogy itt a design alatt nem a csili-vilit értem, tehát ha ugyanolyan sebesség mellett pl. az egyik program több animációt mutat be, akkor az is keltheti a lassúság érzetét.

Végső tanulságként még annyi jegyezhető meg, hogy a placebo hatásra olyankor lehet építeni, amikor a felhasználó fejében van a probléma (pl.: "Az előző program sokkal gyorsabb volt.", és mérésekkel sem lehet meggyőzni az ellenkezőjéről). Természetesen a funkcionális hiányosságokat ez sem tudja elrejteni.

(Az alábbiakat a hozzám eljutott megkeresések és ismerősök beszámolói alapján szűrtem le.)

A tegnapi posztomban is említettem, hogy az itthoni cégek is kezdik felismerni a használatóság (és kapcsolódó területek) hasznát.  Ennek egy jele, hogy egyre több szakembert keresnek általános (nagy) fejlesztő cégek és kisebb, tanácsadással foglalkozó specialisták is.

Sok cégnél ez az első ilyen pozícióra felvett ember, ennek megfelelően inkább szeniorokat keresnek, legalább 2 év munkatapasztalattal. Ez az én értelmezésem szerint azt jelenti, hogy aki csak önszorgalomból foglalkozik vele, de nincs projekttapasztalata és erős kommunikációs készsége, nem nagyon fogja megtalálni a helyét. A módszerek helyes alkalmazása mellett az ilyen helyeken a munka elismeréséért is meg kell küzdeni (a vezetői támogatás nem mindig terjed ki a projekttagokra). Mivel az ilyen esetekben az egész folyamatot egyedül fedi le az ember, néha a projektmanagernél is jobban kell tudni, mit mikor és miért kell csinálni.

Hogy lehet ilyen tapasztalatot szerezni? Sajnos formális használhatósági / HCI képzés nincs, illetve ez pont az a terület, ahol a végrehajtást csak gyakorlatban lehet megtanulni. Én a következő utakat látom erre:

• Amíg az ember hallgató, egyetem: lehet tanszékeket találni, ahol vannak ipari projektek a témában (pl.: a BME-s Ergonómia tanszék). Az ELTE-n szeptembertől indítunk egy 4 féléves, 16 kredites modult, amiben második évtől tervezünk ipari projektet is. Ezek nem feleltethetőek meg a céges tapasztalattal, a másfajta célok (kutatás) miatt, de sok önálló munkával lehet interjún is felmutatható eredményeket generálni. A témában írt szakdolgozat is tud számítani.
• Fejlesztőből usability-guy. Ahol van UI fejlesztés, előbb-utóbb felmerülnek a felhasználói kérdések. Ilyenkor a csapat egy tagja fokozatosan átkerülhet ebbe a szerepbe, először csak kisebb gondolatokat belerakva, később fokozatosan egyre komolyabb módszereket használva. (Én is így kezdtem.)
• Multi. Az előbbihez hasonló út. Bár az itthon dolgoztató nagy multik nem mindig hozzák ide a kreatív munkafolyamatokat, de valamennyi használhatósági munka előfordulhat, aminek kapcsán a külföldi usability teammel együttműködve lehet sokat tanulni.

Én a jövőben a területen előforduló álláslehetőségek további bővülésére számítok, úgyhogy mindenkit csak biztatni tudok, akit érdekel a használhatóság szép világa.