Informatika | Ergonómia » Kiss Balázs - Szoftver-ergonómia a szoftverfejlesztő szemszögéből

Szoftver-ergonómia a szoftverfejlesztő szemszögéből Budapest, 1998. november 15 Írta: Kiss Balázs NMIT II/16 Tartalomjegyzék 1 Mi is a szoftver-ergonómia? 3 2 A szoftver-ergonómia alapvető kérdései 3 3 Az ember mint alrendszer 4 3.1 Az emberi gondolkodás 4 3.2 A mentális igénybevétel 5 4 Szoftver-ergonómia a szoftver életciklus modellben 6 4.1 Tervezés-előkészítés, specifikáció 7 4.2 Tervezés, design 8 4.3 Tesztelés és verifikáció 8 4.4 Kódolás 8 4.5 Marketing 8 4.6 Újrahasznosítás

vagy packaging fázis 8 5 Hasznos tanácsok a szoftver felhasználói felületével kapcsolatban 9 5.1 Általános irányelvek 9 5.2 Az interakció 10 5.21 5.22 5.23 5.24 5.25 6 Választás menüből 10 Űrlapkitöltés 10 Parancseditor 10 Közvetlen manipuláció, Drag-and-Drop 11 “Emberközeli” interakció 11 Irodalomjegyzék 11 2 1 MI IS A SZOFTVER-ERGONÓMIA? Napjaink gazdaságának két leggyakoribb kérdése a gazdaságosság és a hatékonyság. Minden vállalat, vállalkozás, vagy bármi más profitorientált egység a legfelső vezetői

szinten a maximális profit elérésére törekszik, vagyis az időegység alatt előállított termékek utáni bevétel és a termék megtermelési költsége közti különbséget próbálja meg maximalizálni. A profitmaximalizálás hatékony eszköze a hatékonyság növelése. A hatékonyság általában az alacsonyabb vezetői szintek hatásköre alá tartozik, és annál nagyobb, minél kevesebb ráfordítási költséggel termelhető ki ugyanaz a termékmennyiség. A laikus számára e kettő ugyanannak tűnhet, és az esetek többségében a hatékonyság növelése a profit növekedését is vonja maga után. Napjainkban a munkahelyek igen nagy – és egyre növekvő – részében használnak számítógépet. Mint említettük, a profit nagysága erősen függ a hatékonyságtól – ami azt is jelenti, hogy a számítógéppel végzett munkák hatékonysága napjainkban egyre jelentősebb kérdéssé válik. Hogy mennyire hatékonyan is tudja a munkáját végezni egy

dolgozó egy számítógéppel kapcsolatban, azt alapvetően három dolog befolyásolja. Az első – és igen fontos – ilyen dolog a számítógép funkciójának megtervezése a termék előállításának folyamatában. Ez a szemlélet az egész gyártási folyamatot tekinti, a munkafázisokkal, termékspecifikációkkal, a gyártásban szereplő összes emberrel és az információs rendszerrel együtt. Ezt hívják rendszerelméletnek, vagy informatikának (Itt jegyzem meg, hogy az Informatika szó igen tág értelemben használható, és mindenki, aki kapcsolatba kerül vele, általában saját informatika-képet alakít ki magában.) A másik jelentős – de nem annyira kézenfekvő – befolyásoló tényező a számítógépet használó ember(ek) egymáshoz való társadalmi, szociális viszonya. Első látásra ez nem tűnik jelentősnek, de találkozhatunk sok olyan esettel találkoztam, amikor a számítógépet használó ember azért nem tudta normálisan végezni a

munkáját, mert félt, hogy a munkatársai, főnöke úgy találja róla, hogy nem ért a számítógépekhez, ezért lenézi, és ez olyan stresszt váltott ki, ami akadályozta mind az illető alkalmazkodási folyamatát a számítógéphez, mind a hatékony munkavégzését. Ezt a területet nevezik számítógépes szociológiának. Harmadszor – és nem utolsósorban – meghatározó tényezője a hatékonyságnak az ember-gép kapcsolat minősége. A számítógép és az ember kapcsolata, kommunikációja egészen sajátos, egészen más, mint az ember – ember kapcsolat. Megvizsgálva azt a speciális esetet, amikor két ember kommunikál számítógépes felületeken keresztül (erről a témáról is sok esettanulmány készült már), lemérhetjük, hogy a számítógép be- és kiviteli eszközei mennyiben szűkítik le az információ áramlási csatornáját. Ezenkívül figyelembe kell vennünk, hogy a gép nem ember: lehetőségei, tudása sokkal korlátozottabbak

