A felhasználói felület tervezése

Bevezetés

A számítógépes rendszertől elvárható, hogy a gép a rábízott feladatot gyorsan és hibátlanul megoldja, valamint az összekapcsolt gépek egymás között jól kommunikáljanak. A legtöbb alkalmazásnál ebbe a gépláncba az emberi felhasználó is bekapcsolódik. Az embert és a gépet a felhasználói felület (FF) kapcsolja össze.

A számítógépes rendszerek felhasználói felülete a következő elemekből áll: 1. bemeneti készülékek (pl. billentyűzet); 2. kimeneti készülékek (pl. monitor); 3. ezek tág környezetének elemei: a számítógépes munkahely (ennek megvilágítása, a bútorok mérete, elrendezése) 4. az ezeket vezérlő hardware eszközök, pl. videojel-generátor; 5. az ezekhez írt szöveges, képi, vagy hang-információt küldő és beolvasó programok.

Ezeket az elemeket az ember információt közlő, és felfogó sajátságait figyelembe véve kell megtervezni. Az első félévi előadás ("Képmegjelenítők vizuálergonómiája") az 1-4 elemekkel foglalkozott. Jelen előadás az 5. elemmel, vagyis az ember-gép kapcsolat software vonatkozásának ergonomikus tervezésével foglalkozik. Ez a software-ergonómia. Cél, hogy a felhasználói felület könnyen és jól használható legyen: a felhasználó hosszú távon jó teljesítménnyel és elégedetten tudjon vele dolgozni. Ez a software-mérnökök feladata. Például: a megjelenített információt grafikailag jól rendezik el a képernyőn, könnyen kezelhető információ-visszakereső nyelvet fejlesztenek, vagy vizuálisan vonzó bemeneti, kimeneti, illetve keresési lehetőségeket programoznak. A hardware-mérnökök másképpen járulnak hozzá a számítógép-ergonómiához: ők jobb billentyűzetet, mutatóeszközt (pl. egeret), nagyfelbontású és nem villogó képernyőt, vagy beszéd ki- és bemenetet terveznek.

A félév során az ISO 9241 szabványsorozat 10-16 részeinek rendszerét követve, az irodalomjegyzékben közölt könyvek felhasználásával, a software-ergonómia következő kérdései kerülnek előadásra:

1. Bevezetés

2. A számítógéppel folytatott párbeszéd: dialógus-elvek, ISO 9241-10

3. Használhatóság és használhatósági vizsgálat, ISO 9241-11

4. Az információ megjelenítése, ISO 9241-12

5. A felhasználó segítése, ISO 9241-13

6. A menü-dialógus, ISO 9241-14

7. A parancs-vezérelt dialógus, ISO 9241-15

8. A közvetlen dialógus, ISO 9241-16

A felhasználói felület ergonomikus tervezése különösen fontos a következő rendszereknél:

. Szövegfeldolgozó rendszerek (Word processors)

. Irodai publikációs eszközök (Desktop-publishing tools)

. Képbevitel és -manipuláció (Scanning, image manipulation)

. Elektronikus levelezés, telekonferencia, világháló (Email, Computer Conferencing, WWW)

. Digitális képkönyvtárak, pl. az orvostudományban (Digital image libraries, e. g. medicine)

. Adatok vizualizációja a tudományban (Scientific visualisation)

. Szimulátor-munkaállomások (Simulator Workstations)

. Táblázatkezelés (Electronic spreadsheets)

. Döntéstámogató rendszerek (Decision-support systems)

. Információkérés nagy adatbázisokból az oktatásban és a közönség számára (Educational and public access to information)

. Légi közlekedés ellenőrzése (Air-traffic control)

. Software-készítő eszközök, programozási környezetek (Software engineering tools, programming environments)

. Számítógéppel segített tervezés, CAD (Computer-Assisted Design, CAD)

. Munkaállomások a gyártási folyamatban (Manufacturing Workstations)

. Munkaállomások a mérnöki munkában (Engineering Workstations)

. Fogyasztói elektronika: videók, telefonok, kamerák (Consumer Electronics: VCR, telephones, cameras)

A felhasználói felület (FF) tervezésének alapvető célja a felhasználó életminőségének javítása. Ez az Európai Unió kutatási és technológiafejlesztési programjainak is alapvető célja. Az 5. Keretprogram egyik programja az információs társadalom technológiái (IST), amelynek egyik célja az ún. felhasználóbarát információs társadalom. "Az IST program stratégiai célja az információs társadalom előnyeinek megvalósítása Európában, azáltal, hogy gyorsítja annak elterjedését és azáltal, hogy figyelembe veszi az egyének és vállalatok igényeit".

A FF tervezéséhez ma már FF építő software eszközök állnak rendelkezésre. Ezekkel a fejlesztés gyors, és a módosítások egyszerűek. A fejlesztés folyamata közben ún. használhatósági vizsgálati módszerekkel ellenőrizhető és átlátható, hogy a választott FF elemek jók-e a felhasználó szempontjából. A sikeres FF tervező a felhasználó-barátság követelményén túlmenve alaposan érti és átlátja a felhasználók és ún. szakmai feladataik[1] sokféleségét. Ez hozzájárul az ún. hatékony FF kialakításához, amelyet a következők jellemeznek:

1. a felhasználók körében pozitív érzéseket kelt: siker, szakértelem, a rendszer átlátása, és világossága;

2. a felhasználót a számítógépes munka nem terheli meg;

3. a felhasználó előre látja minden akciójának válaszát.

4. a FF szinte eltűnik: a felhasználó szakmai feladatára, illetve a felfedezés vagy játék örömére koncentrálhat; örömmel, elmélyülten dolgozhat.

Mindez a FF tervezőjétől szakértelmet és kemény munkát igényel, és azt, hogy lássa a FF tervezésének céljait:

1. a felhasználó megfelelő teljesítménnyel dolgozzon;

2. ne kelljen különös képességű operátorokat alkalmazni;

3. ne legyen szükség hosszú tanulási időre;

4. az ember-gép rendszer megbízható legyen;

5. a FF az adott rendszeren belül és más rendszerekhez képest szabványos legyen.

Ezen célok eléréséhez minden felhasználói csoportot és minden szakmai feladat fajtát külön meg kell vizsgálni. Fontos, hogy több FF terv készüljön, és ezeket ún. mérhető emberi tényezők alapján értékeljék ki a tervezők, a FF értékelő szakemberek, vagy a rendszer vásárlói a tervezés folyamán:

1. a FF használatának tanulási ideje;

2. felhasználó teljesítménye, sebessége: mennyi idő alatt végez el adott szakmai feladatokat?

3. a felhasználó által elkövetett hibák aránya, hibaarány;

4. megjegyezhetőség: az FF-ről megszerzett tudást mennyire jól tudja a felhasználó felidézni egy óra, egy nap, vagy egy hét múlva?

5. szubjektív elégedettség.

A felsorolt 5 tényező között gyakran arany középutat kell választani, pl. ha szükséges, hogy a hibaarány nagyon kicsi legyen, akkor fel kell áldozni a felhasználó sebességéből.

Miután kialakult néhány FF terv alternatíva, a tervezők - a felhasználókkal együtt - megvizsgálják azokat, és elkészítenek egy dokumentumot a FF 121f54b kinézetéről: milyen dialógust, információ megjelenítési formátumot és sorrendet, valamint terminológiát kell használni a FF fejlesztésekor.

Fontos megjegyezni, hogy a FF tervezése előtt kell gondoskodni a FF alatti rendszer helyes működéséről (funkcionalitásáról) és megbízhatóságáról. Ha a rendszer nem működik helyesen, pl. szakmailag helytelen eredményt jelenít meg pl. vizuálergonómiailag kedvező formában, akkor teljesen mindegy, hogy jól, vagy rosszul van-e tervezve a FF. Azt szokták mondani, hogy a felhasználó rendszerbe vetett bizalma törékeny. Veszélyt jelent még a túlzott funkcionalitás is, amikor a túl összetett szakmai feladatok veszélyeztethetik a használhatóságot. A megbízhatóság azt jelenti, hogy a parancsok jól oldják meg a szakmai feladatot, pl. a megjelenített adatok valóban megfelelnek a megnyitott adatbázis adatainak. Ezen kívül a FF tervezése előtt biztosítani kell a felhasználói titoktartást, a biztonságot, és az adatok sérülésmentességét.

A FF elkészítése során figyelembe kell venni a szabványosság követelményét, hogy a különböző programok FF-ének hasonló funkciójú elemei hasonlóak legyenek, erre példa a szabványos Windows-os felület. A FF sikerének fontos meghatározója a következetesség is, ami azt jelenti, hogy közös az akciók sorrendje, a szóhasználat, a mértékegységek, az információ megjelenítésének elrendezése, a színhasználat, valamint a betűtípusok. Néha nehéz megtalálni az arany középutat a "különböző verziók közötti kompatibilitás" és a "új, jobb funkcionalitás + új, jobb FF" között. Fontos követelmény a hordozhatóság is: ez azt jelenti, hogy az adatok átalakíthatók, és a FF ugyanaz marad különböző software és hardware környezetekben, pl. különböző képernyőméretek és felbontások, színmélységek, mutatóeszközök, adatformátumok.

A FF elkészítésénél alapos időrendi tervezésre és jó vezetésre van szükség. A program késett szállítása vagy a költségtúllépés a program eladhatóságát fenyegeti. Ha a fejlesztők elég figyelmet szentelnek az emberi tényezőket figyelembe vevő tervezési elveknek (l. később) és idejében, szigorúan elvégzik a használhatósági vizsgálatot (l. később), akkor a fejlesztés során kevesebb változtatásra lesz szükség, ezáltal a fejlesztés sokkal gyorsabb lesz, a költségek csökkennek, és a program kiadása után elkerülhetők a költséges korszerűsítések (update-ek). Tapasztalat szerint a piacon sokkal sikeresebb a jobb FF-ű rendszer.

Az egyes mérhető emberi tényezők jelentősége függ a FF alkalmazási területétől:

1. Az ún. élet-kritikus rendszerekben (pl. légi közlekedés, személyzettel ellátott űrhajók, nukleáris reaktorok, erőművek, rendőrség, tűzoltóság, orvosi rendszerek, katonaság) nagyon magas megbízhatóság és hatékonyság szükséges. Itt nem lehet fejlesztési költséget megtakarítani. Elfogadhatók a hosszabb tanulási idők, és a szubjektív elégedettség nem annyira fontos, mert a felhasználók motivációja nagyon nagy (l. pszichometria, valós körülmények között végzett pszichofizikai kísérlet).

2. Ipari és kereskedelmi alkalmazásoknál (bank, biztosítás, megrendelések, leltárak kezelése, számlázás, hitelkártya kezelése) néha az alacsonyabb fejlesztési költségeket választják a megbízhatóság rovására. Fontos a könnyű tanulhatóság és a szakmai feladat könnyű és gyors végrehajtása.

3. Irodai, otthoni, és szórakozási alkalmazásoknál (személyi számítógépek, szövegfeldolgozás, különböző automaták, videojátékok, oktatóprogramok, információkérés, e-mail, telekonferencia, kisvállalkozások ügyintézése) fontos a könnyű tanulhatóság, alacsony hibaarány, a szubjektív elégedettség. Ha a felhasználó nem halad gyorsan a tanulással, akkor gyakran abbahagyja a program használatát, és egy konkurens programot kezd el használni. Fontos a felhasználó azonnali segítése (on-line help), gyakorlati szint beállíthatósága kezdőtől szakértő felhasználóig, továbbá az alacsony fejlesztési költségek.

4. A kutató-felfedező rendszerek, az alkotó rendszerek és az együttműködést segítő rendszerek az emberi intellektuális és felfedező vállalkozásokat segítik. Kutató-felfedező rendszerek pl. az elektronikus enciklopédiák, a világháló böngészők (WWW browsing), döntéstámogatók és tudományos modellező rendszerek. Alkotó rendszerek pl. az író eszköztárak, építészeti tervező rendszerek, művészek munkaállomásai, programozók munkaállomásai, és a zene-komponáló rendszerek. Együttműködést segítő rendszerek pl. a telekonferencia rendszerek, amelyek lehetővé teszik, hogy egymástól messze lévő emberek együtt dolgozzanak. A 4. pontban felsorolt rendszerekben a felhasználó rendkívül motivált, de magasak az elvárásai is. Ezért nehéz ezeket a rendszereket tervezni és kiértékelni. A legfontosabb, hogy maga a számítógép teljesen eltűnjön, és a felhasználó belemerülhessen a szakmai feladatába. Ez legjobban a közvetlen dialógussal (l. később) érhető el: a szakmai feladat egyes akcióinak közvetlenül manipulálható megfelelői legyenek mindig a felhasználó előtt. Ekkor a szakmai feladat végrehajtása gyors, egyszerű választások sorozata, azonnali visszajelzéssel, és újabb választási lehetőségek azonnali megjelenésével.

A FF felület tervezésénél figyelembe kell venni a felhasználók képességeinek változatosságát. Ehhez meg kell érteni az egyes emberek közötti fizikai, érzékszervi, értelmi, és személyiségbeli különbségeket. A fizikai és érzékszervi képességek különbségéről a korábbi "Antropometria" és "Vizuális rendszer" fejezetekben tanultunk.

Az ember-gép kapcsolatot az teszi lehetővé, hogy az ember képes az érzékszervi (különösen a vizuális) bemenetét gyorsan értelmezni, és erre gyors és összetett válasz-akciókat kezdeményezni. A felhasználó a másodperc ezredrésze alatt észrevesz a képernyőn egy apró változást, és parancsok folyamát kezdi el kiadni. A felhasználók érzékszervi és értelmi képességei különbözhetnek: rövid távú memóriájuk, hosszú távú memóriájuk, tanulóképességük, problémamegoldó képességük, döntési képességük, figyelmük koncentrációja és állhatatossága, vizuális keresési képességük, időészleletük.

Az érzékszervi és motoros teljesítményt befolyásolja a felhasználó ébersége vagy fáradtsága: egy adott rendszer más érzékszervi és értelmi megterhelést jelenthet a különböző felhasználóknak. A teljesítmény függ attól is, hogy az adott felhasználónak mennyire monoton a munka, mennyire van elszigetelve munkatársaitól, továbbá a felhasználó kora, illetve helyes/helytelen életmódja (pl. alkoholfogyasztása).

A rendszerrel végzett munka hatékonyságát befolyásolja még az egyes felhasználók személyiségbeli különbsége: vannak, akik nem szeretik a számítógépeket és félnek a rendszertől, másokat kimondottan vonzza a gép és buzgón használják azt. A különböző felhasználók lehet, hogy más dialógus fajtát részesítenek előnyben (pl. menü-dialógus helyett parancs-vezérelt dialógust), lehet, hogy más a dialógus üteme. Egyesek jobban szeretik a grafikonokat, míg mások a táblázatokat. Egyesek a sűrű adatmegjelenítést kedvelik, míg mások a ritkát. Egyesek szeretnek lépésről-lépésre dolgozni, míg mások szeretnek mindent egyszerre átlátva dolgozni. Ezen kívül a két nem közötti különbségek is megfigyelhetők. Vannak, akik befelé forduló személyiségek (introverzió), és vannak akik inkább kifelé fordulnak (extroverzió). Vannak, akik inkább a rutinos eljárásokat kedvelik, míg mások inkább az intuícióra hagyatkoznak. Vannak, akik nem szívesen döntenek, és vannak, akik maguk hozzák meg döntéseiket, és állandóan saját terveik vannak. Vannak, akik inkább érzelmeikre, mások inkább gondolataikra hallgatnak.

