Ux Tanfolyam Manuscript

Nemeth AdamFehértói u. 10

Budapest

[email protected]

(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


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


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


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


Foreword


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?


• 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.


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.

http://ASP.NET

http://ASP.NET


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.


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.


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


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


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


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.




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


• Ü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,


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:


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


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.


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.


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.


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


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


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:


• 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.


• 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!)


• 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


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.


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ő.


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


Képernyőfolyamat




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


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


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.


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.


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


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


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!


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


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ő:


• 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


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


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.


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,


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


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


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

http://www.youtube.com/watch?v=9gkxE3s4p1s








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


í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


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


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


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.


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


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


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á.


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


“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


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.

http://www.youtube.com/watch?v=Ahg6qcgoay4










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>


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.


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.


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.


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


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.


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

http://www.infragistics.com/dotnet/netadvantage/aspnet/webdialogwindow.aspx



http://www.componentsforjsf.com/UXExamples/faces/examplePages/UX-Clear-Entry-Points.jsp

http://www.componentsforjsf.com/UXExamples/faces/examplePages/UX-Clear-Entry-Points.jsp

http://quince.infragistics.com/10ys


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




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





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




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

http://quince.infragistics.com/10xk


Another example from music site Grooveshark. Offer clear entry points to most common

usages: Music Search, My Music, Favorites.


http://quince.infragistics.com/112f

SourcesJennifer Tidwell, Clear Entry Points



http://designinginterfaces.com/Clear_Entry_Points

http://designinginterfaces.com/Clear_Entry_Points


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.

http://quince.infragistics.com/#/Search$tag+=Usability

http://quince.infragistics.com/#/Search$tag+=Navigation

http://quince.infragistics.com/#/Search$tag+=Search

http://quince.infragistics.com/#/Search$tag+=Search

http://quince.infragistics.com/#/Search$tag+=Information+Architecture




http://quince.infragistics.com/#/Search$tag+=Page+Layout

http://quince.infragistics.com/#/Search$tag+=Browse

http://quince.infragistics.com/#/Search$tag+=Browse


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:


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


folyószöveg mindig pontosan ráilleszkedik:



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:


A gridpak tervezőfelülete

Ebből aztán különféle illeszkedések születnek:





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!!!


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.



Endnotes

Documents

Ux Tanfolyam Manuscript