egy emberénél. Ennek a gép-ember kapcsolatnak a hardware részével foglalkozik a hardware-ergonómia, valamint a szoftverrel megoldható, jobbá tehető részével a szoftver-ergonómia. 2 A SZOFTVER-ERGONÓMIA ALAPVETÔ KÉRDÉSEI 3 A számítógépek elterjedése szükségszerűen a felhasználók körének bővülését vonja maga után. A felhasználók számának bővülése pedig azt is jelenti, hogy relatíve egyre kevesebb lesz az olyan felhasználó, aki valójában ért is a számítógépekhez, és egyre több az olyan, aki egyáltalán nem ismeri a számítógépek működési elveit. A számítógépek fejlődése során már eddig is megfigyelhettük a felhasználói felületek a fejlődését. Eleinte, mikor a gépek még kísérleti alkalmazásban szerepeltek, a gépek lehetőségei voltak az elsődleges meghatározó tényezők. Később, mikor a gépek minél hatékonyabb programozása volt a cél, a programozók a saját igényeikhez igazították a

felhasználói felületeket. Manapság már a szoftverek leendő felhasználóinak igényeihez kell méretezni a szoftverek felhasználói felületét. Manapság a felhasználókat alapvetően háromféle csoportba sorolhatjuk. Az első csoport továbbra is a szakemberek csoportja. Ők ismerik a számítógépek működését, profik azok használatában, és gyors funkcionalitást várnak el a számítógéptől. A második csoportba azok tartoznak, akik rendszeresen használják a munkahelyükön a számítógépet, de nem szakemberek. Ők olyan funkciókat várnak, amikhez a legkevesebb számítástechnikai ismeretet kell elsajátítaniuk, és maximálisan támogatja őket a munkában. A harmadik csoport az eseti felhasználók köre: ők csak ritkán kerülnek kapcsolatba a számítógéppel, és csak nagyon hiányos ismereteik vannak róluk. Számukra kell a legemberközelibb rendszereket építeni Mint láthatjuk, a felhasználók kiléte alapvetően befolyásolja a szoftver

arculatát. A leendő felhasználót mindig meg kell ismerni, esetleg különféle módszerekkel “modellezni” kell a szoftver fejlesztése előtt és közben. Nem “bolondbiztos” szoftvert kell tervezni, mert a felhasználó nem bolond; hacsak nem a bolondok házába tervezünk szoftvert. Az ember-gép kapcsolat emberi oldalának szentelem a következő fejezetet Az informatikusok, programtervezők feladata az ember-gép kapcsolat állandó figyelemmel kísérése a szoftvertervezési és –fejlesztési folyamatok során. Hogy hogyan illeszthető be a szoftvertervezés lépései közé a szoftver-ergonómia, azt a negyedik fejezetben fejtem ki részletesen. Sok mindent megemlítettem az eddigiekben, a szoftver-ergonómiával kapcsolatban. Szóltam arról, hogy mi ez, mivel áll kapcsolatban, a részeiről, sőt, még arról is, hogy mikor kell alkalmazni. De ha mindemellé nem társul gyakorlat, módszerek, akkor mindez csak öncélú fecsegés. Éppen ezért gyakorlati

tanácsokkal is szolgálok az utolsó fejezetben a felhasználói felületek tervezéséről. 3 AZ EMBER MINT ALRENDSZER Mint láthattuk, az ember – gép rendszert tekintve az ember az, akin nem tudunk változtatni. A gépet felszerelhetjük színes monitorral, illeszthetünk hozzá egeret, vagy akár megváltoztathatjuk a rajta futó szoftvert. De az emberek – bár taníthatók, így ismeretanyaguk, rutinjuk növelhető – alapvetően ugyanolyanok maradnak. Éppen ezért foglalkoznunk kell azokkal az emberi tulajdonságokkal, amik az ember kommunikációját a számítógéppel alapvetően befolyásolják. 3.1 Az emberi gondolkodás 4 Az ember – mint a számítógép is – tekinthető egy információ-feldolgozó rendszernek. Valamilyen információkat kap – esetünkben a számítógéptől – aztán ezt az információt először is eltárolja, másodszor valamilyen reakciót vált ki belőle. Az információt először is meg kell látnia az embernek. Ha eljutott a