A felhasználói változatosság újabb fontos tényezői a kulturális és nemzeti különbségek. A FF-et ezek figyelembe vételével kell megtervezni: mások lehetnek a betűk, és a számok. Speciális karakterek és betűmódosítók (diacritics) jelenhetnek meg. Vannak, akik balról jobbra, mások jobbról balra írnak, olvasnak. Különbözhetnek a dátum-, idő-, szám-, pénznemformátumok, valamint a mértékegységek, a nevek és titulusok, a társadalombiztosítási számok, igazolvány és útlevélszámok. Más szabályai lehetnek a nagybetűs írásnak és az írásjelek használatának. Gyakran más színeket, ikonokat, nyomógombokat használnak. Más lehet az etikett, a szokások, és a hangnem.

Vannak fogyatékos felhasználók is, akik gyengén látnak vagy vakok. Nekik a képernyő egyes részeit meg kell növelni, illetve a szöveget át kell alakítani hanggá. Vannak gyengén halló, mozgáskorlátozott felhasználók. Különös figyelmet igényelnek az idősebb felhasználók.

Bevezetés - Ellenőrző kérdések

1. Milyen elemekből áll a számítógépes rendszerek felhasználói felülete (5)?

2. Mi a software-ergonómia?

3. Milyen software-ergonómiai tárgyakról szól az ISO 9241 szabványsorozat?

4. Írjon 4 olyan rendszert, ahol különösen fontos a felhasználói felület ergonomikus tervezése.

5. Hogyan járulnak hozzá a számítógép-ergonómiához a hardware, illetve a software mérnökei? Írjon 2-2 példát!

6. Hogyan írják angolul a "Fogalmak" táblázatban szereplő magyar elnevezéseket?

7. Hogyan hangzanak magyarul a "Fogalmak" táblázatban szereplő angol elnevezések?

8. Melyek a hatékony FF jellemzői?

9. Milyen mérhető emberi tényezők alapján értékelik ki a FF-et? Írjon 5 darabot.

10. Miért fontos a FF tervezése előtt meggyőződni a helyes funkcionalitásról és a megbízhatóságról?

11. Mi a szabványosság, a következetesség és a hordozhatóság?

12. Írjon 3 példát ún. élet-kritikus rendszerre. Mely tényezők fontosak és melyek kevésbé fontosak a tervezésnél?

13. Írjon 3 példát irodai, otthoni, és szórakozási alkalmazásokra. Mely tényezők fontosak és melyek kevésbé fontosak a tervezésnél?

14. Írjon egy-egy példát kutató-felfedező rendszerre, alkotó rendszerre és együttműködést segítő rendszerre. Mely tényezők fontosak és melyek kevésbé fontosak a tervezésnél?

15. Milyen személyiségbeli különbségek lehetnek az egyes felhasználók között?

16. Milyen kulturális és nemzeti különbségek lehetnek az egyes felhasználók között?

A számítógéppel folytatott párbeszéd: dialógus-elvek

A dialógusban a felhasználó a számítógéppel közli kéréseit szakmai feladatának megoldására, egyszerűsítésére, vagy támogatására, és a számítógép megadja válaszát. A dialógusnak több útja lehetséges. Az egyik szélsőség az adathalmaz egyszeri bevitele: a felhasználó minden bemenő adatot egyetlen alkalommal ad meg a gépnek, és utána vár, hogy a gép megoldja a szakmai feladatot. A másik szélsőség a közvetlen dialógus, illetve annak legfejlettebb változata, a virtuális valóság. Közvetlen dialógusban gyors kölcsönhatást lehetővé tevő bemeneti készülékek és software módszerek vannak, így a felhasználó folyamatosan adja utasításait és kap visszacsatolást a géptől.

A párbeszéd leírására modelleket alkottak, amelyekben két résztvevő van: a felhasználó és a rendszer. Ezek a modellek megnevezik a dialógus tervezése során felmerülő problémákat és összehasonlítják a különféle kölcsönhatási stílusokat. A következőkben a Norman-féle kölcsönhatási modell, az ún. végrehajtási-értékelési ciklus kerül bemutatásra. Ebben az alapfogalmak a következők:

szakterület: valamely valós tevékenységi kör, amelyhez a software kapcsolódik, pl. grafikai tervezés, gyári folyamatirányítás, ...

alapelemek: minden szakterületnek megvannak a maga alapelemei, pl. a grafikai tervezésben alapelemek a rajzolható alakok, a rajzolóeszközök,...

szakmai feladat: (l. a Bevezetést is) a szakterület alapelemeivel való munka egy-egy lépése.

felhasználó célja: az elvégzendő szakmai feladatra várt szakmai nyelven megadott válasz a számítógéptől.

felhasználó szándéka: a cél pontos megfogalmazása azáltal, hogy a felhasználó egy adott bemeneti sorrendet választ ki a FF-en adott lehetőségek közül.

A FF tervezésének célja az, hogy segítsük a felhasználót céljának kivitelezésében a szakterületen belül. Ehhez először a szakmai feladat elemzésére van szükség: meg kell fogalmazni a szakterülettel, a felhasználó szakmai feladatával, céljával és szándékával kapcsolatos kérdéseket. Fontos figyelembe venni, hogy a felhasználó és a rendszer két különböző nyelvet beszél. A felhasználó nyelve a szakmai feladat nyelve (pl. rajzolható alakok, rajzolóeszközök...). A gép nyelve belső, számítástechnikai nyelv (pl. regiszterek, port- és memóriacímek, adatok,...).

A végrehajtási-értékelési ciklus lényege, hogy a felhasználó megfogalmazza végrehajtandó akcióinak tervét, amelyet utána a FF-en kell megvalósítania. Miután tervét, vagy annak egy részét megvalósította, megfigyeli a FF-et, és megvalósított tervének eredményét értékeli. Ezután újabb akciókat fogalmaz meg. Látszik, hogy két fő lépés van: a végrehajtás és az értékelés, és ezek ciklikusan ismétlődnek. A ciklus 7 al-lépésre bontható:

1. A felhasználó céljának meghatározása, a szakterület alapelemeivel és nyelvhasználatával.

2. A felhasználó szándékának meghatározása: a cél pontosítása a FF lehetőségein belül.

3. A bemeneti akciók sorrendjének meghatározása.

4. A bementei akció végrehajtása

5. A rendszer állapotának, kimenetének észlelése

6. A rendszer állapotának, kimenetének értelmezése

7. A rendszer állapotának, kimenetének összehasonlítása az eredeti céllal illetve szándékkal.

Ha a rendszer állapota a felhasználó céljával megegyezik, akkor sikeres volt az ember-gép dialógus. Ellenkező esetben új célt kell megfogalmazni, és a ciklust meg kell ismételni.

A fenti Norman-féle modell alapján megfogalmazható a FF-ek két alapproblémája: a "végrehajtási szakadék" és az "értékelési szakadék".

A végrehajtási szakadék azért jön létre, mert különbség van a cél érdekében a felhasználó által megfogalmazott bemeneti akciók halmaza és a FF-en megvalósított bemeneti akciók halmaza között.

A FF akkor lesz hatékony, ha a FF-en megvalósított bemeneti akciók megegyeznek azokkal, amelyeket a felhasználó megfogalmaz. Ezért a FF tervezésének egyik célja a végrehajtási szakadék megszüntetése.

Az értékelési szakadék azért jön létre, mert különbség van a rendszer állapotának, kimenetének fizikai megjelenítése (l. az "Információ megjelenítése" c. fejezetet) és a felhasználó ezzel kapcsolatos elvárása között.

A FF akkor lesz hatékony, ha a felhasználó a megjelenített információt azonnal értelmezni tudja felhasználói céljának megfelelően.

Az alábbiakban a FF-en alkalmazható dialógus-típusok kerülnek tárgyalásra, illetve összehasonlításra:

1. Menü-dialógus

2. Parancs-vezérelt dialógus (altípus: természetes nyelvű dialógus)

3. Közvetlen dialógus (altípusok: WIMP, point-and-click, 3D felület, VR)

4. Kitöltés-dialógus (altípusok: űrlap-kitöltés, dialógus-ablakok, információkérés)

1. Menü-dialógus. A felhasználó által kiválasztható opciók megjelennek a képernyőn. A felhasználó ezek közül választ, mutatóeszközt, vagy billentyűket használva.

Előnye az , hogy az opciók láthatók, ezáltal a felhasználó a saját memóriáját kevésbé terheli. Azt, hogy melyik akció melyik menüben van, gyakorlás során tanulja meg. Ez a folyamat gyorsabb és könnyebb, ha a menüopciók (l. a "Menü-dialógus" című fejezetet) értelmesek, és logikusan vannak csoportosítva.

Hátránya az, hogy a hierarchikusan felépített menürendszerben az éppen szükséges menü nem látható a hierarchia legfelső szintjén. Másik hátránya az, hogy nem érhető el a rendszer funkcionalitásának minden eleme.

2. Parancs-vezérelt dialógus: a felhasználói bemenet akciói parancsok, melyeket a felhasználó funkcióbillentyűkkel, egyes karakterekkel, rövidítésekkel, vagy teljes szavakkal ad meg. Még mindig széles körben használják, sok felhasználó kifejezetten ezt szereti. Egyes FF-eken ez az egyetlen mód áll rendelkezésre. Gyakran menü alapú FF-ek kiegészítője. Előnye az, hogy tapasztalt felhasználók részére ez a FF gyors hozzáférést biztosít a rendszer funkcionalitásához. A parancsokat kombinálni lehet úgy, hogy ugyanazon adathalmazhoz sokféle eszköz válik alkalmazhatóvá. Ez a rugalmasság a menü-dialógusnál nincsen meg. A parancsoknak rengeteg opciója lehet, amelyeket sokféle objektumra sokféle módon lehet azonnal alkalmazni.

Hátránya az, hogy nehéz megtanulni és használni, mivel emlékezni kell a parancsokra. Általában nincs lehetőség, hogy a parancssorban utalás legyen arra, melyik parancsot kell éppen használni. Ez a hátrány csökken, ha következetesek és értelmesek a parancsok és ezek rövidítései (l. a "Parancs-vezérelt dialógus" című fejezetet). Összefoglalásképpen az a dialógus-típus a szakértő (expert) felhasználóknak felel meg.

Egyik altípusa természetes nyelvet (pl. angol vagy magyar) alkalmaz. Kevés gyakorlati megvalósítása van, mert a gép nehezen érti meg a gyakran nem egyértelmű természetes nyelvet. Ma még kérdéses, hogy egyáltalán érdemes lesz-e valaha is természetes nyelvet használó FF-et tervezni.

3. Közvetlen dialógus: itt a szakmai feladat egyes akcióinak megfelelői közvetlenül manipulálhatók, és a gép válasza azonnal megjelenik.

Leggyakoribb fajtája az ún. WIMP felület, vagy ablak-felület. A WIMP rövidítés "Windows-icons-menus-pointers"-ből ered, vagyis a dialógust ablakok, ikonok, menük, és mutatóhelyőrök (pointer-ek). Példák: Microsoft Windows - IBM PC, MacOS - Apple Macintosh, X Windows - UNIX. A UNIX - nál az ablakokban gyakran parancs-vezérelt dialógus folyik, illetve karakteralapú (nem-grafikus) programok futnak.

Másik fajtája az ún. mutató-kattintó felület (point-and-click interface), a WIMP felület egyszerűsített változata, ahol a felhasználó egy ikonszerű gombra mutat. Az akció egyszerű kattintással vagy érintőképernyő (touch-screen) esetén érintéssel kezdődik. Leggyakoribb alkalmazása a hypertext és a WWW.

Harmadik változata az ún. háromdimenziós felület, amely a mélység-dimenzióban is jelenít meg adatokat. Legegyszerűbb formája a WIMP elemek háromdimenziós láttatása árnyékolással és textúrával (a "világítás" leggyakrabban jobb oldalt felül helyezkedik el). Az ilyen gombok szinte sugallják a felhasználónak, hogy nyomja meg azokat, l. az alábbi kép alsó sorát:

Ennél bonyolultabb változat az ún. 3D-munkatér, ahol a lapos elemeket perspektívában jelenítik meg. Ha egy grafikus objektum távol van, kevesebb helyet foglal el a képernyőn, rámutatva pedig a felhasználó közeledik hozzá, és az objektum nagyobbá válik. Ezáltal a 3D-munkatér több helyet és természetesebb navigációt nyújt, mint a hagyományos WIMP. Ennek tökéletesített változata az ún. virtuális valóság (virtual reality, VR), amely az információ megjelenítésének legfejlettebb változata. Speciális kimeneti készülékek (pl. fejre szerelt képmegjelenítő, HMD) segítségével a felhasználó egy szimulált háromdimenziós világban mozoghat.

4. Kitöltés-dialógus: itt a felhasználó a gép kérdéseire válaszol, a dialógus lépései előre meghatározottak.

Egyik fajtája az ún. dialógus-ablak, ami a felhasználónak kérdések sorozatát teszi fel, amire a válasz lehet igen/nem típusú, vagy többszörös választási lehetőség, vagy kódok beírása. A felhasználót a rendszer vezeti végig a dialóguson, lépésről-lépésre. Előnye az, hogy gyorsan megtanulható és könnyen használható. Hátránya, hogy ezzel csak egy erősen korlátozott funkcionalitás vehető igénybe. Általában kezdő, vagy ritka felhasználóknak javasolt.

Altípusa az ún. információkérési nyelv. Ezzel adatbázisban tárolt információt lehet visszakérdezni. A keresett szavakat ÉS, VAGY, +, - operátorokkal lehet összekapcsolni. Az információkérési nyelv hátránya, hogy hatékony használatukhoz nagy tapasztalat szükséges.

A kitöltés-dialógus másik fajtája az űrlap-kitöltés. Az ilyen FF-eket elsősorban adatbevitelre használják de információkérés is megvalósítható vele. Űrlap-kitöltésnél fontos, hogy legyen a felhasználónak javítási lehetősége. Az űrlap-kitöltés előnye, hogy könnyű megtanulni és használni, és az, hogy minden felhasználónak megfelel, a kezdőtől a szakértőig.

Az űrlap-kitöltés egyik továbbfejlesztett fajtája az ún. interaktív táblázat (spreadsheet). Cellák hálózata, ahová adatokat, képleteket lehet beírni (pl. MicrosoftT Excel). Sok felhasználónak nagyon vonzó ez a dialógus-típus: szabadon manipulálhatja a beírt értékeket, és a kimenet azonnal megjelenik. A be- és kimenet között a határ elmosódik, és egy igen rugalmas FF jön létre.

Dialógus-elvek[2]

Ez a rész a dialógus-típusok általános és speciális tervezési elveivel foglalkozik. Ezeket az elveket szem előtt tartva hatékony ember-gép párbeszéd tervezhető, és ezáltal jól használható FF jön létre. A FF tervezés és értékelés folyamata felhasználó-centrikus lesz. Meg kell jegyeznünk, hogy a dialógus-elvek a dialógus-típusok kombinációira is vonatkoznak; továbbá, hogy a dialógus elvek nem függetlenek, gyakran meg kell találni közöttük az arany középutat, és alkalmazási sorrendet kell felállítani, a következő szempontok szerint:

a felhasználó célja;

a felhasználói csoport, akinek a FF készül;

a FF által lefedett szakterület, illetve szakmai feladatok;

a rendelkezésre álló technológiák;

a választott dialógus-típusok;

Például ha nem áll rendelkezésre megfelelő technológia, akkor egy adott dialógus-elv fontosabb lehet, mint a másik, illetve egy adott dialógus-elv egyáltalán nem lehet alkalmazható.

A dialógus-elvek a felhasználó következő lélektani sajátságait veszik figyelembe:

a figyelem időtartama;

a rövid távú memória korlátai;

a tanulás módszere;

a tapasztalat foka;

a felhasználó belső modellje a rendszer struktúrájáról és céljáról.

A tapasztalat foka függ a korábban már megismert rendszerek számától és magának az alkalmazott dialógus-típusnak az ismertségétől.

A dialógus-elvek a következők:

1. A szakmai feladat megoldására való alkalmasság

2. Magától értetődőség

3. Ellenőrizhetőség

4. Megfelelés a felhasználó elvárásainak

5. Hibatűrés

6. Testre szabhatóság

7. Tanulhatóság

