Néhány éve egy fejlesztő kollégánk iránymutatásával léptünk rá arra az útra, amely a felhasználói felületek tervezése során egyre inkább tudatosan és célzottan alkalmazza a High Performance HMI paradigmát (a kifejezésről lásd a keretes szövegrészt). A kezdeti botladozásokból, kísérleti megoldásokból mára lassan kialakul egy továbbra is folyamatosan fejlődő, de már viszonylag stabil alapokon nyugvó rutin, amelynek mentén az új generációs HMI rendszereinket fejlesztjük.

Habár számos ipari automatizálási termék hirdeti a dobozán nagy betűkkel kiemelten az "out of the box" megoldásokat, mégis könnyen belátható, hogy egy implementációs gyakorlatot nagyon nehéz (ha nem lehetetlen) “becsomagolni”. Az ilyen tudás elsajátítható, mérnöki szolgáltatásként megvásárolható, de kész, lekódolt termékek között maximum a megvalósítást megkönnyítő segédeszközöket találunk. Ugyanakkor tény, hogy nagyon sok gyártó kínál mára olyan komplex könyvtárakat termékei mellé, melyek használatával kevesebb gyakorlati tapasztalat mellett is jó eredmények érhetők el.
 

Az alábbiakban a teljesség igénye nélkül röviden összegezem azokat a tapasztalatokat, jellemző kihívásokat vagy hibákat, amelyekkel az elmúlt pár év során találkoztunk és amelyek leginkább megnehezítették egy-egy projekt során a HMI fejlesztést.

Tervezni kell!

Általános, mondhatni a témától független probléma, hogy ha a beruházói oldalról él is a megvalósítani kívánt rendszer esetében az életciklus-alapú megközelítés, ennek a tervezés vagy nem képezi részét, vagy nem tulajdonítanak neki kellő jelentőséget, holott a végeredmény szempontjából talán ez a legkritikusabb lépés, ahogy azt előző, Tervezni? Kell! című cikkemben megfogalmaztam. Az ott leírtak a megfelelő kiegészítésekkel a HMI-re is igazak. A tervezést és kivitelezést egységes keretek között tartó, dokumentált rendszert kell használni. Enélkül még akkor is kétséges a siker, ha egy projekten nem több független kivitelező dolgozik. Nagyobb volumenű, szerteágazó munkáknál pedig hiánya egyenes út a nem megfelelő minőségű végtermékhez, azaz a kudarchoz.

A megfelelő eszköz megválasztása

A HPHMI módszertana nem csak az egyes elemek/képernyők implementációját segíti. Nagy hangsúlyt fektet azokra a tényezőkre is, melyek ezeknek az elemeknek a hatékony használatát közvetlenül vagy közvetve befolyásolják. A végeredmény szempontjából kulcsfontosságú a lehető legteljesebb ergonómia. Ha például a beviteli felület esetén a felhasználási terület sajátosságai miatt kizárólag érintőképernyőt lehet használni, akkor mindenképpen olyan felületet  kell választani, amelyen valamennyi, kizárólag ezen a felületen végrehajtható (vagy rutinszerűen ott végrehajtott) feladathoz kapcsolódó funkciót kényelmesen és átláthatóan lehet kezelni.

Ezt leírni könnyű. Csakhogy a tervezés során sokszor nem áll rendelkezésre minden olyan információ, amely alapján ezek a kérdések eldönthetők lennének. Másrészt a beruházó sem szokta megkönnyíteni a tervező dolgát: mivel a legtöbb esetben a nagyobb "mozgástér" (nagyobb képernyő stb.) kisebb-nagyobb költségtöbbletet is jelent, nem szívesen engedi az ilyen megoldások alkalmazását, sokszor nem gondolva döntése hosszútávú hatásaira.

Már 30 éve is így csináltuk...

Szinte minden esetben, amikor meglévő rendszerek leváltását vagy felújítását tűzi ki célul a beruházó, előbb-utóbb felmerül a kérdés: mi az a "helyes gyakorlat", melyet változtatás nélkül érdemes átmenteni, megvalósítani az új HMI esetén, és mely területeken szükséges részleges vagy teljes módosítás. A kérdés megválaszolása nehéz, mert számos aspektusból vizsgálható, és az eredmény a legritkább esetben egyértelmű.

Amikor vizualizálni kívánunk egy folyamatot, figyelembe kell venni, hogy általában a legnagyobb rutinnal rendelkező végfelhasználók (operátorok) számára sokszor kényelmetlenség és potenciális hibaforrás a megszokottaktól való bármilyen eltérés. Szintén fontos tényező az áttervezéshez szükséges időráfordítás. Ezért nagyon gyakran elvárás, hogy az új HMI kinézete "as-is" egyezzen meg a korábbival.

Ugyanakkor egy áttervezés magában hordozza egy (kezelési) folyamat revizionálásának lehetőségét, melynek során az évekig kényszerűségből eltűrt hibák kivezethetők. Emellett ilyenkor bevezethetők olyan, a hatékonyságot és/vagy a megbízhatóságot növelő modern eszközök és (az ezekre alapozó) mérnöki gyakorlatok, melyek kiaknázása jelentősen üzleti előnyt jelenthet.

Mentális modell