szenzorokig, akkor fel kell ismernie. Csak ezután beszélhetünk tényleges információról Jó példa erre a különbségre az alvó ember hallása: álmunkban is halljuk a körülöttünk levő hangokat, de nem ismerjük fel őket, ezért nem jelentenek információt számunkra. A felismert információ először is a rövidtávú memóriába kerül. Ez minden ember esetében igaz, embertől függetlenül öt-kilenc gondolati elem tárolására képes, és másodpercek alatt törlődik. Az emberi agy hosszútávú– vagy munkamemóriája alapvetően asszociatív szervezésű. Ez azt jelenti, hogy könnyen elő tud hívni olyan dolgokat, amiket tud kapcsolni valamihez, de az értelem nélküli adatokat nem tudja tárolni. A kapacitása viszont elvileg végtelen, de egyes részei az idők során nehezebben hozzáférhetővé válnak: amit nem használ az ember, azt fel kell frissítenie. A hosszútávú memória része az a rész is, amiben a begyakorlott, szenzomotoros

készségeket tárolja az agy. Ezeket a készségeket el lehet felejteni, de kis gyakorlással újra elő lehet őket idézni. Az ember reakcióinak egy része tudatos, más része tudat alatti. Begyakorolt dolgokra az embernek nem kell koncentrálnia: például én ebben a szövegszerkesztőben úgy tudok szövegrészeket kivágni, és beilleszteni, hogy erre nem kell odafigyelnem. Bonyolultabb dolgok lassabban válnak ilyenné, illetve egy bonyolultsági foktól kezdve mindig gondolkodással járnak. A tudatos cselekvések vagy egyszerű, de a nem begyakorolt dolgok, vagy bonyolult következtetéseket igénylő folyamatok. Ezek a leglassabb reakciókat eredményező folyamatok, de a legszélesebb hatáskörűek is. 3.2 A mentális igénybevétel A munka – és főképp a számítógépekkel végzett munka – nem csak fizikai, hanem mentális megterheléssel (stress) is jár. Ez a megterhelés – a nagyságától függően – bizonyos mennyiségű igénybevételt (strain) okoz a

dolgozón. Ha ez az igénybevétel egy bizonyos határt átlép, akkor az az illető elfáradásával (fatigue) jár együtt, ami a teljesítményének csökkenését vonja maga után. Ha viszont a dolgozót túl kevés pszichológiai inger éri, akkor könnyen a monotónia állapotába kerülhet, ami szintén teljesítménycsökkenéssel, reakcióidő-növekedéssel jár. Mint láthatjuk, a stressz szintje mint egy motiváció hat a dolgozóra. Ha túl alacsony, akkor a dolgozó nincs megfelelően motiválva a munkára, így nem bírja az lekötni, és csökken a teljesítménye. A megfelelő stressz a feladatra hangolja a dolgozót, így a feladatnak szenteli a teljes kapacitását. Ha túl magas a stressz, akkor eleinte csak túlterheli a dolgozót, aki így kénytelen azokat a dolgokat, amik nem annyira fontosak, mellőzni. Ez a fajta túlterhelés a tévedések valószínűségét is erősen megnöveli Ha nagyon megnöveljük a dolgozót érő stresszt, akkor az pánikba esik, és

teljesen alkalmatlan lesz a feladata ellátására. Jó példa erre az egyetemi tanulók vizsgaidőszaki viselkedése. Ha az illető nem kap elég ösztönzést, nem tudja, hogy mit nem tud, akkor hajlamos ellógni az idejét. Ilyenek azok az emberek is, akikben egyáltalán nincs vizsgadrukk. Ha a tanuló 5 megfelelőképpen tart a vizsgájától (bejárt az órákra, és tudja, mit kell megtanulnia), akkor megfelelő időt fog az anyaggal tölteni, és megfelelő mennyiséget fog tudni. Ha túl szorosan vannak valakinek a vizsgái, akkor a kevésbé fontosakat (amiknek a határideje nem szorít, pl. féléves dolgozatok) elhalasztja, és minden erejével a fontosabb dolgokra fog koncentrálni. Ha a diák úgy érzi, hogy semmit sem tud, és másnap lesz a vizsga, akkor beijed, és másnap tényleg nem fog tudni semmit. Itt jegyzem meg, hogy a visszajelzések döntő fontosságúak a félelmi stressz kialakulásában. Ha a diák jó jegyeket kap a tudására, akkor nem fog félni