1. A szakmai feladat megoldására való alkalmasság: ez azt jelenti, hogy a felhasználót támogatni kell abban, hogy szakmai feladatát hatékonyan végrehajtsa. A dialógusban csak olyan szakmai alapelemek legyenek, amelyekre a felhasználónak valóban szüksége van az aktuális szakmai feladat végrehajtása során. A megjelenő segítő információ (l. a "felhasználó segítése" c. fejezetet is) függjön az éppen megoldandó szakmai feladattól: ha a felhasználó segítséget kér, akkor a FF csak az adott állapothoz ad segítséget. Minden nem-szakmai tevékenységet a rendszer végezzen, a felhasználó igénybevétele nélkül: a helyőrt (kurzort) automatikusan kell mozgatni, pozícionálni, a szakmai feladat sorrendjétől függően. A rendszer belső műveletekkel megkapható információt ne kérjen bemenetként a felhasználótól.

A dialógus során a kimeneti információt úgy kell megjeleníteni, hogy azt a felhasználó könnyen feldolgozhassa: lehetőleg ne legyenek több oldalas kimenetek. Ennek elérésére a dialógust több lépésre kell lebontani és úgy felépíteni, hogy a gép által adott kimenetben a leggyakoribb, illetve a logikailag összefüggő adatok ugyanarra az oldalra kerüljenek. A be- és kimenet típusa és formája feleljen meg a szakmai feladatnak: a bemeneti képernyők struktúrája olyan legyen, hogy egy adott forrásból származó adatok együtt jelenjenek meg. A bemenetnél megkívánt illetve a kimenetben megjelenített pontosság egyezzen meg a szakmai feladat által megkívánt pontossággal.

A felhasználó kérésre kapjon egy általános áttekintést a FF-ről, és képes legyen a szakmai feladat egyik részéről a másikra kapcsolni. A FF támogassa a felhasználót az ismétlődő szakmai feladatok végrehajtásánál: legyen benne lehetőség egy adott tevékenység mentésére, illetve későbbi felhasználására. Ne kelljen a felhasználónak szabványos alapértelmezett értékeket bementként megadnia, viszont legyen lehetőség az alapértelmezett értékek egyéb értékekkel való kicserélésére. Olyan feladatnál, amely közben az adatok megváltoznak, legyen lehetőség továbbra is elérni az eredeti adatokat.

2. Magától értetődőség: ez azt jelenti, hogy minden dialógus-lépés azonnal érthető, mert azonnal érkezik visszajelzés a rendszertől, és magyarázat a rendszer állapotához. Fontos, hogy minden felhasználói akció után érkezzen visszajelzés, pl. a bebillentyűzött karakterek azonnali megjelenítése; és magyarázat, különösen akkor, ha az akció súlyos következményekkel járhat, pl. törlés. Ha a törlés már nem visszafordítható, akkor előtte legyen megerősítő kérdés. A visszajelzést és a magyarázatot a szakterület nyelvhasználatával kell megfogalmazni, és nem a rendszer terminológiájával: "Speak the user's language" = "A felhasználó nyelvét beszélni". A dialógusban előforduló szakmai nyelv kifejezései egyezzenek meg az adott szakterületen éppen használtakkal, és a felhasználói kézikönyv terminológiájával.

A visszajelzések és magyarázatok

segítsék a felhasználót abban, hogy általános képet nyerjen a FF-ről, kialakuljon a felhasználóban egy mentális modell a FF-ről;

a felhasználó feltételezett tudásszintjének feleljenek meg;

hossza és típusa változtatható legyen, a felhasználó igénye szerint;

bármikor elérhetők legyenek, pl. "Help" billentyű lenyomásával;

általános és példán keresztül bemutatott formában egyaránt álljanak rendelkezésre.

Ha jók a visszajelzések és a magyarázatok, akkor a felhasználónak nem kell gyakran a kézikönyvhöz, vagy más külső forráshoz nyúlnia. Fontos továbbá, hogy a FF megmutassa a dialógus állapotát valahányszor bemeneti adatra van szükség vagy egy parancs éppen futás alatt áll. A felhasználó lássa a dialógus jövőbeli folytatásának lehetőségeit, és a dialógus addigi történetét. Végül, a kért bemenet formátumát jelezni kell, pl. dátumbeírásnál "év.hónap.nap".

3. Ellenőrizhetőség: ez azt jelenti, hogy a felhasználó irányítja a FF-et: a dialógus sebességét a felhasználó szabja meg, és nem a rendszer (pl. a bemeneti mezők nem törlődnek addig, amíg a felhasználó nem jelezte az adatbevitel végét). A felhasználó állíthatja be, hogyan szeretné a dialógust folytatni, pl. a rendszer a helyőrt (kurzort) a következő bemeneti mezőre állítja, de nyitva áll másik mező választásának lehetősége is. Ha a dialógus megszakadt, a felhasználó mondja meg, mely ponton akarja folytatni. Fontos, hogy legyen visszaállítási funkció (undo). A visszajelzés információmennyiségét, és a megjelenített adatok formáját, típusát a felhasználó ellenőrizhesse, pl. szöveges vagy grafikus megjelenítés. A felhasználó választhassa ki, hogy milyen I/O készüléket használ, pl. billentyűzetet vagy egeret.

4. Megfelelés a felhasználó elvárásainak: ez azt jelenti, hogy a FF megfelel a felhasználó kultúrájának, műveltségi és tapasztalati szintjének, tudásának, illetve szokásainak. A dialógus lefutása és megjelenése a FF-en legyen következetes, pl. a rendszer állapotát jelző információ mindig ugyanabban a sorban jelenjen meg, vagy mindig ugyanazt a gombot használjuk a dialógus befejezésére. A dialógus állapotát megváltoztató opciók legyenek következetesek, és mindig elérhetők, pl. az "Escape" mindig a felső dialógus-szintre ugorjon. A dialógusban a felhasználó által jól ismert (szakmai) terminológiát kell használni.

Hasonló szakmai feladat megoldására szolgáló dialógusok felépítése hasonló kell legyen, pl. minden parancsnak szabványos struktúrája van, vagy a parancsnevek halmaza következetes (l. "A parancs-vezérelt dialógus" c. részt is). Ekkor a felhasználó FF-ről alkotott mentális modelljében általános feladatmegoldó sémák alakulnak ki. A felhasználó elvárja, hogy a gép azonnal reagáljon, ne fagyjon meg, pl. a mutatóhelyőr egérmozdulat után azonnal mozduljon meg. Ha a rendszer előreláthatóan nem fog reagálni hosszabb ideig, erről a felhasználót informálni kell, pl. "Ez az eljárás várhatóan .... percig fog tartani".

5. Hibatűrés: ez azt jelenti, hogy annak ellenére, hogy a felhasználó hibás bemenetet ad meg, célját el tudja érni. A FF-nek meg kell akadályoznia a felhasználót abban, hogy hibás bemenetet adjon meg, pl. a szám-bemenetet ellenőrzi a rendszer. A hibaüzenetek legyenek könnyen érthetők, tárgyilagosak és építő jellegűek. A hibaüzenetek struktúrája a FF-en következetes legyen. Rossz a következő hibaüzenet: "Ennek semmi értelme". Kijavítása: "A megadott adatot nem lehet születési dátumként értelmezni, kérem használja a következő formát: év, hó, nap". Tehát a hibát el kell magyarázni a felhasználónak, hogy segítse a rendszer a hiba javítását.

Az információt úgy kell megjeleníteni, hogy a felhasználó könnyen felismerje a hiba helyét, pl. pirossal megjelölni azt a helyet, ahol a bemenet hibás, odahelyezni a helyőrt, és mellette elfogadható példa-bemeneteket mutatni. Ha a FF képes önműködően javítani a hibát, akkor a javításról értesíteni kell a felhasználót, és meg kell adni neki a lehetőséget az automatikus javítás visszautasítására. Erre példa a helyesírás-ellenőrző program. A hibakezelést a felhasználó halaszthassa későbbre, pl. a helyesírás-ellenőrzést a levélírás utánra. Hibajavítás közben legyenek további magyarázatok. A hibát ki lehessen javítani a dialógus állapotának megváltoztatása nélkül, pl. ha az üzenet címe rossz, azt ki lehessen javítani az üzenet elvesztése nélkül.

6. Testre szabhatóság: ez azt jelenti, hogy a dialógus lefolyását meg lehet változtatni az adott felhasználó saját igényei és adottságai szerint:

nyelv;

kultúra;

tudásszint;

tapasztalat;

érzékszervi képességek, pl. jó vagy rossz színlátás;

kognitív képességek;

motoros képességek, pl. jobb- vagy balkezesség.

Legyen lehetőség választani az információ megjelenítésének módjai között, pl. kimeneti diagram típusa. Lehessen változtatni a magyarázat mennyiségét. A felhasználó alakíthasson ki egy saját szótárat: tetszése szerint nevezhesse el az objektumokat, akciókat; alkothasson személyi makrókat, saját funkciókat. Példa erre annak lehetősége, hogy a felhasználó felvehesse bizonyos gombok lenyomásának sorrendjét, és ezt a sorrendet később lejátszhassa. Az idő-paraméterek változtathatók legyenek, pl. a görgetés sebessége. Fontos, hogy a felhasználó maga választhasson a dialógus-típusok között, pl. menü helyett parancs-vezérelt dialógus.

7. A tanulhatóság azt jelenti, hogy a FF tanulása során a rendszer a felhasználót támogatja és kalauzolja: szabályokat és elveket mutat be neki, hogy gyorsabban megjegyezhesse a FF működését. A tanulást példákkal, illetve gyakorlatokkal segíti: " learning by doing". A felhasználó a példán keresztül segítő dialógusban tetszése szerint léphet előre vagy hátra, míg el nem sajátítja a műveletet. A gyakori parancsokhoz gyorsbillentyűt, a ritka parancsokhoz több segítséget kell biztosítani. Cél az, hogy a felhasználó minél hamarabb megtanulja a dialógus elemeit.

A számítógéppel folytatott párbeszéd: dialógus-elvek. Ellenőrző kérdések

1. Mi a dialógus két szélsőséges lehetősége, és mi jellemző ezekre?

2. Mi a Norman-féle kölcsönhatási modell, vagy végrehajtási-értékelési ciklus 5 alapfogalma?

3. Mit jelent a Norman-féle kölcsönhatási modellben a szakterület?

4. Mit jelent a Norman-féle kölcsönhatási modellben az alapelem?

5. Mit jelent a Norman-féle kölcsönhatási modellben a felhasználó célja?

6. Mit jelent a Norman-féle kölcsönhatási modellben a felhasználó szándéka?

7. Miben különbözik a felhasználó nyelve és a rendszer nyelve?

8. Melyek a végrehajtási-értékelési ciklus lépései?

9. Mi a végrehajtási szakadék?

10. Mi az értékelési szakadék?

11. Mi a FF-en alkalmazható dialógusok 4 fő típusa?

12. Mi a menü-dialógus előnye és hátránya?

13. Mi a parancs-vezérelt dialógus előnye és hátránya?

14. Miért érti nehezen a számítógép a természetes nyelvet?

15. Mi a közvetlen dialógus 4 fajtája?

16. Mi a WIMP, és mi jellemző rá?

17. Mi a 3D munkatér és mi jellemző rá?

18. Melyek a kitöltés-dialógus fajtái?

19. Mi a dialógus-ablak előnye és hátránya?

20. Mi jellemző az interaktív táblázatra?

21. Milyen szempontok alapján kell alkalmazási sorrendet felállítani a dialógus-elvek között?

22. Mi a 7 fő dialógus-elv?

23. Mit jelent a következő dialógus-elv: szakmai feladat megoldására való alkalmasság?

24. Mit jelent a következő dialógus-elv: magától értetődőség?

25. Mit jelent a következő dialógus-elv: ellenőrizhetőség?

26. Mit jelent a következő dialógus-elv: megfelelés a felhasználó elvárásainak?

27. Mit jelent a következő dialógus-elv: hibatűrés?

28. Mit jelent a következő dialógus-elv: testre szabhatóság?

29. Mi a személyi makró?

30. Milyen egyéni igényei és adottságai lehetnek egy adott felhasználónak?

31. Mit jelent a következő dialógus-elv: tanulhatóság?

Használhatóság és használhatósági vizsgálat

Az ebben a fejezetben leírt anyag az ISO 9241-11 nemzetközi szabvány és Alan J. Dix, Janet E. Finlay, Gregory D. Abowd, Russell Beale, "Human-Computer Interaction" című könyve alapján készült.

A FF tervezése során a legfontosabb szempont, hogy a kész FF alkalmas legyen a felhasználó szakmai feladatának megoldására, és a munka könnyű és hatékony legyen. Az ilyen elkészült FF-et nevezik használhatónak. A FF tervezője két kérdéssel szembesül:

1. Hogyan fejlesszük a FF-et, hogy használható legyen?

2. Hogyan lehet a FF használhatóságát vizsgálni, mérni?

Kétféle megközelítés létezik: az egyik jól használható példákat mutat be, hogy ezeket ismerve és utánozva legyen a készítendő FF is jól használható. A másik ún. használhatósági elveket rögzít, amelyeket a FF tervezése során észben tartva hozható létre a jól használható FF. Ez a fejezet először a fenti 1. kérdésre válaszolva a használhatósági elveket csoportosítja és részletezi, majd a 2. kérdésre válaszolva leírja a használhatósági vizsgálat fajtáit és módszereit.

A használhatósági elvek csoportosítása: az elveket három nagy csoportra lehet osztani:

Tanulhatóság: mennyire könnyen tudja az új felhasználó megkezdeni a hatékony dialógust a géppel, és milyen hamar jut el a maximális teljesítményéhez.

Rugalmasság: mennyire sokféle út áll rendelkezésre a dialógushoz.

Támogatottság: mennyi támogatást kap a felhasználó szakmai feladatának megoldásához a FF-en.

1. A tanulhatóság mértékét a következő öt használhatósági al-elv határozza meg: előrejelezhetőség, modellezhetőség, kitalálhatóság, általánosíthatóság, következetesség.

Előrejelezhetőség: a FF segíti a felhasználót abban, hogy következő akciójának hatását meghatározza, ha ismeri a múltban történt akcióit; valamint nem történnek váratlan események. A váratlan események csak speciális FF-en megengedhetők, pl. egyes videojáték-programok. Az előrejelezhetőség szintje függ attól, hogy mire kell és mire nem kell a felhasználónak visszaemlékeznie. A legkisebb megterhelést jelentő szint az, amikor a felhasználó az adott képernyőn mindent észlel ahhoz, hogy meg tudja állapítani következő akciójának hatását. Például, a felhasználó egy rajzoló programmal vonalakból, körívekből ábrát készített. Ezután a képet bezárta, de később újra megnyitotta. Ebben az esetben az előrejelezhetőség azt jelenti, hogy a felhasználó az újból megnyitott képen látja, melyek azok a vonalak és ívek, amelyeket együtt, csoportként is kiválaszthat. Ez a fajta előrejelezhetőség azzal kapcsolatos, hogy mi lesz a felhasználó akciójának hatása. Az előrejelezhetőség másik fajtája azt jelenti, hogy a felhasználó észlelni képes, hogy milyen akciók hajthatók végre a következő lépésben egyáltalán. Ha egy akció végrehajtható, akkor azt valamilyen módon tudatja a FF a felhasználóval.

Modellezhetőség: a FF segíti a felhasználót abban, hogy felépítse a saját mentális modelljét a rendszerről. A mentális modellben kialakul az a képesség, hogy a korábbi akciók hatására a felhasználó képes felbecsülni a rendszer adott pillanatbeli állapotát. A mentális modell felépítéséhez fontos, hogy a FF jelezze, ha valamilyen akció hatására a rendszer állapota megváltozott. Ez a követelmény a FF ún. "őszintesége": vagy azonnal visszajelez, ha az állapot megváltozott, vagy a felhasználónak lehetősége van erre rákérdezni. Például, a felhasználó egy állományt (file-t) áthelyez az egyik könyvtárból (directory-ból) a másikba. Ekkor a parancs-vezérelt dialógusban rá kell kérdezni a felhasználónak, hogy valóban ott van-e, míg egy WIMP-felületen azonnal meglátja. Például a modellezhetőséget sérti, ha a WIMP-felületen az újonnan létesített könyvtár ikonja legalul jelenik meg, és a felhasználó nem látja azonnal. Ilyenkor a felhasználó hajlamos rengeteg üres könyvtárikont csinálni, amíg rá nem jön, mi történik.

