ux tanfolyam manuscript
DESCRIPTION
Course materialTRANSCRIPT
Nemeth AdamFehértói u. 10
Budapest
(Your agent’s name)(Your agent’s address)
9,800 words
UX tanfolyam programozóknak
by Nemeth Adam
UX tanfolyam programozóknak/Nemeth 2
Contents
Chapter One - Stratégiai UX 7
bevezető 7
Az óra célja 7
Az UCD 8
A felhasználó számára a UI a rendszer 9
bibliográfia 10
Az első nap bibliográfiája 10
A felhasználók 11
Kik azok a felhasználók 11
A felhasználók csoportosítása 12
A felhasználók további csoportosítása 13
UX tanfolyam programozóknak/Nemeth 3
A perszónák 14
A felhasználókutatás 18
A felhasználói interjúk 18
Az ügyfél nem a felhasználó 18
A field study-k fontossága 19
Az én gyakorlatom 21
A várt eredmény 24
Problémamodellezés 24
A számítógép interaktív 24
Problémák és célok 25
Problémákból követelmények 25
Use Case modellezés 26
Skiccek (Sketches) 26
A történetek ereje 29
Folyamattervek 32
Skicc, terv és prototípus 33
Absztrakt folyamattérkép 33
Képernyőfolyamat 34
Prototípizálás 37
UX tanfolyam programozóknak/Nemeth 4
Tesztelés 38
Heurisztikus tesztelés 38
Automata vs felhasználói tesztelés 40
Tesztelés és történetek 41
Kikkel teszteljünk? 42
A tesztelés szabályai 44
A tesztelés körülményei 44
Krug-féle tesztszkript 46
Chapter Two - Mikro UX 49
A második nap bibliográfiája 49
Az ember képességei 49
A figyelem 50
Az agy működése 51
Mentális modellek, Norman-féle mentális modell 55
A sebesség 57
A látás 59
Tervezési minták 64
Gyakorlati hasznuk 65
Tervezési minták formátuma 66
UX tanfolyam programozóknak/Nemeth 5
Tipikus buktatók 66
Quince példa 67
Untitled 77
Tipográfia 77
CRAP 77
Vizuális hierarchia 78
Gridek 78
Betűkülönbségek 87
Betűütközés 88
UX tanfolyam programozóknak/Nemeth 6
Foreword
UX tanfolyam programozóknak/Nemeth 7
Chapter One: Stratégiai UX
bevezető
Az óra célja
Az óra célja
Az óra célja
Az óra célja az, hogy jó szoftvert építsünk. Ez mindig egy jó cél egy fejlesztőcég életében. Na de mi a jó szoftver?
A jó szoftver az, amelyik képes a felhasználókat sikerrel segíteni abban, hogy elérjék valós életbeli céljaikat.
Következő néhány kérdés merül fel:
• Kik azok a felhasználók?
UX tanfolyam programozóknak/Nemeth 8
• Mik a céljaik, és ezt honnan tudjuk meg?
• Mi az a valós élet?
• Hogyan érik el?
• Honnan tudjuk, hogy sikerül-e?
Ezeket mind fogjuk boncolgatni a nap folyamán.
Az óra további célja hogy képesek legyünk egyfajta stratégiai dokumentumot, ha így tetszik magas szintű specifikációt készíteni.
Ez lesz az a dolog, ami alapján az ügyfelekkel át tudjuk beszélni, hogy milyen feladatokat kell a rendszernek ellátnia.
Az UCD
Az itt részletezett módszer neve user-centered design.
Mint a neve is mutatja, ezek a módszertanok arról szólnak, hogy (wikipedia) a felhasználó szükségletei, igényei és korlátai határozzák meg a tervezett termék tulajdonságait.
A felhasználó-központú tervezésnek két fontos szempontja van:
1. Nem találjuk ki hogy mi a jó a felhasználónak, se bizottságilag, se karosszékből, ergo folyamatos interakció kell felhasználókkal
2. A felhasználó számára az interfész maga a rendszer.
UX tanfolyam programozóknak/Nemeth 9
A felhasználó számára a UI a rendszer
Vegyünk egy egyszerű példát.
Van egy ASP.NET site, aminek egy része flashben van írva, de belső szoftver, a flash fel van telepítve, frissül, stb.
Egyik nap új műszaki vezetés jön.
Ők a java-ra esküsznek meg a HTML5-re.
Szépen csendben megbíznak egy külső fejlesztőcéget, hogy minden flash komponenst írjanak újra HTML5-ben, és az egész szervert úgy ahogy van tolják át java-ra, a windowsos szervereket pedig cseréljék le linuxosra. Még három kérésük van:
• A rendszer viselkedésében ne változzon
• A rendszer kinézetében ne változzon
• A rendszer egyik részművelete se legyen lassabb
Sikerül. Mit észlel ebből a felhasználó?
Semmit.
Anekdota: TwitterA twitter évekig a Ruby on Rails zászlóshajója volt. Egyetlen baj volt vele, nagyobb eseményeknél a mikroblogging szolgáltatás, dollármilliók ide, dollármilliók oda, összeomlott. Ez megszokott jelenség volt, ilyenkor kiraktak egy bálnát, amit úgy hívtak, a Fail Whale. A twitter, nagy esemény, összeomlás, ezek összetartoztak.
UX tanfolyam programozóknak/Nemeth 10
Egyszercsak feltűnt az embereknek, hogy az amerikai közbülső választáson nem omlott össze a rendszer. Kiderült, hogy már fél éve átállt az egész backend scala-ra, amivel jobban bírták a terhelést.
Ez itt nem a scala reklámja. Ez itt annak a reklámja, hogy a felhasználó észre se fogja venni a változást amíg annak nincs kihatása a felhasználói felületre. A felhasználó számára a felhasználói felület A rendszer.
bibliográfia
Az első nap bibliográfiája
Goodwin: Designing for the Digital Age
Ginsberg: Designing the iPhone User Experience
—————————————————
Cooper: About Face 3
Brown: Communicating Design
Aki egyetemi jegyzetet akar, annak a DfDD Goodwintől. 700 oldal, minden benne van szinte, olyan, mint a Norvig könyv Mesterséges Intelligenciából.
Aki ennél rövidebbet akar, hasonló tartalommal, annak a Ginsberg-féle iPhone-os könyvet ajánlom. Meg kell jegyezni, nem az iPhone-ról szól.
UX tanfolyam programozóknak/Nemeth 11
A Cooper könyv mindazoknak ajánlott, akik vállalati szoftvereket terveznek.
A diagramok közül azokat, amiket nem tanítanak informatikából, vagy nem én találtam ki kínomban, azokat a Dan Brown könyv tartalmazza. Hozzá kell tenni, azok a diagrammok, amikkel mi ma fogunk foglalkozni, letölthetőek a könyv honlapjról ingyen - www.communicatingdesign.com
A felhasználók
Kik azok a felhasználók
Felhasználónak nevezzük mindazokat, akik kapcsolatba kerülnek magával a rendszerrel annak működése során, illetve inputot biztosítanak számára, vagy az output hatással van az életükre.
Rendszer
Elsődleges felhasználó aki közvetlen kapcsolatba kerül a rendszerrel, azaz valamilyen interaktív felületen használja azt a saját céljaira.
UX tanfolyam programozóknak/Nemeth 12
Másodlagos felhasználó, aki valamilyen inputot biztosít (pl. előállít egy excel táblát), vagy felhasználja az outputot (villanyszámla)
UX esetén felhasználó alatt mindig “széntüzelésű” felhasználót, rendszerint embert értünk, de a megoldások egy része valószínűleg kutyaetető-automata készítésére is alkalmas (bár az interjútechnikáinkon valószínűleg finomítani kéne - tudsz bernáthegyiül?)
A felhasználók csoportosítása
A felhasználókat elsősorban céljaik szerint csoportosítjuk.
A felhasználó célja soha nem a rendszerrel kapcsolatosak, hanem az őket körülvevő világgal.
Példa: a felhasználó nem photoshoppol, a felhasználó fotót retusál. Mi gyerekkorunkban nem gépeztünk, hanem Lara Croftot próbáltuk meg eljuttatni a pálya egyik végéből a másikba, esetleg cseteltünk a barátainkkal, vagy valamiről olvastunk.
Az elsődleges felhasználó a rendszerhez valamilyen célból közeledik. Nem fogjuk bekapcsolni a számítógépet csak úgy, hanem pl. Ha
• meg akarom nézni az indexen a híreket,
• el akarom olvasni a leveleimet,
• el akarok intézni egy beszállítást
• Ki akarom a rezsiszámlákat
• Rendelni akarok egy pizzát
UX tanfolyam programozóknak/Nemeth 13
A felhasználók további csoportosítása
A felhasználókat csoportosítjuk valamilyen, a rendszer használatával kapcsolatos tulajdonságaik alapján.
Ilyen lehet például a demográfia. Az öregedéssel párhuzamosan egyre kevesebb fotocella van a szemünkben, ráadásul az egész szem tunyul, nem képes már a kis betűket kezelni.
Ilyen lehet például valamilyen képesség. A férfiak 8%-a színvak vagy színtévesztő. Van itt a teremben színtévesztő?
Ilyen szokott lenni, hogy a felhasználók mennyire jártasak az adott szakterületen, ill. a számítógéphasználatban. Ez utóbbival óvatosan kell bánni.
Fontos lehet még, hogy a felhasználók milyen gyakran kerülnek kapcsolatba a rendszerrel. Nem mindegy ugyanis, hogy egy rendszert napi szinten, legfeljebb néhány naponta használunk, vagy egyhavonta egyszer, akár csak évente kapcsoljuk be.
Gondoljunk a karácsonyfa-állításra. Számomra minden évben meglepetés, hogy a jó büdös pikulába fogom én azt a fenyőt beleállítani a talpba. Ehhez hozzá kell tenni, hogy műfenyőnk van, évek óta változatlan. De mégis, minden egyes évben újra kell tanulnom a rendszer használatát, minden egyes alkalommal én tulajdonképpen új felhasználó vagyok.
Nem engedhető meg, hogy olyan rendszerekben, amelynek használata nem napi jellegű, az oktatásra hagyatkozzunk. Nincs az a
UX tanfolyam programozóknak/Nemeth 14
tréninganyag, amit valaki minden egyes évben hajlandó végignézni, már csak büszkeségből sem.
A perszónák
A perszónák kitalált karakterek, amelyek sztereotipikusan jellemeznek egy-egy homogénnek tekinthető felhasználói csoportot.
Fogjuk azokat az embereket akik valamilyen szempontokból azonosak,
• társítunk hozzájuk egy képet (én rajzolni szoktam, de a hivatalos megoldás, hogy olyan fényképet kell találni, ahol egy hasonló szerepben - munkakör, stb - épp dolgozó ember van ábrázolva),
• társítunk hozzájuk életcél(okat)
• Társítunk hozzájuk képességeket (tipikusan amolyan fekete-fehér, esetleg valamiféle 1-5 ig skálázós módon)
• Opcionálisan teszünk hozzájuk valamiféle háttértörténetet
Felmerül a kérdés, nem lehetne-e ehelyett role-okról beszélni. De. Csakhogy az emberi agy sokkal inkább feldolgozni történeteket,mint absztrakt fogalmakat. Amikor a csoportokat perszónákkal reprezentáljuk, akkor az ügyfelek számára egy sokkal kézzelfoghatóbb lényt hozunk létre. Tehát a perszóna célja az, hogy megfoghatóvá tegye a felhasználót, megszűntessen egy absztrakciót. Ebből a szempontból a perszóna egy prezentációs, kommunikációs technika.
A perszónák elsődleges célja azonban az elvonatkoztatás magunktól, mind a fejlesztők, tervezők, mind az ügyfelek részéről. “Én értem, hogy te így szeretnéd, de Carol a recepciós képtelen lenne ezt így
UX tanfolyam programozóknak/Nemeth 15
kezelni”.
Ügyeljünk arra, hogy konzisztensen a perszónákat használjuk, nevük, képük folyamatosan jelenjen meg a hozzájuk kapcsolódó feladat-folyamatokat ábrázoló dokumentációkban.
Fontos, hogy a perszóna nem egy létező személy, és ebből következően nem lehet az egyik interjúalanyunk képét felhasználni, pláne nem nevét. Szó szerinti idézetet viszont gyakran érdemes használni az érvelés alátámasztására.
A perszóna íly módon olyan, mint a görög szobor, akinek a combját a város legjobb focistájáról, fejét viszont a város orvosáról mintázták.
UX tanfolyam programozóknak/Nemeth 16
UX tanfolyam programozóknak/Nemeth 17
UX tanfolyam programozóknak/Nemeth 18
A felhasználókutatás
A felhasználókutatás (User Research) célja, hogy megértsük a felhasználókat.
A felhasználókutatás több fázison keresztül kiséri a felhasználó-orientált tervezést. Felhasználók nélkül a felhasználó-orientált tervezés elképzelhetetlen.
A felhasználókutatásnak több módja van, mi itt a megfigyelést és a felhasználói interjúkat ismertetjük (ill. Később a tesztelést). Meggyőződésünk (és a szakmában ezt több jegyzet osztja) hogy ezek nélkül nem beszélhetünk igazán felhasználókutatásról.
A felhasználói interjúk
Az ügyfél nem a felhasználó
Jellemző, hogy azok az emberek, akik megrendelik, netalán felügyelik a rendszer fejlesztését, soha nem fogják használni azt. Megteszik ezt helyettük
• Beosztottjaik
• Partnereik
UX tanfolyam programozóknak/Nemeth 19
• Ügyfeleik
Nekünk ezekkel az emberekkel kell beszélnünk. Az elsődleges felhasználókat keressük elsősorban.
Ehhez ragaszkodjunk. Semmi értelme például egy 10 éve projektmenedzsmenttel foglalkozó, de informatikus végzettségű embert megkérdeznünk arról, hogy mik legyenek az új Visual Studio képességei.
Még akkor is, ha valaki úgy gondolja, hogy ő ehhez még mindig ért, de a napi életben szükségszerűen eltávolodott tőle, nem alkalmas felhasználói interjúra.
Senki ne gondolja magát olyan okosnak, főleg biznisz szoftvernél, hogy ő majd jobban tudja úgyis. Még egy takarítónő is tud meglepetésekkel szolgálni a takaritás mibenlétéről.
Egy kicsit olyan ez, mint egy nagy meglepi, amit valaki olyan készített elő, aki még nem igazán ismer minket.
A field study-k fontossága
Amikor csak lehet, a felhasználót abban a környezetben interjúzzuk, amelyben a rendszer használva lesz.
Ennek egyfelől pozíciós memória okai vannak. Ha most megkérdezlek, hogy mi van a hűtődben, feltehetően nem tudnál rá válaszolni. Ha viszont odamegyünk a hűtődhöz, és előtte állva kérdezlek meg,
UX tanfolyam programozóknak/Nemeth 20
valószínűleg több választ kapnék. Ha pedig kinyithatnád a hűtőt, egész részletesen el tudnád mondani.
Fontos aztán a komfortérzet. Elviszel valakit egy laborba, detektívüveg van, fehér falak, kevés, esetleg műszaki jellegű berendezés, frusztrált lesz.
Fontos, hogy minél inkább elkerüljük a self-reporting hibáit. Az emberek egy csomó dolgot kifelejtenek, vagy épp természetesnek vesznek. Ezt a legegyszerűbben úgy tudjuk elkerülni, hogy figyeljük őket miközben dolgoznak. Ehhez be lehet jelentkezni amolyan furcsa juniornak egy adott céghez, vagy meg lehet kérni néhány élethű példa használatára az illetőket. Érdemes megjegyezni, hogy önmagában a statisztikák és közvetett adatok nem elégségesek.
A mobileszközöknél különösen fontos, hogy megértsük a használat kontextusát.
Mobiltelefon biciklire erősítve (Ginsberg könyvéből, fotózta: Marcus Kwan)
Láttam én már lányt okostelefont használni lovon ülve. Talán épp tájékozódni próbált, merre menjenek. Mit használnánk mi erre? Google Maps-ot. Gondoljuk meg:
UX tanfolyam programozóknak/Nemeth 21
FejlesztőLány a lovon
Laptop Mobil
Nagy képernyő Kicsi képernyő
Vezetékes internet Edge
Stabil felület Ló
Áll Mozog
A laptopra figyel csak Minden másra is figyel
Szabályozott fényviszonyok Tűző napsütés
Azért meg kell jegyezni, a mobilokat nagyon gyakran, és a tableteket szinte mindig nyugalmi helyzetben használják.
Az én gyakorlatom
Én úgy interjúzok, hogy
1. Megkérdem a felhasználót, szerinte kik a felhasználói a rendszernek
2. Szerinte milyen céljaik vannak a rendszerrel
3. Milyen hasonló rendszereket használt már
4. Mondja el egy átlagos munkanapját
UX tanfolyam programozóknak/Nemeth 22
5. Mondja el (ha lehet, mutassa meg a jelenlegi rendszeren), hogyan éri el a céljait (találjunk ki egy hihető célt előtte), kérdezzük meg minél többször, hogy az adott dolgot “miért” csinálja, miért van rá szükség (az ésszerűség határain belül)
6. Mondja el, mi zavarja
7. Mondja el, mit használ jelenleg az új modul helyett
8. Mondja el, milyen, az új modulhoz hasonló szoftvereket ismer, használt már
9. Mondja el, az új modulban mit csinálna
10. Kezdjünk el rajzolni felület-vázlatokat, és kérdezgessük,
⁃ hogyan jönnének az egyes lépések
⁃ Milyen információkra lenne szükség az egyes lépések megtételéhez
⁃ Honnan szerezhetőek be ezek az információk
⁃ Milyen lehetséges hibák lépnének fel
⁃ Ezekkel mit kell kezdeni
A “hivatalos” megoldás szerint az a felhasználó akivel interjúzunk, nem lehet az, akivel a különböző fázisokban tesztelünk. Ettől azonban én naponta használandó szoftver esetén eltekintek, helyette a folyamatos együttműködésre helyezem a hangsúlyt, és végig, a munkafolyamat minden egyes fázisában ugyanazt a néhány felhasználót kérdezem meg, néha-néha véletlenszerűen bevonva másokat is.
UX tanfolyam programozóknak/Nemeth 23
Anekdota: Áramszolgáltató honlapjaAz egyik áramszolgáltatónál honlap-készítésbe kapcsolódtunk be online marketingesként. A honlapot mindenféle bizottsági meetingeken beszélték át, ahol leültek, és többek közt megegyeztek, hogy az olyan dolgokat, amelyek az áramvásárlással kapcsolatosak (fogalmak, folyamatok, stb) egy ún. Tudástár menüpontban helyezik el, a letölthető dolgokat pedig egy Dokumentumtár menüpontban. Ezt 2-3 meetingen megegyezték, és hát ez így milyen jó.
Menüteszteléseket végeztünk, a menütesztelés röviden olyan dolog, hogy adunk egy valós életbeli feladatot, meg egy kinyitható-becsukható faszerkezetet, és megkérünk jelen esetben 100 embert, hogy keressék meg a szerintük a feladat megoldásához vezető menüpontot. Tartalom nincs, nem mondjuk meg hogy a megoldás “jó” volt-e vagy sem, csak megköszönjük az együttműködést.
Voltak feladataink a Tudástárral és a Dokumentumtárral kapcsolatban is, pl. “Szolgáltatót szeretne váltani. Keresse meg a szerződéssablont, amit ki kell ehhez töltenie”. Ezek a feladatok rendszerint csúfos bukással végződtek, 20%, vagy még annyi se találta meg ezeket a menüpontokat.
A felhasználók ugyanis nem voltak ennek a közmegegyezésnek részei. Hiába logikus, miután megértettük ezt a megegyezést, azoknak, akik nem voltak ott, vagy elfelejtették, komoly fejtörést okoz.
UX tanfolyam programozóknak/Nemeth 24
A várt eredmény
A felhasználókutatás eredménye, hogy a felhasználókat fel tudjuk osztani felhasználói csoportokra, ezeket a csoportokat pedig egy-egy perszónával tudjuk reprezentálni.
A felhasználókutatás másik eredménye, hogy tisztában vagyunk azzal, mire fogják használni a szoftvert, és hogy gondolkoznak ezekről a folyamatokról. Hogy ezt hogyan kezeljük le, az a következő lépés problémaköre.
A felhasználókutatás triviális eredménye a felhasználói interjú jegyzet. Ezekben érdemes az alkalmazást meghatározó gondolatokat aláhúzni, kijegyzetelni, és a perszónákhoz felhasználni, “szájukba adni”. Természetesen érdemes eltenni, és egy későbbi fázisban átolvasni, hogy még mindig megfelelünk-e az azokban elmondott gondolatoknak.
Problémamodellezés
A számítógép interaktív
Az elsődleges felhasználó az, aki a rendszerrel közvetlen kapcsolatba lép, méghozzá azért, mert a rendszerrel célja van.
Vegyük észre: itt egy kölcsönhatás történik. Megtörténik valami esemény, amely után a rendszer vagy a felhasználó nem lesz ugyanolyan.
UX tanfolyam programozóknak/Nemeth 25
Ebből következően ez egy folyamat, és elsősorban idővonal mentén értelmezhető.
Problémák és célok
Az “életcélokat” amiket a perszónáknál definiáltunk, szét kell bontani. A cél olyan, amely segíti a nagy cél megoldását, ugyanakkor nem számítógép-specifikus. A “fájl mentése” pl. számítógép-specifikus, de a “minden projekt dokumentumai egy helyen legyenek” már nem az.
Problémákból követelmények
Milyen módszert alkalmazzunk a követelmények létrehozására?
A válasz egyszerű: majdnem mindegy, a lényeg, hogy az elemek egymásra épüljenek, és a fa (matematikusoknak: erdő) csúcsán a felhasználók céljai és képességei álljanak
Mindezt pedig interjúkkal, (felhasználói) tesztekkel (és esetekben tudományos eredményekkel) támogatva.
Azt már korábban észrevették mások (az építészetben Alexander, az informatikában pl. Conway) hogy egy szoftver minősége elsősorban a létrehozási folyamattól függ.
Tehát ha a létrehozási folyamat felhasználócentrikus, és a létrehozás a felhasználók bevonásával történik, a szoftvert sokkal jobban fogják szeretni a felhasználók, mintha valaki megmondaná, hogy mi legyen nekik a jó, anélkül, hogy ezt az elméletét legalább tesztelné velük.
Ha a létrehozási folyamatba nem engedünk felesleges elemeket - pl. a
UX tanfolyam programozóknak/Nemeth 26
megrendelők laikusságból adódó kívánságait, vagy a programozók saját mániáit - akkor a szoftver sokkal kevesebb bottleneck-kel fog rendelkezni.
Mindegy, milyen követelményrendszert használunk, a lényeg az, hogy a követelmények “generálják” a rendszert. A konzisztenciát az biztosítja, ha valamiféle DNS-kódként működnek.
Use Case modellezés
Cockburn klasszikus informatikai könyve - Writing Effective Use Cases - nagyon jól lefedi a Use Case modellezést, és nagyon hasznos is.
Mindaz, amit ő leír a use case-ekről igaz, és használandó.
Egyetlen egy baj van vele: nehezen áttekinthető és olvasható egy use case az ügyfelek számára. Ha csak és kizárólag magunknak írnánk a dokumentációt, use case is the way to go.
Minden tervünket validáltatnunk kell a felhasználókkal és az ügyfelekkel. Az ügyfelekkel azért, hogy elhiggyék, hogy dolgozunk, a felhasználókkal pedig azért, hogy olyan rendszert csináljunk, amit ők aztán később használni fognak.
Ezért aztán máshogy fogjuk prezentálni ugyanazt az információt.
Skiccek (Sketches)
A felhasználói interjúknál utaltam már rá, hogy az interjú során
UX tanfolyam programozóknak/Nemeth 27
vázlatokat (nevezzük így: skiccek, angolul: sketches) készítek.
Egy skicc különbözik a prototípustól vagy a dizájntól. Először is olcsóbb, sokkal.
Másodszor, kevésbé kidolgozott. Gyakran magyarázott.
A médium majdnem mindegy. Egy skicc lehet rajzolt, lehet szöveges, lehet legóból összerakott, lehet hogy photoshopban dobjuk össze, a lényeg a gyorsasága és a kidolgozatlansága.
Fontos megjegyeznünk, hogy skiccet csak és kizárólag olyan emberrel kommunikáljunk, akivel épp folyamatos kommunikációs kapcsolatban vagyunk. Az első kérdése egy olyan embernek, akivel nem vagyunk ilyen kapcsolatban, hogy miért nincs ez rendesen kidolgozva? Miért szürke? Miért görbék a vonalak? Miért van az ott? Ilyen lesz a végleges is?
Helyszíni szemlén délután, másnap még vissza lehet menni egy vázlattal, de utána már semmiképp.
Egy skiccet nem tömeges bemutatásra szánunk, sokkal inkább beszélgetésekhez, segédanyagnak. Ha prezentálni akarunk, ahhoz már terv - dizájn - kell.
Buxton: Sketching User Experiences - Getting the right design and getting the design right
To help guide us, here is my best attempt to go “meta” and capture their relevant attributes of conventional sketches. Sketches are:
UX tanfolyam programozóknak/Nemeth 28
• Quick: A sketch is quick to make, or at least gives the impression that that is so.
• Timely: A sketch can be provided when needed.
• Inexpensive: A sketch is cheap. Cost must not inhibit the ability to explore a concept, especially early in the design process.
• Disposable: Sketches are disposable. If you can’t afford to throw it away when done, it is probably not a sketch. The investment with a sketch is in the concept, not the execution.
• Plentiful: Sketches tend to not exist in isolation. Their meaning or relevance is generally in the context of a collection or series, not as an isolated rendering.
• Clear vocabulary: The style in which a sketch is rendered follows certain conventions that distinguish it from other types of renderings. The style, or form, signals that it is a sketch. The way that lines extend through endpoints is an example of such a convention, or style.
• Distinct Gesture: Not tight. Open. Free.
• Constrained Resolution: Sketches are not rendered at a resolution higher than is required to capture their intended purpose or concept. Going beyond “good enough” is a negative, not positive. (Which is why I take marks off student’s work if it is too good.)
• Appropriate Degree of Refinement: The resolution or style of a sketch’s rendering should not suggest a degree of refinement of the concept depicted that exceeds the actual state of development, or thinking, of that concept.
UX tanfolyam programozóknak/Nemeth 29
• Ambiguity: Sketches are intentionally ambiguous, and much of their value derives from their being able to be interpreted in different ways, and new relationships seen within them, even by the person who drew them.
• Suggest & explore rather than confirm: More on this later, but sketches don’t “tell,” they “suggest.” Their value lies not in the artifact of the sketch itself, but its ability to provide a catalyst to the desired and appropriate behaviours, conversations, and interactions.
A történetek ereje
Az emberi agy két dolgot tud nagyon jól feldolgozni: más embereket, és velük kapcsolatos történeteket. Igaz ez az ügyfeleinkre, felhasználóinkra, és ránk is.
A jó történet ismérvei:
• A történetnek van főhőse (aki az egyik perszónánk)
• A főhősnek van célja, ami összhangban van az életcéljával
• Ezt a célt (pozitív történet esetén) eléri
• A történet hihető, tehát nem tartalmaz az adott univerzumba nem illő elemeket (Mátyás király idejében a “kocsijába szállt, és Budáról két óra alatt Bécsben volt” nem számíthatott hihető történetnek, de mi is elhisszük Gandalfról, hogy tud varázsolni)
• A történetnek narratívája van, azaz, bármilyen sorrendbe is tesszük az egyes elemeit a mesélésben, ezek “időben síkbarajzolhatóak” (még a 22-es Csapdájának is volt narratívája!)
UX tanfolyam programozóknak/Nemeth 30
• A történetben konkrét adatok vannak (nem “kiválasztja a fájlt amivel szeretne valamit kezdeni” hanem előveszi a múlt heti projekt aktáját)
• A történet a főhős képességeivel, belső mozgatórugóival “magától” megtörténik - pl. előre tudja, hogy a menüpontot hogy fogják hívni, vagy melyik gombot kell megnyomni.
Ha a terveinket vesszük, gráfelméleti szempontból a történet nem más, mint egy bejárás a belépési pontoktól valamely befejezésig.
Minden folyamat-modellnek egy vagy több történettel kell rendelkeznie.
Ezeken a történeteken keresztül mutatjuk be őket, ezeken a történeteken keresztül teszteljük őket.
Tréninget csak és kizárólag olyan történetekhez készíthetünk, amelyek napi rendszerességgel, konzisztensen fordulnak elő minden felhasználónál. Minden más esetben feltételeznünk kell, hogy a főhős nem rendelkezik plusz információval, ami előbbre vinné. Erről részletesen a holnapi napon lesz szó.
Anekdota: Az Airbus halálaAz Air France tragikus sorsú 447-es járata egy AirBus 337-es géppel közlekedett.
Az AirBusról tudni kell, hogy elsődleges tervezési elvük a PEBKAC, azaz a hibák elsődleges oka az emberi mulasztás, és ennek megfelelően igyekeznek minden lehetséges dolgot
UX tanfolyam programozóknak/Nemeth 31
automatizálni a repülőkben.
Történt pedig, hogy kikapcsolt a robotpilóta. Ez önmagában nem probléma, a robotpilóta azért kapcsolt ki, mert inkonzisztenciákat vélt felfedezni a különböző szenzorok értékei között, azok ugyanis pillanatnyilag befagytak.Egy manuálisan reptetett gépen ez teljesen rutinhelyzet lett volna, és természetesen megvolt rá a megfelelő procedúra. Azonban annyira ritkán fordult elő ez a helyzet, hogy a pilóták pánikszerűen reagáltak ,miközben a gép süllyedni kezdett.
Az Airbus közvetett irányítású gép, a botkormányok csak számítógépes joystickok tulajdonképp. A két botkormány működése ráadásul független. A kevésbé tapasztalt harmadpilóta pánikszerűen elkezdte húzni maga felé a botkormányt, hogy feljebbkerüljenek. A tapasztalt kapitány hiába vezette szabályosan a gépet, a két joystick közül a másik hatása volt előbbrevaló.
Átfordulás veszélye állt fent, ennek megfelelően a gép vészszirénája felvijjogott. A sziréna 48 másodpercen keresztül szólt. A 48 másodperc többségében a hiba megelőzhető lett volna, azonban, mivel nem volt hova tenni a dolgot, nem értették, mi történik figyelmen kívül hagyták.
A felhasználók is ugyanígy járnak, ha nem napi esemény történik velük, és valamiért nem észlelik tetteik és a rendszer viselkedése közti összefüggést. Csak remélni tudjuk, a hatás kevésbé lesz katasztrofális.
UX tanfolyam programozóknak/Nemeth 32
Folyamattervek
A folyamatterv - ahogy a nevében is benne van - terv, design. Részünkről ez azt jelenti, hogy explicit konvenciókat követ. Továbbá azt is jelenti, hogy elvárás vele szemben a saját keretein belüli konzisztencia.
A folyamatterv egy modell abban az értelemben, hogy a valóság vagy elképzelés bizonyos elemeit kihangsúlyozza, míg más elemeit elrejti.
Fontos, hogy a vázlatainkból tudjunk terveket készíteni.
A vázlat félreérthető. Lehet, hogy akivel beszéltünk, mást értett a vázlaton, mint mi, vagy mi magunk mást értünk alatta feldolgozás közben mint akkor
A vázlat nem konzisztens. Teli van hibákkal.
A terv ellenőrzi egy elképzelés helyességét az által, hogy konvencióknak felel meg.
Értelemszerűen a vázlataink alapja a tervstílusok lesznek. Ehhez minél több ábrázolási módot kell elsajátítani, hogy képesek legyünk minél több nézőpontból látni ugyanazt, képesek legyünk megragadni a fontos részleteket.
A terveink alapjai pedig természetesen a vázlataink lesznek.
Egy folyamattervet be lehet mutatni, alkalmas tömegkommunikációra. Lehet pro és kontra érveket felhozni vele szemben, hisz nem félreérthető.
UX tanfolyam programozóknak/Nemeth 33
Skicc, terv és prototípus
Skicc Terv Prototípus1:1 kommunikációra Tömegkommunikációra 1:1 kommunikációraFőleg felhasználóknak Mindenkinek Főleg felhasználóknakKétértelmű Egyértelmű Egyértelmű, de korlátosCsak a kapcsolódó beszélgetéssel együtt érthető
Önmagában állÁllhat önmagában, de korlátai előzetes megegyezés tárgya
Beszélgetés része Egyből áttekinthető Nem áttekinthető
Felfedezni (elképzelést gyártani)
Biztosítani a konzisztenciát (azaz, hogy az elképzelés helyes)
Validálni a tervet (hogy az elképzelés megfelel a valóságnak)
Absztrakt folyamattérkép
UX tanfolyam programozóknak/Nemeth 34
Képernyőfolyamat
UX tanfolyam programozóknak/Nemeth 35
UX tanfolyam programozóknak/Nemeth 36
UX tanfolyam programozóknak/Nemeth 37
Prototípizálás
Miért prototípizálunk?
Először is, mert nem szeretnénk rögtön a lovasságot küldeni.
Másodszor, mert ha már a kész szoftverrel találkoznak a felhasználók, már az lesz az indok, hogy “rossz ,rossz, de ha már ennyi pénzt beleöltünk…”, pedig korán ki lehetne szűrni az ilyen dolgokat.
Ne feledjük: a számítógép interaktív. Kizárólag interakcióban lehet megérteni, hogy a működés jó-e vagy sem.
Ugyanakkor azt se feledjük, a felhasználókat nem érdekli a backend. Egy üres héjat kell prezentálnunk, ami viszont valós adatokon alapszik. Szóval szerezzünk be valós adatokat, de semmiképpen ne kapcsoljuk adatbázishoz a prototípust!
VIgyázzunk a prototípus élethűségével: ha túl élethű, a felhasználó azt hiszi, már csak néhány nap és kész a teljes változat is. Ha nem elég élethű, beleképzeli a kacsalábat meg a forgóvázat is.
A prototípust mindenképp lássák fejlesztők is, akik a rendszeren dolgoznak, nehogy véletlenül mi tegyük bele a kacsalábat, hamis ígéretet adva ezzel a felhasználóknak.
A prototípus tipikus médiuma a Powerpoint, az interaktív PDF, a képváltó megoldások (akár a felülettervező programon belül), vagy az HTML5-JS.
Anekdota: Alexander és a prototipizálásAlexander nagyon hitt a prototipizálásban. Az Eishin egyetem
UX tanfolyam programozóknak/Nemeth 38
kampuszának ablakait pl. Úgy építette meg, hogy először a műhelyükben összeraktak kartonpapír falakat, amikre lyukakat vágtak, azokat pedig pauszpapírra vonták be. Ezután lámpákat helyeztek a kartonlapok mögé, és szimulálták a nap járását.
Amikor ezzel végeztek, és már megépült az a szint az épületben, de még falak nélkül - csak a tartószerkezet - ahova ezt szánták, odamentek, és a konkrét épületet végigvonták ezekkel a kartonlapokkal, és így tesztelték le, az utolsó két dizájnból melyik a megfelelő
Forrás: Nature of Order
Tesztelés
Heurisztikus tesztelés
Visibility of system statusThe system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Match between system and the real worldThe system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. User control and freedomUsers often choose system functions by mistake and will need a clearly
UX tanfolyam programozóknak/Nemeth 39
marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Consistency and standardsUsers should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Error preventionEven better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. Recognition rather than recallMinimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Flexibility and efficiency of useAccelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Aesthetic and minimalist designDialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
UX tanfolyam programozóknak/Nemeth 40
Help users recognize, diagnose, and recover from errorsError messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Help and documentationEven though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
Automata vs felhasználói tesztelés
Robotokkal kiválóan lehet tesztelni azt, hogy a rendszer jó lesz-e robotoknak.
Az automatikus teszteléssel két baj van:
1) Az új divat szerint az automatikus tesztet az írja, aki magát a szoftvert. Logikus módon valamelyest egy rugóra jár az agyuk, akármennyire is próbálja ezt szándékosan elrejteni, és egy elég jó elképzelése van arról, hogyan kéne belsőleg működnie, sőt, lehet, hogy emlékszik is rá
2) Az automata tesztelés bürokrata: egyféleképpen hajtódik végre, egyféleképp fogadja el a működést: az ember nem ilyen. Az ember rengeteg, papíron különböző megoldást tud elfogadni, és minden egyes alkalommal egy picit másképp csinálja a dolgait. Az automata tesztelés szükségszerűen rugalmatlan, mint egy hivatalnok: az emberi gyarlóságot legjobban emberekkel tudjuk bevinni.
UX tanfolyam programozóknak/Nemeth 41
Embereknek szóló rendszereket embereken is kell tesztelnünk.
Vegyünk egy példát: tételezzük fel, hogy felkérnek egy város építésére: neked kell megtervezned. Megtervezed, megcsinálják, utána viszont a térképek elvesznek. Te mégis sokkal jobban fogsz tudni közlekedni a városban, hisz a térkép egy része “belédég”.
Ha viszont egy idegen városba kerülsz, térkép nélkül, nem igazán tudod, mi merre van: fokozatosan fogod felfedezni az egészet. Adott esetben teljesen más ismereteid lesznek neked a városról, mint egy másik ott bóklászónak, más kereszteződések ragadták meg a figyelmeteket, másra emlékeztek.
Tesztelés és történetek
Az előző fejezetben szó volt történetekről.
Ezeknek a történeteknek volt főhősük, akiről feltételeztük, hogy adott céljai, képességei és mozgatórugói vannak, a történetről pedig feltételeztük, hogy ezek a célok “automatikusan” elérhetőek a főhős tulajdonságaival a szoftveren belül.
A teszt bizonyos szempontból nem más, mint ennek a történetnek az élethűségének a tesztelése.
Ehhez keresünk olyan embereket, akik képességeikben hasonlóak az elképzelt főhőseinkhez (pl. azért, mert róluk mintáztuk őket), majd
UX tanfolyam programozóknak/Nemeth 42
felruházzuk őket azokkal a célokkal, amikbe képzelt főhőseinket rángattuk, és megfigyeljük, tényleg automatikusan túljutnak-e az akadályokon.
Ezzel teszteljük azt is, hogy a főhőseinket tényleg az-e a motivációja amit mi gondoltunk.
A legtöbb esetben, hacsak nem valami nagyon szakértői rendszerről van szó, nem fontos, hogy pontosan illeszkedjen a főhőseink és a tesztelőink tudása.
Kikkel teszteljünk?
A tesztalanyok körét a gyakorlatban leginkább a titoktartási szerződések szűkítik. Minden alkalmat ragadj meg, amikor ezeket ki lehet kerülni (pl. A program meglévő, nyilvánosan letölthető változata, konkurens alkalmazások, stb), ill. Vond bele a tesztalanyokat a titoktartási körbe.
Innentől kezdve szinte mindenkivel.
Nem érdemes túlzottan tesztelnie az adott modul írójának: marha jól ismeri az egészet. Általában az a javaslatom, hogy a programozók sikereit ne vegyük túl komolyan: mindaz a tudás ami egy átlagos állásfelvételi túléléséhez szükséges a munkakörükben túlságosan előre helyezi őket absztrakció, és modellalkotás területén, ráadásul sokuk 0-24 gép előtt ül.
Ha napi használatú, vállalati szoftverről van szó, akkor teszteljünk nyugodtan azokkal a felhasználókkal, akikkel interjúztunk. Ezeknek a szoftvereknek ugyanis nem baj, ha van betanulási időszaka. De ha valamit a második-harmadik alkalommal se találnak meg, kérdés
UX tanfolyam programozóknak/Nemeth 43
nélkül cseréld!
(Ne kérdezd meg, hogy szerintük cseréld-e: minden felhasználó úgy érzi, hogy ő a hülye, ha valamit nem talál a programban, de nem, a program rossz.)
Havi, vagy ritkább használatú szoftvernél a betanulás viszont elképzelhetetlen, csakúgy, mint casual szoftvereknél. Egy havi programra minden egyes alkalommal úgy fognak tekinteni, mint borjú az újkapura. Egy konzumer program (pl. Egy mobilalkalmazás) ha nem használható a feltelepítés utáni első alkalommal, az esetek 26%-ban (2011-es adat) nem még egy alkalma bizonyítani. A webapp ennél rosszabb.
Ergó az összes alkalmazást, de főleg a konzumer és ritkán használt belső alkalmazásokat “alkalmazás-szűzekkel” is kell tesztelni
Az, hogy mennyire kell “domain” előélet az alkalmazás használatához, változó. Ha a Photoshop használatához grafikusnak kéne lenni, az Adobe sokkal szegényebb lenne. Általában ha egy szakmában dolgozó sem találja meg a gombokat egyáltalán, már régen rossz.
Általánosan elmondható, hogy egy átlagos felhasználó, főként adminisztratív munkakörben nincsen “igazán” ott, nem rendelkezik annyi speciális tudással, amelynek hiánya komolyan kell, hogy akadályozza a használatot. Persze jobb, ha a tényleges célokkal valaki tisztában van, de a felhasználó elsősorban ember, és másodsorban szakértő, így a hibák nagy része emberi mivoltából következik. Tehát ha nem találunk szakmabeli alanyt, ez nem lehet indok arra, hogy nincs tesztelés, vagy nem vesszük komolyan annak eredményeit!
UX tanfolyam programozóknak/Nemeth 44
A tesztelés szabályai1. A programot teszteljük, nem a felhasználót. Ha a felhasználó nem talál
valamit, a program rossz.2. Kuss - nem magyaráz el, nem mutat meg, legfeljebb kérdez. 3. Ha nem sikerül, nem sikerül, majd átírjuk a programot, hogy legközelebb
sikerüljön4. Nem csak azt teszteljük, amire kiváncsiak vagyunk, azt is teszteljük,
mennyire különbözik a látásmódunk. A felhasználónak lehet, tök más a fontos, és ő fog a programmal élni, nem mi.
A tesztelés körülményei
A tesztelés zajlhat
• A felhasználó saját életterében (otthonában, munkahelyén)
• Tesztlaborban
• Kocsmában
• Tesztélettérben (Living Lab)
Philips ExperienceLab tesztélettér, Eindhoven
A tesztélettérre valószínűleg senkinek nincs pénze, ilyenje van pl. A Philipsnek. Komplett családokat költöztetnek egy Való Világ-szerűen bekamerázott lakótérbe, ahol fejlesztés alatt álló termékeket adnak
UX tanfolyam programozóknak/Nemeth 45
nekik.
A kezdő tesztelő bizonyára a tesztlabort tartja megfelelőnek, hisz ott csak a feladatra lehet koncentrálni. Tesztlabor ma már bármi lehet, amibe belefér egy számítógép (mobiltelefon) és két ember, régebben ez egy bekamerázott és detektívtükrös helyiséget jelentett. Ma már egy laptop webcamja és képernyőképe bárhova közvetíthető, a hanggal együtt. A Tobii legújabb szemkamerája pedig kb. egy rúd Toblerone méretét jelenti, az esetek többségében azonban egyáltalán nincs rá szükség
A való életben használat során azonban nem csak a feladatra koncentrálunk, folyamatosan körül vagyunk véve zavaró tényezőkkel (nyílt irodában a munkatársak, otthon a gyerek vagy a szomszéd fűnyírója).
Ezért elsődleges tesztelési módszer a felhasználó saját életterében való tesztelés.
A kocsmában tesztelés előnye(!), hogy a felhasználók egyfelől egy sok zavaró tényezővel rendelkező térben vannak, másrészt részegek. A kismértékű alkoholfogyasztással ugyanis pont azok a képességek változnak meg - koncentráció csökkenése, elkalandozás, helyzetfelismerési hibák - amikre az egész usability épül.
Azt az alkalmazást, amit egy kocsmában két sör elfogyasztása után még mindig lehet használni, színjózanon is menni fog bármikor.
Fontos, hogy ilyen alkalommal ilyenkor inkább csak a felhasználó igyon, ne mi. Az se árt, ha a teszteléshez használt készülékek nem kapnak alkoholmérgezést a teszt végrehajtása során.
A tesztelés kimenete minden esetben a következő:
UX tanfolyam programozóknak/Nemeth 46
• Egy képernyőfelvétel (vagy váll mögüli felvétel) a használatról
• Egy hangfelvétel a felhasználó gondolatairól és a lezajlott diskurzusról, szinkronban az előzővel
• Egy (lehetőleg időpontos) jegyzet akkor-és-ott figyelemreméltó eseményekről
• Opcionálisan egy videófelvétel a felhasználó arcáról használat közben
• Opcionálisan szemkamerás követési gráf vagy hőtérkép
Tesztelni lehet prototípust (paper prototype, informatikusoknak inkább interaktivizált powerpoint vagy egyéb hotspot-alapú megoldás) vagy kész terméket is.
Krug-féle tesztszkript
Introduction
UX tanfolyam programozóknak/Nemeth 47
Hi, . My name is Steve Krug, and I'm going to be walking you through this session.
You probably already know, but let me explain why we've asked you to come here today: We're testing a web site that we're working on to see what it's like for actual people to use it.
I want to make it clear right away that we're testing the site, not you. You can't do anything wrong here. In fact, this is probably the one place today where you don't have to worry about making mistakes.
We want to hear exactly what you think, so please don't worry that you're going to hurt our feelings. We want to improve it, so we need to know honestly what you think.
As we go along, I'm going to ask you to think out loud, to tell me what's going through your mind. This will help us.
If you have questions, just ask. I may not be able to answer them right away, since we're interested in how people do when they don't have someone sitting next to them, but I will try to answer any questions you still have when we're done.
We have a lot to do, and I'm going to try to keep us moving, but we'll try to make sure that it's fun, too.
You may have noticed the camera. With your permission, we're going to videotape the computer screen and what you have to say. The video will be used only to help us figure out how to improve the site, and it won't be seen by anyone except the people working on the project. It also helps me, because I don't have to take as many notes. There are also some people watching the video in another room.
If you would, I'm going to ask you to sign something for us. It simply says that we have your permission to tape you, but that it will only be
UX tanfolyam programozóknak/Nemeth 48
Background information questions
Before we look at the site, I'd like to ask you just a few quick questions. First, what's your occupation?
Good. Now, roughly how many hours a week would you say you spend using the Internet, including email?
How do you spend that time? In a typical day, for instance, tell me what you do, at work and at home.
Do you have any favorite Web sites?
Now, finally, have you bought anything on the Internet? How do you feel about buying things on the Internet?
And what have you bought?
OK, great. We're done with the questions, and we can start looking at things.
Usability test
First, I'm just going to ask you to look at this page and tell me what you think it is, what strikes you about it, and what you think you would click on first.
For now, don't actually click on anything, just tell me what you would click on.
And again, as much as possible, it will help us if you can try to think out loud so we know what you're thinking about.
From this point it's up to you. Ask them to consider the elements of the site and ask for their verbal feedback every step of the way.
UX tanfolyam programozóknak/Nemeth 49
Chapter Two: Mikro UX
A második nap bibliográfiája
Jeff Johnson: Designing with the Mind in Mind
Weinschenk: 100 dolog amit minden dizájnernek tudnia kell az emberekről (magyarul is)
———————————————————
Tidwell: Designing Interfaces
Krug: Rocket Surgery Made Easy
Az ember képességei
Az informatika legnagyobb korlátja az ember. Minden változik, de az ember az egyetlen fix pont. Az ember képességei, órajele,
UX tanfolyam programozóknak/Nemeth 50
figyelőkészsége nem változik, azok ugyanis biológiailag meghatározottak.
A későbbiekben látni fogjuk, hogy az emberek nem figyelnek, és ahhoz túl gyorsak, hogy a programozók lusták legyenek, ahhoz viszont túl lassúak, hogy mindent észrevegyenek.
Egy fontos dolgot szeretnék megjegyezni: a programozó is ember. Ugyanakkor a programozót sokkal jobban készteti a környezete arra, hogy a figyelmét a számítógépre összpontosítsa, mivel ezért fizetik. Egy átlagfelhasználó számára maga a számítógép nem, de a vele elvégzendő feladat nagyonis érdekes.
A figyelem
Először is: se a nők, se a férfiak nem képesek figyelni egyszerre két mentális cselekvésre (Weinschenk 46). Képesek vagyunk figyelni egy begyakorlott fizikai és egy mentális cselekvésre, így fordulhat elő, hogy tudunk sétálva beszélni.
A jó hír az, hogy egész jók vagyunk preemptív multitaszkingban, és ezzel megteremtjük a multitaszk illúzióját magunknak.
Kockául: Human, release code “Sapiens”. Number of CPU Cores: 1.
Figyelemidő
Másodszor: a napi tevékenységeink során az esetek 30%-ában nem figyelünk. (Weinschenk 29). Ezek azok a tevékenységek, amiket különösebb zavaró tényezők nélkül végzünk, ráadásul ezért fizetnek
UX tanfolyam programozóknak/Nemeth 51
minket. A rossz hír az, hogy ennek nem vagyunk tudatában, és le is fogjuk tagadni, cserébe tervezni kell vele.
Amikor nem a fő feladatunk az, amit csinálunk (jelen esetben a szoftver kezelése), akkor ez a szám nem 30%, simán lehet 70% is.
A felhasználó nem hülye, csak sokszor nem figyel. Ez biológiai működéséből következik, ez egy tervezési követelmény, nem pedig átnevelendő viselkedésminta.
Ennek a helyzetnek a tesztelésével foglalkozni kell.
Van még egy ezzel kapcsolatos probléma: ha nem figyelünk, és hirtelen kérdéseket tesznek fel, bizonytalanok vagyunk. A bizonytalan ember pedig makacsul ragaszkodik eredeti elképzeléseihez (Weinschenk 30). Ezt a kövekező példán lehet egyszerűen szemléltetni:
Soha ne tegyünk fel utólag kérdéseket.
A felhasználóról általánosan elmondható, hogy nem az eszközre figyel, hanem a célra, amit el akar érni. A legtöbb felhasználót nem a program vagy honlap érdekli, hanem az, amit csinál, így nem figyel a programra. De ha figyelne, akkor is max az esetek 70%-ában.
Az agy működése
UX tanfolyam programozóknak/Nemeth 52
Ha 10 másodperced van válaszolni a következő kérdésre:
Egy baseball ütő és labda együtt 110$-ba kerül. Az ütő 100 $-ral kerül többe mint a labda, mennyibe kerül a labda?
Mit válaszolsz?
Az emberek többsége azt fogja válaszolni, hogy 10$.
Rövid matematikai számolással belátható, valójában a labda csak feleennyibe kerül.
A másik, magyar példa erre ez: http://www.youtube.com/watch?v=9gkxE3s4p1s
De miért is számolunk félre?
A két agy modell szerint az embereknek két üzemmódjuk van: a robotpilóta, és az éber üzemmód. Az éber üzemmód azonban fárasztó, ezért nem használjuk annyit, inkább csak akkor, ha fontos, és szükség van rá.
Normál esetben az autópilóta vezet, és ha nem értékeli fontosnak a problémát, nem ébreszti fel a gondolkozást. Ennek az autópilótának azonban relatív gyengék a következtetési képességei, inkább az arányokat érzékeli csak.
Lehet, hogy két agy-üzemmódunk van, de jelen kutatások szerint nincs két memóriánk. Egyetlen memória-rendszer van, ami kettős feladatot lát el, mind hosszútávú, mind rövidtávú emlékezetként funkcionál.
A rövidtávú memória félrevezető fogalom. Helyesebb lenne “munka
UX tanfolyam programozóknak/Nemeth 53
memóriának hívni”. Az átmeneti tárolás ideje néhány másodperc, maximum 1 perc, és ezek azok az elemek, amik “épp fejben vannak”.
Ezek kontextusfüggőek. Mint látni fogjuk, a figyelem biztonságosan kb. 10 másodpercig tartható fenn, amint feladatot váltunk, a munkamemória elemei törlődnek. Tipikusan kontextusfüggő:
Odamész a hűtőhöz, hogy egyél egy joghurtot. Elindulsz a konyhába, beérsz, kinyitod a hűtőt és… gondolkozol, miért is jöttél.
A konyhában más kontextusba kerültünk, a munkamemória tartlama törlődött.
A törlődésre a legjobb példa az a kandikamera-showba illő kísérlet, ahol beépített emberek elveszett túristaként kiálltak a városba, egy térképpel a kezükben. Az arra járó emberektől segítséget kértek, hogy magyarázzanak el valamit. Az emberek elkezdtek gondolkozni, de közben két munkás (szintén beépített emberek) egy nagy ajtót cipelt el kettejük között. A kísérletalanyok nem vettek észre semmit, és folytatták az útbaigazítást, pedig ezalatt a turistát kicserélték egy másikra, aki adott esetben más ruhában volt, vagy épp szakállas.
A munkamemória nem képes 7 különböző elem kezelésére. A valós szám 4-5 körül van, amit telefonszámokkal lehet leginkább illusztrálni:
1-345-4544
Ha 7-elemű lenne a memóriánk, lennének 5 elemű részek a telefonszámokban. A probléma nyitja az, hogy az eredeti kísérletekben 2-3 elemet mindig csoportokba lehetett fűzni amelyek
UX tanfolyam programozóknak/Nemeth 54
így már egyetlen elemet alkottak.
A munkamemória egyenes következménye, hogy a kontextusnak, rendszerállapotnak mindig jelen kell lennie: a felhasználónak válaszolnia kell tudnia a “hol is vagyok?” kérdésre.
Példa:
• Ha az alkalmazás módot vált (pl. Egy digitális fényképezőgép videó- vagy fényképmódja, egy rajzolóprogram eszközkészlete), ez a mód legyen nagyon világos (kurzor, keretszín, bazi nagy piros pont vagy középen villogó ikon..)
• keresés esetén a keresett kifejezés mindig maradjon látható
• Navigáció esetén minden “helynek” legyen neve, és lehessen oda-vissza közlekedni.
• Ha valamilyen recept van, lépésről-lépésre, az legyen látható, de legalábbis könnyen előhozható a lépések között
A hosszútávú memóriáról azt kell tudni, hogy a jó program arról ismerkszik meg, hogy nem használtatja. A hosszútávú memória felbontása nagyon változó (figyelemtől függ), a tartalma cserélhető (ha eleget sulykolnak egy eseményt, el fogod hinni, hogy megtörtént),
A sulykolást azonban előnyünkre is használhatjuk: ha eleget sulykolunk valamit, öntudatlanul is megtanulják az emberek, ezért kell az interfésznek konzisztensnek lennie, és konzisztens mintákat követnie.
Kérdés (Johnson): melyik a következő szekvenciák közül a leginkább
UX tanfolyam programozóknak/Nemeth 55
tanulható?
Kivág-beszúr A B C
Szöveg Ctrl-X, Ctrl-V Ctrl-X, Ctrl-V Ctrl-X, Ctrl-V
Videó Ctrl-X, Ctrl-V Ctrl-C, Ctrl-P Ctrl-X, Ctrl-V
Kép Ctrl-X, Ctrl-V Ctrl-Z, Ctrl-Y Ctrl-X, Ctrl-V
Rajz Ctrl-X, Ctrl-V Ctrl-W, Ctrl-N Ctrl-X, Ctrl-V
Táblázat Ctrl-X, Ctrl-V Ctrl-Q, Ctrl-R Ctrl-E, Ctrl-R
Következő kérdés: melyik tanulható a legrosszabbul?
Első logikus válasz: B. Valószínűleg tényleg hosszú lenne megtanulni, de idő után megszoknák az emberek, hiszen egy konzisztens struktúra
Az igazi válasz: C. Az emberek rendszeresen hibáznának, hisz mindig ugyanúgy kell csinálni, kivéve, ha táblázat van.
Mentális modellek, Norman-féle mentális modell
Az ember egy olyan élőlény, amely hajlamos mindent megmagyarázni magának. Nem szeretjük a magyarázat-nélküliséget, ezért mindent igyekszünk összekötni.
Sokszor azzal magyarázzuk meg a dolgokat, hogy hülyék vagyunk. Pl. Ha az előbbi példában a táblázatot rosszul szúrnánk be, mondanánk, hogy ja, persze, hülye vagyok, holott a szekvenciát, mint
UX tanfolyam programozóknak/Nemeth 56
megbeszéltük, igazából az életbe nem lehet helyesen megtanulni. Persze senkinek nem kell sokáig gondolkozni, hogy “misztikus” példákról tegyen beszámolót
A dolgok mibenlétéről és viselkedéséről alkotott összetett képeinket mentális modelleknek hívjuk. Amíg a mentális modell és a valóság szinkronban van, addig nem zavar minket, hogy esetleg köze nincs hozzá - gondoljunk csak a kis emberekre a tévében.
Norman hosszan foglalkozik a mentális modellekkel klasszikus könyvében (Design Of Everyday Things). Négy alapszabályt fogalmaz meg:
• Készítsünk egy jó fogalmi modelt
A fogalmi modell nem rendszermodell. A fogalmi modell lehetőleg egyszerű, és a felhasználótól jön: az ő szavait használja, az ő összefüggéseit. A rendszermodell technikai szükségletekből jön. Példa erre egy hűtőszekrény: a két potméter közül az egyik a fagyasztó teljesítményét szabályozza, a másik hogy ebből mennyit adjon át a sima hűtő térbe. A kettő közt nyilván van egy matematikai összefüggés. Rendszerileg teljesen érthető, de a felhasználó valószínűleg ha lát két kapcsolót, az egyiket fent, a másikat lent, nem erre gondol, benne nincs olyan modell, amely ezt fontossá tenné.
Ismét: trénelni, elmagyarázni lehet, de főleg napi használatú programot. Ne akarjuk a felhasználókat rákényszeríteni az implementációs modell megismerésére, inkább az implementációs modellt közelítsük a felhasználó fogalmi modelljéhez pl. Domain-Driven Design módszerekkel!
• Legyen látható minden, amivel kezdeni lehet valamit
UX tanfolyam programozóknak/Nemeth 57
Ha programoztunk már olyan készüléket, amelyen ehhez nem volt elég gomb, valószínűleg értjük: a “nyomja meg duplán, ha ezt, és hosszan, ha azt” nem jó modell
• A leképzések legyenek egyértelműek
A legismertebb esete ennek a villanykapcsolók: bár ugyanannyi villanykapcsoló van, mint lámpa, melyik-melyik? A másik tipikus eset a tűzhely: sose tudni, melyik lángot melyik kapcsolja.
• Mindenen látszódjon, mire való (affordance)
Ha valami gomb, akkor emelkedjen ki. Ha valami link, legyen kék. Ha valami húzható, legyen “recés”. Ha lehet még lefele scrollozni, lógjon bele a tartalom az aljába.
A sebesség
A 90-es években az internet meglehetősen lassú volt. Ez gondolom mindenkinek feltűnt, aki ebben az időben internetezett. Jött Nielsen, és 99-es könyvében bejelentette, hogy egy weboldalnak 1 másodpercen belül be kell töltődnie vagy a felhasználó ideges lesz.
Nyilván felmerült a kérdés: ez az illető hülye?
Az az igazság, hogy a türelemfaktunk velünk született.
A számítógépek sebességének elsődleges felső és alsó korlátja az ember. Várhatóan ez egy olyan komponens, amit nem fogunk kicserélni sohase mindenhol.
Alsó korlát azért, mert ha valami túl lassú, az emberek türelmüket vesztik, vagy fejben másik feladatra váltanak.
UX tanfolyam programozóknak/Nemeth 58
Felső korlát azért, mert bizonyos sebesség felett tökmindegy, milyen gyors az alkalmazás, sőt, ha egy változás túl gyorsan történik, fel se tűnik. Ezt persze előnyünkre is fordíthatjuk, pl. Gyorsan, lopakodva betölthetünk még elemeket, mert az emberi reakcióidő lassú.
De mik is ezek a reakcióidők? (Johnson könyve nyomán)
Animációk
Látástól tudatosodásig, avagy framerate sapiens
100 msec
Ok-okozati összefüggések maximális ablaka
140 msec
Összeszámolás sebessége 4-5 elemig
200 msec
Egyszerre kezelt elemek időablaka
200 msec
Figyelemkihagyás felismerés után
500 msec
Váratlan eseményre adott vizuális reakció (hirtelen odanézés)
700 msec
Kínos csend beállta 1 000 msec = 1sec
UX tanfolyam programozóknak/Nemeth 59
Szünet nélküli max figyelem egy feladatra
10 sec
Minimális felismerhető szünet hangban
1 msec
Ismerős dolgok ismerősnek kategorizálása tudatalatt
10 msec
Ok-okozati összefüggések 100 msec Kattintás feedback
Kínos csend és tudatos reakció idő 1 sec
Ennyi időd van kirakni egy ablakotMegjelenítés után ennyi időd van csendben betölteni dolgokat (1 mp amíg feldolgoz egy új képernyőt)Ennyi időd van automata folyamatokat (pl. Automata mentés) végrehajtani hogy ne zavarjonEnnyi időt kell kihagyni két figyelmeztetés közt minimum
Szünet nélküli figyelem 10 sec
Ennyi idő alatt kell tudni befejezni egy egységnyi feladatotEnnyi idő alatt fog a felhasználó, és ennyi időt hajlandó rád is várni ha “hosszabb” a feladat
Kritikus helyzetben döntés 1.5 perc Ennyi idő alatt mindennek ott kell lennie ami a döntéshez szükséges
Egy dologra figyelés maximális időtartama
10 perc (max 20), gyereknél 2 perc
A látás
UX tanfolyam programozóknak/Nemeth 60
Az első dolog, amivel foglalkozni kell, a színvakok.
A férfiak 8%-a színvak vagy színtévesztő. A nőknél ez az arány kevesebb mint fele ennek, de így is jelentős.
Ha valaki egyszer egy zöldeskék készüléket tervez majd, eszébe ne jusson nagy piros önmegsemmisítő gombot rakni rá.
UX tanfolyam programozóknak/Nemeth 61
Protanópiás teszt (piros színvak) http://aspnetresources.com/tools/colorBlindness oldalon készítve.
A google térképei pedig nem azért szürkéssárgák mert ez a szín volt a kedvence a dizájnereknek.
Látásfókusz
Iskolában megtanultuk, hogy kétféle látórendszer van, az egyik a
UX tanfolyam programozóknak/Nemeth 62
“csapok”, a másik a “pálcikák” rendszere. A rossz hír az, hogy a csapokat olyan jó száz éve nem használjuk, az ugyanis a sötétben látáshoz való. A pálcikáknak viszont változó a felbontása a látótéren belül:
A szem felbontásaJeff Johnson könyvéből
UX tanfolyam programozóknak/Nemeth 63
Foveated Imaging - wikipedia
Nézzük meg ezt a videót: http://www.youtube.com/watch?v=Ahg6qcgoay4
Persze mindig azt hisszük, mi mindent élesen látunk, ez nem igaz: az emberi látás ugyanis “cache-ből dolgozik”: bármilyen új területen először feldolgozzuk a környezetet gyors, öntudatlan szemmozgásokkal, majd az agyunk ezt így eltárolja. Használjuk a perifériás látást is, de csak a kontextus feldolgozására, arra, hogy észrevegyük, ha valami változik, meg hogy tisztában legyünk a környezetünkkel.
UX tanfolyam programozóknak/Nemeth 64
Tehát a felhasználó nem “látja” a dolgokat a képernyőn, ha úgy gondolja, hogy valamit azon a részen kell keresni, akkor majd keresni fogja.
Ez az elsődleges oka annak, hogy platform-konvenciókat használunk, és ez az elsődleges oka annak, hogy fontosabb elemeket soha, semmi esetre sem mozgatunk arrébb a képernyőn.
Tervezési minták
A tervezési minták eredete az építészethez vezethetőek vissza.
1977-ben Christopher Alexander kiadta A Pattern Language című könyvét. Érdemes visszatérni ezekhez a gyökerekhez, amikor a felhasználói interfészek tervezési mintáiról beszélünk.
Míg az informatika tervezési mintái elsősorban egy belső szaknyelv létrehozásának igényével készülnek, a felhasználói interfészek sokkal inkább rejtett nyelvként működnek: attól még, hogy nem tudja egy felhasználó a combobox nevét, fogja tudni használni, ha konzisztensen ugyanúgy működik, inkább csak “érzi”, semmint megfelel neki.
A tervezési minták konstellációk, elemeket kötnek össze, az elemek szabadon behelyettesíthetőek.
A felület-tervezési minta legfontosabb része a problémadefiníció. Tulajdonképp egy tervezési mintát a következőképp lehet leírni:
HA az a baj hogy <problémadefiníció> és fennáll, hogy <kontextus>, akkor használd azt hogy <megoldásdefiníció>, úgy hogy… <megoldás részletezése, menete>
UX tanfolyam programozóknak/Nemeth 65
Gyakorlati hasznuk
A tervezési minták egy követelményrendszer-előállító megoldás. Ennek ellenére legtöbbször nem ezért használjuk őket, hanem hogy:
• Olyan megoldásokat használjunk, amiket a felhasználók már ismernek
• Platformok közötti váltást könnyítsük meg
Azonban egyik sem csodaszer: még ha olyan mintakönyvtárat használunk is, ami elvileg tesztelt, közel sem biztos, hogy a mi felhasználóinkon. Ezért az általuk használt rendszerek konkurrenciatesztjét érdemes elvégezni, és ezek alapján összeírni azok mintáit. Nagyon sok közösségi mintagyűjtemény (és sajnos néhány könyv is) nem feltétlenül tesztelt, mint inkább látványos megoldásokon alapszik. Egy minta gyakorisága rövidtávon nem feltétlen van összefüggésben annak használhatóságával!
Platformok közötti váltást is akkor könnyít meg, ha konzisztensen használjuk: egyfelől a platformnak is vannak saját mintái (ez az Android, vagy pl. A Blackberry 10 esetén ráadásul ebben a formában szerepelnek a hivatalos dokumentációban is), másfelől fel kell térképezni a rendszerben használt mintákat és hogy melyiknél nem érvényes az új platformon a kontextus.
UX tanfolyam programozóknak/Nemeth 66
Tervezési minták formátuma
Ha választani kell, az általunk ismertetett forma a quince-formátum (bár használható a patternry vagy a ui-patterns formátuma is:
• Probléma (max 2 SMS-nyi szöveg) - a probléma definíciója
• Megoldás (max 2 SMS-nyi szöveg) - a megoldás definíciója (NEM használd ezt, hanem egy summás leírás)
• Kontextus (feltételek felsorolása) - azok a feltételek, ahol a probléma alkalmazható
• Indoklás (rationale) (részletes szöveg) - annak indoklása, a megoldás miért oldja meg a problémát
• Megvalósítás módja (részletes szöveg) - leírás, mire kell figyelni
• Kapcsolódó minták (linklista)
• Szakirodalmi hivatkozások (linklista, könyv)
• Példák (képek, videók) - megvalósítás más rendszerekben
Tipikus buktatók
Az valószínűleg nem tervezési minta, ami egyetlen rendszerben egyszer lett használva valamire. Widget lehet, tervezési minta nem.
UX tanfolyam programozóknak/Nemeth 67
Az se tervezési minta, ami pixelpontosan ugyanúgy néz ki: egy tervezési mintának rengeteg megvalósítása lehet.
Az se tervezési minta, amely nem ad problémadefiníciót: az maszturbálás, dizájnerkedés, de nem tervezési minta.
A problémának és a megoldásnak kapcsolatban kell lenni egymással.
Quince példa
ProblemIt may not be obvious what people can or should do when starting an application or
visiting a site.
SolutionGive people a set of clear entry points into the application or Web site based on their most
common tasks or destinations.
Context
• You can identify or already have a known set of top tasks or destinations that
apply to most people.
• A significant number of users will be first time users or infrequent users.
UX tanfolyam programozóknak/Nemeth 68
RationaleWithout clear entry points, new or infrequent users can feel lost immediately upon
opening an application or site. By guiding people with clear entry points, you take the
mental burden off of them to figure out what they can or should do.
This pattern only works if you have or can discover a set of the most common tasks or
destinations for a large segment of your target audience. If you can’t do this, the pattern
actually causes more trouble because it gets in the way and doesn’t really guide people to
what they want to do.
It’s important that most of your users be new or infrequent because, unless these are the
only relevant tasks, regular users may find that clear entry points get in the way. This is
an extension of the last issue—if the clear entry points aren’t actually guiding most
people to the tasks or destinations they need, they just get in the way and even add
confusion.
Don’t be deceived into thinking that “it’s obvious” what people should do. Many Web
sites, especially, throw everything they have at people on their home pages—the main
entry point for a lot of sites. Homepages often end up being a smorgasbord of everything
the organization behind it has to offer, and people are left confused and not knowing what
to do or where to go. Clear entry points can help almost any Web site by hiding the
internal complexities and driving them to the main destinations.
ImplementationThe trick with this pattern is successfully identifying the top tasks or destinations. If you
used user-centric design, you should have already identified these as the tasks that
address the key goals for your users. Use that information to design your clear entry
UX tanfolyam programozóknak/Nemeth 69
points.
If you didn’t use user-centric design, you need to do some research, probably both
internally and externally, to determine the key tasks and destinations. If your app or site
already exists, looking at usage logs is a great source. You can also usually distill key
tasks even from functional specs, but you should try to validate those with users or at
least business stakeholders to ensure that the tasks you’re selecting are in line with the
key goals that the application or site serves.
Once you’ve nailed down your key tasks, you should consider how they need to be
presented. If you have more than a handful, you should think about how you might group
them visually, but remember, this should not be a replica of your main navigation—it
really needs to be key tasks.
Display the tasks very clearly and centrally on the starting view of your app or site. Be
sure to phrase them in terms of what the user is trying to accomplish, not in terms of any
fancy or branded terminology like tool names. If you can communicate the task in a few
words, that is ideal, but you probably should supplement names with helpful descriptions
that make it abundantly clear what people can accomplish by choosing that task or
destination.
It is best not to just make these be like trap doors, where suddenly people are dropped
into the middle of your solution structure. The destination they reach by choosing the task
should be clearly connected to the task; this is a good start to a Wizard, but it doesn’t
have to be wizard-based—just make the connection between the selected task and the
view they reach by selecting the task.
If there are sub-tasks that people can jump directly into, you can consider having those be
revealed when the main task is selected, but remember, this should not be a full menu or
navigational scheme.
UX tanfolyam programozóknak/Nemeth 70
It’s good practice to visually emphasize the most common tasks over the less common
ones. This way most people are drawn to the most common tasks, but you can still have
less common ones there for those who need them.
This main entry point view should not be surrounded by the usual navigational structure
or ancillary tools/information. Hide those away to keep the focus on the entry points.
Help Me Get There
Infragistics has some tools that can jumpstart your efforts to implement this pattern.
Broken down by technology, they are as follows.
ASP.NET
You could use the WebDialogWindow to overlay a clear entry points dialog if your
solution is more application-like than informational/navigational.
JavaServer Faces
You can easily implement this pattern using NetAdvantage for JSF’s link component
combined with the corepanel grid component. You can also use NetAdvantage’s themes
to help with styling. See an example here.
ExamplesThis is another example from Adobe Fireworks CS4. They offer a few clear entry points--
open recent, create new PNG, extend, and info/help links. Note they also let you indicate
not to show that again, and of course you can just get busy in other ways, if you prefer
that.
http://quince.infragistics.com/10ys
UX tanfolyam programozóknak/Nemeth 71
The primary example for this pattern is Live.com. Keyword searching is their users’
number one task, so they make it front and center with a big box. You note that they still
serve other interests through less prominent links.
http://quince.infragistics.com/11fr
UX tanfolyam programozóknak/Nemeth 72
ING Direct uses clear entry points very effectively to drive users to their primary tasks on
the site, and they also provide minimal secondary navigation for other options. Note the
use of the exit chute "Learn more," which drives to a much more in depth navigation
structure; this can be an option to cover those users who won't be hit by the majority
scenarios you've identified.
http://quince.infragistics.com/1116
UX tanfolyam programozóknak/Nemeth 73
This is the starting screen for Microsoft Expression Blend. It assumes that most users,
most of the time will want to start a new project, open a project, or open a site, and it also
lists recent projects as the most likely destination. It uses Tab Dialogsgs to organize the
top-three high-level destinations—Projects, Help, & Samples. Note also that it provides
users with the option to not stop here on their way to their destination (when they open
Blend) and the ability to close and instead use the main, menu-driven navigation.
http://quince.infragistics.com/11el
UX tanfolyam programozóknak/Nemeth 74
Infragistics’ sample application faceOut applies this pattern, showing a list of customers
and describing what the user should do to get started—select a customer.
http://quince.infragistics.com/10xk
UX tanfolyam programozóknak/Nemeth 75
Another example from music site Grooveshark. Offer clear entry points to most common
usages: Music Search, My Music, Favorites.
UX tanfolyam programozóknak/Nemeth 76
http://quince.infragistics.com/112f
SourcesJennifer Tidwell, Clear Entry Points
UX tanfolyam programozóknak/Nemeth 77
TagsUsability, Navigation, Search, Information Architecture, Page Layout, Browse.
Untitled
Tipográfia
CRAP
Robin Williams (dizájner) egyszerűsítése. Először a Non-Designers’ Design Book-ban jelent meg.
Proximity (közelség) - témában közel levő elemek legyenek térben is közel, témában távoli elemek legyenek térben is távol
Alignment (igazítás) - minden elemnek az oldalon igazodnia kell valami máshoz
Repetition (ismétlés) - az azonos dolgokat jelöljük azonosan
Contrast (kontraszt) - valami legyen vagy azonos, vagy nagyon különböző
Elmondható, hogy jobb, ha szöveget mindig csak balra igazítunk. A középre igazításnak van egy csomó tipográfiai feltétele amibe nem érdemes belemenni.
UX tanfolyam programozóknak/Nemeth 78
Vizuális hierarchia
A vizuális hierarchia azt jelenti, egyes elemeket kihangsúlyozunk, másokat szándékosan elnyomunk.
Gridek
A grid egy egyszerűsítés.
Segít betartani a vizuális hierarchiát azáltal, hogy úgymond egy négyzetrácsos füzetre helyezi az elemeket. Persze ez a négyzetrács nem is mindig négyzetrács:
UX tanfolyam programozóknak/Nemeth 79
Karl Gerstner: A Capital magazin gridje.
A gyakorlati grideknek két(!) komponensük van:
• A függőleges ritmust meghatározó baseline grid
• A vízszintes ritmust meghatározó oszlopgrid
A függőleges ritmus megtartásának alapja, hogy akármi történik, egy
UX tanfolyam programozóknak/Nemeth 80
folyószöveg mindig pontosan ráilleszkedik:
UX tanfolyam programozóknak/Nemeth 81
UX tanfolyam programozóknak/Nemeth 82
Müller-Brockmann: moduláris grid. A Grid-Systems in Graphic Design c. Munkájából
A függőleges ritmus elérésére három módunk van:
1. Nem piszkáljuk a betűméretet és -típust, ha nem muszáj
2. A sortávolságot és az elemtávolságot úgy állítjuk be, hogy azok ne borítsák fel a gridet
3. A méreteket úgy állítjuk be (a sortávolságokkal együtt), hogy azok ne bortsák fel a gridet.
A képekre is figyelni kell, azokat is úgy kell vágni, hogy ne borítsák fel a ritmust. Erre weben léteznek könyvtárak.
Természetesen a ritmus igényét felülírhatják lényegesebb dolgok (pl. Egy képszerkesztő programban nem vágunk a képből azért, hogy ritmuson legyünk, ott manapság leginkább “brickflow” megoldásokat alkalmaznak), de a saját tartalmainkat igyekezzünk ritmusban tartani függőlegesen.
A horizontális ritmus hasábokból áll. Az hasábok közt csatornát (guttert) képzünk. Egy elem lehet több hasáb széles, azonban a szélei (szöveg esetén néha csak a bal széle, kép esetén mindkettő) hasábszélre illeszkedjenek A webes tipográfia sokszor megkülönböztet szöveg és margócsatornát:
UX tanfolyam programozóknak/Nemeth 83
A gridpak tervezőfelülete
Ebből aztán különféle illeszkedések születnek:
UX tanfolyam programozóknak/Nemeth 84
UX tanfolyam programozóknak/Nemeth 85
UX tanfolyam programozóknak/Nemeth 86
UX tanfolyam programozóknak/Nemeth 87
A vízszintes ritmust sokkal könnyebb betartani, mint a függőlegest, így lehetőleg tartsuk is be mindig.
Betűkülönbségek
Betűk különbözhetnek:
• Típusban (typeface, font, betűtípus) és stílusban
• Méretben
• Súlyban (vastagságban)
• Színben
Az alapszabály: minél kevesebb változatot!!!
UX tanfolyam programozóknak/Nemeth 88
Egy oldalon 1 − 3 betűtípus legyen.
Színben is 2-3 szín.
Érdemes megjegyezni:
• A sima (regular) és a dőlt (italic) betű valójában két külön típus azonos családból
• A kisbetű - és nagybetű is külön típus, fejléceket, gombokat lehet nagybetűkkel szedni
•
Betűütközés
A betűkre is érvényes a kontraszt-szabály.
Betűk 3 kapcsolatban állhatnak egymással (CCC):
• Contrast- egyértelmű különbözés
• Concord - egyes tulajdonságaiban egyezés, másokban egyértelmű különbözés (pl. Ugyanannak a betűnek a dőlt és álló változata ilyen, de van olyan betűtípus, ahol csak kis, vagy csak nagybetű használható, mert nem áll fenn ez a reláció (Eurostile)
• Conflict - ha két betűtípus ütközik.
Tipikus ütközésprobléma, ha az x-magasságok nem stimmelnek. Az x-magasság a kisbetűk (pl. kis “x”) és a nagybetűk (pl. nagy I) és magas betűk (kis l) magasságának aránya.
UX tanfolyam programozóknak/Nemeth 89
UX tanfolyam programozóknak/Nemeth 90
Endnotes