a vizsgáitól, hiába van azokra kevés ideje. Ha viszont kevés ideje van, és még – mondjuk – meg is bukott abból a tárgyból már egyszer, akkor sokkal könnyebben alakul ki benne félelmi stressz. Az, hogy egy adott feladat mennyire veszi igénybe az adott embert, előre nem látható. Ezt viszont le lehet mérni többféleképpen is Először is, meg lehet vizsgálni egy kísérleti személy teljesítményét. Ebből kiszűrhető, hogy mekkora terhelés számára az optimális, viszont esetleg más embereknél ez az adat változhat. Meg lehet azt is tenni, hogy a személyre rábíznak egy másodlagos feladatot is, amit akkor kell csinálnia, mikor az elsődlegessel éppen nincs munkája. Ebből lemérhető, hogy milyen terhelés mellett foglalkozik száz százalékosan az elsődleges feladattal. A probléma ezzel a módszerrel csak az, hogy nehéz olyan másodlagos feladatot találni, ami pont ugyanazokat a képességeket igényli, mint az elsődleges, és nem túl nehéz

rá az áttérés. Ezenkívül megkérdezhetjük a célszemélyt is, hogy milyennek találta a feladat nehézségét, valamint megfigyelhetjük a személyt. Ezekkel a módszerekkel csak az a probléma, hogy nem elég pontosak. A legmodernebb módszerek a fáradságot mérik, vagy pszihofizikai, vagy pszihofiziológiai módszerekkel. Az előbbivel a fáradás fizikai hatásait tudják lemérni (pl reakcióidő csökkenés), az utóbbival a fiziológiaiakat, mint például pulzusszám vagy percenkénti pislogásszám. 4 SZOFTVER-ERGONÓMIA A SZOFTVER ÉLETCIKLUS MODELLBEN A szoftvert annál nehezebb és költségesebb megváltoztatni, minél előrébb jár az életciklusában. Egy ergonómiailag rosszul tervezett szoftver viszont ugyanúgy eladhatatlan, mint egy funkcióiban rosszul működő, vagy egy túlzott hardverigényű. Ebből következik, hogy a szoftver ergonómiai oldalát minél előbb bele kell tervezni a szoftverbe, egyszerűen azért, mert később ugyanaz többe

kerül. Viszont a dolog nem mindig ilyen egyszerű: éppen a megterheltségmérés példáján láthattuk, hogy egyes lépéseket nem lehet elvégezni, mielőtt a szoftver el nem ér egy bizonyos fejlettségi szintet. Éppen ezért nagyon oda kell figyelnünk, hogy a megfelelő intézkedéseket a megfelelő időben tegyük meg a szoftver életciklusa folyamán. A szoftver hagyományos életciklusa a következő lépésekből áll:  A szoftver életciklusa a specifikációval kezdődik. Itt tisztázódik, hogy mi is az, amit meg kell építeni.  A második nagy lépés a tervezési fázis: itt dől el, hogy hogyan is fogja megvalósítani a specifikációban megadott szoftvert a programozó team. 6  A harmadik lépés a tesztelés és a verifikáció lépése. Itt még végezhetők korrekciók a szoftverben.  A negyedik hagyományos lépés a programozás. Ez a terv manuális leképezését fedi a kódra. A kód általában részekben készül, és a megvalósítás

utolsó fázisában történik az integrálása. Ebben a fázisban már csak apróbb változtatások, kalibrálások lehetségesek, amik a szoftver lényegét nem változtatják meg.  Az ötödik lépés a szoftverkarbantartás. Sajnos ma még ott tartunk a szoftverekkel kapcsolatban, ahol száz évvel ezelőtt az autókkal. Ugyanis akkoriban volt az, hogy az autóhoz szerelő és sofőr kellett, mert leállt minden tíz kilométeren. Így ma minden szoftvercégnek szüksége van “szerelőkre” és “sofőrökre” (be kell tanítani a szoftverfelhasználókat). Mivel a szoftver is termék, ezt az életciklus-modellt ki kell még egészítenünk a termék-életciklus modellből ismert lépésekkel. Ilyenek a Tervezés-előkészítés, valamint a marketing a gyártás után, és az újrahasznosítás az eladás után. Ez utóbbi elég furcsán hangzik szoftverek esetében, de be kell látnunk, hogy jelentôs dolog: ha már volt egy sikeres termékünk, miért ne