Kitalálhatóság: a FF segíti a felhasználót abban, hogy tanulás közben felhasználja korábbi tapasztalatait. Például a régi szövegfeldolgozó programoknál a mechanikus írógép ún. metaforáját használták. A metaforák a FF korábbi, ismert tárgyakhoz hasonlító objektumai. Minél több a jó metafora, annál jobb a felhasználó első benyomása a FF-ről, annál könnyebben tudja elindítani első akcióit. Például, egy 3D nyomógomb a WIMP-felületen szinte sugallja, hogy nyomja meg azt a felhasználó. A kilincs metaforája pedig a belépés lehetőségét sejteti.

Általánosíthatóság: a FF segíti a felhasználót abban, hogy egy már ismert dialógus működési módjából másokra következtessen. Ezáltal a mentális modell még jobban működik. Az általánosíthatóság megjelenhet egy adott rendszeren belül, vagy rendszerek között. Például a rajzolóprogramban azt, hogy a felhasználó a kört valamilyen billentyűvel korlátozott egérmozdulattal általános ellipszisként rajzolhatja meg, lehessen általánosítani úgy, hogy a négyzetet viszont hasonló módon általános négyszögként rajzolhatja meg. Másik példa a WIMP-felületen a "cut/paste/copy" műveletek hasonlósága minden alkalmazásban. A "szabványos" FF-ek (pl. Windows FF-ek) előnye a nagyfokú általánosíthatóság a tanulás során.

Következetesség: a FF hasonló helyzetekben hasonlóan viselkedik. Az egyik legfontosabb követelmény: a felhasználó következetes FF-re támaszkodik. Például a súlyos következményekkel járó események színkódja mindig piros, a kevésbé súlyos sárga, és az egyszerű közléseké zöld.

2. A rugalmasság mértékét a következő öt használhatósági al-elv határozza meg: a dialógus kezdeményezése, többszálú dialógus, feladat-átadhatóság, helyettesíthetőség, és a testre szabhatóság.

Dialógus kezdeményezése: a FF azon tulajdonsága, hogy a felhasználó szabadon kezdeményezhessen dialógusokat. Ezen dialógusok közben a rendszer bizonyos mértékig korlátozhatja a felhasználót egyéb tevékenységek végzésében, például közben más szakmai vagy egyéb feladatot nem végezhet, más dialógust nem nyithat meg. Bizonyos helyzetekben azonban a rendszernek is kezdeményeznie kell dialógust, például, ha a felhasználó akciója hibához vezet.

Többszálú dialógus: a felhasználó egyszerre több (szakmai) feladattal is foglalkozhat. Bizonyos esetekben a felhasználó bemenete egyidejűleg több (szakmai) feladathoz is eljuthat. A többszálú dialógus leggyakoribb példája az ablakokat használó (WIMP) felület. A többszálúságot megkönnyíti, ha a dialógusnak több csatornája is van: billentyűzet, egér, hang-bemenet, hang-kimenet, szöveges kimenet. Például miközben az egyik ablakban szöveget szerkesztek, a levelező program hangjelzéssel jelzi, hogy üzenetem érkezett.

Feladat-átadhatóság: a (szakmai) feladatok ellenőrzését, végzését a rendszer átadhatja a felhasználónak, vagy a felhasználó a rendszernek. Lehetséges legyen teljesen rendszer által végzett feladatok megosztott formában való végzése. Erre példa a helyesírás-ellenőrzés: a rendszer rákérdez a kétes esetekre, pl. arra, hogy a szókettőzés szándékosan, vagy véletlenül történt. Ilyet a helyesírás-ellenőrző program maga nem tud eldönteni. Másik példa: a repülőgépet irányító program vészhelyzetben bizonyos feladatok irányítását azonnal, feltűnés nélkül átad a pilótának.

Helyettesíthetőség: a bemeneti és kimenetei adatok formája sokféle lehessen:

sokféle egységben legyen megadható a be- és kimenet, pl. hüvelykben vagy cm-ben, illetve algebrai formulával;

a kimenet lehessen szöveges, vagy grafikus, például a hőmérséklet jelzésére egy hőmérő rajza, vagy egy szám hőmérséklet-egységgel;

a bemenet egyben lehessen kimenet is. Erre példa az interaktív táblázat.

Testre szabhatóság: ez a 6. dialógus-elv. Azt jelenti, hogy a felhasználó saját igénye szerint módosíthatja a FF-et, de nem a funkcionalitást. A FF legyen képes információt nyerni vagy kérni a felhasználótól, a felhasználóról, és ennek ismeretében idomulni a felhasználó igényéhez. Két formája van: a beállíthatóság és az automatikus alkalmazkodóképesség. A beállíthatóság azt jelenti, hogy a felhasználó maga állíthatja be a dialógus-típust, a be- és kimenet formáját, az információ-megjelenítés módját. Az automatikus alkalmazkodóképesség azt jelenti, hogy a rendszer figyeli a felhasználó viselkedését, rendszeresen ismétlődő feladatait, és ennek alapján önműködően állítja be, hogy a felhasználó kezdő vagy szakértő, illetve önműködően makrót készít a gyakori (szakmai) feladataihoz.

3. A támogatottság mértékét a következő négy használhatósági al-elv határozza meg: megfigyelhetőség, visszaállíthatóság, válasz-gyorsaság, és a szakmai feladat megoldására való alkalmasság.