A tervezési/kivitelezési folyamat legnehezebb és talán legtöbb kihívást jelentő fázisa, amikor a végfelhasználói és az alkalmazásfejlesztői oldal próbálja (sokszor a projekt vélt érdekében) saját álláspontját a másik kárára érvényesíteni, holott éppen ezek szinergiája a kívánatos. A probléma gyökere általában az, hogy nem beszélik egymás nyelvét. A végfelhasználó (operátor stb.) érti a folyamatot, érti annak technológiáját és függőségeit, de nincs tisztában a folyamat-felügyeleti (SCADA, DCS) rendszer – elsősorban – technikai korlátaival, összefüggéseivel. Az alkalmazásfejlesztő ellenben érti utóbbiakat, de a folyamatra vonatkozó kellő szakismeret és/vagy helyi sajátosságok ismerete nélkül problémát okoz számára az adaptálás, illesztés.

Az egyetlen helyes út a párbeszéd. A felhasználó a folyamatról alkotott mentális modellje szerint írja le azt a működést, melyet a fejlesztőnek a front-end oldalon úgy kell szimulálnia, hogy elfedi mindazt, ami a tényleges megvalósításhoz technikailag szükséges. A párbeszédben mindkét oldalról olyan személyeknek kell részt venniük, akik az adott feladatra nézve kellő kompetenciával rendelkeznek.

Az adat nem információ!

A tervezés során számtalanszor szembesülünk azzal, hogy – legtöbbször erőforrás vagy idő hiányában – a végfelhasználó nem tudja, vagy nem akarja pontosan végiggondolni, hogy a folyamat során, melyhez az adott rendszert tervezzük, mely adatok milyen módon, esetben és prioritásban fontosak a számára.

A ma kapható szoftvereszközök szinte mindegyike tartalmaz olyan "varázslókat", melyekkel "fogd és dobd" módon, másodpercek alatt megjeleníthető egy adatforrás aktuális (vagy akár historikus) értéke. A marketingüzenetek ezeket a lehetőségeket hajlamosak a termelékenység kulcsaként emlegetni. Tévesen. Ugyanis ez maximum annyiban igaz, hogy egy gyakorlott fejlesztő munkáját egyszerűsítheti. Egy gyakorlatlan felhasználó esetén azonban magában hordozza annak a vélt rutin tévhitére alapozott magabiztosság minden kockázatát, amely aztán technikai vagy egyéb téren nem megfelelően kivitelezett rendszert eredményez. Az sem elhanyagolható, hogy a valós fejlesztői munkát is alulértékelté teszi.

Minden képernyőn pontosan annyi és olyan adatot érdemes megjeleníteni, ami a felhasználó számára még átlátható, egyértelműen és "egy szempillantás alatt" értelmezhető, valamint a folyamat szempontjából számára releváns.

Ennek szükséges, de nem elégséges feltétele a jól megtervezett struktúra és hierarchia, valamint az adatforrások (elsősorban technológiai szempontból való) pontos ismerete. Az információ az adatok megfelelő helyen, a szükséges időben, kezelhető mennyiségben, megbízható minőségben és helyes kontextusban történő reprezentációja a felhasználó számára.

Tesztelni, tesztelni, tesztelni...

A projektek határidői általában szorosak, ritka, hogy van elegendő idő az átfogó, részletes tesztelésre. Már ezért is érdemes a projekt során végig úgy fejleszteni, hogy abba beleépítjük a tesztelés lépéseit. HMI tervezés esetében a leggyakrabban az "End to End" módszertan szerint dolgozunk, de a felületek mögött futó kódoknál például a "unit test" eljárások is szóba kerülhetnek.

Gyakori, hogy a fejlesztő és a tesztelő ugyanaz a személy. Ez még akkor sem szerencsés, ha a tesztelés célja kizárólag a kódolási/működési hibák kiszűrése. Az ún. usability-tesztnél pedig kifejezetten kerülendő.
 

Ezt a felületet már a High Performance HMI elvei szerint készítettük el

A teszteléshez nem kell feltétlenül bonyolult eszköz. Már a fejlesztés kezdeti szakaszaiban is érdemes akár papíron felskiccelve, akár a fejlesztőeszköz segítségével bemutatni a körvonalazódó képernyőminták vizuális megjelenését. Ez csupán pár perc, mégis jelentős eredmények érhetőek el. Arra készteti ugyanis a felhasználót, hogy végiggondolja a folyamatot, és időben jelezze, ha valamit nem ért, nem tart jónak. Ez a fejlesztőnek is segít, mert láthatja, hogyan közelít a felhasználó a tervezett felülethez: milyen bejárási sorrendet tart, hogy kísérel meg használni elemeket, hol akad el, mely elemek értelmezése során bizonytalanodik el, milyen hibákat vét, milyen (téves) következtetéseket von le stb.

Mindez csak ízelítő...

A téma a fentieknél természetesen lényegesebb szerteágazóbb, de már a felvillantott fogások alkalmazásával is komoly előrelépés érhető el.

Általánosságban egy tanács adható: gondoljuk végig, hogy a végfelhasználó egyetlen kapcsolata a majdani rendszerrel a HMI. Hiába működik a mögöttes rendszer stabilan és hibamentesen, ha a felhasználó a kezelőfelületet kényelmetlennek, nehézkesnek érzi,  akkor nagy valószínűséggel a komplett rendszert fogja negatívan megítélni.

 A szerző informatikus mérnök, több éve dolgozik nagy projekteken a Com-Forth Kft.-nél architektként.