hasznosíthatnánk azokat a részeit, amik még jók, egy másik termékben, vagy egy újabb verzióban? Még annak is van értelme, hogy “környezetbarátra” kell terveznünk a terméket, hiszen már a tervezésnél lehet ügyelni arra, hogy a kód később újrafelhasználható legyen. Megjegyzendő még, hogy egyes szoftvertervezési módszertanok nem pontosan ezeket az életciklus-lépéseket tartalmazzák, de ettől most eltekintünk. Ezután a kitérő után lássuk, hogy az életciklus mely lépésében mit tehetünk a szoftver ergonómiájának javításáért! 4.1 Tervezés-előkészítés, Specifikáció A szoftver életciklusa tipikusan egy ötlettel kezdődik. Lehet, hogy az az ötlet nem egészen eredeti, ekkor lopásnak hívjuk. De ez, mint látni fogjuk, a szoftverek esetében nem szokatlan. Gondoljunk csak arra az esetre, ha egy cég kiad egy szoftvert, ami ergonómiailag nem megfelelő. Ekkor már csak annyit kell tenni, hogy megtervezzük ugyanazt, jobb

felülettel, és máris van egy versenyképes termékünk. Lehet, hogy ez egy kicsit furcsának hangzik, de gondoljunk arra, hogy a Microsoft éppen az Machintosh fejlett felhasználói felületének ellopásából él a mai napig – és nem éppen rosszul. Ha megvan az ötletünk, a specifikáció alatt kiemelt figyelmet kell fordítanunk az ergonómiai aspektusokra. Gondoljunk csak arra, hogy egy interjú alatt a felhasználónak valószínűleg sok minden eszébe fog jutni a funkcionalitásokról, amit igényel, de a kényelmére a saját irányított kérdéseinkkel kell rákérdeznünk. Az User Interface (MMI) specifikációjánál külön ügyeljünk majd arra, hogy hova milyen felületet tervezünk a következő fejezetben felsoroltak közül. Jegyezzük meg, hogy milyen felhasználásra milyen felhasználási felület a célszerű. Mindezek mellett ne menjünk nagyon mélyre az ergonómiai oldalon sem (ne válasszuk még ki a menük típusát), mert ez ugyanúgy

túlspecifikációhoz vezet, mint a tartalmi kérdések túlzott taglalása. Az alrendszerek választásakor ügyeljünk a megfelelő tagolásra, a kódújrafelhasználhatóság miatt. 7 4.2 Tervezés, Design Ebben a fázisban dől el – többek között – az MMI kinézete is. Itt mindent meg kell fontolni azzal kapcsolatban, és lehetőleg úgy kell tervezni, hogy a még nyitva álló ergonómiai kérdések később kalibrálhatók legyenek (tehát redundanciát kell tervezni itt a kódba). A részek tervezésénél ügyeljünk arra, hogy a következő fejezetben található tanácsokat, és korábbi ergonómiai tapasztalatainkat figyelembe vegyük. Soha ne feledjük: a program nem nekünk készül, így építsünk oda is redundanciát, ahol mi még éppen nem igényelnénk. Ha a tervezésünkkor “végrehajtható” formátumú terv készül (pl. CASE eszközök esetén, MMI tervezéskor), akkor vizsgáljuk meg, illetve vizsgáltassuk meg a leendő felhasználóval. Mivel