Megfigyelhetőség: a felhasználó - a rendszerről önmagában alkotott mentális modelljét felhasználva - a megjelenített információból képes a rendszer belső állapotát értékelni, és ez alapján szándékát (user's intention) szükség esetén módosítani. A megfigyelhetőség a következő négy kisebb elvre bontható le: böngészhetőség, alapértékek, elérhetőség, és megjelenítve maradás.

A böngészhetőség azt jelenti, hogy a rendszer aktuális állapotáról - felhasználói kérésre - összefoglaló vázlat jelenik meg. Ezt a vázlatot böngészve a felhasználó nem tudja megváltoztatni a rendszer állapotát. Például, miközben egy dokumentumot ír, annak vázlatát is megtekintheti.

Az alapértékek megjelenítése csökkenti a felhasználó memóriájának igénybevételét és a bemeneti akciók számát. Ezáltal a felhasználói hibát is megelőzi. Lehetnek ún. dinamikus alapértékek is, amelyeket a rendszer a dialógus során megadott bemenetekből állít elő.

Az elérhetőség azt jelenti, hogy a felhasználó - a FF-en keresztül - képes a rendszer bármely állapotából bármelyikbe eljutni. Például, egy hibamentesítő (debugger) programban egy változó értékének megjelenítését ne lehessen véglegesen törölni, úgy, hogy azt csak a program újraindítása után lehet újra megjeleníttetni.

A megjelenítve maradás: Néhány esetben szükség lehet arra, hogy a dialógus befejezése után is megjelenítve maradjon valamilyen információ arról, hogy a dialógus lezajlott. Például, ha e-mail érkezett, egy kis zászló marad valahol, jelezvén, hogy még nincs elolvasva.

Visszaállíthatóság: ez azt jelenti, hogy ha a felhasználó a dialógusban hibát fedezett fel, akkor ezt ki tudja javítani, és célját végre tudja hajtani. Két formája van: az egyikben a felhasználó elfogadja a rendszer dialógus-hiba utáni állapotát, és a FF támogatja abban, hogy célját elérje. Másik formája, amikor a felhasználó vissza tud térni a korábbi állapothoz, visszaállítási (undo) funkcióval. Ehhez kapcsolódik az ún. összemérhetőségi elv: a rendszer által fizikailag nehezen visszaállítható akciókat nehezen lehessen kivitelezni a FF-en. Például file-törlést csak többszöri visszakérdezés után, a fizikailag könnyebben visszaállítható file átnevezést pedig azonnal engedje meg a FF.

Válasz-gyorsaság: a felhasználói akció után lehetőleg gyorsan változzon a rendszer állapota és a dialógusban lehetőleg azonnal válaszoljon a gép. Ha ez nem lehetséges, a FF jelezze a feldolgozás folyamatának tényét a felhasználónak. Fontos továbbá, hogy a válasz-gyorsaság a dialógus során állandó maradjon.

Szakmai feladat megoldására való alkalmasság: ez az 1. dialógus elv: a FF minden szakmai feladatot támogat. Elképzelhető, hogy az elkészült FF-el korábban lehetetlen szakmai feladatok is megoldhatók. Fontos a végrehajtási és az értékelési szakadék minimálása, áthidalása.

Használhatósági vizsgálat

A használhatósági elvek megismerése után felmerül az a kérdés, hogy milyen módszerrel lehet egy - csak tervben létező, illetve részben vagy teljesen elkészült - rendszer funkcionalitását és FF-ét használhatósági szempontból értékelni. Érdemes már a FF tervezése közben is használhatósági vizsgálatot végezni, és nem csak a végén. Ezáltal idő és költség takarítható meg. A használhatósági vizsgálat lehet automatikus (erre a célra írt speciális programokkal), formális (rendszer-modelleket használó), értékelő szakember által végzett, vagy valódi felhasználók által végzett. A tervben létező FF-et általában értékelő szakemberek vizsgálják, míg a már elkészült FF-et általában valódi felhasználókat megkérdezve elemzik. Az utóbbi esetben a felhasználóknak leggyakrabban kérdőíveket töltenek ki. A jelenlegi tananyag az értékelő szakemberek két módszerét mutatja be, a FF tervének vizsgálatára.

A használhatósági vizsgálat három alapcélja:

a funkcionalitás vizsgálata: minden szakmai feladat megoldásához van-e azt megvalósító programrészlet, illetve adatállomány?

a használhatósági elvek teljesülésének vizsgálata;

speciális használhatósági problémák felderítése.

A használhatósági vizsgálatot két helyen lehet végezni: vagy a fejlesztés helyén (laboratóriumi vizsgálat), vagy az alkalmazás helyén (valós vizsgálat). Az előnyök, és hátrányok hasonlók a korábban leírt laboratóriumi/valós pszichofizikai kísérlet előnyeihez/hátrányaihoz.

Laboratóriumi vizsgálat során a dialógus akár videofelvétellel is rögzíthető, és jól értékelhető. Nehéz azonban egy felhasználói csoport munkájának tanulmányozása. Egy-felhasználós rendszerek, valamint valós vizsgálattal elérhetetlen rendszerek (pl. űrállomás) vizsgálatához használható. A valós vizsgálat előnye, hogy itt valós felhasználók valós körülmények között dolgoznak a FF-el. Fontos, hogy a kísérletvezető (kiértékelő) ne legyen közvetlenül jelen.

A FF tervének vizsgálata

Érdemes már a FF tervét is értékelni, azelőtt, hogy kód készülne, hogy az esetleges FF-hibák egyáltalán ne kerüljenek megvalósításra. Két módszer kerül bemutatásra: a körüljárás és a heurisztikus értékelés. Ezeken kívül használhatók az ún. rendszer-modellek, de ezek kívül esnek a jelenlegi tananyagon.

A körüljárás során az értékelő szakember (aki a használhatósági vizsgálatot végzi) felhasználói akciók lehetséges sorozatán lép végig, amely egy adott szakmai feladat megvalósításához szükséges. Közben - leginkább a tanulhatóságra koncentrálva - leírja, ha használhatósági problémát talált: miért jó, vagy nem jó az adott lépés vagy akció az (új) felhasználónak. A körüljáráshoz a következőkre van szükség:

a készítendő rendszer prototípusának leírása, elég részletesen, pl. a menük helye és szövege;

a szakmai feladatok leírása: amelyeket a legtöbb felhasználó a FF-en végezni szeretne;

ezen feladatok végrehajtásához szükséges akciók listája a prototípuson belül;

a felhasználók, valamint tapasztalati és tudásszintjük leírása.

Ezután minden lépésnél, azaz minden felhasználói akciónál az értékelő szakember a 3. pont felhasználói akciólistáján végigmegy és a következő négy kérdésre válaszol írásban:

Szakmai szempontból megfelelő-e a FF-en megvalósítandó akció?

A FF-en mindig észlelhető a következő lépésnek megfelelő objektum?

Ezt az objektumot a felhasználó könnyen azonosítani tudja a következő lépés szakmai feladatával?

Az akció után a visszajelzést (kimenetet) könnyen megérti és értékeli a felhasználó?

Fontos, hogy az értékelő szakember leírja, hogy mi jó, és mi javítandó a FF tervében. Érdemes a leíráshoz formanyomtatványt használni, minden akciólistához külön.

A heurisztikus értékelés során 3-5 értékelő szakember a FF elemeit, akcióit írásban értékeli, észben tartva a dialógus-elveket, a használhatósági elveket, vagy az alábbiakban leírt ún. heurisztikus elveket. Ez a módszer, és más módszerek megtalálhatók a következő könyvben: Jakob Nielsen (Ed) and Robert L. Mack (Ed): Usability Inspection Methods, Wiley 1994. Az értékelő szakemberek először egyenként dolgoznak, majd írásos anyagukat vezetőjük összeveti, értékeli. Másik lehetőség, hogy egy megbeszélésen összesítik a FF heurisztikus elvek alapján elkészült kritikáját. Az értékelő szakemberek egy tipikus felhasználói munka-forgatókönyv alapján dolgoznak. Ezt a szakmai feladatelemzés alapján készítik el, amelyben megvizsgálják, milyen szakmai feladatokat hajt végre az átlagos felhasználó, akinek a programot szánják. Az egyes értékelők írásos anyaga tartalmazza a felfedezett használhatósági problémákat, opcionálisan azzal a heurisztikus elvvel együtt, amely megsérült. Az értékelés után el lehet végezni egy ún. költség-hozam analízist, arról, hogy a fejlesztés adott állapotában az újratervezés vagy újraírás munkaköltsége (pl. 1 MFt) hogyan viszonyul a FF várt javulása által hozott többletbevételhez (pl. 500 MFt). A heurisztikus értékelésnél érdemes kérni a felfedezett hibák vagy hiányosságok súlyosság-becslését, pl. 5 lépéses rating skálákon (l. a korábbi "Pszichometria" című fejezetet):

1. skála: milyen gyakran fordul elő a probléma?

2. skála: mennyire súlyos a felhasználó szempontjából?

3. skála: a probléma feltételezett hatása az eladhatóságra.

A 10 heurisztikus elv a következő:

A felhasználó mindig észlelje a rendszer állapotát;

A rendszer beszélje a felhasználó szakmai nyelvét;

A felhasználó uralja, ellenőrizze a rendszert;

Következetesség és szabványosság;

Hibák megelőzése;

Észlelés a visszaemlékeztetés helyett: az objektumok, akciók és opciók megjelenítése;

Rugalmasság és hatékonyság: felhasználói akciókat gyorsító lehetőségek;

Esztétikus és minimális tervezés: csak fontos információk megjelenítése;

Segítség a felhasználónak a hibák felismerésében és megszüntetésében: világos és konstruktív hibaüzenetek;

Általános segítség és dokumentáció.

Összegyűjtötték a leggyakoribb 249 használhatósági problémát, és az ehhez tartozó kisebb elveket. Ezeket az elveket is lehet használni a használhatósági vizsgálatnál a fenti 10 heurisztikus elv helyett.

Használhatóság és használhatósági vizsgálat. Ellenőrző kérdések

1. Mi jellemző a használható felhasználói felületre?

2. Mi a használhatósági elvek három nagy csoportja?

3. Mit jelent a következő használhatósági elv: tanulhatóság?

4. Mit jelent a következő használhatósági elv: rugalmasság?

5. Mit jelent a következő használhatósági elv: támogatottság?

6. Mi a tanulhatóság öt használhatósági al-elve?

7. Mit jelent a következő használhatósági al-elv: előrejelezhetőség? Írjon egy jó, vagy rossz példát.

8. Mit jelent a következő használhatósági al-elv: modellezhetőség? Írjon egy jó, vagy rossz példát.

9. Mit jelent a következő használhatósági al-elv: kitalálhatóság? Írjon egy jó, vagy rossz példát.

10. Mi a FF-en alkalmazott metafora?

11. Mit jelent a következő használhatósági al-elv: általánosíthatóság? Írjon egy példát.

12. Mit jelent a következő használhatósági al-elv: következetesség? Írjon egy példát.

13. Mi a rugalmasság öt használhatósági al-elve?

14. Mit jelent a következő használhatósági al-elv: dialógus kezdeményezése?

15. Mit jelent a következő használhatósági al-elv: többszálú dialógus? Írjon egy példát.

16. Mit jelent a következő használhatósági al-elv: feladat-átadhatóság? Írjon egy példát.

17. Mit jelent a következő használhatósági al-elv: helyettesíthetőség? Írjon egy példát.

18. Mi és mit jelent a következő használhatósági al-elv: "testre szabhatóság" két formája?

19. Mi a támogatottság négy használhatósági al-elve?

20. Mit jelent a következő használhatósági al-elv: "megfigyelhetőség"? Melyik 4 kisebb al-elvre bontható ez le? Írjon egy példát a "megfigyelhetőség"-re.

21. Mit jelent a következő használhatósági al-elv: "visszaállíthatóság", és mi ennek a két formája?

22. Mi az összemérhetőségi elv?

23. Mi a használhatósági vizsgálat három alapcélja?

24. Írja le a körüljárás módszerét.

25. Írja le a heurisztikus értékelés módszerét.

26. Írjon 5 heurisztikus elvet.

Az információ megjelenítése

Ez a fejezet - az ISO 9241-12 alapján - tárgyalja az információ vizuális megjelenítésére vonatkozó software-ergonómiai elveket. Szó lesz a vizuális információ elrendezéséről, szervezéséről a képmegjelenítő 2D felületén, és a különféle információ-kódolási módszerekről. Elveket, szabályokat, ajánlásokat láthatunk a felhasználói felület tervezésének információ-megjelenítéssel kapcsolatos lépéseihez. Fontos, hogy már az alapértelmezett (default) megjelenítés jól használható legyen, és a FF ne bízza teljesen a felhasználóra ennek kialakítását testreszabási lehetőségekkel.

Ebben a részben csak 2D felületekkel foglalkozunk: a szöveges felületekkel és a grafikus felhasználói felülettel (GUI). Utóbbi a WIMP szinonimája. Nem térünk ki a 3D munkaterekre, valamint a VR, illetve HMD alkalmazásokra. HMD segítségével sztereo kép és hang biztosítható, a megjelenített kép a teljes látóteret elfoglalja; ezáltal a felhasználó "belemerül" a virtuális valóságba. Ezért ezekre speciális hardware- és software-ergonómiai szabályok vonatkoznak, melyek jelenleg kívül esnek a tananyagon.

Fogalmak

Területek: A képmegjelenítők illetve ablakok következő területeit különböztetjük meg (l. az 1. ábrát):

1. ábra: Az ablakok területei. 1: Azonosítási terület 2: I/O terület 3: Kontroll terület 4: Üzeneti terület

Az azonosítási terület az ablakban megjelenített információ címe, megnevezése, vagy rövid összefoglalása. Jelzi a felhasználó jelenlegi helyét és szakmai feladatát. Az I/O terület a dialógus helye, ahol a felhasználó információt ad vagy kap. A kontroll-területen a dialógus vezérlésére szolgáló kezelőszervek, parancs-bevitel vagy parancs-választás történik. Az üzeneti terület tartalmazza a rendszer állapotát, a hibaüzeneteket, a program futásának állapotát, illetve bármilyen egyéb visszajelzést a felhasználónak.

Vizuális kód : információ megjelenítési technika, a képmegjelenítőből a felhasználó szemébe érkező fény spektrális vagy térbeli eloszlását változtatva. Maguk a felismerhető (olvasható) alfanumerikus karakterek, grafikai szimbólumok, ikonok; a betűtípus, szín, vagy kiemelés.

Mnemonik kód: rövid, könnyen megjegyezhető szavak gyűjteménye, amelyeknek könnyen megtanulható jelentése van a felhasználó számára: pl. "add" az összeadás mnemonikja.

Kezelőszervek: grafikai objektum, gyakran metafora (a FF korábbi, ismert tárgyakhoz hasonlító objektumai), pl. rádiógombhoz hasonló. A közvetlen dialógus alapeleme.

Mező: az ablak valamely területének rögzített karakterhosszú része, lehet bemeneti vagy csak-olvasható mező. Mezőcsoport: mezők vizuálisan összekapcsolt és más vizuális objektumoktól elhatárolt csoportja.

Kiemelés (highlighting): a kiemelt információ vizuális keresési ideje kisebb, mint a többié. Történhet polaritásváltással (pozitív polaritás: sötét szöveg világos háttéren, negatív polaritás: fordítva), villogtatással, aláhúzással, színhasználattal, a fénysűrűségi kontraszt növelésével (világossági kódolás), kiegészítő grafika hozzáadásával (pl. a kiemelendő információ köré téglalapot rajzolva), vagy méretnöveléssel.

Ikon: a képmegjelenítő grafikai objektuma, amely valamely rendszerobjektumot, akciót, vagy funkciót jelöl. Gyakran metafora.

Címke (label): egy mezőt, táblázatot, kezelőszervet vagy más grafikai objektumot tömören jellemző felirat.

Jelző (marker): egy grafikai vagy szövegelem mellett annak állapotát jelzi, vagy kiemeli azt. Például: *, x, +, vagy

Elsődleges ablak: az operációs rendszer, egy alkalmazás, vagy egy objektum adott állapotát jeleníti meg; dialógusban belőle másodlagos ablakok nyílhatnak meg, a felhasználó vagy a rendszer kezdeményezésére.

Ablakozási formák: csempeszerű, átfedő (altípusa: kaszkád), vagy vegyes, lásd az alábbi ábrákat.

Csempeszerű ablakozási forma:

Átfedő ablakozási forma:

Kaszkád ablakozási forma:

Vegyes ablakozási forma:

A megjelenített információ jellemzői

Az információt úgy kell megjeleníteni, hogy a felhasználó képes legyen a szakmai és a rendszerrel kapcsolatos feladataihoz szükséges vizuális feladatokat hatékonyan, elégedetten, és hosszú távon sem fárasztó módon végrehajtani. Ehhez a megjelenített információnak rendelkeznie kell az alábbi 6 tulajdonsággal:

1. Pontosság: az információ pontosan és gyorsan jelenik meg;

2. Megkülönböztethetőség: az egyes elemeke egymástól vizuálisan jól elkülönülnek;

3. Tömörség: csak a (szakmai) feladat végrehajtásához szükséges mennyiségű információ jelenik meg;

4. Következetesség: hasonló információ ugyanúgy jelenik meg mindig, végig az egész alkalmazásban;

5. Olvashatóság;

6. Érthetőség: az megjelenített információ érthető, egyértelmű, értelmezhető, és felismerhető.

Ha a fenti jellemzők teljesülnek, akkor a felhasználó könnyebben és gyorsabban felfogja, megérti az információt, és növekszik a vizuális keresés sebessége.

Az információ használható megjelenítésére vonatkozó elvek, ajánlások

Ezek az elvek 1. az információ elrendezésére, 2. a grafikai objektumokra, valamint 3. az információ-kódolási módszerekre vonatkoznak. Fontos, hogy ne mechanikusan alkalmazzuk ezeket, hanem alkalmazásuk közben minden dialógus- és használhatósági elvet magunk előtt lássunk, hogy ezek ne sérüljenek, és az egyes elvek között megtaláljuk az arany középutat.

1. Az vizuális információ elrendezése

1.1 Ablakok

Az ablak a képernyő önállóan kontrollálható része, ahol különböző forrásokból jelenik meg információ. Ezek a források lehetnek: különböző operációs rendszerek, alkalmazások, adatállományok, adott adatállomány különböző részei, azonos információ különböző megjelenítési formái (szöveges vagy grafikus), vagy adott alkalmazás különböző részei. Az ablakok tervezésére a szakmai feladat menete szempontjából a következő elvek vonatkoznak:

1. A felhasználó képes egyszerre több rendszerrel, alkalmazással, vagy program-folyamattal dialógust folytatni;

2. Egyikből a másikba könnyen vihető át adat;

3. Részfeladatok megoldása közben is látható minden, a tágabb feladatra vonatkozó információ;

4. Fontos üzeneteknél (pl. hibaüzeneteknél) a felhasználónak először vissza kell jeleznie (tudomásul vétel) és csak utána folytathatja a feladatot;

5. A feladat végrehajtásához szükséges kiegészítő információ dialógus-elemei a feladatvégzés vizuális figyelem centrumához közel jelennek meg, pl. ha a dialógus során a felhasználó az I/O terület valamelyik mezején dolgozik, akkor annak alapértékei szomszédos ablakban vagy mezőn jelennek meg.

Az ablakok tervezésére két további elv vonatkozik, a rendszer (hardware-) sajátságai szempontjából:

6. A felbontás és a képernyőméret legyen akkora, hogy a felhasználó értelmes mennyiségű információt láthasson az ablakokban, anélkül hogy gyakran kellene az ablakokat mozgatni, újraméretezni, bennük görgetni vagy lapozni;

7. A grafikai hardware válasza elég gyors legyen ahhoz, hogy a mozgatni szándékozott ablakok azonnal elmozduljanak.

A fenti általános ablaktervezési elveken kívül érdemes tekintetbe venni még az alábbi kilenc ablaktervezési elvet is:

8. Mindig át kell gondolni, hogy melyik eredményez használhatóbb FF-et: több ablak, vagy egyetlen ablak több I/O mezővel;

9. Az ablakok azonosítása egyértelmű legyen, pl. rendszer+alkalmazás+funkció vagy szakmai feladat+adatállomány neve, vagy néhány ezek közül;

10. Az ablak megjelenésének alapértelmezett helye, mérete: ezeket úgy kell meghatározni, hogy a felhasználó azonnal elkezdhesse szakmai feladatának megoldását, pl. alapértelmezésben egy új ablak úgy jelenik meg, hogy nem takar el más, a szakmai feladat szempontjából fontos információt;

11. Következetes ablakmegjelenés adott alkalmazáson belül (bizonyos ablaktípusokon belül al-típusok is lehetnek);

12. Elsődleges-másodlagos ablak viszony jelzése, pl. a másodlagos ablak az elsődleges ablakban van, vagy kereteik stílusa, színe megegyezik, vagy azonosító címkéjük az azonosítási területen megegyezik;

13. Az ablak kontroll-elemei (pl. bezárás, átméretezés) könnyen azonosíthatók legyenek.

14. Átfedő ablakozási formát akkor kell használni, ha a szakmai feladathoz változtatható típusú, számú, tartalmú, és elrendezésű ablakok szükségesek, és ha a maximális vizuális információ-sűrűség kicsi, pl. a kis felbontás miatt;

15. Csempeszerű ablakozási formát akkor kell használni, ha a szakmai feladathoz nem szükséges az ablakok típusának, számának, tartalmának, és elrendezésének változtatása, és ha minden ablakban megjelenített információra folyamatosan szükség van, és ha az átfedő ablakok manipulációja hátráltatja a szakmai feladatot a felhasználó igénybevétele vagy a rendszergépidő igénybevétele miatt;

16. A felhasználó választhassa ki a használni kívánt ablakozási formát, és menthesse el azt alapértelmezettként (l. "rugalmasság" használhatósági elvet is a "Használhatóság és használhatósági vizsgálat c. fejezetben).

1.2 Ablakon belüli területek

A használhatósághoz fontos, hogy az azonosítási terület, az I/O terület, a kontroll terület, és az üzeneti terület az 1. ábrán látható következetes helyen legyen az ablakon belül. Ne legyen a vizuális információ túl sűrűn megjelenített, mert ez vizuális zűrzavar észleletét kelti a felhasználóban. Szöveg-megjelenítésnél a karakterhelyek max. 40%-a legyen szóköztől eltérő karakterrel betöltve. GUI esetén a túl sok grafikai elem (ikon, vonal, nyomógomb) vezethet vizuális zűrzavarhoz.

Az ablak legnagyobb területe az I/O terület, amelyben különösen fontos a megjelenített információ jó elrendezése. Erre az alábbi 3 tervezési elv vonatkozik:

1. Ha lehetséges, minden, a szakmai feladathoz szükséges információ jelenjen meg. Ha ez nem lehetséges, akkor a szakmai feladatot értelmes al-lépésekre kell bontani, és ezek szerint kell az információt megjeleníteni. Ügyelni kell arra, hogy ez a felbontás ne menjen a használhatóság rovására, vagyis a szakmai feladat továbbra is jól megoldható legyen;

2. Ha két megjelenített információ-halmaz közötti összefüggést kell a felhasználónak megtalálnia, akkor a két halmaz legyen egyszerre látható: ne kelljen lapozni vagy görgetni;

3. Fontos a megjelenített információ relatív pozíciójának kijelzése csúszkával (slider) a görgetőlécen (scroll bar), vagy az x. oldal y oldalból jelzéssel, vagy annak jelzésével, hogy hányadik sorban, oszlopban jár a felhasználó az adott szöveges állományban.

Az információ megjelenítése. Ellenőrző kérdések

1. Mi jellemző az ember-számítógép dialógusra virtuális valóságban?

2. Mi az ablakok 4 területe?

3: Mi az azonosítási terület?

4: Mi az I/O terület?

5: Mi a kontroll terület?

6: Mi az üzeneti terület?

7. Mi a vizuális kód? Írjon még 3-at: betűtípus, ..., ..., ...

8. Mi a mnemonik kód?

9. Milyen módon lehet a megjelenített információt kiemelni? Írjon 5 módot.

10. Mi az elsődleges és a másodlagos ablak?

11. Írja le a 4 ablakozási forma nevét és elrendezési vázlatát.

12. Fogalmazzon meg az ablakok tervezésére vonatkozó elvek közül négy tetszőleges elvet.

13. Milyen legyen az új ablak megjelenésének alapértelmezett helye, az újonnan megjelenő ablak mérete?

14. Írjon 2 módot az elsődleges-másodlagos ablak viszony jelzésére.

15. Mikor kell használni az átfedő ablakozási formát?

16. Mikor kell használni a csempeszerű ablakozási formát?

17. Mi vezet vizuális zűrzavarhoz szöveges FF-en és GUI-n? Maximálisan hány % szóköztől eltérő karakterrel kerülhető ez el szöveg-megjelenítésnél?

18. Írjon 2 elvet a megjelenített információ elrendezésére I/O területen.

A felhasználó segítése

Mindenfajta rendszer felhasználója először tanulmányozza a rendszert és gyakorol. Ehhez ma már minden rendszertől elvárják, hogy legyen hozzá - egymással következetesen összehangolt - azonnali segítő (online help), kézikönyv (manual) és tankönyv (tutorial).

A nyomtatott segítő anyagok fajtái (Ben Shneiderman, Designing the User Interface, Third Edition. Addison-Wesley, 1998):

Rövid kezdő jegyzet (getting started notes) az első felhasználóhoz;

Bevezető tankönyv (introductory tutorial), amely a rendszer alapvető jellemzőit tartalmazza;

Teljes tankönyv (tutorial), az összes feladat (task) leírásával;

Gyors-referencia kártyák (quick reference card), a szintaxis tömör leírásával;

Áttérési kézikönyv (conversion manual), egy hasonló rendszert már ismerő felhasználóknak;

Részletes felhasználói kézikönyv (reference manual, user manual).

A segítő anyagok elektronikus (online) változatai:

Elektronikus felhasználói kézikönyv (online user manual): a nyomtatott felhasználói kézikönyv elektronikus formája. Könnyebb keresni benne, de olvashatósága kisebb, mint a nyomtatotté, l. alább;

Azonnali segítő, címszólista (online help, title list): kulcsszavakat, kifejezéseket lehet benne gyorsan keresni;

Elektronikus tankönyv (online tutorial): a teljes tankönyv (tutorial) elektronikus változata, benne a működő rendszer szimulációival, animációkkal, és működő minta-dialógusokkal.

Demonstráció: ez a program felülnézetből mutatja be a software FF-ét, annak legfontosabb elemeit, lehetőségeit egy körbejárás során, miközben kalauzolja a felhasználót.

Duffy és mtsai (Duffy T., Palmer J., and Mehlenbacher B., Online Help Systems: Theory and Practice, Ablex, Norwood, NJ, 1992) csoportosítását is felhasználva a segítő anyagok osztályozása a felhasználó célja szerint:

A felhasználó segítésének, tanításának egyéb módjai: felhasználócsoport szóbeli oktatása (tantermi szeminárium); egyéni oktatás, gyakoroltatás; telefonos konzultáció; hang- és videokazetta anyagok.

Miért használják a felhasználók még ma is szívesen a nyomtatott anyagokat? Ennek oka monitoron 1. a vizuálergonómiai követelmények rossz teljesülése: rossz betűtípus, elégtelen fénysűrűségi kontraszt, a monitoron megjelenő környezeti reflexiók, észlelhető a villogás, a rosszul elrendezett munkahelyen túl nagy az olvasási távolság, a nézésvonal (line-of-sight) lehet, hogy kényelmetlenül felfelé irányul; 2. antropometriai követelmények rossz teljesülése: kényszertesttartás; 3. az információ-megjelenítés software-ergonómiai követelményeinek figyelmen kívül hagyása: kis információ sűrűség, rossz ablakozás, gyakori lapozás/görgetés, a vizuális információ rossz elrendezése, formattálása; a karaktersorok helytelen igazítása. Ezért minden elektronikus segítő (online help) anyagnál nagyon kell ügyelni az előbbi 3 követelményre.

Nyomtatott segítő anyagok készítése

Régebben a FF-fejlesztő csoportok nem szenteltek nagy figyelmet a segítő anyagoknak. Ezért ezek gyakran rossz minőségűek voltak, és nem jelentek meg időben. Ma a bonyolult software-eknél fontos követelmény az átgondolt segítő anyag. Ezzel a felhasználó gyorsabban tanul, teljesítménye jobb lesz, és ritkábban kér egyénileg a fejlesztőktől további segítséget, támogatást.

A segítő anyagok elkészítéséhez használható az ún. objektum-akció-felület modell (object-action interface model, OAI, Ben Shneiderman, Designing the User Interface, Third Edition. Addison-Wesley, 1998). Alapfogalmai a végrehajtási-értékelési ciklus, vagy Norman-féle kölcsönhatási modell elemeivel egyeznek meg. A szakmai feladatban, vagyis a valóságban van egy számos alapelemből álló valós rendszer. Az objektumok itt a rendszer, a részrendszerek, és az alapelemek. Az akciók itt a szakmai cél elérésére tett lépések, lépéssorozatok. A szakmai feladatot leképező FF-en (pl. GUI-n) pedig a valós rendszer, a részrendszerek, és az alapelemek helyett azok metaforái, azaz grafikai objektumok szerepelnek, a megfelelő akciók pedig a közvetlen dialógus akciói (kattintás, kettős kattintás, húzás, elengedés), ezek összessége pedig a végrehajtandó akciók terve.

Tankönyvre (bevezető vagy teljes) van szüksége annak a felhasználónak, aki semmit nem tud a FF-ről, és szakmai feladatának alapelemeit és lépéseit sem ismeri teljesen. Utóbbiak megismerése alapján sajátíthatja csak el a FF-et. Például ha egy ilyen felhasználó szövegszerkesztőben levelet szeretne írni, először meg kell tanulnia pl. az üdvözlések, vagy aláírások helyes használatát. Áttérési kézikönyvre van szüksége annak a felhasználónak, aki teljesen ismeri szakmai feladatának alapelemeit és lépéseit, de most új FF-et kapott, amely ugyanezeket képezi le. Az áttérési kézikönyvben le kell írni a régi és az új grafikai objektumok, metaforák, és akció-tervek közötti kapcsolatot. Példa: egy gépi szövegszerkesztésben már tapasztalt felhasználó új szövegszerkesztő programot kap. Gyors-referencia kártyákra vagy felhasználói kézikönyvre van szüksége annak a felhasználónak, aki mind a szakmai feladatot, mind a FF-et ismeri, de nem tud visszaemlékezni a tervhez szükséges akciókra, nem tudja pontosan, hogy hogyan fogalmazza meg a célját a FF-en megengedett akciók nyelvén.

A segítő anyagot készítő szerzőnek először a szakmai feladat és a FF technikai részleteiben kell elmélyülnie, majd foglalkoznia kell a felhasználó igényeivel is. Az anyagot az egyszerűtől a bonyolultabb fogalmak felé haladva kell felépíteni, elkerülve az anyagban előremutató hivatkozásokat. Először a szakmai feladat nyelvén (a valóságban) kell definiálni az új fogalmat, megadva bevezetésének értelmét, majd megadni megfelelőjét (pl. egy metaforát, vagy dialógus-akciót) a FF-en, végül pedig leírni a pontos megvalósítás módját a FF-en (a szintaxist). Fontos a leírás megfelelő, irodalmi értelemben vett stílusa, az adott nyelven (pl. angolul vagy magyarul). A tanulást könnyíti, ha a szöveges szakaszokat gyakran szakítják meg olyan gyakorlatok, amelyekkel a kezdő felhasználó azonnal kipróbálhatja, "dolgoztathatja" a FF-et. A gyakran előforduló, értelmes példák során szerzett gyakorlat a felhasználónak sokszor fontosabb, mintha egy hosszú tanító szöveget olvasna végig. Az ilyen példák az adott szakmai feladat végrehajtásának lépéseit részletezik, pl. a felhasználó kiválaszt egy adott menüpontot, utána kiválasztja a ....

Az ún. minimál-kézikönyvek (minimal manuals) a magyarázó szóáradat helyett a rendszer "kalauzolt felfedezésére" ösztönöznek. A GUI példa-képernyőkre rajzolt magyarázó ábrák segítik a felhasználó rendszerről alkotott belső mentális modelljének kialakulását. Hasonló hatást érnek el a menütérképek.

A segítő szövegben kerülni kell a számítógépet megszemélyesítő fogalmazást, pl. "A szakértő rendszer felfedezi Önnek a megoldást ha az F10 gombot megnyomja." Ez zavarja a felhasználót, és figyelmét elvonja. Helyette a felhasználóra és a szakmai feladatra koncentrálva kell fogalmazni, pl. "Ön megkapja a megoldást, ha megnyomja az F10 gombot". Későbbi fejezetekben alkalmazható egészen rövid fogalmazás is, pl. "A megoldáshoz nyomja meg az F10 gombot". Ez vonja el legkevésbé a felhasználó figyelmét a szakmai feladattól.

A felhasználói kézikönyv írásakor nagyon fontos, hogy elegendő munkatárs álljon rendelkezésre, akiket egy - szervezéshez értő - szakember irányít; valamint, hogy a munka során annak előrehaladását megfelelően ellenőrizzék: megvan-e egy-egy munkaszakasz lezárásához szükséges eredmény, melynek neve mérföldkő (milestone).

Az előbbieket összefoglalva a felhasználói kézikönyv írásának alapelvei a következők:

felépítése a szakmai feladatra alapuljon és vegye figyelembe a felhasználó tanulási folyamatát;

először a szakmai fogalmakat mutassa be, és csak utána a FF objektumait és akcióit;

a stílus tiszta és egyszerű legyen;

sok példát mutasson be;

legyenek értelmes és teljes példák, szakmai feladatok megoldási mintáiként;

mutasson kibontott menütérképeket;

helyenként rendszerezze és foglalja össze a felhasználó megszerzett tudását;

legyen benne tartalomjegyzék, tárgymutató, és fogalomjegyzék;

legyen benne az összes lehetséges hibaüzenetet felsoroló lista;

a minőséget növeli a hivatásos író segítsége;

korán kell elkezdeni az írását, lehetőleg már a tényleges programozás előtt;

a kéziratokat gondosan ellenőrizni: valódi cél-felhasználókkal is;

legyen lehetősége az olvasónak a visszajelzésre;

jelenjen meg új kiadás, ha a software-ben valami megváltozott.

Elektronikus (online) segítő anyagok készítése

Az online segítő anyagok előnye, hogy bármikor lehívható, nem vész el; ha a software változik, tartalma könnyen aktualizálható; nem foglal külön helyet a munkaasztalon; az elektronikus anyagban a keresés gyors, vázlatában könnyű a tájékozódás; továbbá alkalmazható a GUI, multimédia, vagy VR FF minden lehetősége. További előnyök:

hibaüzenetek magyarázata azonnali és bőséges;

dialógus közben azonnal megjelenik;

példát mutat a helyes bemenetre vagy parancs-szintaxisra;

megjeleníti a felhasználót segítő lehetőségek ikonjait.

Az online segítő anyagok hátránya, hogy a monitoron megjelenített információ gyakran gyengébben olvasható (okait l. fent), mint a nyomtatott anyag; a megjelenített információ sűrűsége kisebb, ráadásul új ablakok nyitása tovább csökkenti a helyet a monitoron; továbbá a kezdő felhasználónak meg kell tanulnia kezelni magának a segítő rendszernek a FF-ét is.

Online felhasználói kézikönyvek

Gyakran nagy a kísértés arra, hogy a nyomtatott kézikönyv anyagát közvetlenül online anyagként használják. A vizuális információ optimális elrendezése azonban más a papíron, és más a monitoron. Csak akkor várható elfogadható eredmény, ha minden oldal külön, jó minőségben ráfér egy képernyőre. Ha azonban a képernyő felbontása ekkor nem elég, akkor a felhasználó továbbra is a nyomtatott anyagot fogja előnyben részesíteni.

A következő elemek növelik az online felhasználói kézikönyv használhatóságát:

karakterfüzér keresés (string search);

részletes tárgymutató;

tartalomjegyzék;

sok ábra;

elektronikus könyvjelző;

megjegyzések készítésének lehetősége;

hivatkozások, hypertext;

a segítő dialógus történetének automatikus feljegyzése;

jól tervezett ablakozási formák;

a vizuális információ többféle kódolása (betűtípus, szín, vagy kiemelés);

multimédia: hang, kép, animáció.

Parancs-vezérelt dialógusnál érdemes a parancsokat értelmes kategóriákba sorolni, és kezdőknek egy külön listát készíteni az alap-parancsokkal. Sokat segít a gyorsbillentyűket (shortcut) leíró lista, továbbá az ún. helyérzékeny segítő (context-sensitive help). Utóbbi a dialógus éppen aktuális eleméhez jelenít meg segítő információt.

Online tankönyvek (tutorials)

Ezek kalauzolt minta-dialógusokkal vezetik be a kezdő felhasználót a FF kezelésébe. Gyakori formája az ún. "demo-lemez", amely egy új program sajátságait mutatja be, annak lehetséges jövőbeli felhasználóinak.

A felhasználó segítése. Ellenőrző kérdések

1. Írjon még 3 különböző fajta - a felhasználót segítő - nyomtatott anyagot: Rövid kezdő jegyzet (getting started notes),...,...,...,....

2. Melyek a segítő anyagok elektronikus változatai? Írjon 3-at.

3. Írjon két indokot, amiért a felhasználók még ma is szívesen használnak nyomtatott anyagokat.

4. Mi az objektum-akció-felület modell?

5. Milyen felhasználónak van szüksége a FF-et leíró (bevezető vagy teljes) tankönyvre (tutorial)?

6. Milyen felhasználónak van szüksége áttérési kézikönyvre (conversion manual)?

7. Milyen felhasználónak van szüksége gyors-referencia kártyákra vagy felhasználói kézikönyvre(user manual)?

8. Hogyan fogalmazzon a segítő anyag szerzője ahhoz, hogy ne vonja el a felhasználó figyelmét a szakmai feladattól?

9. Melyek a felhasználói kézikönyv írásának alapelvei? Írjon 4-et.

10. Mi az online segítő anyagok előnye? Írjon 3-at.

11. Mi az online segítő anyagok hátránya? Írjon 2-t.

A menü - dialógus

Menü-dialógusnál a FF opciók egy vagy több csoportját jeleníti meg, ezek közül a felhasználó kiválaszt egy vagy több opciót, és a rendszer végrehajtja a választott opciók által jelölt feladatokat (ISO 9241-14). A menü dialógus tervezésében a következő elemek fontosak:

Menü: opciók halmaza;

Menüpanel: a menüstruktúra felhasználó részére megjelenített része; példa: 3 menüpanel (A, B, és C) két teljes szinttel:

A                     B C 1. szint

A1                   B1 C1

A2                   B2 C2 2. szint

A3                   B3

B4

Menü-elérés: annak módszere, amivel a felhasználó kiválaszthat egy opciót:

kulcsszavak vagy parancsok bebillentyűzésével;

gombnyomással: számot, vagy kódot, utána néha "Enter" gombot is a kivitelezéshez;

funkcióbillentyűvel vagy gyorsbillentyűvel;

mutatóeszközzel (pl. egér);

jelzővel (marker), pl.

beszédhanggal.

Gyorsbillentyű: megjelenítés nélkül választható ki egy adott opció;

Menüpanel kaszkád: minden almenü a választott opció mellett jelenik meg a képernyőn, jelezve ezzel eredetét;

Kritikus opció: fontos opció, hatása nagyon jelentős a rendszerre vagy a szakmai feladatra; amellyel a rendszer romlását, vagy valamilyen katasztrófát (pl. tömeges törlés) lehet előidézni vagy megakadályozni;

Romboló opció: pl. file-törlés;

Hierarchikus menü: "fa"-struktúra;

Menüsor: vízszintesen megjelenített opciók, általában az I/O terület tetején. Ezek közül egyet kiválasztva menüpanel-kaszkádként almenü jelenik meg vagy közvetlenül egy adott akció kezdődik;

Menütérkép: a menüstruktúra grafikus átnézeti megjelenítése (segítő céllal);

Legördülő menüpanel (pull-down): a menüsor választott eleme alatt jelenik meg az almenü:

A                     B C

B1

B2

B3

B4

Előugró menüpanel (pop-up): adott objektum mellett jelenik meg, vagy a mutatóhelyőr (pointer) mellett, adott felhasználói akció hatására, pl. gombnyomás.

Menüstruktúra: az opciók kapcsolata, pl. hierarchikus ("fa-") struktúra;

Többszörös választás: a felhasználó egyszerre több opciót választhat ki;

Menü-navigáció: opcióról opcióra vagy menüpanelről menüpanelre történő mozgás a menüstruktúrán belül;

Menühálózat: a hierarchikus menütől eltérően itt az opciók csomópontokként, és az ezeket összekötő kapcsolatokként (link-ek) vannak elrendezve. Az opciók között redundáns elérési utak is vannak;

Opciójelölő: röviden jelöl egy opciót; lehet explicit, amely a jelölt opció előtt áll, pl. "P - print", vagy implicit, amely a jelölt opció részeként jelenik meg, pl. "print".

Menüstruktúra

A tervezés során felmerülő első kérdés: hierarchikus menüstruktúra esetén hogyan kell az opciókat csoportosítani, és menükbe, szintekbe szervezni? A következő elveket lehet alkalmazni:

Csoportosítás hagyományos vagy "természetes" kategóriák szerint, pl. zöldség-gyümölcs;

Logikai kategóriák, pl. objektumok és akciók: Alapelv: a szintek száma minimális, az opciók száma maximális legyen. Egy menü opcióinak száma a rendelkezésre álló területtől és az egyes opciók megkülönböztethetőségétől függ;

Tetszőleges kategóriák: következetesen szintenként 4-8 opciót, pl. betűrendben vagy sorszámozva;

Vizuális keresési idő minimális legyen, ehhez legfontosabb az opciók számának növelése, hogy egyszerre minél többet lásson a felhasználó. Görgető léc használata nem javasolt, mert megnöveli a keresési időt. A keresési idő optimális színhasználattal is csökkenthető.

Adott menüpanelen belül is érdemes az opciókat csoportosítani, ha lehetséges, akkor értelmes logikai csoportokat alkotva. Ha ez nem lehetséges, akkor ahány opció van, kb. ennek négyzetgyöke számú csoportot alkossunk az opciókból tetszőlegesen, pl. ha a menüpanelen 19 opció van, akkor legyenek 4-5 opcióból álló vizuálisan elkülönülő csoportok.

Az opciók sorrendbe helyezése a menün belül

A következő elveket lehet alkalmazni:

A sorrend következetessége, pl. mindig a következő sorrendet alkalmazzuk: "file, edit, insert, print"

Fontosság, pl. "save file" opció a menü elejére;

Konvencionális sorrend, pl. a hét napjai;

Szakmai feladatban megszokott sorrend, pl. üzleti év kezdete nem január, hanem július;

Használat természetes sorrendje, pl. először "copy", utána "paste";

Használat gyakorisága;

Ha a fentiek közül egyik sem alkalmazható, akkor betűrendbe kell helyezni az opciókat.

Menü-navigáció

Tájékoztató információ a menü-navigációhoz (navigational cues)

Hogyan könnyíthető meg a tájékozódás a menüstruktúrában? Az alábbi elvek növelik a menü-dialógus használhatóságát (különösen a tanulhatóság növekszik meg):

Jól megkülönböztethető, tömör (pl. parancsszavak), és összetehető feliratok. Az összetehetőség azt jelenti, hogy a menüsor-almenü-opció nevekből jól megjegyezhető lánc építhető fel, pl. "állatok/madarak/...";

A menüstruktúra számozása, pl. a felső szinten 1, utána 1.1, 1.1.1, 1.1.2,... Ezáltal a menüstruktúra a felhasználó számára nyilvánvaló lesz. A számokat egyszersmind az opciók billentyűkkel történő választására is lehet használni;

Egyéb vizuális kód is alkalmazható, pl. az egyes szinteken, vagy menükben különböző színek, vonaltípusok, betűtípusok;

Ha egyszerre jelenik meg több menüpanel, akkor azonnal látható legyen a panelek közötti viszony, pl. hierarchia - menüpanel-kaszkád;

Menütérkép megjelenítése, ez jelentősen megkönnyítheti a navigációt.

Gyors navigáció tervezési elvei

Elérési idő: minél hamarabb (lehetőleg 500ms-on belül) jelenjenek meg az opciók;

Menühálózat alkalmazása, kapcsolatokkal (link-ek) és többszörös opció-elérési utakkal;

A felhasználó képes legyen a hierarchiában bizonyos szinteket átugrani, pl. gyorsbillentyűkkel;

Visszatérési lehetőség a legfelső menühöz, pl a "home" billentyűvel;

A struktúrában felfelé mindig ugyanúgy, egyszerűen lehessen mozogni, pl. az "Esc" gombbal.

Meggondolandó, hogy egyes opciók többféle elérési útvonalon is elérhetők legyenek.

Az opciók választása és végrehajtása

Az opció-választás legjobb módszere általában függ az adott szakmai feladattól, a rendelkezésre álló bemeneti készüléktől, valamint a felhasználó egyéni adottságaitól, és preferenciájától. A következő elvek megkönnyítik a tervezést:

Több, alternatív opció-választási módszer rendelkezésre bocsátása, pl. az opciójelölő bebillentyűzése, vagy az opcióra kattintás az egérrel;

Ha a gyorsaság nem fontos, vagy kritikus opcióról van szó, akkor a választásra és a végrehajtásra legyen két különböző akció, pl. választás: mutatóhelyőrrel (pointerrel), végrehajtás: kattintással;

Gyors eléréshez két alapvető módszer használatos: A) közbeeső szinteket elkerülő mechanizmussal, pl. opciójelölők bebillentyűzése gyorsan egymás után, vagy az opció nevének leírása közben, amint egyértelművé válik; vagy B) választás és végrehajtás egyesítésével, pl. azonnal végre is hajtódik, amint az opciójelölőt bebillentyűzte, vagy csak az ALT együttes lenyomásakor hajtódik végre azonnal;