ez az utolsó pont, ahol még könnyen változtathatunk, a részletes tesztelés is megéri. Ahol nem tudunk dönteni valamilyen kérdésről, építsünk be redundáns, kalibrálható részt. 4.3 Tesztelés és verifikáció Ebben a fázisban készülnek a felhasználói dokumentációk és a prototipus. Itt mindenképpen szembesülnie kell a felhasználónak a rendszerrel, így itt is végezhetünk ergonómiai vizsgálatokat. Ha súlyos problémákat találunk, akkor javasolt új terv-verzió kiadása is. Ne feledjük, hogy a prototípust ugyan nehéz javítani, de a kész alkalmazást lehetetlen! 4.4 Kódolás Ez a fázis – ha minden tervszerűen megy – teljesen automatikus. Ha mégis tervezési problémák adódnának a kódolás közben, figyeljünk arra, hogy az esetleges módosítások ne váljanak az ergonómia hátrányára. 4.5 Marketing A forgalmazás már nem kapcsolódik szorosan a szoftverhez. A megfelelő doboz kiválasztása, a hangsúlyozandó paraméterek

összeválogatása ugyan szakmai, de nem informatikai feladat. Ami fontos ebben a fázisban, az a felhasználói tapasztalatok összegyűjtése. Ezek az információk felbecsülhetetlen értékűek lesznek a következő verzió ergonómiai tervezésében. 4.6 Újrahasznosítás vagy Packaging fázis “A halál egy újabb születés?” – kérdezhetnénk. Egy újabb termékhez kaphatunk alapötletet egy régi továbbfejlesztésével, így egy újabb életciklust indítva. Itt lesz majd lényeges az, hogy a specifikációs fázisban az alrendszereket úgy különítettük el, hogy a kód újra felhasználható legyen. 8 5 HASZNOS TANÁCSOK A SZOFTVER FELHASZNÁLÓI FELÜLETÉVEL KAPCSOLATBAN Ebben a fejezetben megpróbálok néhány “használható” dolgot összeszedni a felhasználói felületek ergonómiájával kapcsolatban. Először néhány általános irányelvet írok le, azután rátérek a felhasználói felületek elemeinek és típusainak ismertetésére. 5.

1 Általános irányelvek Első irányelv, hogy mindig tartsuk szem előtt, hogy az alkalmazás kinek készül. Ne “bolondbiztos” alkalmazást tervezzünk, hanem ismerjük meg, és tartsuk tiszteletben a felhasználót, hiszen ő az, aki végül is fizet a programunkért. A második, hogy ugyan lehet, hogy a felhasználó nem ismeri a gép működését, de egy cseppet sem segít rajta, ha a gépet emberi jegyekkel ruházzuk fel, és így próbáljuk közelebb hozni hozzá. Ekkor merülnek fel azok a problémák, hogy a gép nem ember, így nem is tud megfelelni azoknak az igényeknek, amiket ekkor a felhasználó elvár tőle. Manapság a monitorok és a vezérlőkártyák már sokszínű, nagy felbontású módokat kínálnak a programozók számára. Mindemellett két dologra állandóan tekintettel kell lennünk:  Ne árasszuk el a felhasználót valami vad színkavalkáddal. A háttér, és a háttérben levő részek legyenek valamilyen sötétebb, nyugtató színűek,

míg a dokumentum, ha a felhasználása közben normál papírra is kell néznie a felhasználónak, legyen papírfehér, fekete betűkkel. Az alkalmazásaink felhasználói felületénél se használjunk három – öt színnél többet.  Ha a felhasználó bármilyen változtatást eszközöl a képernyőn, azt azonnal jelezzük. (A válaszidő legyen kicsi) Ez azért kell, hogy a felhasználó ne érezzen flusztrációt amiatt, hogy nem sikerül csinálnia semmit, “lassú a program”. A billentyűzet kezelésére egy dolgot jegyzek meg: nagyon zavaró, ha a különböző alkalmazások más-más billentyűzetkiosztást alkalmaznak. Ez igaz lehet a magyar ékezetes karakterekre is, de az úgynevezett “hot-key” –ekre is. Úgy általánosságban is igaz, hogy próbáljunk mindenütt hasonló dolgokat, jelöléseket, kifejezésrendszert használni, hogy a felhasználókognitív készsége minél előbb kialakulhasson. A programot tervezzük úgy, hogy a felhasználó