Nagyon fontos, hogy visszajelzés (feedback) mindig legyen, ennek módszerei:

legjobb a választott opció(k) kiemelése (highlighting);

a helyőr (cursor) kerüljön a választott opció mellé;

a választott opció mellett jelenjen meg egy jelző (marker), vagy színe változzon meg, különösen többszörös választásnál;

beszélt visszajelzés a választott opció hangos megismétlésével;

Mindig legyen lehetőség a választás megszűntetésére (deselecting) a végrehajtás előtt, és a végrehajtás után legyen visszaállítási funkció (undo);

6. Ha a választás után a gép 3s-nál tovább dolgozik, akkor erről jelenjen meg üzenet;

7. Többszörös választás esetén legyen lehetőség először minden választást és módosítást megtenni, és csak utána végrehajtani.

Alfanumerikus billentyűzet használata opció-választásra

Az alfanumerikus billentyűzet különösen akkor alkalmas opció-választásra, ha a felhasználó az I/O területen sok adatot visz be billentyűvel, és ezért ujjai már eleve ott vannak. A tervezés alapelvei a következők:

Leütések száma minimális legyen, erre valók az opciójelölők;

Az opcióválasztáshoz használt parancssor mindig ugyanott legyen a képernyőn;

Kis- és nagybetűk között ne legyen különbség;

Az opciójelölők legyenek egyértelműek;

Ne használjunk betűrend szerinti opciójelölőket, pl. helytelen: a=copy, b=print, helyes: c=copy, p=print;

Ha a FF-hez mind menü- mind parancsvezérelt dialógus csatlakozik, akkor az opciójelölők a parancsok rövidítései legyenek;

A gyorsbillentyűk egyezzenek meg a megfelelő opciójelölőkkel;

Az opciójelölők képzési szabálya általában is legyen egyszerű: az opció nevének első betűje, azonos első betűk esetén pl. a második betűje.

1-től (nem 0-tól) kezdődő számsort akkor használjunk explicit opciójelölőként, ha az opciók sorrendbe állítása fontos a szakmai feladatban, illetve akkor, ha az opció nevének betűi változnak, pl. aktuális file- vagy ablaknevek.

Funkcióbillentyűk használata opció-választásra

Nagyon gyakran használt menü-opciók választására érdemes funkcióbillentyűket (F1, F2, ...) használni. Ezeknél fontos, hogy a funkcióbillentyűk jelentése vagy mindig jelen legyen, vagy adott funkcióbillentyű (pl. F10) lenyomásakor jelenjen meg. Fontos a funkcióbillentyűk következetes használata, pl. F10 mindig a segítő (help).

Helyőrmozgató gomb (cursor key) használata opció-választásra

Ha a menüben 5-nél kevesebb opció van, akkor a helyőrmozgató ("nyíl") gombok lehetnek az opció-választás megfelelő eszközei.

Mutatóeszköz (pointing device) használata opció-választásra

Ez a módszer - különösen kezdő felhasználóknál - rövidíti a keresési időt. Fontos, hogy az opcióhoz tartozó mutatási terület elég nagy legyen a biztonságos rámutatáshoz és választáshoz. Általában min. 20-30 mm², de legalább kétszer akkora, mint a mutatóhelyőr területe. Utóbbiba csak a "nyíl feje" számít, "nyele" nem. További követelmény, hogy a billentyűzeten is legyen megfelelője a mutatóeszközzel történő opció-választásnak.

Beszédhang használata opció-választásra

Csak akkor használjuk, ha a beszédhang-felismerő rendszer megbízható. Az opciókhoz rendelt szavak fonetikailag különbözőek legyenek, és küszöböljük ki a környezeti zajt. Más beszédhangok ne keveredjenek bele, mert a beszédfelismerők a jel-zaj arányra nagyon érzékenyek.

A menü megjelenítése

Az opciók elérhetősége és megkülönböztethetősége

Erre a következő tervezési elvek vonatkoznak:

A kritikus opciók (pl. "undo") mindig megjelennek;

Gyakran használt opciók (alul a kontroll területen) mindig megjelennek;

Ritkán használt opciók kérésre jelennek meg, pl. előugró menüpanelen (pop-up menu);

Nem elérhető opciók megjelenítése: ha az opció a dialógus során később elérhetővé válik, meg lehet jeleníteni, valamilyen vizuális kóddal. Legjobb a szürke betűk használata, de a betűk színessége is változtatható;

Az alapértelmezett opcióra kerüljön a helyőr (cursor), vagy a kiemelés (highlighting). Mi legyen az alapértelmezett (default) opció-választás? A) a leggyakoribb opció (ha ismert), B) az első opció, C) a felhasználó által utoljára választott opció, D) a legkevésbé romboló hatású opció;

Látható legyen, ha az adott menüből többszörös választás (is) megengedett;

Az explicit opciójelölőknél ne keveredjen a kis- és nagybetű, pl. "Print" esetén helytelen: "Pr", helyes: "pr", vagy "PR";

Implicit opciójelölők vizuális kóddal különüljenek el az opciónév egyéb karaktereitől, pl. "restart" (az első betű az implicit opciójelölő);

Az opciók nevei

A gyors felismerés céljából a menü-opcióknak egyértelmű, ismert, tömör neveket kell adni, és azonos betűtípussal kell azokat megjeleníteni. A név megfogalmazása az opció (összetett) nevének legfontosabb szavával kezdődjék, pl. ha több "nyomtatási" opció is van, akkor "Dokumentum nyomtatása" a helyes. Fontos, hogy a név markánsan jellemezze az opcióhoz kapcsolódó szakmai feladatot, pl. helytelen az olyan általános elnevezés, mint "információ". Az opciók elnevezésénél is fontos a felhasználó szakmai nyelvét használni. Az akciók neve lehetőleg ige[4] (pl. töröl), az objektum neve lehetőleg főnév (pl. mappa) legyen. Akció-objektum típusú opcióknál ige-főnév kombinációt használunk . Ha a menü-dialógushoz parancs-vezérelt dialógus is kapcsolódik, akkor az opciók nevei a parancsokkal egyezzenek meg. Más opciókhoz vagy dialógusablakhoz vezető opcióknál ezt a név melletti jobbra mutató nyíl, három pont ("..."), vagy "menü" kiegészítés jelölje.

A menü - dialógus. Ellenőrző kérdések

1. Mi a hierarchikus menü és a menühálózat?

2. Melyek a menü-elérés módszerei? Írjon 4-et!

3. Mi a menütérkép?

4. Mi az opciójelölő?

Hierarchikus menüstruktúra esetén hogyan kell az opciókat csoportosítani, és menükbe, szintekbe szervezni? Írjon 3 elvet!

6. Hogyan kell az opciókat sorrendbe helyezni a menün belül? Írjon 4 elvet!

Hogyan könnyíthető meg a tájékozódás a menüstruktúrában? Írjon 4 elvet!

8. Melyek a gyors navigáció tervezési elvei? Írjon 3 elvet!

9. Milyen tervezési elvek vonatkoznak az opció-választásra? Írjon 4-et!

10. Opció-választáshoz melyek az alfanumerikus billentyűzet használatára vonatkozó tervezési elvek? Írjon 6-ot!

11. Hogyan kell a funkcióbillentyűket opció-választásra használni?

Hogyan kell a mutatóeszközt (pointing device) opció-választásra használni?

Hogyan kell a beszédhangot opció-választásra használni?

14. Írjon 6 tervezési elvet az opciók elérhetőségére és megkülönböztethetőségére!

15. Hogyan kell az opciók nevét megfogalmazni? Írjon 4 szempontot!

A parancs-vezérelt dialógus[6]

A parancs-vezérelt dialógusban a felhasználó - a menü-dialógussal ellentétben itt emlékezetéből felidézett - teljes vagy rövidített (pl. mnemonik, egyes betűk, funkciógombok, gyorsbillentyűk) parancs-kifejezéseket közöl a géppel. A parancs-kifejezések és paramétereik egy parancsnyelv szintaxisát követik. Itt is, mint minden dialógus-típusnál, fontos, hogy a FF tervezője ismerje a szakmai feladatot, és a tervezési elveket ennek alávetve alkalmazza.

A parancs-vezérelt dialógus tervezéséhez a következő fogalmak fontosak:

1. argumentum: a parancs-kifejezésben használt független változó, amely a parancs akcióját módosítja, vagy irányítja;
2. parancs: teljes szó, rövidítés, vagy szavak füzére (string), amely a rendszer, vagy alkalmazás valamely akcióját reprezentálja;
3. parancsnyelv parancsok halmaza + lehetséges kifejezések + struktúra = szintaxis;
4. parancssorozat: parancskifejezések egyszerre bevitt halmaza, egyenként történő közlés helyett;
5. parancs-kifejezés: parancs + elválasztók + argumentumok + paraméterek;
6. kulcsszó: a parancs-kifejezés legfontosabb szava, amely azt is megszabja, hogy milyen argumentumokkal együtt alkalmazható;

A parancs-vezérelt dialógus tervezése

A tervezés során fontos meghatározni azt, hogy a felhasználó mennyire szabadon kontrollálhatja a dialógust. Nem szabad a felhasználót rendszerre, vagy alkalmazásra tartozó részletekkel, továbbá állandóan informálni kell a munka folyamatáról, a rendszer állapotáról (l. a dialógus-elveket). Figyelni kell az információ megjelenítésének szabályaira, és a vizuálergonómiai elvekre.

A következő esetekben érdemes parancs-vezérelt dialógust használni:

1. A felhasználó

jó billentyűzési (gépelési) képességgel rendelkezik;

gyakran használja a rendszert, vagy alkalmazást;

a használat előtt tanulási, gyakorolási alkalommal rendelkezik;

jól ismeri a számítógépes technológiát és a parancsnyelveket.

2. A szakmai feladat

olyan, hogy nem lehetséges megjósolni a felhasználó által a dialógus során alkalmazott akciókat, illetve azok sorrendjét;

olyan, hogy a dialógusban az opciók, adatok bármilyen sorrendben következhetnek;

olyan, hogy szükség lehet speciális funkciók gyors elérésére;

olyan, hogy szükség lehet a dialógus lehetőségeinek kiterjesztésére, új parancsok hozzáadása által.

Struktúra és szintaxis

1. Azonos funkciójú parancsok neve legyen az egész alkalmazásban azonos; adott funkcióhoz ne legyen több, különböző nevű parancs;
2. A felhasználó tudjon makrókat készíteni a gyakran használt parancssorozatokhoz;
3. Nem jók a hosszú (8-nál hosszabb) argumentumlisták. Ha ilyenekre lenne szükség, akkor további parancsneveket kell képezni, vagy újabb, többfunkciós argumentumokat (paramétereket, vagy parancs-módosítókat) kell létrehozni, vagy csoportokra kell bontani az argumentumokat.
4. A parancs paraméterei ne változtassák meg túl erőteljesen a parancs funkcióját, pl. "Quit -c" = Quit-Cancel: kilépés mentés nélkül, helyette jobb az új parancs: "Cancel";
5. Fontos a parancsok egyszerű elválasztása a parancssorozaton belül, pl. üres karakterrel, vagy "/" jellel.
6. Amilyen mértékben lehetséges, a szintaxis kövesse a természetes nyelvet, illetve a felhasználó által ismert adatleírási módot;
7. Az argumentumok (paraméterek, vagy parancs-módosítók) néha jobb, ha teljes, értelmes szavak, a betűk helyett;
8. A parancs argumentumában sokszor jobb további kulcsszavakat használni, pl. "change shape=round colour=red size=4", "change round red 4" helyett;
9. Ne használjunk homályos értelmű kulcsszavakat, argumentumokat, pl. "kevés", "sok".