bármely állapotban kikapcsolhassa a gépet, és ne vesszenek el adatok eközben. Az egérkurzort nagyon hatékonyan lehet arra használni, hogy mindig mutassuk vele, hogy hol van a felhasználó a képernyőn. Ha megnyomható területre érünk, akkor érdemes alakot váltanunk, illetve ha kiérünk az alkalmazás egyes területeiről, ráállunk a menüre, stb. Mindemellett ne használjunk túlcifrázott mutatókat, mert nem elég funkcionálisak. Az egérgombokat használjuk következetesen, és más programokhoz hasonlóan, a billentyűzetnél említett okok miatt. 9 5.2 Az interakció Interakciók esetén mindig tartsuk be a négy “H”-s szabályt, vagyis hogy a képernyőről mindig könnyen meg lehessen állapítani, hogy:     Hol vagyok? Hogy kerültem ide? Hova mehetek? Hát itt meg mit tehetek? 5.21 Választás menüből A menük használata szinte forradalmasította a felhasználói felületeket az Apple megjelenésekor. Ez is mutatja, hogy a

felhasználó számára milyen lehetőségeket nyújt Hátránya lehet, hogy túl sok funkció esetén nem fér el a képernyőre, és így nehézzé teszi a választást. Megjegyzendő, hogy egy menübe nem érdemes 7+-2 –nél több elemet helyezni, mert így a felhasználó nem látja át őket a rövidtávú memóriájának korlátozottsága miatt. Ebben az esetben almenük használata javallott Gyakorlott felhasználók számára ajánlott rövidítések, shortcut-ok elhelyezése a gyakrabban használt funkciókra. 5.22 Űrlapkitöltés Az űrlapok, form-ok nagyobb mennyiségű adat bevitelére hatékonyak. Megjegyzendő, hogy ezek kitöltésére a felhasználó leginkább a billentyűzetet használja, így próbáljuk a form minden funkcióját a billentyűzetre helyezni, lehetőleg minél kevesebb kombinációval. Az űrlap legyen áttekinthető, és próbáljunk alapértelmezett értékeket megadni ott, ahol valószínű, hogy a felhasználó ezeket fogja használni. 5.23

Parancseditor Ez az interakció legrégebbi stílusa: a felhasználó begépeli a parancssort, a gép pedig végrehajtja, és visszajelzést ad. A parancsformátumok megtanulása ugyan hosszabb időt vesz igénybe, de azután sokkal gyorsabban használható, mint bármely más interfész. Éppen ezért tapasztalt felhasználók számára javasolt. Ha ilyet tervezünk, ügyeljünk arra, hogy a parancssor ismételhető, karakterenként javítható, automatikusan kiegészíthető legyen (tab-funkció). A hosszabb parancsok 10 rövidítését is ajánlott lehetővé tenni, valamint jó, ha az elrontott szintaxisú parancs után a gép kiírja a helyes formátumot. 5.24 Közvetlen manipuláció, Drag-and-Drop Ez a manipulációs stílus szintén az Apple megjelenésétől terjed. Nagyon könnyű megtanulni, könnyű újratanulni, pozitívan motiválja a felhasználót. Mindemellett igen nehéz ilyet kódolni, és nagyon ügyelni kell a következő dolgokra:  A képernyőn lévő

kép kapcsolható legyen a manipulált dologgal  Egérmozgatással minden manipuláció megoldható legyen  A válaszidő legyen észrevehetetlenül kicsi  A húzott tárgy lehetőleg a képernyőn is mozogjon  Miután az egér egy elég bizonytalan beviteli eszköz, legyen minden változtatás azonnal visszavonható  Egyszerű funkciókat valósítsunk meg így 5.25 “Emberközeli” interakció Ez a típus emberi nyelvre, gesztusokra épített rendszereket jelent. A bevitel ilyesforma átalakítása még eléggé gyerekcipőben jár, de a kimenetek átalakítása már sok eredményt hozott. A számítógép képes bármilyen szöveget felolvasni, és ma már megközelíthető a “virtuális valóság” érzete is. Ezek a dolgok ma még nem elterjedtek, így tapasztalatok sem állnak még a rendelkezésünkre a felhasználásukkal kapcsolatban. 6 IRODALOMJEGYZÉK Izsó Lajos: A rendszer- és szoftverergonómia alapkérdései. Ergofit Kft Budapest, 1997 Krammer

Gergely: Szoftver-ergonómiai értelmező szótár. Ergofit Kft Budapest, 1997 Szabó Beatrix Katalin – Krammer Gergely: Bevezetés a szoftver-ergonómiába. Ergofit Kft. Budapest, 1997 11