Parancsnevek

Fontos, hogy a felhasználó emlékezetében könnyen hozzá tudja kapcsolni a parancsnevet a funkciójához. Általában könnyen megjegyezhető felszólító módú igei alakot használjunk, amely illeszkedik a szakmai feladathoz, a felhasználó feltételezett korábbi tapasztalataihoz, és nyelvhasználatához. A parancsnevek legyenek egyértelműek, és jól megkülönböztethetők. Olyan parancsnevet kell használni, amelynek a természetes nyelvben viszonylag szűk, specifikus jelentésköre van, pl. "beszúr - töröl" (specifikus), "hozzáad - eltávolít" (általános). Csak néhány karakterben különböző, de nagyon eltérő jelentésű parancsneveket nem jó együtt alkalmazni, pl. az angolban "store" (tárol), "restore" (helyreállít). Ellentétes értelmű parancsnév párok jól megjegyezhetők, pl. olvas/ír, nyit/zár, igen/nem. Meggondolandó, hogy különböző felhasználói csoportoknak különböző parancsnév-készletek álljanak rendelkezésre. Általában érzelmileg neutrális parancsneveket használjunk, pl. az angolban a semleges "cancel"-t az érzelmileg negatív jelentéssel is bíró "abort" helyett. Ha a parancsneveket be kell billentyűzni, akkor a nevek ne legyenek 7 karakternél hosszabbak, kivéve, ha ezek sokkal jobban hangzanak, és könnyebben megjegyezhetők, mint a rövidített forma, pl. az angol "allocate". Ne használjunk felesleges igekötőket, ragokat, és képzőket, pl. az angolban helyesebb a "delete", a "deleting" helyett.

Parancsnevek rövidítései

A használhatóságot növeli, ha a felhasználó a parancsnevek rövidítéseit is beírhatja. Ugyanakkor jó, ha végrehajtás közben megjelenik a teljes parancsnév, különösen a tanulási fázisban. A rövidítésnek minél egyszerűbb szabálya legyen, amely minden kulcsszóra és minden rövidíthető argumentumra vonatkozzon, pl. első két karakter: print->pr, vagy magánhangzók kihagyása: print->prnt, vagy a parancsnév végéről annyi karakter hagyható el, amennyi még egyértelművé teszi a parancsnevet.

Bemenet és kimenet

Legyen lehetőség parancssorozatok alkotására, és ezeket újra fel lehessen használni, mindig legyen egy lista a korábban használt parancsokról. A rendszer, vagy alkalmazás - rákérdezés után - fogadja el a kis helyesírási hibával beírt parancsokat is. A kulcsszavak önmagukban állva jelentsenek valamilyen alapértelmezett, gyakran használt argumentum-kombinációt. Ez nagyban hozzájárul a tanulhatósághoz. Miután a felhasználó az önmagában álló, alapértelmezett kulcsszót megtanulta használni, képessé válik a paraméterek használatának elsajátítására is. Súlyos következményekkel járó parancsoknál (pl. törlés) az alkalmazás kérjen megerősítést, vagy ha lehet, legyen visszaállítási funkció (undo). A testre szabhatóság teljesül, ha a felhasználó a felkínált parancsnevek helyett azok szinonímáit is definiálhatja, és később bármikor visszatérhet az alapértelmezett parancsnév-készlethez. Fontos, hogy a beírt parancsok azonnal jelenjenek meg a képernyőn. A parancskifejezésben legyen lehetőség a kimenet átirányítására, megszakítására, vagy leállítására.

A parancs-vezérelt dialógus. Ellenőrző kérdések

1. Milyen esetekben érdemes parancs-vezérelt dialógust használni?

2. Írjon 3 tervezési elvet a parancs-kifejezések struktúrájára és szintaxisára!

3. Milyen szabályok vonatkoznak a parancsnevek képzésére? Írjon 4-et!

4. Hogyan kell a parancsneveket rövidíteni?

A közvetlen dialógus[7]

A közvetlen dialógusban a felhasználó vizuális visszacsatolással közvetlenül hat a megjelenített objektumokra; például mutatóeszközzel rámutat, mozgatja azokat, vagy megjelenésüket változtatja meg. A megjelenített objektumok a software reprezentációi a FF-en, lehetnek 1. a szakmai feladat metaforái (pl. toll, papírlap, elektronikus alkatrészek, kapcsolási rajz.); vagy 2. a FF használatát lehetővé tevő (adminisztrációs) kezelőelemek (gomb, csúszka, ablak, ikon.). A GUI fogalma tágabb, mint a közvetlen dialógusé, a GUI-n belül ugyanis a közvetlen dialóguson kívül szerepel még a menü és a parancs-vezérelt dialógus is. Megjegyzendő, hogy a közvetlen dialógus nem minden feladatra a leghatékonyabb típus, pl. ha minden, "d"-vel kezdődő file-t le szeretnénk törölni, akkor érdemes menü-dialógusban név szerint rendezett megjelenítést választani, és utána törölni.

A következő esetekben érdemes közvetlen dialógust használni:

1. A felhasználó

nem képes elég jól írni/olvasni, de a közvetlen dialógushoz szükséges szenzoros-motoros képességei tökéletesek, pl. gyermekek;

teljesítményét a megjelenített metaforák növelik, mert elősegítik jelenésük felidézését;

teljesítménye grafikus objektumokkal jobb, mint szöveggel.

2. A szakmai feladat

objektumaihoz könnyű jó metaforákat találni;

objektumait és akcióit nehéz szöveggel kifejezni, pl. egy metaforára mutatni sokkal egyszerűbb, mint a metaforát leírni;

részfeladatainak sorrendje nem rögzített és rugalmasságra van szükség a végrehajtáshoz;

végrehajtása közben nagyfokú ellenőrizhetőségre van szükség;

szükséges bementét nehéz leírni (pl. parancsok), de könnyű metaforákkal megjeleníteni;

az egyes szakmai feladatokat önmagukban általában ritkán fordulnak elő.

3. A rendszerben

a képmegjelenítő és a mutatóeszköz felbontása nagy;

a grafikai objektumok gyorsan megjeleníthetők és a rendszer képes gyorsan visszajelezni a felhasználói akciókat.

A dialógus-típusok közül a közvetlen dialógus használja ki leginkább az emberi vizuális rendszer gyors, párhuzamos feldolgozási képességét. Ehhez fontos a felhasználói akciók azonnali visszajelzése, pl. a vizuális objektumok folyamatosan mozognak, színük, formájuk azonnal változik.

Metaforák

A metaforákat úgy kell megtervezni, hogy a felhasználó benyomása az legyen, hogy magán a szakterületen dolgozik. Segítségükkel képes legyen belemerülni szakmai feladatába. Sokszor a korábbi valós feladatok megoldási sorrendjének átvétele nem célravezető, mert a jó FF közvetlen dialógussal ennél hatékonyabb módszert kínál, pl. a keresés egy elektronikus könyvben sokkal könnyebb egy-egy kulcsszóra való kattintással. A jól tervezett metafora megkönnyíti a mentális modell felépítését, ezáltal a felhasználó hamar megérti a rendszert, könnyen tervezi és hajtja végre akcióit. A következő elvek vonatkoznak a metaforák választására, tervezésére:

Minden metafora illeszkedjék bele egy keretbe, pl. egy szoba tárgyai és nyitott ajtaja jelzi, hogy a felhasználó elérheti ezeket az elemeket; vagy a dokumentum ikonja a nyomtató ikonjához mozog, és nyomtatás közben a nyomtató ikonja a papír kijövetelét szimulálva folyamatosan változik;

Fontos, hogy a metaforát megjelenítő objektum (pl. ikon) jól felismerhető legyen;

Ha egy metafora a rendszer valamelyik részében nem alkalmazható, ezt a FF jelezze a felhasználó felé. Ha a metafora a felhasználót korlátozott alkalmazhatósága miatt összezavarná, akkor használatát el kell kerülni, pl. munkaasztal metaforánál a nem mozgatható akció-gombok be vannak keretezve; vagy egy alkalmazás "kidobásánál" jeleznie kell a FF-nek, hogy az alkalmazástól végleg megszabadulni csak az összes alkotóelem törlésével ("deinstalláció"-val) lehet, ellentétben pl. egy dokumentummal, amit egyszerűen ki lehet dobni.

A következő elvek pedig a metaforákat megjelenítő grafikai objektumok - ikonok, gombok és mutatóhelyőrök (pointer-ek) - tervezésére vonatkoznak:

A mutatható és választható területek legyenek elég nagyok a mutatóhelyőr (pointer) méretéhez képest (általában min. 20-30 mm², de legalább kétszer akkora, mint a mutatóhelyőr területe, l. "A menü - dialógus");

A megjelenítendő objektumokat vizuálisan úgy kell tervezni, hogy látszódjék, milyen FF-akciók alkalmazhatók rájuk, pl. állandók vagy változtathatók (közvetlenül manipulálhatók), pl. a mutatóhelyőr átalakul, ha a szöveg változtatható, vagy a grafikai objektum kontrollhelyére (handle) érve, a mutatóhelyőr alakja az objektum tulajdonságait jelzi;

Adott pillanatban nem elérhető grafikai objektumok lehetőleg maradjanak láthatók a képernyőn. Más dialógus-típusokban (pl. menü-dialógus) is erre használt vizuális kód jelezze a nem-elérhetőséget, pl. a papír nélküli nyomtató ikonja szürke, vagy az éppen kiválasztott objektumhoz tartozó gombok is szürkék;

Kevéssé fontos grafikai objektumok eltakarhatók más ablakokkal, teljesen elrejthetők, vagy a képernyő szélére helyezhetők, de állapota ne változzon, amíg nem érkezik rá vonatkozó felhasználói akció, és ha mégis ismét fontossá válnak, akkor legyen valamilyen lehetőség az elérésére.

Ha túl sok, és/vagy túl nagy méretű grafikai objektumot kellene adott helyen egyszerre megjeleníteni, akkor a felhasználó választhasson egy másik megjelenítési módot, pl. nagy ikonok helyett apró ikonok és szöveg.

Visszajelzés

A közvetlen dialógusnál különösen fontos az azonnali és folyamatos vizuális és egyéb visszajelzés. Ennek tervezési elvei a következők:

1. A közvetlen dialógus típusát jelző különféle mutatóhelyőr(pointer)-fajták, pl.:
• rámutatást (pointing) egy nyíl jelez;
• egyetlen objektum mozgatását egy apró objektummal ellátott nyíl jelzi;
• több objektum mozgatását apró objektumok halmazával ellátott nyíl jelzi;
• átméretezést kettős végű nyíl jelez;
• a rajzolást "ceruza"-metafora jelzi;
• hipertext hivatkozásra való ugrást vízszintes nyíl jelzi.
2. A mutatóhelyőr fajtája jelzi, ha a közvetlen dialógus adott objektumon nem elvégezhető, pl.:
• a mutatóhelyőr "órává" alakul, amíg az alkalmazás dolgozik;
• grafikai objektum húzásakor (drag) a mutatóhelyőr "tiltó jellé" változik, ahol az objektumot nem lehet letenni.
3. Ha közvetlen dialógussal nem bevihető adatokra van szükség, akkor az alkalmazás kezdjen kitöltés-dialógust, alapértelmezett értékekkel, pl. miután a felhasználó egy objektumot a nyomtató ikonjára ejtett, az alkalmazás kéri a példányszámot, a kiválasztott oldalakat.
4. Folyamatos visszajelzésre példa: a mozgatott grafikai objektum, vagy annak egyszerűsített változata (körvonalai) folyamatosan mozognak, ahogyan a felhasználó a mutatóeszközt mozgatja.
5. Azonnali visszajelzésre példa: amint a felhasználó kiválasztott egy dokumentum ikont, az azonnal kiemelődik (higlighting), és amint a felhasználó törli, eltűnik.
6. Azonnali és folyamatos visszajelzésre példa: ha a mutatóhelyőrt (pointer-t) a felhasználó nyomógomb felett mozgatja, akkor a nyomógomb körül keret jelenik meg, amely jelzi, hogy ez a terület érzékeny a bemenetre (bementre érzékeny terület=input sensitive area). Amint a felhasználó kiválasztó akciót (kattintást) tesz, a nyomógomb vizuálisan azonnal kiemelődik (highlighting), hogy visszajelezze a kiválasztást. Ha a mutatóhelyőrt a felhasználó elviszi a nyomógomb felületéről, miközben nyomva tartja az egérgombot, akkor a kiemelés és a keret eltűnik, azonnal jelezvén, hogy a kiválasztást a felhasználó törölte. Ha a felhasználó az egérgombot a nyomógomb felett elengedi, akkor a kiemelt gombfelületet az alkalmazás kétszer villogtatja (blinking), jelezvén a felhasználónak, hogy az alkalmazás elkezdte az akció végrehajtását.
7. Újonnan létrehozott vagy megnyitott objektumok általában az előtérben jelenjenek meg, pl. újonnan megnyitott ablakok.

Bemeneti készülékek (input devices)

A közvetlen dialógus tervezésekor az ismert bemeneti készülékek közül egyet vagy többet ki kell választani. Gyakran érdemes több bemeneti készüléket használni egyszerre, pl. egy objektum nagy távolságon történő húzásához egeret, finom pozicionálásához "nyíl" billentyűket. Bizonyos felhasználóknak nehézséget okozhat a mutatóeszközök használata, ehelyett nekik mindig álljon rendelkezésre a billentyűzet, pl. a dokumentum megnyitásához a "tab" billentyűvel lehessen azt elérni, és utána az "Enter"-rel megnyitni. fontos, hogy a felhasználónak ne kelljen a különböző bemeneti készülékeket gyakran cserélnie, pl. kitöltés-dialógusnál továbblépésnél egérkattintás helyett "tab" billentyűvel haladhasson tovább.

A közvetlen dialógus. Ellenőrző kérdések

1. Mi a különbség a GUI és a közvetlen dialógus között?

2. Milyen esetekben érdemes közvetlen dialógust használni? Írjon 5-öt!

3. Milyen elvek vonatkoznak a metaforák választására, tervezésére? Írjon 3-at, és összesen 2 példát!

4. Melyek a grafikai objektumok - ikonok, gombok és mutatóhelyőrök (pointer-ek) - tervezési elvei? Írjon 3-at!

5. Melyek az azonnali és folyamatos visszajelzés tervezési elvei? Írjon 3-at!

6. Írjon egy példát azonnali és folyamatos visszajelzésre!

Fogalmak

Rövidítések

FF = felhasználói felület

GUI = grafikus felhasználói felület, graphical user interface

HMD = fejre szerelt képmegjelenítő, Head Mounted Display

OAI = objektum-akció-felület modell, object-action interface model

VR = virtuális valóság, virtual reality

WIMP = windows-icons-menus-pointers

Irodalomjegyzék

1. ISO 9241 International Standard, Ergonomic requirements for office work with visual display terminals (VDTs), Parts 10-17.

2. Ben Shneiderman, Designing the User Interface, Third Edition. Addison-Wesley, 1998.

3. Handbook of Human-Computer Interaction, 2^nd Ed., Elsevier, 1997.

4. Alan J. Dix, Janet E. Finlay, Gregory D. Abowd, Russell Beale, Human-Computer Interaction, Second Ed., Prentice Hall Europe, 1998.

5. Jakob Nielsen (Ed) and Robert L. Mack (Ed):        Usability Inspection Methods, Wiley 1994.

6. Krammer Gergely, ELTE TTK Szofverergonómia előadás, https://valerie.inf.elte.hu/~krammer/eltettk/szofterg/szergelo.html

7. Duffy T., Palmer J., and Mehlenbacher B., Online Help Systems: Theory and Practice, Ablex, Norwood, NJ, 1992