}w !"#$%&'()+,-./012345
Masarykova univerzita Fakulta informatiky
Uživatelské rozhraní ERP systému Diplomová práce
Bc. Otakar Hypš
Brno, jaro 2014
Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorských dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při práci používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: Ing. Leonard Walletzký, Ph.D. ii
Poděkování Děkuji Ing. Leonardu Walletzkému, Ph.D. za vedení práce. Děkuji rodičům a bratrovi za dlouhodobou podporu v průběhu celého studia. Dále děkuji všem, kteří pomáhali směřovat moje kroky v průběhu tvorby této práce. Mým drahým přátelům děkuji za životní oporu. Děkuji společnosti CÍGLER SOFTWARE, a.s. za důvěru a ochotu participovat na tomto díle.
iii
Shrnutí Tato diplomová práce se zabývá uživatelským rozhraním ERP systémů. Značná část se věnuje mapování prostředí, ve kterém ERP systémy fungují a poukazuje na typické problémy složitých rozhraní. Výsledkem práce je softwarový prototyp, který navrhuje jedno z možných řešení zahlceného menu v prostředí webových ERP systémů. Řešení vychází z uživatelských požadavků a je podloženo dvěma koly testování.
iv
Klíčová slova uživatelské rozhraní, ERP, SAP R3, Windows UI, HCI, HMI, menu, adaptivní a adaptibilní rozhraní, testování, hodnocení použitelnosti, user centered design
v
Obsah 1 2
3
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . ERP systémy . . . . . . . . . . . . . . . . . . . . 2.1 Další definice ERP systémů . . . . . . . . . . 2.2 ERP v užším slova smyslu . . . . . . . . . . . 2.3 ERP II . . . . . . . . . . . . . . . . . . . . . . 2.4 Ekonomické systémy . . . . . . . . . . . . . . 2.5 Klasifikace ERP systémů . . . . . . . . . . . . 2.6 Open source a proprietární software . . . . . 2.6.1 Open source . . . . . . . . . . . . . . . 2.6.2 Proprietární řešení . . . . . . . . . . . 2.7 Historie ERP . . . . . . . . . . . . . . . . . . 2.7.1 Nové trendy . . . . . . . . . . . . . . . 2.8 Příklady ERP a Ekonomických systémů . . . 2.8.1 SAP . . . . . . . . . . . . . . . . . . . 2.8.2 iDempiere . . . . . . . . . . . . . . . . 2.8.3 Money S3 . . . . . . . . . . . . . . . . 2.8.4 iDoklad.cz . . . . . . . . . . . . . . . . Uživatelské rozhraní . . . . . . . . . . . . . . . 3.1 Historie uživatelského rozhraní ERP . . . . . 3.1.1 Historie SAP R/3 . . . . . . . . . . . 3.1.1.1 SAP R/2 . . . . . . . . . . . 3.1.1.2 SAP R/3 verze 1.0 a 1.1 . . 3.1.1.3 SAP R/3 verze 2 a 2.1 . . . 3.1.1.4 SAP R/3 verze 3 a 3.1 . . . 3.1.1.5 SAP R/3 verze 4 . . . . . . . 3.1.1.6 SAP R/3 verze 4.6 a novější 3.1.2 Historie UI MS Windows . . . . . . . 3.1.2.1 Windows 95 . . . . . . . . . 3.1.2.2 Windows 98, ME, 2000 . . . 3.1.2.3 Windows XP . . . . . . . . . 3.1.2.4 Windows Vista . . . . . . . . 3.1.2.5 Windows 7 . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3 3 4 4 4 5 6 6 7 7 8 9 9 9 10 10 11 11 12 12 12 13 15 15 18 19 19 19 20 21 21 vi
3.1.2.6 Windows 8 . . . . . . . . . . . . . . . . . . . Ribbon User Interface . . . . . . . . . . . . . . . . . . 3.1.3.1 Software bloat . . . . . . . . . . . . . . . . . 3.1.3.2 RUI a uživatelé . . . . . . . . . . . . . . . . 3.1.4 Web ERP . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Obecná pravidla a pojmy z oblasti HMI . . . . . . . . . . . . 3.2.1 Osm pravidel pro návrh uživatelského rozhraní . . . . 3.2.2 User centered design . . . . . . . . . . . . . . . . . . . 3.2.3 Metafory . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Mentální model . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Mapování . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6 Zpracování informací . . . . . . . . . . . . . . . . . . . 3.2.6.1 Tvarová psychologie – Gestaltpsychologie . . 3.2.7 Funkce a forma . . . . . . . . . . . . . . . . . . . . . . 3.3 Desktopové aplikace . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Human Interface Guidelines . . . . . . . . . . . . . . . 3.3.2 Časté chyby . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Webové aplikace . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Časté chyby . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Mobilní zařízení . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Formuláře . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 Cíl menu . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1.1 Pedagogic Vector . . . . . . . . . . . . . . . 3.7.2 Rozdělení menu dle míry přizpůsobitelnosti . . . . . . 3.7.2.1 Statické . . . . . . . . . . . . . . . . . . . . . 3.7.2.2 Adaptibilní . . . . . . . . . . . . . . . . . . . 3.7.2.3 Adaptivní . . . . . . . . . . . . . . . . . . . . 3.7.3 Porovnání Statického, Adaptibilního a Adaptivního menu 3.7.4 Adaptivní rozhraní Boulevard . . . . . . . . . . . . . . Hodnocení použitelnosti rozhraní a testování . . . . . . . . . 4.1 Použitelnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Metody hodnocení použitelnosti . . . . . . . . . . . . . . . . . 4.2.1 Explorační . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Hodnoticí . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Ověřovací . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Příklady . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4.1 Focus Group . . . . . . . . . . . . . . . . . . 4.2.4.2 Strukturované interview . . . . . . . . . . . . 4.2.4.3 Dotazník . . . . . . . . . . . . . . . . . . . . 3.1.3
4
21 21 22 24 25 26 26 26 27 27 28 28 29 29 30 31 31 31 33 33 34 34 35 35 35 35 36 36 36 36 38 38 38 39 39 39 39 39 40 40 vii
4.3
Kvantitativní a kvalitativní . . . . . . . . . . 4.3.1 Typy otázek . . . . . . . . . . . . . . . 4.3.1.1 Otevřené / Uzavřené . . . . 4.3.1.2 Přímé / Nepřímé . . . . . . . 4.3.1.3 Dle úlohy v testování . . . . 4.3.1.4 Škálové dotazy . . . . . . . . 5 Návrh menu webového ERP systému . . . . 5.1 Explorace . . . . . . . . . . . . . . . . . . . . 5.2 Papírový prototyp . . . . . . . . . . . . . . . 5.3 Softwarový prototyp . . . . . . . . . . . . . . 5.3.1 Zpracování výstupů finálního testování 6 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . A Scénář testování papírového prototypu . . . . B Scénář testování softwarového prototypu . . C Obsah elektronické přílohy v archívu IS MU
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
41 41 42 42 42 42 43 43 45 48 52 55 63 65 66
viii
Kapitola 1
Úvod Uživatelské rozhraní je hranice zprostředkovávající komunikaci mezi dvěma prostředími. V této práci se jedná o prostředí mezi počítačem a člověkem. První jmenované se specifikuje na odvětví ERP systémů. Jedná se o rozsáhlé systémy sloužící k řízení společnosti a zasahující do všech odvětví organizace. Návrhům uživatelských rozhraní se obvykle nevěnuje dostatečná pozornost. Nezřídka vznikají na základě úsudku programátorů pracujících na vývoji daného softwaru. Rozhraní pak často kopíruje strukturu programu, aniž by byl zohledněn pohled uživatele neznalého vnitřní struktury. Oddělení návrhu rozhraní od struktury programu je zásadním krokem pro zlepšení použitelnosti softwaru. Správnou cestou návrhu je design zaměřený na uživatele. Cílem této práce je zmapovat prostředí ERP systémů ve vztahu k jejich uživatelským rozhraním a navrhnout řešení konkrétního problému. Z tohoto důvodu je zpočátku nahlíženo na ERP systémy ze široka. Téma práce se zužuje k návrhu rozhraní menu webového ERP systému. To vede k řešení problému zahlceného menu u systémů nabízejících široké spektrum funkcí. Zároveň řešení podporuje přesun takových systémů do prostředí webu. Kapitola nazvaná ERP systémy zavádí definice různých typů podnikových systémů. Mapuje prostředí jejich výskytu v historii, současnosti i blízké budoucnosti. Zavádí klasifikace a praktické příklady. Třetí kapitola se zabývá uživatelským rozhraním. Seznamuje s jeho historií ve vztahu k ERP systémům a představuje zásadní principy a termíny z oblasti komunikace člověka s počítačem. Poukazuje na jeden z největších problémů rozhraní, kterým je zahlcení navigace u rozsáhlých systémů. V závěru kapitoly se téma zaměřuje na principy navigace. Kromě uživatelských rozhraní se kapitola částečně věnuje tématu tvarové psychologie a nabízí malý exkurz do historie architektury v části nazvané Funkce a forma. Pro použití metod hodnocení použitelnosti v praktické části je třeba definovat principy, kterými se hodnotí a testuje použitelnost rozhraní. Základní metody jsou představeny ve čtvrté kapitole. V části Návrh menu webového ERP systému se práce blíží závěru. Soustředí se prakticky na jeden problém, jehož řešení spočívá v implementaci 1
1. Úvod informací získaných průzkumem mezi uživateli. Vytvořeny jsou dva druhy prototypů na různých úrovních abstrakce. Ty jsou otestovány ve spolupráci se společností CÍGLER SOFTWARE, a.s. Výstupem z testování je funkční prototyp menu webového ERP systému.
2
Kapitola 2
ERP systémy Zkratka ERP vychází z anglického názvu Enterprise Resource Planning, česky přeloženo jako plánování podnikových zdrojů. ERP je možné definovat jako integrovaný softwarový systém, který podporuje plánování a řízení všech hlavních procesů podniku. Důležitou vlastností je používání standardizovaných přístupů k těmto procesům. Terminologie v oblasti informačních systémů není dosud pevně sjednocena, a tak je možné se setkat s různými definicemi ERP.[1] Nejednotnost je dána mimo jiné velikou rozmanitostí a úhlem pohledu na každý jednotlivý ERP systém.
2.1
Další definice ERP systémů
„Soubor ucelených funkcí pro organizování, definování a standardizaci pracovních procesů nutných pro efektivní plánování a řízení organizace takovým způsobem, aby tyto vnitřní znalosti mohla organizace využívat jako výhodu v konkurenčním boji.“ [2] „ERP je typ aplikace, respektive aplikačního software, který umožňuje řízení a koordinaci všech disponibilních podnikových zdrojů a aktivit. Mezi hlavní vlastnosti ERP patří schopnost automatizovat a integrovat klíčové podnikové procesy, funkce a data v rámci celé firmy.“[3] „ERP systém pomáhá podniku automatizovat a integrovat hlavní procesy, sdílet společná podniková data a umožnit jejich dostupnost v reálném čase. Při jeho zavádění často dochází k Business Process Reengineeringu, tj. restrukturalizaci společnosti a jejích procesů.“[4] Z těchto definic lze chápat ERP systém od základu jako velice komplexní řešení pro všechny společnosti. Je nutné si uvědomit, že struktura společností se značně liší. První možné dělení, jaké se nabízí, je dle velikosti podniku. Český statistický úřad dělí malé a střední podniky na drobné s počtem zaměstnanců menším než deset, malé v rozmězí 10 až 49 a střední od 50 do 250 3
2. ERP systémy zaměstnanců.[5] Právě počet zaměstnanců je významný faktor, který určuje, jak rozsáhlý ERP systém bude vhodné v podniku nasadit.
2.2
ERP v užším slova smyslu
Jak je naznačeno výše, společnosti se liší a to nejen velikostí, ale i specifickými nároky. Proto jsou ERP systémy obvykle skládány z jednotlivých modulů. Samotný ERP systém je jádro společné všem podnikům obsahující funkcionality, jako například: Financování, Lidské zdroje, Nákup, Prodej, Výroba. Na takový systém lze nahlížet jako na ERP v užším slova smyslu. [1]
2.3
ERP II
Úpravy takzvaně na míru se dotváří buď implementací dodatečných modulů k jádru ERP systému, nebo programováním specifického modulu přesně dle požadavků zákazníka. Typickými moduly jsou CRM (Řízení vztahu se zákazníky), BI (Podnikové zpravodajství), SCM (Řízení vztahu s dodavateli) a další. ERP spolu s těmito aplikacemi pak lze považovat za ERP v širším slova smyslu, nebo též ERP II.[4]
Obrázek 2.1: Struktura ERP systému v širším pohledu
2.4
Ekonomické systémy
Nejen softwarové, jak je popsáno výše, ale též hardwarové nároky na provozní zařízení i síť jsou vysoké. Vyvstává otázka, pro koho jsou tyto rozsáhlé systémy určeny. Drobní podnikatelé, podle definice v kapitole 2.1, nevyužijí 4
2. ERP systémy kompletně ani jádro ERP systému. I oni potřebují způsob provozu nejnutnější agendy, jako je fakturace, skladové hospodářství a mzdy. Jim určené aplikace se nazývají Ekonomické systémy. Základní rozdíl mezi ERP a Ekonomickým systémem je v počtu funkcí. Další výrazný rozdíl je rozsah vnitřní integrace. To znamená, že v Ekonomickém systému jsou uložena data pro fakturaci, mzdy i sklad, ale tato data jsou uložena separátně a nejsou nijak propojena. Nelze na ně nahlížet v ucelené formě, jako je to obvyklé u BI (Business inteligence1 ) modulů v ERP systémech.
2.5
Klasifikace ERP systémů
Veškeré programové vybavení počítače je možné dělit na:
∙
Systémový software
∙
Aplikační software
Systémový software představují skupiny programů a modulů tvořící operační systémy, překladače, služební programy a další. Úzce souvisí s vývojem zařízení směrem k lepšímu využití technických prostředků. Aplikační software lze nejlépe klasifikovat z hlediska cíle, pro který byl navržen. Může se jednat o individuální balík programů, který má sloužit jednomu účelu, nebo byl systém vytvořen pro vícenásobné použití. Takto lze aplikační software rozdělit na individuální a standardizovaný. ERP systémy patří ke standardizovanému programovému vybavení, přitom není vyloučeno, že mohou být doplněny funkcemi speciálně vyvinutými na zakázku, ať už vlastními silami či dodavatelem. Standardizované systémy si kladou za cíl použití ve větším počtu organizací. V případě ERP systémů podporují ekonomickou činnost podniku a to mimo jiné také transakčně. Patří tedy mezi transakční systémy. Jejich klasifikace se nachází v tabulce 2-1. Takové rozdělení je poměrně hrubé, ale pro obecný pohled dostačující.[1]
1. Výraz Business inteligence lze volně přeložit do českého jazyka jako Podnikové zpravodajství.
5
2. ERP systémy Typ Vertikální (odvětvové)
Transakční
Speciální
2.6
Popis Zaměřují se na řešení specifických funkcí v určitém odvětví. Zajišťují běžné transakce v organizaci dle jednotlivých subsystémů. Poskytují speciální funkce často v návaznosti na provozní funkce transakčních systémů.
Příklad Systémy řízení nemocnic, systémy v automobilovém průmyslu aj. Výroba, skladové hospodářství, logistika aj.
Statistické programy, experimentární systémy, prognostické programy, systémy pro podporu rozhodování aj. Tabulka 2-1: Klasifikace transakčních systémů [1]
Open source a proprietární software
Velice podstatným kritériem dělení ERP systémů je cena. Opět vystačíme s hrubým dělením, v tomto případě na software zdarma a placený software. Každé z těchto řešení nese své klady a zápory. Není možné jednoznačně říci, které z nich je lepší, protože to závisí na velikosti i struktuře společnosti a také na tom, k jakému účelu a v jakém rozsahu chce společnost ERP systém využívat.
2.6.1 Open source Jednoznačnou výhodou Open source řešení je cena. Potřebný software obvykle získáte legálně zdarma. Samotná instalace software, nastavení a hardwarové nároky mohou nést dodatečné náklady. Stále se cena takového ERP systému bude pohybovat pod cenou komerčních řešení, ale již nelze hovořit o systému zdarma. Výhodou je bez pochyby otevřený kód softwaru, díky němuž je možné program přizpůsobit na míru požadavkům. Poměrně zásadní nevýhodou je nepřítomnost technické podpory pro konkrétní verzi systému, který byl upravován právě pro potřeby společnosti. Toto je možné řešit externím dodavatelem s jistou mírou garance, ale opět přítomnost dodavatele výrazně zvýší náklady. Nyní již ne na pořízení software, ale už na jeho provoz. 6
2. ERP systémy 2.6.2 Proprietární řešení Proprietární software nemá veřejně přístupný zdrojový kód, a proto není možné jej upravovat dodatečně vlastními silami. Někdy je též nazýván software s uzavřeným kódem2 . Takový software nemusí být nutně komerční, ale ve většině případů tomu tak je.[9] Bývá poskytován jako hotové celoplošné řešení, někdy označované jako krabicový software. Obvykle je spravován společností, která zajistí veškerý servis spojený s instalací, provozem, reklamacemi i školením zaměstnanců společnosti, kde bude systém nasazován.
2.7
Historie ERP
Pro orientaci mezi ERP systémy a pro dobrý odhad fáze jejich vývoje je nutné znát také základní milníky jejich historie. Evoluce těchto systémů probíhala současně s vývojem informačních technologií a počítačového hardwaru. Dříve, než se vůbec nové technologie dostaly na veřejnost, byly využívány sálové počítače pro řízení skladových zásob. K tomu sloužily legacy systémy programované v jazycích jako je COBOL, ALGOG či FORTRAN. Hovoříme o šedesátých letech dvacátého století. O desetiletí později se objevovaly takzvané MRP systémy (Material requirements planning), které zahrnovaly převážně plánování výroby. Na ně navazovaly systémy MRP II, jež kladly důraz na optimalizaci procesů synchronizováním materiálu a nároků na jeho produkci. Taktéž zahnovaly nová rozšíření, jako řízení distribuce, projektový management, lidské zdroje i financování. Těchto rozšíření se předchůdci ERP systémů dostalo v osmdesátých letech.[6] Až s příchodem roku 1990 se začíná hovořit o prvních ERP systémech založených právě na systémech MRP a MRP II. Zahrnují výrobu, distribuci, účetnictví, finance, lidské zdroje, projektový management, údržbu a mnoho dalších modulů. Taktéž prodejci začali vyvíjet nové moduly, které bylo možné doplnit k jádru systému a tím jej přizpůsobovat pro konkrétní společnost. Například na přelomu tisíciletí docházelo k masivnímu rozvoji obchodování přes internet[7], což vedlo k častým implementacím elektronického obchodování do ERP.[8] Systém zahnující tyto přídavné moduly se v literatuře objevuje pod názvem ERP II nebo též rozšířený ERP (extended ERP).[6] Každé desetiletí od šedesátých let definuje jeden krok ve vývoji ERP systémů. ∙ 2.
1960 - sálové počítače a řízení zásob Z anglického closed source software.
7
2. ERP systémy ∙
1970 - MRP I
∙
1980 - MRP II
∙
1990 - ERP
∙
2000 - ERP II
∙
2010 - Cloud Computing3
Na závěr výčtu je připojen rok 2010. Dá se předpokládat, že dalším krokem ve vývoji ERP bude v tomto desetiletí přesun systémů do cloudu. 2.7.1 Nové trendy Mnoho společností vyvíjejících ERP systémy se nyní snaží cílit na menší a střední podniky. Nejen kvůli tomu, že v době krize po roce 2000 bylo potřeba rozšířit portfolio klientů, ale také proto, že se ERP a Ekonomické systémy staly cenově dostupné i pro menší podniky a nejen pro veliké korporace. Jednoznačným trendem je krabicový software, který je jednoduše dostupný, přednastavený a oproti korporátním řešení také levný. Obvykle se tento software úzce zaměřuje na přesný typ klientů. Například na internetové obchody. Změnou neprošel pouze samotný systém, nýbrž i služby nabízené spolu s ním. Implementace probíhá rychle, přímo na míru, personál prochází školeními a klient se nemusí starat o správu hardwaru. Není výjímkou ani outsourcing4 celého systému. To souvisí s novinkou SaaS (Software as a Service), což je pojem s českým významem Software jako Služba a jedná se o připojení k serveru, kde se klient nemusí starat o licence, software ani provoz hardwaru, navíc jsou jeho data zálohována a systém pravidelně optimalizován dle aktuální legislativy. Software je takto poskytován prostřednictvím Internetu hromadně velikému počtu klientů, což snižuje náklady a navíc je větší pravděpodobnost, že bude služba provozována kvalitně a bez výpadků.[10] Nevýhodou takového řešení může být fakt, že citlivá firemní data se nenachází pod střechou firmy, ale jsou ve správě třetí strany, která pochopitelně může garantovat jejich šifrování a nedotknutelnost. 3. Cloud computing je technologie známá přibližně od roku 1950, ale značný boom zaznamenala až o šedesát let později. To souvisí s dostatečnou kvalitou a pokrytím Internetu, který slouží jako prostředek ke vzdálenému ukládání dat. Díky tomu je možné přistupovat ke službám a pracovat s aktuálními daty odkudkoliv.[13][14] 4. Outsourcing je využití služby externího poskytovatele za účelem dosažení efektivních výsledků.[15] Výhodný je v případě, kdy je externí poskytovatel schopen dodat lepší výsledek v kratším čase, či snížit náklady.
8
2. ERP systémy Vzhledem k trendu poskytování SaaS u ERP systémů se dá očekávat masivní posun na poli zabezpečení uložených dat a jejich přenosu. Podle studie společnosti IFS z roku 2011 patří mezi nejnovější trendy v oblasti ERP systémů mobilní přístup a intuitivita rozhraní.[11]
2.8
Příklady ERP a Ekonomických systémů
Zde jsou představeny příklady produktů, které pokrývají široké pole ERP a Ekonomických programů. Na tyto příklady je dále v práci odkazováno. 2.8.1 SAP Společnost SAP je světovým lídrem ve vývoji ERP systémů a třetí největší světový výrobce software. Pyšní se více než čtvrt milionem zákazníků ze 188 zemí světa a zaměstnává více než 66 500 lidí ve 130 státech. SAP je zakladatelem odvětví, ve kterém již od roku 1972 nemá výraznější konkurenci. Nejslavnější produkt společnosti nese název SAP R/3.[12] 2.8.2 iDempiere Univerzální ERP systém, jehož vývoj probíhá od roku 2006 postupně ve verzích Compiere ERP a ADempiere. Je šířen jako Open source řešení pod General Public License (GPL), což poskytuje volnost úprav kódu i úprav dosavadních funkcí. Spouští se ve webovém prohlížeči, čímž se přibližuje cloudu a zajišťuje přenositelnost v rámci operačních systémů. Zahrnuje obrovské množství modulů a jeho obliba dle statistik serveru SourceForge.net v roce 2009 dosahovala více než deseti tisíc stažení[16] a celkově vývojové verze dosáhly více než milion stažení po celém světě.[17] Nastavení systému je velice podrobně popsané na 400 stranách knihy ADempiere Solutions od Bayu Cahya Pamungkas. Vzhledem k tomu, že se jedná o jeden z nejpopulásrnějších Open source ERP systémů na světě, funguje v jeho okolí široká komunita podporovatelů a vývojářů. Také v České republice existuje Československá Aliance pro podporu ADempiere, která působí v oblastech marketingu, vývoje a podpory ADempiere se zvláštním ohledem na lokalizaci5 software.[18] Na Fakultě informatiky Masarykovy Univerzity funguje Laboratoř servisních systémů6 zaměřená na iDempiere. Komunity se podílejí na tvorbě nových modulů systému i na údržbě stávajícího kódu. Členy komunity nemusí být pouze fyzické osoby, ale též spo5. Lokalizace software je přizpůsobení programu podmínkám pro místní nastavení jako je jazyk, měna, časové pásmo, legislativa. 6. http://ssme.fi.muni.cz/student/laborator-ses
9
2. ERP systémy lečnosti, které poskytují služby na základě Open source systému. Jedním z příkladů je společnost Adaxa, která pro ADempiere vyvinula mobilní verzi rozhraní.[19] 2.8.3 Money S3 Zástupcem proprietárního software je systém Money S3 vyvíjený společností CÍGLER SOFTWARE, a.s., která působí na poli účetních systémů od roku 1990 a je jednou z největších v České republice. Jako první uvedli na český trh účetní krabicový software. Ten byl následně inovován, až se rozštěpil do několika současných verzí. Money S3 je zástupce software pro menší a střední podniky. Money S5 bylo poprvé představeno v roce 2005 jako zástupce rozsáhlých ERP systémů, avšak s opožděným nástupem na trh oproti konkurenci. Money S4 je doplněním mezery mezi Money S3 a S5, ze kterého bylo odvozeno. Jedná se tedy o méně náročný ERP systém pro střední podniky.[20] Systém Money je komerční software. Ve všech variantách zpoplatněný jiným způsobem. Od zkušební verze zdarma, přes licence dle počtu uživatelů až po indivituální komplexní řešení ERP systému na míru. Společnost CÍGLER SOFTWARE, a.s. také poskytuje veškeré služby spojené s implementací, podporou a údržbou systémů. 2.8.4 iDoklad.cz Proprietární software, jak je zmíněno výše, se může objevovat ve verzi zdarma. To z něho nedělá nekomerční software, protože může být použit, stejně jako iDoklad.cz, formou služby popularizující společnost a její další zpoplatněné produkty. Webová služba iDoklad.cz je jednoduchý fakturační nástroj reflektující moderní přístup přes Internet. Pracuje ve webovém prohlížeči. Je tedy multiplatformní a svou funkcí se blíží cloudovému řešení. Systém provozuje CÍGLER SOFTWARE, a.s.
10
Kapitola 3
Uživatelské rozhraní Zkratka UI skrývá pojem User Interface, který v překladu do českého jazyka znamená uživatelské rozhraní. Pro správné chápání tohoto pojmu je nutné si vysvětlit co vlastně znamená. Rozhraní je místo na pomezí dvou rozdílných prostředí. Slouží k tomu, aby spolu tato dvě prostředí mohla komunikovat. Nejedná se pouze o pojem z oboru informatiky, rozhraní je například i hranice státu. Ve skutečnosti není vidět, ale existují určité prostředky jak hranici překročit, jak se dorozumět s cizím státem a jak spolupracovat. Otevřením hranic v rámci Evropské unie se zjednodušil proces překročení hranic a rozhraní se tím zjednodušilo. V běžném životě lze též nalézt rozhraní. Jsou tak dokonale přizpůsobena člověku, že je už nevnímá. Taková rozhraní jsou ideální. Může to být třeba láhev, nebo dveře. U obojího je zřejmé, jakým způsobem se ovládá. U lahve stačí změnit směr otáčení víčka, nebo u dveří špatně označit, na kterou stranu se otevírají, a běžná věc se stane obtížnou. Stejně jako je důležité pro správné fungování aplikace, aby byla dobře naprogramována a architektura byla dobře navržena, je stejně důležité, aby bylo kvalitně zpracováno uživatelské rozhraní. Tato práce se zabývá rozhraním na pomezí komunikace člověka a počítače. Dvě odlišná prostředí. Počítačem je konkrétně myšlen ERP systém, který svému uživateli poskytuje data a ta podle pokynů zpracovává.
3.1
Historie uživatelského rozhraní ERP
První interakce se objevovaly ještě dříve, než je kdokoliv stihl pojmenovat. Kouřové signály Indiánů v Americe, pomocí kterých se bylo možné dorozumívat na veliké vzdálenosti. O mnoho let později vzniklo první komunikační rozhraní. Samuel Morse ve třicátých letech devatenáctého století vynalezl jazyk, kterým se bylo možné dorozumět díky přenosu jednoduchých elektromagnetických signálů. Nejen, že vynalezl jazyk, ale také rozhraní, pomocí kterého bylo možné komunikovat. Jedná se o první komunikační rozhraní, 11
3. Uživatelské rozhraní které se rozšířilo masově po celém světě. Přesto, že jeho použití je složité. Uživatel musí znát přesně používaný kód a nesmí udělat chybu, protože oprava neexistuje.[40] U prvních grafických rozhraní bylo velikým úspěchem už to, že se je dařilo zobrazit a nějakým způsobem ovládat. Technologie byly teprve v plenkách a rozhraní tvořili obvykle inženýři, kteří systém programovali. Z jejich pohledu tedy ideálním rozhraním bylo takové, jenž přesně kopírovalo vnitřní strukturu systému. Protože tu oni znali velmi dobře. Vyráběli rozhraní pro sebe, aniž by si uvědomovali, že je rozhraní učeno uživatelům, kteří systém neznají. Obecně v začátcích informačních technologií platilo, že uživatel komunikoval s rozhraním a přizpůsoboval se jeho potřebám. Takové byly hardwarové a softwarové nároky. Technologie by měly sloužit člověku a ne naopak, proto se role otočily a aktuání snahou je, aby rozhraní komunikovalo s člověkem tak, jak je to člověku přirozené. Nejlépe takovým způsobem, aby komunikační rozhraní vůbec nevnímal a považoval je za přirozené. Na smazání rozhraní mezi člověkem a počítačem se aktuálně pracuje v oblastech jako zpracování řeči a monitorování pohybu. Nyní se zaměříme na vývoj uživatelských rozhraní ERP systémů od prvopočátků až k nejnovětším trendům. 3.1.1 Historie SAP R/3 Společnost SAP, která vznikla v roce 1972, kdy se osamostatnilo pět inženýrů z IBM, je od prvopočátku až do dnes průkopníkem v oblasi ERP systémů. Je také největší společností s podílem 60% v celosvětovém ERP průmyslu. Historie společnosti poskytuje kompletní průřez vývojem uživatelského rozhraní.[6] 3.1.1.1 SAP R/2 Za první ERP systém je považován SAP R/2 z roku 1979, který se spouštěl na sálovém počítači s centralizovanou databází. Pro tento systém byl využíván hardware Siemens 7738 v kombinaci s IBM/370-148, který byl brzy nahrazen výkonějším IBM 4341. Rozhraní bylo simulováno v terminálu a bylo dostupné pro Unix, OS/2 i Windows. [21] 3.1.1.2 SAP R/3 verze 1.0 a 1.1 Po několika letech práce a investicích do vývoje, které v roce 1989 čítaly 33% výdělků celé společnosti, byl v roce 1991 v Hanoveru poprvé prezentován 12
3. Uživatelské rozhraní
Obrázek 3.1: Terminálové rozhraní SAP R/2 [22] systém SAP R/3. Přinášel jako první uniformní grafické rozhraní. To neobsahovalo žádné grafické elementy jako rámečky, checkboxy, radiobuttony, záložky, ikony, nebo jiné pokročilé prvky. Rozhraní se v podstatě nelišilo příliš od SAP R/2. Přibylo menu a pushbutton bar, který se nacházel ve spodní části obrazovky a zobrazoval nejdůležitější funkční klávesy. Verze SAP R/3 1.1 byla rozšížena o barevné podbarvení polí pro vstup dat. Analogie se vzhledem dnešních formulářových polí. Také přinášela klávesové zkratky pro rychlý přístup k menu a možnost ovládání pouze klávesnicí. Vzhled rozhraní u první verze měl tendence se blížit rozhraní OS/2, zatímco verze 1.1 se upínala k OSF/Motif vzhledu určeným pro Unix. [23] 3.1.1.3 SAP R/3 verze 2 a 2.1 Další verze systému přišla v roce 1994. Primárním operačním systémem se stává MS Windows 3.1. Další podporovaná rozhraní jsou OSF/Motif, OS/2 a Mac OS. Přináší vzhled obdobný Windows. Neobsahuje žádné vodicí tečky. Podbarvená pole pro vstupní data dostávají 3D vzhled. Kromě menu se objevuje ještě toolbar, který obsahuje ikony. Objevují se také první grafické elementy jako checkboxy, radiobuttony, rámečky, tlačítka a seznamy. Vzhled Windows GUI se stává standardem. Na obrázku 3.3 je příklad rozhraní SAP R/3 verze 2.1. Toto rozhraní nebyla reálná Windows aplikace, ale jednalo se o simulovaný vzhled v terminálu.[22, 13
3. Uživatelské rozhraní
Obrázek 3.2: Terminálové rozhraní SAP R/3 verze 1.1 [22]
14
3. Uživatelské rozhraní 24]
Obrázek 3.3: Rozhraní v terminálu simulující vzhled Windows (SAP R/3 verze 2.1) [22]
3.1.1.4 SAP R/3 verze 3 a 3.1 Nejzásadnější změnou v rozhraní byl přesun aplikace z terminálu do prostředí operačního systému Windows. Třetí verze SAP R/3 byla uvedena v roce 1996 a jednalo se o aplikaci pro Windows 95. Novinkami bylo proporcionální písmo, záložky či plochá tlačítka.[22, 24] 3.1.1.5 SAP R/3 verze 4 Stejně jako nabývá systém na objemu co do funkcionality, stejným způsobem přibývají prvky, které jsou součástí GUI. Textová pole, oddělovače, stromové struktury a mnoho dalších. Obrazovky obsahují více informací údajně kvůli redukci navigačních prvků. Například ikony lze nalézt i jinde v rozhraní než pouze v toolbaru. Změn se dostalo i tabulkám.[22] 15
3. Uživatelské rozhraní
Obrázek 3.4: GUI SAP R/3 verze 3 ve Windows 95. [22]
16
3. Uživatelské rozhraní
Obrázek 3.5: Zvyšující se složitost rozhraní SAP R/3 verze 4.5 [22]
17
3. Uživatelské rozhraní 3.1.1.6 SAP R/3 verze 4.6 a novější Společnost SAP se rozhodla slepě nenásledovat HIG1 v prostředí Microsoft Windows ani jiného operačního systému, ale nechali si vytvořit vlastní značkový vizuální styl od společnosti Frog Design. Ten vycházel z prvků rozhraní MS Windows. Součástí nového designu byl výzkum zaměřený na optimalizaci uživatelského rozhraní. Společnost byla k tomuto kroku vedena obrovským nárůstem funkcí programu a nutností optimalizace uživatelského rozhraní z důvodu přesycenosti. Výsledkem byl vzhled aplikací na první pohled rozeznatelný od konkurence a uživatelské rozhraní, které dokázalo běžnému uživateli snížit čas strávený vykonáváním úloh až o 50%. Nové UI šetří tisíce úloh na jednoho uživatele za den.[22, 25] Společnost SAP si vytvořila vlastní guidelines pro uživatelská rozhraní.2 K tomuto kroku došlo v roce 2000. Následně se uživatelská rozhraní SAP vyvíjela po malých částech, což umožňovaly časté aktualizace přes Internet.
Obrázek 3.6: Uživatelské rozhraní SAP R/3 verze 4.6 [22]
1. Human Interface Guidelines je sada doporučení pro uživatelské rozhraní v operačním systému. Typicky jsou tyto směrnice navrženy za účelem zachování homogenity prostředí, ve kterém je aplikace navrhována. 2. Guidelines pro SAP R/3 dostupné na http://www.sapdesignguild.org/resources/ MiniSG/index.htm.
18
3. Uživatelské rozhraní 3.1.2 Historie UI MS Windows Od roku 1990 poskytuje společnost MS Windows nejrozšířenější operační systém na světě. Vzhledem k majoritnímu podílu na trhu byla většina aplikací i ERP systémů vyvíjena právě pro operační systém firmy Microsoft. Starší verze systému Windows již nejsou nadále podporovány, guidelines nejsou oficiálně dostupné na webu společnosti a lze čerpat jen z archivu a jiných zdrojů. Novější systémy od verze Vista jsou dosud podporovány a jejich guidelines jsou stále dostupné. 3.1.2.1 Windows 95 Přináší první grafické uživatelské rozhraní systému Windows, které je založeno na stejném konceptu, jaký je běžný ve všech dalších verzích systému Windows. Obsahuje tlačítko Start, plochu, koš, taskbar3 , tři tlačítka pro ovládání oken – minimalizaci, maximalizaci a zavření okna.[26]
Obrázek 3.7: Uživatelské rozhraní MS Windows 95 [26]
3.1.2.2 Windows 98, ME, 2000 V rozmezí let 1998 – 2000 byly představeny tři verze operačních systémů firmy Microsoft. Windows 98 je systém určený primárně pro spotřebitele. Novinkou je panel rychlého spuštění nacházející se v taskbaru (Obázek 3.8). 3. Taskbar je lišta na spodní straně obrazovky, na kterou jsou minimalizována okna v operačních systémech Windows.
19
3. Uživatelské rozhraní
Obrázek 3.8: Panel rychlého spuštění
V systému Windows Milenium označovaného zkratkou ME se poprvé objevuje funkce Obnovení systému, s jejíž pomocí se dá obnovit konfigurace softwaru počítače k určitému datu, nebo do doby, než nastaly potíže. Svým způsobem se i tato funkce vztahuje k rozhraní. Uživatel se nemusí obávat fatálních kroků, které by svým zacházením mohl způsobit.[26]
3.1.2.3 Windows XP Systém Windows XP představuje grafické schéma Luna, které je pro XP velmi specifické. Došlo k větším změnám grafiky systému jako barvy a tvary, koncept rozhraní zůstal zachován.[27]
Obrázek 3.9: Windows XP, grafické schéma Luna [26]
20
3. Uživatelské rozhraní 3.1.2.4 Windows Vista Operační systém Windows Vista přichází v roce 2006 s novým grafickým zpracováním rozhraní, které nese název Aero. Původní koncept je zachován, stejně jako u verze XP, ale dostalo se mu několika nových prvků.[28] Hlavní viditelnou změnou jsou poloprůhledné rámy oken aplikací. Takzvaný skleněný efekt, který je typický právě pro Aero. Do konceptu přibyly nové verze menu. Například Toolbar Menu, které je vhodné použít v případě, že se jedná o jednodušší aplikaci a její funkcionalita by spadala do jedné kategorie dosavadního menu.[29]
Obrázek 3.10: Toolbar menu [29]
3.1.2.5 Windows 7 Vizuální motiv Aero se udržel i do verze Windows 7. Došlo ke změně task baru, kde se okna jedné aplikace shlukují a při výběru se zobrazují jejich živé miniaturní náhledy. Aplikace lze také do taskbaru připnout, což nahrazuje panel rychlého spuštění.[28] Poprvé se zde objevují gesta pro ovládání oken. Po uchopení okna kurzorem myši lze měnit jeho velikost přetažením do stran či vrchu obrazovky a tím okno maximalizovat, nebo připnout na pravou a levou půlku obrazovky.[30] 3.1.2.6 Windows 8 Aktuálně nejnovětší verze operačního systému Windows je multimodální, nabízí dvojí rozhraní. Primárním se stalo takzvané rozhraní Metro (Obrázek 3.11), které je určené převážně pro přenosná zařízení. Rozhraní je ploché, vymezené různě velikými barevnými čtverci a obdélníky, které reprezentují aplikace. Sekundárním rozhraním je Aero z Windows 7, které slavilo celosvětový úspěch a je určeno pro náročnější práci s desktopovými aplikacemi.[31] 3.1.3 Ribbon User Interface Mezi produkty firmy Microsoft patří také kancelářský balík programů Office. Uživatelské rozhraní verze 2007 uvedlo novinku v podobě Ribbon User Interface (RUI). Do té doby bylo známé a nejpoužívanější rozhraní WIMP 21
3. Uživatelské rozhraní
Obrázek 3.11: Windows 8 rozhraní Metro [31] (Window, Icon, Menu, Pointing device – neboli Okno, Ikona, Menu, Označovací zařízení). RUI není rozhraním pouze MS Office, je přístupné i pro další programy operačního systému Windows. Případ MS Office lze snadno vztáhnout k problémům, se kterými se potýkají všechny komplexní programy. Mezi něž patří i ERP systémy.
Obrázek 3.12: Rozhraní WIMP v MS Word 2003
3.1.3.1 Software bloat Od první verze Microsoft Office uběhlo 24 let vývoje. S každou další verzí přibývaly nové funkce, které vizuálně zahlcovaly grafické rozhraní a vyžadovaly více zkušeností uživatelů i komplexního porozumění problematice počítačů. Tento fenomén je známý pod pojmem creeping featurism. Lze jej popsat 22
3. Uživatelské rozhraní
Obrázek 3.13: Rozhraní Ribbon v MS Word 2007 jako masivní rozšíření mezi diverzifikované publikum uživatelů s odlišnými nároky. Objevuje se též soupeření mezi softwarovými společnostmi známé jako feature war.
Obrázek 3.14: Software Bloat v MS Word 2003 [34] Příčinou narůstajících požadavků a soupeření bylo zahlcení rozhraní. Takzvaný software bloat, neboli nafukování software, definované jako: „Výsledek přidávání nových funkcí do systému až k bodu, ve kterém jsou benefity nových funkcionalit převáženy nároky na technické zdroje(RAM, místo na disku, výkon) a komplexnost užití.“ 23
3. Uživatelské rozhraní Definice Creeping featurism: „Tendence komplikovat systém přidáváním nových jednorázových funkcionalit bez systematického plánu.“ Ideálním příkladem nárůstu UI komplexity je Microsoft Word. Počet toolbarů a položek menu demonstruje komplexitu aplikace napříč jednotlivými verzemi. Na obrázku 3.15 je možné sledovat značný nárůst funkcí s verzí Word 97. [32, 33]
Obrázek 3.15: Podíl verzí na funkcionalitě MS Word [34]
3.1.3.2 RUI a uživatelé Ribbon User Interface byl reakcí právě na software bloat, ke kterému docházelo v programech balíku Microsoft Office. RUI poskytuje rychlejší přístup k více funkcím na jedno až dvě kliknutí myši. Při najetí kurzorem myši na tlačítko funkce se uživateli zobrazí náhled akce, kterou provede kliknutím. Je tak podporována předvídatelnost, která je jedním z pravidel návrhu UI dle kapitoly 3.2.1. Také se rozhraní pomocí takzvané Kontextové záložky přizpůsobuje obsahu, s jakým uživatel aktuálně pracuje. Často kritizovaným nedostatkem RUI je jeho velikost. Na výšku již v defaultním nastavení zabírá na menších monitorech podstatnou část prostoru pro zobrazení dokumentu. RUI přináší zcela nový koncept UI, který není vždy vítán mezi uživateli. Problematikou přijetí RUI se zabývá práce User Acceptance of the Microsoft Ribbon User Interface[33]. Studie zkoumá pomocí dotazníku vzorek 117 uživatelů textových editorů, z nichž pouze 68 má předchozí zkušenosti s programem Word 2007. Z textu vyplynulo, že více zkušení uživatelé jsou méně spokojeni s používáním RUI, a uživatelé, kteří velmi často pracovali s předchozími verzemi programu Word obsahující rozhraní WIMP, jsou také méně spokojeni s rozhraním RUI. Práce došla k závěru, že největším problémem RUI je zvyknout si na nově 24
3. Uživatelské rozhraní vytvořené uživatelské rozhraní. Nutno podotknout, že RUI není náhradou rozhraní WIMP, ale jeho alternativou, která je doporučena ve Windows Vista Human Interface Guidelines pro středně veliké aplikace sloužící k tvorbě obsahu. Rozhraní WIMP je doporučeno pro velmi složité4 a naopak jednoduché5 aplikace. Také kombinace rozhraní WIMP a RUI není považována za dobrou cestu. [33] 3.1.4 Web ERP ERP systémy v prostředí webu se začaly objevovat s masivním rozšířením Internetu. Jejich společnou vlastností je pouze to, že se spouští ve webovém prohlížeči a veškerá data jsou uložena na vzdáleném serveru, neboli v cloudu. Z hlediska rozhraní je prostředí webu velmi otevřené. Žádná striktní doporučení pro rozhraní neexistují, a tak je možné se setkat s nepřeberným množstvím různých přístupů k návrhu UI. Existují pouze běžná doporučení platná pro všechny webové stránky. Společnost SAP se jako první průkopník otevřela myšlence přesunout své služby na Internet. Nejprve pomocí webové prezentace své produkty pouze prodávala. Následně se rozhodla pro převod celého systému SAP R/3 na Internet. Základní pravidlo, od kterého SAP neodstupuje, je jednotný vzhled všech aplikací. Zároveň není možné do prostředí webu zkopírovat grafické rozhraní desktopu. Protože se v prostředí webu nabízí velmi mnoho možných variant přístupu, nechala si společnost SAP zpracovat vlastní HIG, kterými se striktně řídí pro všechny webové aplikace, které provozuje. SAP HIG se dělí na tři části.[35] ∙
SAP HTMLB Guidelines6
∙
SAP iView Guidelines for Java7
∙
SAP Interaction Design Guide for Internet Application Components8
První dvě směrnice slouží pro definici správného použití předdefinovaných technologií založených na HTML, nebo jazyce Java. Jedná se především o základní pravidla přístupnosti, pravidla pro rozložení rozhraní a pokyny pro vzhled, chování a použití dané technologie. Třetí z výše jmenovaných 4. 5. 6. 7. 8.
Například vývojářský software. Například simulace dětských deskových her. http://www.sapdesignguild.org/resources/htmlb_guidance/index.html http://www.sapdesignguild.org/resources/ma_guidelines_2/index.html http://www.sapdesignguild.org/resources/Web_Guidelines/INDEX.HTM
25
3. Uživatelské rozhraní je obsáhlá příručka interakčního designu, který propojuje prvky předchozích dvou. Open source systém iDempiere je od prvopočátku navržen pro webové prohlížeče, ale striktně stanovené HIG nikde neuvádí.
3.2
Obecná pravidla a pojmy z oblasti HMI
Pro správné fungování aplikace v určitém prostředí jsou definována Human Interface Guidelines (HIG). Nad nimi stojí ještě obecná pravidla návrhu uživatelských rozhraní platná napříč operačními systémy. Všechna tato pravidla je nutné dodržovat z důvodu vytváření správných mentálních modelů uživatele. Ten pak díky upevněným mentálním modelům bude schopen jednodušeji ovládat veškeré aplikace na dané platformě. 3.2.1 Osm pravidel pro návrh uživatelského rozhraní Jedná se o základní pravidla návrhu, která je třeba dodržovat napříč všemi rozhraními. Pochází z učebního textu předmětu PV252 Tvorba uživatelských rozhraní a hodnocení použitelnosti.[37] 1.
Usilujte o konzistenci.
2.
Respektujte širokou skupinu uživatelů.
3.
Poskytujte zpětnou vazbu.
4.
Navigujte uživatele.
5.
Předcházejte chybám.
6.
Umožněte uživateli vrátit se a buďte tolerantní k jeho chybám.
7.
Vytvářejte předvídatelné uživatelské prostředí.
8.
Nepřetěžujte krátkodobou paměť uživatele.
3.2.2 User centered design Filozofií User Centered Designu9 (UCD) je jednoduché prohlášení: „Uživatel ví nejlépe.“. Protože právě lidé, kteří budou výsledný produkt používat, musí sami nejlépe vědět, co chtějí udělat. Prací návrháře je zvolit správný způsob, jak se co nejpřesněji dozvědět, co by chtěl uživatel udělat. To ve zkratce 9.
Český význam je Design zaměřený na uživatele.
26
3. Uživatelské rozhraní znamená, že má-li být vyvíjeno rozhraní pro prodávání kávy, nejdříve by měli být osloveni lidé, kteří pijí kávu. První náznak UCD se objevil v roce 1955 s knihou Designing for people autora Henryho Dreyfusse. Ještě několik desetiletí však trvalo, než vznikl prostor pro změnu paradigmatu. Původní rozhraní byla odrazem toho, jak pracuje počítač. Vytvářeli jej techničtí pracovníci, kteří měli přehled o vnitřní stavbě a funkcionalitě systému a podle toho pak často navrhhovali i jeho rozhraní. Návrh rozhraní takzvaně probublal z vnitřních útrob systému až na povrch. Správný návrh na základě UCD by měl vycházet z požadavků definovaných uživateli a neměl by se zabývat technickým řešením, nýbrž soustředit se na uživatele a jeho komfort.[40] 3.2.3 Metafory Metafora (z řeckého metaférein, přenos) je přenesení významu na základě vnější podobnosti. Jedná se o přenášení principů z reálného světa do uživatelských rozhraní. Tato metoda je vhodná pouze pro principy uznané za obecně známé. Metafory přispívají k snazšímu pochopení, podporují učení a tvorbu mentálních modelů. Typickou metaforou v oblasti uživatelských rozhraní je koš, do kterého jsou v operačních systémech vyhazovány soubory. Tento softwarový koš opravdu funguje stejně jako fyzický koš. Nepotřebné do něho lze odhodit, ale dokud není vynesen, je možné v něm omylem odhozenou věc nalézt a obnovit. Metaforická může být například i celá aplikace. Kalkulačka, nebo poznámky v operačním systému Mac OS, které vypadají jako papírový poznámkový blok. Metafora nemusí být vždy vhodným řešením. Obzvláště v případě, že se nejedná o lehce identifikovatelnou metaforu, kterou navíc nelze považovat za obecně akceptovanou. U ikon, které také patří do rodiny metafor, platí podle International Standards Organisation, že musí být správně identifikovány dvěma třetinami testujících subjektů.[44] 3.2.4 Mentální model Mentální modely slouží k abstraktnímu pochopení fungování systému. Model funkce, který uživatel nosí v hlavě, může a nemusí reflektovat, jak věc funguje ve skutečnosti. Pochopitelně nejlepší možný způsob je, aby každý uživatel nosil v hlavě ten nejpřesnější model fungování systému. To není možné, protože tolik informací není člověk schopen uchovávat v paměti. Proto se pro 27
3. Uživatelské rozhraní uživatelská rozhraní používají zjednodušené modely, které není tak těžké si zapamatovat a zároveň jsou dostatečné pro ovládání systému. Ideálním příkladem je třeba automobil. Každý řidič dokáže bez problému otáčet volantem, šlapat na pedály, řadit atd. Ale ne každý řidič má přesnou představu o tom, co se s autem děje ve chvíli, kdy otáčí volantem, nebo sešlapuje spojku. Takže pokud by řidiče automobil informoval o detailech jako „Momentálně vstřikuji palivo do prvního válce.“, rozhodně by se řidiči naučili, co se přesně děje v průběhu jízdy, ale k ničemu by jim to nebylo, protože pomocí zjednodušeného rozhraní se dokáží dostat z místa A na místo B. K tomuto účelu je primárně automobil určen.[40] Existuje ještě model prostoru, který uživatelé také nosí v hlavě, a pomáhá jim při orientaci v mapě systému. V ideálním případě bude mít uživatel mapu systému vždy kompletní v paměti. Ve skutečnosti si je schopen zapamatovat jen určitý počet kroků, další tuší, ale není si jistý, a ty úplně vzdálené si jen stěží vybavuje. To souvisí také s krátkodobou a dlouhodobou pamětí. 3.2.5 Mapování Mapování popisuje vztah mezi ovládacím prvkem a ovládaným objektem. U přirozeného mapování není třeba přemýšlet, ihned je jasný vztah mezi ovladačem a objektem. Špatné mapování nutí uživatele přemýšlet a přerušuje tak hladký průchod systémem. S tím souvisí mentální modely a vytváření návodnosti systému. Neboli to, jak je systém schopen uživatele přirozeně vést rozhraním.[43] S mapováním souvisí takzvaný Poka-Yoke princip založený na omezeních schválně vložených do systému za účelem prevence chyb. Příkladem mohou být šedivé neaktivní ikony, nebo rozhraní pro připojení konektorů. Každý konektor má jiný tvar, aby nedocházelo k jejich záměně při připojení. Svým specifickým tvarem může konektor napovídat do jakého tvaru rozhraní bude pasovat, tím je mapován.[40] 3.2.6 Zpracování informací Chybu programátora systému je obvykle možné odhalit ihned, protože aplikace nebude fungovat. Obtížnější je to s uživatelským rozhraním. Chyba v návrhu rozhraní může způsobovat nechuť práce se systémem, přílišnou unavenost a podobné symptomy. Její identifikace není tak jednoduchá a jednoznačná. Uživatelské rozhraní různě zatěžuje naši paměť a vnímání. Jako první na rozhraní reaguje senzorická paměť, kde se vjemy uchovávají v řádu sekund. 28
3. Uživatelské rozhraní Tato paměť rozpoznává například pohyb. Krátkodobá paměť je schopna si udržet informace související s určitou činností po dobu, kdy je činnost prováděna. Přístup k paměti je velice rychlý. Kapacita je omezená pravidlem 7±2. Tato čísla definují počet kusů informací, které si je uživatel schopen v paměti uchovat. Obecným pravidlem je krátkodobou paměť nepřetěžovat. Informace v krátkodobé paměti se obnovují velice rychle. V řádu sekund je možné mít v krátkodobé paměti kompletně nový seznam informací. Dlouhodobá paměť je podporována učením. Vymazání některých informací je nemožné, jiné se mažou velice pomalu. Má velikou kapacitu. Přístup do paměti trvá déle. Jedná se o sémanticky strukturovanou paměť faktů, zkušeností i konceptů. Výše zmíněné metafory využívají právě dlouhodobé paměti.[41] Z hlediska dlouhodobé paměti je správné podporovat dobré návyky pro ovládání rozhraní. To je podpořeno dodržováním obecných pravidel návrhu rozhraní i HIG. Uživatel je tak rychleji schopen se v aplikaci orientovat a uložit si do paměti správné mentální modely, které mu v budoucnu usnadní používaní všech dalších aplikací, které se těmito pravidly řídí. 3.2.6.1 Tvarová psychologie – Gestaltpsychologie Tvarová psychologie vychází z německého názvu gestalt, které v překladu znamená tvar. Výchozí myšlenkou tvarové psychologie je předpoklad, že psychické celky nejsou tvořeny spojováním jednotlivých prvků, ale jsou to celky struktury uspořádané od samého počátku. Tvaroví psychologové prokázali pomocí experimentů, že člověk tíhne ke spojování rozpojeného a ve zcela náhodně umístěných bodech má tendenci vidět určitý význam. Má tendenci tíhnout k takzvaným „dobrým tvarům“, kterým odpovídá již známá struktura v mozku. Jedinec se tyto tvary nesnaží hledat, ale automaticky je vnímá kolem sebe i v sobě. Viz jednoduchý příklad na obrázku 3.16. Je důležité, co na obrázku vidíme a co se tam opravdu nachází. Vidíme bílý trojúhelník, ale ve skutečnosti jsou zde pouze tři kruhové výseče.[42] 3.2.7 Funkce a forma Forma reprezentuje vzhled produktu a funkce jeho poslání. Již v roce 1896 prohlásil architekt Louis Sullivan: „Form follows function“. Do českého jazyka přeloženo jako Forma sleduje funkci. Toto tvrzení platí až dodnes a nejen mezi architekty. Lze je jednoduše vztáhnout k návrhu rozhraní. Pokud 29
3. Uživatelské rozhraní
Obrázek 3.16: Takzvaný „Dobrý tvar“
je vytvářen produkt, u kterého se v první řadě požaduje, aby plnil svůj účel, pak tomu jeho vzhled zcela postačuje.[38] „Tou měrou, jak se rozvíjí kultura, ornament mizí z užitkových předmětů. (...) Chci-li jíst perník, zvolím pravoúhelník velmi přesný, a ne kus, jenž představuje srdce, miminko, nebo husara. Člověk XV. věku by mi nemohl rozumět. Ale všichni moderní lidé mi rozumějí.“
Ornament a zločin, Adolf Loos[39]
3.3
Desktopové aplikace
V anglickém jazyce se tento termín objevuje jako application software. Jedná se o počítačové programy(aplikace), které jsou spouštěny v operačním systému (system software) a přinášejí uživateli konkrétní funkcionalitu. Operační systémy prošly dlouhým vývojem. Jejich rozhraní se ustálilo a je obecně považováno za nejlepší aktuálně dostupné. Napříč operačními systémy jsou dodržována pravidla, avšak každý systém nese svá specifika. Při návrhu aplikace pro konkrétní operační systém je doporučeno se řídit pomocí HIG. Desktopové aplikace operačního systému jsou malé části specifikující prostředí, kde je systém používán, a které dodržují jeho směrnice. 30
3. Uživatelské rozhraní 3.3.1 Human Interface Guidelines HIG je soubor doporučení a pravidel, které by měly splňovat aplikace konkrétního operačního systému. Nejedná se pouze o základní pokyny, ale o velice detailní specifikaci, jež se vyvíjela několik let. Lze se setkat s přesnými rozměry částí formulářů, definicemi vzdálenosti prvků a mimo jiné i definicí jak správně pojmenovávat jednotlivé položky v menu. Nemá význam zde popisovat detailně celé HIG, protože by takový seznam rychle zestárl. Guidelines se mění často s každou novou verzí systému. Aktuální HIG bývají zpravidla dostupné ve vývojářské části webu výrobce operačního systému. Aktuální příklady HIG ∙
MS Windows HIG http://msdn.microsoft.com/en-US/windows/ desktop/aa511258.aspx
∙
Apple OS X HIG https://developer.apple.com/library/mac/ documentation/UserExperience/Conceptual/AppleHIGuidelines/ Intro/Intro.html
3.3.2 Časté chyby Chyby se lze dopustit nedodržením HIG. Existuje-li i pro takové porušení dobrý důvod, nemusí se jednat o vadu. Je možné se setkat s problémy rozhraní, které nejsou chybami, ale vznikají kvůli evoluci informačních technologií. Například zahlcení menu, nebo rozhraní pro mobilní zařízení.
3.4
Webové aplikace
Desktopové aplikace jsou spouštěny v prostředí operačního systému a měly by dodržovat pravidla definovaná systémem. K webovým aplikacím se přistupuje z webových prohlížečích. To jsou programy operačního systému. Pomocí webu se tedy aplikace dostávají na třetí úroveň. První jsou operační systémy, ty tvoří absolutní základ komunikace s hardware a umožňují jeho ovládání. Druhá úroveň patří desktopovým aplikacím, které dodávají operačnímu systému specifickou funkci, a poslední jsou webové aplikace, přístupné skrze aplikaci instalovanou v operačním systému. Na rozdíl od uživatelského prostředí operačních systémů neposkytuje prostředí prohlížečů žádné jednotné směrnice, které by přesně specifikovaly vzhled webových stránek. To proto, že vzhled webových stránek není definovaný prohlížečem, ale samotnými tvůrci webu. 31
3. Uživatelské rozhraní Funkcí webových stránek je prezentovat informace. K tomu slouží značkovací jazyk HTML. Ten je tvořen přesnou specifikací, která dodržuje základní pravidlo form follows function. Bohužel se vývoj HTML nebyl schopen flexibilně přizpůsobovat aktuálním potřebám uživatelů Internetu. Z toho důvodu vznikly moduly jako Flash, Silverlight, či Java plugin. Ty se musí instalovat dodatečně do prohlížeče, aby byl schopen zobrazit obsah. Existují také metody, jak změnit vzhled HTML tak, že dojde k upřednostnění formy před funkcí. Z požadavků uživatelů tak vzešlo umělecké prostředí bez pravidel, kde na každém webu vzniká jedinečné dílo. Pravidla uživatelského rozhraní, existujíli, jsou určena autorem webu. Spočívají v základních pravidlech a velice těžko lze hodnotit kvalitu návrhu a porovnávat ji napříč weby. Jsou sepsána doporučení pro webové uživatelské rozhraní, ale liší se od autora, stáří i cíle rozhraní. Žádná doporučení, týkající se uživatelských rozhraní, nejsou v prostředí webu uznávána celosvětově a striktně jako HIG operačních systémů. V únoru roku 2014 vyšla zatím poslední nefinální specifikace HTML510 , které doplňuje zastaralý značkovací jazyk o nové možnosti implementace moderních prvků. Ani to není jednoznačným signálem ke sjednocení webových uživatelských rozhraní. Ve vývoji webových rozhraní lze sledovat jistou analogii s historií těch desktopových. V prvních fázích vývoje dektopového rozhraní bylo úspěchem, že se vůbec podařilo nějaké rozhraní vykreslit pomocí příkazového řádku. GUI se stalo nedílnou součástí počítačů, což postupně vedlo k myšlenkám optimalizace pro uživatele. Dnešní vývoj technologií a webu probíhá mnohem rychleji, než v ranné fázi prvních rozhraní, a proto je složitější a delší cesta k sjednocení v prostředí webu. Původní záměr webových stránek je do dnes zachován. Primárně prezentují informace. Na přelomu tisíciletí se výraznějí prosazoval termín Web 2.0, který zavádí novou definici webu. Dosud byl obsah tvořen autorem webové stránky a uživatelé mohli data pouze konzumovat. Nyní jsou i uživatelé webu schopni vytvářet obsah a zároveň ho i konzumovat. Web se změnil z jednostranného komunikačního kanálu na platformu, na které je možné stavět navzájem komunikující rozsáhlé systémy.[45] Web zůstává volným prostředím pro uživatelský prožitek, protože zde mohou vznikat různé typy rozhraní. Konzumní, produkční i jejich kombinace. V prostředí Internetu se nacházejí weby, které slouží jako marketingové přehlídky produktů doplněné o videoukázky a zvukové stopy, ale též produkční 10. http://www.w3.org/TR/html5/
32
3. Uživatelské rozhraní informační systémy vyžadující celodenní soustředění uživatele. Záleží pouze na autorovi webové stránky, jaký směr zvolí. Nutností je dodržovat guidelines určené pro jeden konkrétní web a vyvarovat se odchylkám. 3.4.1 Časté chyby U desktopových uživatelských rozhraní je chybou porušení HIG. U webových rozhraní se težko spcifikuje, kdy došlo k opravdovému porušení pravidel, protože nejsou žádná obecně určena. Chyby lze identifikovat při porušení základních pravidel tvorby rozhraní, ale ta nejsou definována striktně a jde spíše o doporučení, která mohou nabývat subjektivního rázu. Chyby oproti směrnicím mohou vzniknout pouze v případě, že má webová služba svoje vlastní guidelines navrhnuté. Příkladem je společnost SAP, která pro převod systému R/3 na web zavedla vlastní HIG (více informací v kapitole 3.1.1.6). Dodržováním takových směrnic lze dosáhnout kvalitního rozhraní i v rámci vlastního prostředí webového systému. A díky nim je následně možné identifikovat chyby. V kapitole 3.1.3.1 je zmíněný software bloat na desktopových ERP systémech, které mají menu zahlcené velikým množstvím funkcí. V HIG operačních systémů existují pokyny jak se zahlceným menu zacházet. Metody jako progressive disclosure11 , kaskádové menu a další zjednodušují uživateli použití složitého menu. Přesun do prostředí webu a poskytování rozsáhlých systémů formou SaS přináší software bloat do webového produkčního prostředí.
3.5
Mobilní zařízení
První přenosná dotyková zařízení se objevovala v přibližně v roce 1992. Byla to PDA od firmy Palm a Apple. Ovládala se dotykovým perem a jejich UI víceméně kopírovalo rozhraní desktopových aplikací. Bez většího úspěchu zmizela z trhu. Boom zaznamenal až příchod telefonu iPhone od firmy Apple v roce 2007. Nekopíroval rozhraní desktopových operačních systémů, ale přinesl nový koncept.[46] Návrh UI pro iPhone kladl důraz na to, kde se takové zařízení typicky používá. Není k dispozici plnohodnotná klávesnice jako u počítače. Uživatel se nachází v pohybu, na cestách a mnohdy se špatným internetovým připojením. Telefony i tablety jsou určeny ke konzumaci obsahu v pohybu, nikoliv 11. Český překlad progressive disclosure je postupné rozvíjení. Jedná se o metodu, kdy je zobrazena pouze významnější část menu a ta méně používaná, tudíž i méně významná, je připravena se zobrazit až po kliknutí například na tlačítko „více“.
33
3. Uživatelské rozhraní v klidném prostředí, kde se uživatel může plně soustředit. Hledá-li uživatel informace na mobilním zařízení, obvykle se jedná o základní data, nikoliv o detailní analýzy. A téměř výjimečně se tato zařízení používají k vytváření obsahu. Typickým textovým vstupem je krátká zpráva, odpověď na email, nebo vyplnění formuláře na webu. Jedná se o zařízení, která zprostředkovávají prezentaci obsahu ve formě adekvátní k prostředí, v jakém se obvykle uživatel mobilního zařízení nachází. Tedy mobilní – pohyblivý.
3.6
Formuláře
Formuláře jsou důležitým prvkem produkčního prostředí. Jako jediný element slouží výhradně pro vstup dat od uživatele. HTML formuláře jsou definované standardem. Pokud je standard dodržen, neměl by být žádný problém ovládat formulář pouze z klávesnice. Bohužel HTML standard není natolik flexibilní, aby okamžitě reflektoval veškeré změny uživatelského rozhraní webu. Například při zadávání data je vhodný prvek kalendář pro výběr konkrétního termínu. Ten nativně obsahuje až specifikace HTML5, které se již používá na mnohých webech přesto, že není oficiálně uvolněno. Bohužel čekání na nový standard HTML trvalo moc dlouho, a tak vznikly různé knihovny, které dokáží kalendář v prohlížeči simulovat. Upravený HTML prvek formuláře nemusí mít stejnou podporu klávesových příkazů jako standardní prvky HTML fomuláře. Nefunkčnost základních příkazů k ovládání klávesnicí nutí uživatele ovládat rozhraní myší, což zkušené uživatele zpomaluje při práci. TAB Shift + TAB Mezerník
Přechod na další prvek formuláře. Předchod na předchozí prvek. Zobrazení a volba nabídky typu select. Volba zaškrtávacích polí typu checkbox, radio a multiselect. Enter Odeslání formuláře. Šipky Procházení nabídek. Tabulka 3-1: Klávesové zkratky webových formulářů
3.7
Menu
Součást uživatelského rozhraní, která je nepostradatelná a zároveň natolik samozřejmá, že se nad ní uživatel nepozastavuje. To je ideální bod, do kterého by měl dospět každý důležitý prvek rozhraní. Tradiční návrh menu 34
3. Uživatelské rozhraní v operačních systémech pracujících s okny je uznáván za správný. Ve webovém prostředí není ustálený model menu a simulování desktopoveho rozhraní na webu se nedoporučuje. 3.7.1 Cíl menu Hlavním cílem menu je odhalit uživateli, co má k dispozici za funkce, jak se k nim dostane, a co se stane, až vybranou položku zvolí. Dalšími cíli jsou seznámit jej s klávesovými zkratkami a ikonami reprezentujícími nejčastěji používané funkce. Jedná se o nejúčinnější metodu, jak představit uživateli možnosti produktu. 3.7.1.1 Pedagogic Vector Toolbary obsahující ikony se rozšířily v roce 1989. Ikony jsou stavebním kamenem Pedagogic Vectoru. Položky menu nejčastěji používaných funkcí zobrazujích společně s názvem také ikony a klávesové zkratky. Postupným používáním menu se v dlouhodobé paměti ukládají tyto symboly reprezentující danou funkci, až je uživatel schopen k funkci přistupovat bez obtíží přímo z toolbaru a nemusí používat menu. Přirozeně si zapamatoval symbol, nebo zkratku. V případě klávesových zkratek odpadá jakákoliv interakce s GUI a funkce je spouštěna příkazem přímo z klávesnice. Je to přirozený způsob učení pomocí nenuceného opakování. Nezkušení uživatelé nemají mít problém s použitím aplikace, protože menu je stále přístupné ve své základní formě a navádí postupně začátečníka k cíli. Středně pokročilý uživatel využívá ikony a příležitostně hledá v menu. Velmi zkušený uživatel používá pro nejčastější funkce klávesové zkratky, ikony toolbaru a jen zřídka vyhledává v menu. [43] 3.7.2 Rozdělení menu dle míry přizpůsobitelnosti Každý uživatel software je jiný, má odlišné nároky, jinak zachází s počítačem a používá odlišné funkce v různé míře. Rozhraní menu se může přizpůsobovat potřebám konkrétního uživatele a tím zefektivnit a zrychlit jeho práci s rozhraním. Existují tři přístupy k optimalizaci menu: statické, adaptibilní a adaptivní. 3.7.2.1 Statické Pozice funkcí statického menu jsou předem definovány a uživatel nemá za žádných okolností šanci manipulovat s položkami menu. 35
3. Uživatelské rozhraní 3.7.2.2 Adaptibilní Tento přístup se považuje za zlatý střed. Původní menu je statické, ale uživatel má možnost si je upravit podle svých požadavků. V případě, že uživatel není pokročilý, nemusí si menu upravovat a to zůstane nezměněné. 3.7.2.3 Adaptivní Jedná se o extrémní případ menu, které se automaticky upravuje podle toho, jak s ním uživatel zachází. Klasicky nejčastěji používané funkce se řadí na první místa. Rozhraní se doslova mění uživateli pod rukama. Po delší době užívání takového menu by mělo vzniknout ideální rozložení pro jednoho konkrétního uživatele. 3.7.3 Porovnání Statického, Adaptibilního a Adaptivního menu Z článku A comparison of Static, Adaptive and Adaptable Menus[47] vyplynulo, že optimální statické menu je znatelně rychlejší než adaptivní. Uživatelé byli schopni chápat adaptibilní menu po krátkém představení. Za těchto okolností nebyla rychlost zacházení s adaptibilním rozhraním téměř vůbec odlišná od statického. Z kvalitativního průzkumu vyplynulo, že většina účastníků (55%) preferuje adaptibilní rozhraní. 3.7.4 Adaptivní rozhraní Boulevard Z předchozí kapitoly porovnávající tři způsoby zobrazení menu vychází nejhůře adaptivní rozhraní. Na Fakultě Informatiky Masarykovy Univerzity vzniká adaptivní rozhraní Boulevard. V jeho přístupu jsou zohledněna všechna negativa adaptivního přístupu a ta odpovídajícím způsobem řeší. Boulevard byl původně navržen a testován na OpenOffice.org. Později vznikl také prototyp pro ERP systém SAP. Adaptivní rozhraní má za cíl co nejvíce zefektivnit práci s rozhraním. V odvětví ERP systémů se jedná o zásadní věc, protože zrychlení práce s rozhraním může vést ke konkurenční výhodě systému i jiným benefitům. Za největší nedostatek adaptivního rozhraní jsou považovány systémem řízené změny v průběhu používání menu. Boulevard nemění původní statické menu a toolbary. Sám o sobě funguje jako přídavný panel zobrazený na straně pracovního okna. Je tady lehce oddělitelný dynamický a statický obsah. Navíc je schopen párovat sémanticky podobné funkce, takže například tlačítka Tučně, Kurzíva a Podtržení budou při sobě, i když nejsou využita naprosto srovnatelně. 36
3. Uživatelské rozhraní S délkou doby uživání adaptivního rozhraní se postupně vytváří ideální menu. Čím déle bude použito, tím více by se mělo modelovat do ideální podoby pro konkrétního uživatele. Problém ovšem nastává ve chvíli, kdy po roce užívání programu začne uživatel potřebovat novou funkci. Trvalo by poměrně dlouho, než by se tato nejnovější funkce objevila v nabídce Bloulevardu. Proto je zavedeno různé hodnocení starých funkcí používaných delší dobu a novinek mezi oblíbenými funkcemi uživatele. Jedná-li se o funkci, která je opravdu využívána nárazově, stejně rychle, jako se mezi oblíbenými funkcemi adaptivního rozhraní objevila, zase zmizí. Konkrétní výpočet oblíbenosti funkcí a další informace o systému Boulevard jsou k dispozici v článku Adaptive User Interface Personalization in ERP Systems.[48]
37
Kapitola 4
Hodnocení použitelnosti rozhraní a testování User Centered Design určuje, že požadavky na systém by měly pocházet od uživatele, který s ním bude pracovat. K tomu slouží metody získávání dat. Na jejich základě se následně vytvoří prototypy, které jsou podrobeny uživatelskému testování a hodnocení použitelnosti. Praktická příprava výzkumu může v praxi trvat i několik měsíců.
4.1
Použitelnost
Existují různé pohledy na použitelnost. Každý z nich ji definuje trochu jiným způsobem. Slovo samotné pokrývá velmi širokou oblast HCI. Proto je vhodné ji rozdělit na menší celky. Takto k definici přistupuje Jakob Nielsen a Ben Shneiderman. Dělí použitelnost na 5 menších částí: ∙
Snadnost naučení se ovládat systém – jak rychle uživatel zvládá základní úkony systému?
∙
Rychlost ovládání – jak efektivně je uživatel schopen ovládat systém?
∙
Poměr chyb a snadnost zotavení se – ke kolika chybám dochází? Dokáže se s nimi uživatel vypořádat sám?
∙
Zapamatovatelnost – je uživatel schopen pracovat stejně efektivně, jako při předchozí návštěvě systému?
∙
Spokojenost uživatele – jaký má uživatel pocit z práce se systémem?
Složením prvků výše uvedených vzniká skladba pěti různých pohledů, které se propojují a definují použitelnost. [52, 53]
4.2
Metody hodnocení použitelnosti
Použitelnost je možné hodnotit a nebo se jí snažit dosáhnout. Už těmito dvěma přístupy se dělí metody a techniky testování. Žádná z nich se nedá 38
4. Hodnocení použitelnosti rozhraní a testování považovat za univerzální. Každá je vhodná pro určitou fázi projektu a pro dosažení specifických cílů. Výsledek může být ovlivněn i skupinou, na kterou je metoda aplikována. Také není možné během testování navodit shodné prostředí s místem, kde bude software následně používán. Tyto i další faktory se odráží ve výsledcích testování. 4.2.1 Explorační Metody sloužící k získání nových informací. K objevení neznámých faktů a dat týkajících se projektu. Používá se zpravidla na začátku projektu k prozkoumání prostředí. Cílem je stavět na pevných základech. 4.2.2 Hodnoticí Frekventovaný způsob testování rozhraní. Používá se v průběhu vývoje a hodnotí se jím obvykle prototypy. Zkoumá a srovnává schopnost uživatelů plnit úkoly napříč porovnávanými verzemi. Používá dotazníky, A/B testování a další observační metody. 4.2.3 Ověřovací Ověřovací (též validační) metody lze použít nejčastěji ve finálních fázích projektu. Klade důraz na formální provedení – procesy, metody, zpracování výstupů. Cílem je ověření částí v kontextu celku. Testuje se jen malá součást rozhraní, ale sleduje se, jaký dopad má testovaný prvek na okolí. Například se může zkoumat čitelnost znaků na tachometru automobilu. Kontext odhalí, že znaky jsou čitelné dobře, ale display oslňuje za určitých podmínek řidiče a tím ruší při jízdě. Tyto metody se obvykle plánují dlouhodobě. Jsou velmi důsledné a drahé. Výstupy jsou podrobné studie. 4.2.4 Příklady 4.2.4.1 Focus Group Specifická explorační metoda, které se najednou účastní 3–12 participantů a moderátor. Metoda probíhá formou řízené diskuze. Moderátor udržuje správný směr diskuze pomocí vhodných otázek, zabraňuje odbíhání od tématu a klade doplňující otázky. Tato metoda běžně trvá hodinu až dvě, obvykle do úplného vytěžení informací. Je založena na diskuzi, během které se participanti mohou provokovat svými názory a tím dát vzniknout novým pohledům na zkoumaný objekt. Schéma typického průběhu této techniky se nachází v elektronické příloze. [50, 51] 39
4. Hodnocení použitelnosti rozhraní a testování 4.2.4.2 Strukturované interview Během strukturovaného interview pokládá tazatel otázky jednomu účastníkovi. Sada otázek je předem připravena a má pevně stanovenou strukturu. Není zde prostor pro další diskuzi. Účastník testu odpovídá svými slovy a tazatel označuje nejvhodnější z předpřipravených odpověďí v listu, který má k dispozici pouze on sám. Používá se v případě, že je pevně stanovený typ výstupních dat. Volnější forma strukturovaného interview povoluje tazateli klást doplňující otázky. Výsledkem mohou být i jiné odpovědi, než předem definované v listu. [50, 51] 4.2.4.3 Dotazník Dotazník nabízí flexibilní způsob sběru velkého množství dat. Používá se při hodnocení designu, použitelnosti, spokojenosti uživatelů, testování chyb i pro získání názoru uživatele. Tvorba dotazníků není jednoduchá disciplína, přesto, že by se to tak mohlo zdát. Každá otázka musí mít svůj důvod a musí být promyšlena do hloubky. Striktní pravidla neexistují, ale lze se setkat s různými sadami návodů. Níže nastíněný postup vychází z knihy Human Factors Methods: A Practical Guide for Engineering and Design[50]. ∙
Dříve, než se vztáhne ruka k dotazníku, je potřeba definovat, jaké má přinést výstupy. Co by měl zjistit za informace.
∙
Vhodná volba respondentů je klíčová. Reprezentativní vzorek by měl být rozmanitý, ale přesto stále odpovídající cílům.
∙
Při sestavování dotazníku je třeba v začátku představit informace potřebné pro uvedení do problému. Zároveň úvodem nesmí být participant nijak ovlivněn v následujících odpovědích. Klasifikační (Screeningová) část dotazníku zjišťuje data o participantovi. Obvykle věk, pohlaví, zkušenosti s problematikou, vzdělání apod. Tyto informace jsou osobní, a proto by neměly být vyžadovány v případě, že to není pro zpracování výsledků nutné. Otázky týkající se problematiky jsou až ve třetí části dotazníku. Je důležité, aby vedly k dříve definovanému cíli a aby byl typ odpovědi zvolen adekvátně k očekávatelné formě. V závěru dotazníku by měl být uveden kontakt na tazatele, případně komentář k problému či dotazníku.
∙
Často opomíjenou avšak doporučenou částí přípravy je pilotní test. Ten se provádí před oficiálním nasazením dotazníku. Pomáhá odhalit 40
4. Hodnocení použitelnosti rozhraní a testování chyby a nedostatky. Pilotní testy se provádějí na menším vzorku cílových respondentů i specialistech zkoumaného oboru. ∙
Způsob organizace průzkumu může být také různý. Ideální variantou je, když se sejdou všichni respondenti ve stejnou dobu na jednom místě a vyplnění probíhá současně. Takový průzkum bývá náročné uspořádat. Provádí se také korespondenční průzkum, ten se bohužel setkává s nízkou mírou odpovědí – přibližně 10% účast.
∙
Dostatečné množství dat je zpracováno statistickými metodami.
∙
Na úplný závěr patří prezentace výstupů z průzkumu a poděkování respondentům.
System Usability Scale Existují zavedené dotazníky, jako je právě System Usability Scale (SUS). Jedná se o standardizovanou formu dotazníku. Pochází z roku 1986 a vznikla na půdě společnosti Digital Corporation. SUS metoda je populární díky jednoduchosti a léta ověřeným postupům. Je vhodná například pro srovnávání alternativ v explorační fázi. Existují další podobné standardní dotazníky.[51]
4.3
Kvantitativní a kvalitativní
Metody lze dělit podle různých klíčů na objektivní a subjektivní, reálné a experimentální atd. Nejčastěji se lze setkat s dělením na kategorie kvalitativní a kvantitativní. Kvantativní metody spočívají v jevech objevujících se zpravidla v měřitelné podobě. Výstupem jsou statistické údaje, reprezentující skupinu dotazovaných. Používá se v pozdějších fázích vývoje rozhraní. Oproti tomu kvalitativní průzkum je založen na subjektivních výpovědích respondentů a na vnitřních psychologických pochodech. Je hůře interpretovatelný a neporovnatelný. Dokáže velmi dobře posloužit v explorační fázi pro zíkání povědomí o prostředí, kam bude aplikace zasazena. [49] 4.3.1 Typy otázek Otázky jsou nejdůležitější částí testů. Správná formulace a načasování může být stěžejní. Platí, že jednodušší otázky vyvolávají komplexnější odpovědi. V případě málo spontáních odpovědí je možné, že ještě existuje bariéra mezi tazatelem a respondentem. Případně to může značit vykonstruovanou a neupřímnou odpověď. 41
4. Hodnocení použitelnosti rozhraní a testování 4.3.1.1 Otevřené / Uzavřené Na uzavřenou otázku lze odpovědět jednoslovně ano či ne. Otevřená otázka vyzývá k širší odpovědi, vysvětlení i odhalení názoru. Rozpoutává diskusi a nechává více prostoru pro reakce. Typicky začíná slovy: jaký, co, proč, atp. 4.3.1.2 Přímé / Nepřímé Přímá otázka se týká podstaty věci. Nemá žádný skrytý význam. Obvykle se používá v kvantitativním výzkumu. Nepřímá otázka se ptá zdánlivě mimo téma, ale ve skutečnosti se snaží odhalit kus tématu. Její formulace zastírá pravý význam. Přímá otázka může být: „Máš raději maminku, nebo tatínka?“ a nepřímá „Když tě něco trápí, za kým jdeš?“. 4.3.1.3 Dle úlohy v testování ∙
filtrační – slouží k výběru správného vzorku uživatelů před testy
∙
kontaktní – motivují respondenty k ochotě odpovídat
∙
analytické – účelem je uspořádat a třídit informace
∙
demografické – používají se k určení sociální pozice respondenta
4.3.1.4 Škálové dotazy V přápadě potřeby porovnání výstupů z testů je vhodné zvolit techniku, kde se odpovědi měří na stupnici. Příkladem může být pěti stupňová Likertova Škála [54]. Jedná se o předem definované odpovědi na stupnici od 1 do 5, kde jedna je zcela souhlasím, tři nevím a pět znamená zcela nesouhlasím. Odpovědi dva a čtyři vyjadřijí souhlasím a nesouhlasím. Takto získaná data je možné nadále matematicky zpracovávat. Likertova Škála nejen že získává obsah postoje, ale i jeho přibližnou sílu.
42
Kapitola 5
Návrh menu webového ERP systému Na základě této práce a praktických testů uživatelského rozhraní vznikl prototyp obsáhlého menu ERP systému v prostředí webu. Níže je popsán průběh a výsledky návrhu i uživatelského testování provedeného ve spolupráci se společností CÍGLER SOFTWARE, a.s. Výsledný prototyp nabízí jedno z možných řešení přístupu k návrhu navigace ERP systémů.
Obrázek 5.1: Současné menu iDoklad.cz.
5.1
Explorace
Explorace, neboli průzkum, se v tomto případě dělí na dvě fáze. První spočívá v porozumění prostředí rozsáhlých ERP systémů. Jaké typy existují. Jak přistupují k uživatelským rozhraním. S jakými se potýkají problémy a jak je řeší. Kapitoly číslo dvě a tři shrnují důležité informace o prostředí, ve kterém jsou ERP systémy zasazeny. Na základě této faktické explorace vznikla sada domnělých požadavků na úpravy menu ERP systému. Tyto domněnky bylo třeba potvrdit či vyvrátit od uživatelů samotných systémů. 43
5. Návrh menu webového ERP systému Druhá fáze explorace spočívá v průzkumu mezi uživateli. Metodou Focus Group byla zkoumána skupina pěti uživatelů. Cíl Hlavním cílem bylo zjistit, jak se uživatelům pracuje s programem Money a iDoklad.cz. Zároveň bylo cílem získat názory od uživatelů, kteří se pravidelně setkávají se zahlceným menu ERP systémů. 1.
Vyžadují uživatelé adaptibilní menu? Dokáží s ním pracovat?
2.
Jakým způsobem zefektivňují svoje pracovní procesy?
3.
Jak používají uživatelé záložky v systémech Money?
Diverzita účastníků Zvolená skupina uživatelů byli čtyři pravidelní uživatelé některého ze systémů od společnosti CSW, a.s. a jeden uživatel z oboru marketingu, který příležitostně pracuje se systémem Money S3. Scénář U explorační metody formou Focus Group se nechává volný průběh diskuzi, která je pouze korigována moderátorem. Přesto je vhodné si předem připravit vlastní přehled témat a základních otázek, jež se k tématu vztahují, a které rozvinou diskusi správným směrem. Mind mapa s okruhy témat a vzorovými otázkami z testování se nachází v elektronické příloze. Průběh Diskuze se účastnilo všech pět respondentů zároveň. Dále byl přítomen zástupce společnosti CÍGLER SOFTWARE, a.s. jako pozorovatel. Role moderátora jsem se ujal já sám. Zapisovatel nebyl přítomen. Se souhlasem účastníků bylo použito záznamové zařízení. Výstupy 1.
Adaptibilní menu není součástí systémů Money ani iDoklad.cz. Uživatelé velmi rychle chápali jeho význam. Dle jejich názoru by se jednalo o užitečnou součást rozhraní, pokud by nezasahovala do klasického menu. 44
5. Návrh menu webového ERP systému 2.
Z nepřímých otázek vyplynulo, že si uživatelé vytváří vlastní menu pomocí záložek. Dále mají vytvořené svoje vlastní oblíbené položky, které fungují obdobně, jako ve webových prohlížečích. Nevyužívají je tak často, ale vědí poměrně přesně, kde by je hledali a jakým způsobem by přidali nové. Někteří využívají hojně klávesové zkratky.
3.
Záložky jsou poměrně nevýrazná součást systémů Money. Lehce lze přehlédnout fakt, že je možné používat více záložek zároveň. Nicméně zkušení uživatelé tyto záložky využívají k navigaci téměř výhradně. Záložky (Taby), se otevírají v prostoru mezi pracovní plochou a menu. Jednou z funkcí je možnost záložku zamknout. Díky tomu zůstane na svém místě při každém spuštění programu.
Obrázek 5.2: Záložky v systému Money S3
5.2
Papírový prototyp
Na základě celkové analýzy uživatelských rozhraní ERP systémů a interview s uživateli je navržen papírový prototyp. Prototypování na papír je velice jednoduché a efektivní. Pro tvorbu prototypu není potřeba žádný designérský software, ale pouze obyčejná tužka a papír. Podtrhuje nejdůležitější vlastnosti úvodních návrhů rozhraní. Není do nich vkládáno přehnané množství práce a je možné prototypy rychle upravovat opět pomocí tužky i v průběhu testování. Jedním ze základních pravidel je nepoužívat v prototypech barvy. Další informace o prototypování na papír je možné nalézt v knize Paper prototyping[55]. Papírové prototypy mají za úkol otestovat rozhraní na té nejzákladnější úrovni. Pro účastníky testu mohou být náročnější z důvodu vysoké abstrakce. 45
5. Návrh menu webového ERP systému Proto je nutné uživatele předem důkladně informovat a ujistit je, že oni sami se nepodrobují testu, ale slouží jako prostředek k testování papírového návrhu. Návrh Několik papírových prototypů bylo vytvořeno ještě před začátkem interview s uživateli. To z důvodu získání bližšího vhledu do problematiky a vytyčení cílů metody Focus Group. Po vyhodnocení uživatelských požadavků, vycházejících z explorace, byly vytvořeny postupně koncepty, které se snažily přizpůsobit všem nutným podmínkám. Těmi jsou: ∙
Musí obsahovat kompletní menu se všemi funkcemi systému.
∙
Mělo by nabízet oblíbené položky. Volené uživatelem a z části předpřipravené dle skupin uživatelů. Například účetní, skladník atp.
∙
Může obsahovat adaptivní menu.
Papírový prototyp přinesl nový koncept. Uživatelé ERP systémů nepřisupují do menu tak často, ale více používají své oblíbené položky, které mají otevřené a zamčené v záložkách. Jen příležitostně nastane situace, kdy musí použít menu. Z toho plyne fakt, že plnohodnotné menu může být částečně odsunuto do pozadí a prototyp upřednostní menu s oblíbenými položkami – sekundární menu. Zároveň platí, že uživatelé na blízkých pozicích zamykají obdobné záložky. Proto by se vždy pro konkrétní firemní strukturu navrhla sekundární menu s různými položkami, které by odpovídaly definovaným skupinám uživatelů ve společnosti. Tím by uživatelé od začátku používání softwaru získali verzi menšího menu ideálního pro jejich pozici a navíc by měli příležitost si je jednoduše upravovat přesunem pomocí myši. Klasické záložky zůstaly v návrhu zachovány ve vertikálním bloku. Nebylo umožněno je zamknout jako v systémech Money, ale je možné je otevírat přímo ze sekundárního menu a taktéž i z menu primárního, které bylo odsunuto do pozadí. Cíl Cílem této fáze testování bylo odhalit základní nedostatky návrhu už v jejich zárodku. Dříve, než se bude implementovat rozhraní do pohyblivého softwarového prototypu, získá návrh zpětnou vazbu už ve fázi konceptu. Tento přístup by měl přispět k hladšímu průběhu testování reálných prototypů. 46
5. Návrh menu webového ERP systému
Obrázek 5.3: Papírový prototyp: červená: tlačítko MENU, zelená: sekundární menu, modrá: záložky.
Obrázek 5.4: Hlavní menu prototypu je vertikální, aby mohlo obsahovat libovolné množství prvků. Červená: první úroveň menu, modrá: druhá úroveň menu.
47
5. Návrh menu webového ERP systému Průběh Testování se účastnilo šest respondentů jednotlivě. Každému zvlášť byl představen prototyp a jeho účel. Participanti sami za sebe ovládali rozhraní na papíře a moderátor prováděl změny prototypu pomocí připravených ústřižků. Celý test probíhal dle předem připraveného scénáře, který se nachází v příloze A.
Výstupy Všichni uživatelé byli schopni identifikovat klíčové ovládací prvky a pojmenovat je. Sekundární menu bylo mylně považováno za záložky a v návaznosti na tento problém si nebyli uživatelé jisti, co jsou položky ve vertikálním výpisu záložek. Plnohodnotné menu skryté pod tlačítkem budilo u některých uživatelů nedůvěru. Především proto, že nebylo zřejmé, jedná-li se o tlačítko, či pouze o označení líšty se sekundárním menu. Předem nastavené položky sekundárního menu byly přijaty bez obtíží. Úprava sekundárního menu měla probíhat přetažením položky z primárního menu do lišty toho sekundárního. To na první pokus odhalil pouze jeden z participantů. Ostatní hledali kontextové menu po použití pravého tlačítka. Mazání položek ze sekundárního menu přetažením do koše uživatelé většinou odhalili až po zkušenosti s přesunem položek v rámci menu.
5.3
Softwarový prototyp
Finální verze prototypu má za úkol sama reagovat na akce uživatele a snaží se maximálně přiblížit realitě. Protože se jedná o návrh rozhraní webového ERP systému, je i finální prototyp implementován pomocí technik využívaných k prezentací informací na webu.
Návrh Nová verze prototypu byla založena na předchozích výstupech. V softwarovém prototypu jsou spojeny záložky a sekundární menu v jeden prvek. V podstatě se jedná o záložky, které pořád zůstávají na svém místě, dokud je uživatel nevyhodí do koše. Záložky je možné si libovolně řadit, přidávat nové z menu i zbavovat se nepotřebných. Záložky vytváří sekundární menu a uchovávají v něm uživatelem používané agendy. 48
5. Návrh menu webového ERP systému
Obrázek 5.5: Softwarový prototyp. Červená: adaptivní menu, žlutá: sekundární menu, které je zároveň záložkami.
Obrázek 5.6: Hlavní menu vyvolané tlačítkem MENU vlevo nahoře.
49
5. Návrh menu webového ERP systému Adaptivní menu Prototyp počítá hodnocení jednotlivým prvkům menu podle toho, jak často jsou použity. Dle hodnocení se vykreslují nejoblíbenější funkce v postranním adaptivním menu. Algoritmus pro řazení položek je převzat z práce Adaptive User Interface Personalization in ERP Systems[48]. |𝑥| rank(x) = 𝑤 + (1 − 𝑤) 𝑇
∑︀
𝑝𝑖 ∈𝑃𝑥
(𝑞 − 𝑝𝑖 + 1) 𝑖=1 𝑖
∑︀𝑞
Funkce rank vypočítává důležitost jednotlivých položek v rámci navigace. První část rovnice vyjadřuje faktor frekvence užití. Druhá část, začinající výrazem (1 − 𝑤), počítá aktuálnost užití. Proměnná 𝑥 značí položku menu a |𝑥| počet aktivací této položky. T vyjadřuje celkový počet spuštění všech položek menu. Každý spuštěný příkaz se nachází po určitou dobu ve frontě 𝑞. Délka fronty 𝑞 se určuje implicitně a v této práci je nastavena na hodnotu 10. Byl-li příkaz spuštěn n krát v posledních 10 aktivacích menu, bude se i ve frontě nacházet n krát na různých pozicích. Množina 𝑃𝑥 obsahuje pozice výskytu příkazu x ve frontě q. Poslední spuštěná položka se nachází na pozici 1, nejdříve spuštěná na pozici q. Proměnná 𝑤 ∈< 0, 1 > ovlivňuje váhu relativní frekvence užití (dlouhodobého vzorku užití). Zde popsaná rovnice řeší problém upřednostňování déle používaných funkcí před novými popsaný v kapitole 3.7.4 Adaptivní rozhraní Boulevard. Rozhraní bylo maximálně zjednodušeno a zároveň splňuje vešekeré požadavky uživatelů. Je schopné vyhovět vysokým nárokům na obsah menu ERP systému. Prototyp je implementován jako webová stránka za použití technologií HTML, CSS, JavaScript s nadstavbou jQuery. Cíl Softwarové prototypy reprezentují finální verzi rozhraní. V případě potřeby by se prováděly testy v krátkých iteracích a vždy by se testovaly nejdrobnější změny. Cílem tohoto testování bylo ověřit navrhnutý směr vývoje webového rozhraní ERP systému. Jinak řečeno, zda uživatelé bez obtíží porozumí významu rozhraní přesto, že je maximálně zjednodušené a odlišné od rozhraní ostatních systémů. Průběh Uživatelé byli obeznámeni s faktem, že se jedná o prototyp webového systému. Testovaná maketa rozhraní se pro přiblížení realitě spouští stejně jako 50
5. Návrh menu webového ERP systému webové stránky v prohlížeči. Testování softwarového prototypu se účastnilo dvanáct osob. Po seznámení s průběhem samostatně podstoupili jednotlivá sezení pod dohledem pozorovatele. Ovládali prototyp dle připraveného scénáře a na závěr sezení každý uživatel vyplnil dotazník pro honocení metodou System Usability Scale (více o metodě v kapitole 4.2.4.3). Scénář se nachází v příloze B a dotazník SUS je součástí elektronické přílohy práce. V průběhu testování bylo poznat, že tento způsob je uživatelům výrazně bližší, než předchozí testování papírových prototypů. Pravděpodobně protože se z pohledu participantů testoval reálný software a ne jeho napodobenina. Podle toho k hodnocení přistupovali. Byli více kritičtí a sdílní v citových projevech i vlastních názorech. Výstupy Pomocí slovní zpětné vazby participantů a sledování interakce s rozhraním byly zaznamenány následující výstupy: 1.
Téměř všichni uživatelé měli problém při požadavku na zavření záložky. Na místo přesunutí do koše se snažili zavřít záložku z kontextového menu (kliknutím pravého tlačítka myši).
2.
Někteří uživatelé používali dvoj-klik přesto, že to nebylo nutné. Vzhledem k tomu, že položky sekundárního menu je možné uchopením přesouvat, někteří uživatelé během volby položky v tomto menu pohnuli kurzorem, tak deaktivovali původně zamýšlenou akci a položku menu neotevřeli. To vedlo ke zmatení a použití dvoj-kliku jako alternativy. V jednom případě participant používal dvoj-klik i bez předchozí negativní zkušenosti.
3.
Uživatelé ve více případech vyžadovali možnost zavření více záložek najednou.
4.
Dva uživatelé použili klávesové zkratky, které nebyly do prototypu implementovány. Jednalo se o zkratku pro nápovědu tlačítkem F1 a snahu o označení více záložek přidržením klávesy control v kombinaci s kliknutím myši.
5.
Tlačítko MENU nacházející se v levém horním rohu bylo ihned identifikováno 8 uživateli. Zbylí 4 uživatelé potřebovali čas k prozkoumání rozhraní. 51
5. Návrh menu webového ERP systému 6.
Všichni uživatelé chápali význam adaptivního menu a většina z nich jej použila v průběhu testu.
7.
Používání záložek jako sekundárního menu nezpůsobovalo žádné problémy.
Z dotazníku System Usability Scale vychází celkové skóre použitelnosti rozhraní na 78 bodů ze 100 možných. Hodnocení pohybující se v rozmezí 74 a 80 se dá považovat za známku B na stupnici od nejhorší F, přes D, C, B až k nejlepšímu A. [56] 5.3.1 Zpracování výstupů finálního testování Závěrečné testování odhalilo nedostatky prototypu. Technickou chybou bylo ztížení volby v sekundárním menu, což popisuje druhá odrážka seznamu výstupů. Tento problém je nyní v přiloženém prototypu vyřešen pomocí jQuery funkce sortable a jejího parametru distance. Pomocí něho je možné nastavit počet pixelů, které musí urazit kurzor myši, aby se položka pohnula ze svého původního místa. Momentálně je parametr nastaven na 25 pixelů, což se jeví jako dostačující. Protože skryté hlavní menu a adaptibilní sekundární menu jsou prvky ve webovém prostředí zatím poměrně neobvyklé a mohly by působit některým uživatelům komplikace, bylo by vhodné při prvním přihlášení uživatele provést novinkami rozhraní. Vysvětlit, proč obsahuje sekundární menu a k čemu slouží. Takto se lze vyhnout některým nejasnostem plynoucích z výstupů. Úvodní tutoriál je běžnou součástí například v rozhraních uživatelských účtů YouTube.com či Facebook.com. Možný návrh tutoriálu představují následující obrázky.
52
5. Návrh menu webového ERP systému
Obrázek 5.7: Tutoriál: Tlačítko pro vyvolání hlavního menu.
Obrázek 5.8: Tutoriál: Představení sekundárního menu.
53
5. Návrh menu webového ERP systému
Obrázek 5.9: Tutoriál: Zavření záložky sekundárního menu.
Obrázek 5.10: Tutoriál: Přesun záložky do koše.
54
Kapitola 6
Závěr Hlavním cílem této diplomové práce bylo zmapovat prostředí uživatelského rozhraní ERP systémů, identifikovat jeho časté problémy a přijít s vlastním řešením jednoho z nich. Výsledek pak otestovat na vhodném vzorku uživatelů. Výstupem je prototyp rozhraní menu, který vznikl na základě studie uživatelských požadavků. Výsledek byl testován ve dvou kolech. Nejdříve byly testovány papírové prototypy, následně softwarové. Dle závěrečného měření metodou SUS je prototyp hodnocen 78 body ze 100 možných. Což je považováno za známku B na stupnici F, D, C, B, A, kde A je nejlepší možné a F je nevyhovující. Explorace dat a testování probíhalo ve spolupráci se společností CÍGLER SOFTWARE, a.s., která se v době tvorby této práce zabývala návrhem nového rozhraní pro službu iDoklad.cz. Cílem společnosti je poskytnout uživatelům iDoklad.cz širší paletu funkcí. To ovšem povede k nutnému rozšíření menu a k tomu v současném rozhraní iDoklad.cz není příliš prostor. Prototyp přináší jeden z pohledů nabízející směr vývoje rozhraní iDoklad.cz. Finální prototyp je vytvořen jako webová stránka pomocí technologií HTML, CSS a JavaScript. Jedná se tedy o lehce upravitelnou šablonu, která je navržena tak, že ji lze v budoucnu použít pro další vývoj. Tím by mohl být návrh pro dotyková zařízení, studie klávesových zkratek, nebo optimalizace zadávání vstupních dat. Za významnou část práce považuji její přínos pro mne. Ten spočívá v čase věnovaném studiu ERP systémů a uživatelských rozhraní. Doba strávená studiem se přímoúměrně rovná i množství nastudované literatury. Měl jsem též příležitost se pohybovat na rozmezí mezi odborníky z praxe, akademickými pracovníky i běžnými uživateli ERP systémů. Takové prostředí mi dávalo jedinečnou šanci uvést do praxe některé z předmětů mého magisterského studia, jako jsou Soft Skills, Komunikace člověka s počítačem či aktuálně studovaný předmět Tvorba uživatelských rozhraní a hodnocení použitelnosti. Věřím, že právě takové prostředí je naplněním cílů studovaného oboru Service Science, Management and Engineering. 55
Literatura [1] VYMĚTAL, Dominik. Podnikové informační systémy - ERP. Vyd. 1. Karviná: Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné, 2010, 134 s. ISBN 9788072486182. [2] APICS. Dictionary information [online]. c2013 [cit. 20. března 2014]. Dostupné z:
. [3] GÁLA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha: Grada, 2009, 496 s. ISBN 978-80-2472615-1. [4] BASL, Josef a Roman BLAŽÍČEK. Podnikové informační systémy: podnik v informační společnosti. 3., aktualiz. a dopl. vyd. Praha: Grada, 2012, 323 s. ISBN 978-80-247-4307-3. [5] KUPKA, Václav. Malé a střední podniky (jejich místo a role v české ekonomice) | ČSU [online]. 31. srpna 2007, poslední revize 20. srpna 2012 [cit. 20. března 2014]. Dostupné z: . [6] RASID, Mohammad A., Liaquat HOSSAIN a Jon David PATRICK. The Evolution of ERP systems: A Historical Perspective. In Enterprise Resource Planning: Global Opportunities and Challenges. pages 1-16, 2002, IRM Press. [7] KOSKA, Šimon. Historie a vývoj e-shopů v podmínkách českého trhu [online]. 26. listopad 2013 [cit. 21. března 2014]. Dostupné z: [8] MOLNÁR, Zdeněk. Podnikové informační systémy. Praha: Vydavatelství ČVUT, 2004, 127 s., ISBN 80-01-03079-2. 56
6. Závěr [9] Free Software Foundation, Inc. Kategorie svobodného a nesvobodného softwaru [online]. c2010, poslední revize 18. května 2013 [cit. 24. března 2014]. Dostupné z . [10] KOPECKÝ, Jakub. Open source ERP pro malé a střední firmy [online]. 2012 [cit. 2014-03-26]. Diplomová práce. Masarykova univerzita, Fakulta informatiky. Vedoucí práce Jaroslav Ráček. Dostupné z: . [11] RATHMANN, Charles. Overview and Projections on Remote Access to Enterprise Data. IFS ERP Mobility Survey. Industrial and Financial Systems North America, 2011. [12] SAP AG. SAP at a glance: Capital Market Information [online]. updated 2014-02-28 [cit. 2014-04-28]. Dostupné z: . [13] Gartner, Inc. Gartner IT Glossary - Cloud Computing [online]. 2013 [cit 2014-03-26]. Dostupné z: [14] STEDDUM James. A Brief History of Cloud Computing [online]. 2013-07-29 [cit. 2014-03-26]. Dostupné z: [15] Gartner, Inc. Gartner IT Glossary - IT Outsourcing [online]. 2013 [cit 2014-03-26]. Dostupné z: [16] PAMUNGKAS, Bayu Cahya. ADempiere 3.4 ERP solutions :design configure, and implement a robust enterprise resource planning system in your organization by using ADempiere. 1st ed. Birmingham: Packt Publishing, 2009. xiv, 437 s. ISBN 9781847197269. [17] ADempiere.cz Československá aliance pro podporu Adempiere: Podpora [online]. 2012 [cit. 2014-03-27]. Dostupné z: . [18] ADempiere.cz Československá aliance pro podporu Adempiere: O nás [online]. 2012 [cit. 2014-03-27]. Dostupné z: . 57
6. Závěr [19] ADAXA. Adaxa announces the release of the Mobile User Interface for ADempiere ERP & CRM [online]. 2011-06-03 [cit. 2014-03-27]. Dostupné z: . [20] CÍGLER SOFTWARE, a. s. Historie Systémů Money [online]. 2012, poslední revize 2013-01-29 [cit. 2014-03-27]. Dostupné z: . [21] SAP AG. History 1972-1981 | Company Information | About SAP AG | SAP [online]. [cit. 2014-03-28]. Dostupné z: . [22] WALOSZEK, Gers. SAP Design Guild – R/3 History in Screen Shots [online]. 2004, poslední revize 2004-04-16 [cit. 2014-03-28]. Dostupné z: . [23] SAP AG. History 1982-1991 | Company Information | About SAP AG | SAP [online]. [cit. 2014-03-28]. Dostupné z: . [24] SAP AG. History 1992-2001 | Company Information | About SAP AG | SAP [online]. [cit. 2014-03-28]. Dostupné z: . [25] Frog Design. Case Study: SAP Enterprise Software [online]. [cit. 201403-28]. Dostupné z: . [26] Microsoft Windows. Historie Windows [online]. poslední revize listopad 2013 [cit. 2014-03-29]. Dostupné z: . [27] CASTLE, Alex a Florence ION. A Visual History of the Windows GUI | Maximum PC [online]. 2009-10-22 [cit. 2014-03-29]. Dostupné z: . [28] Microsoft Windows. What is Windows Aero? [online]. [cit. 201403-31]. Dostupné z: . 58
6. Závěr [29] Microsoft Windows. Toolbars [online]. [cit. 2014-03-31]. Dostupné z: . [30] Microsoft Windows. Aero - Microsoft Windows [online]. [cit. 2014-0331]. Dostupné z: . [31] SINOFSKY, Steven. Designing for Metro style and the desktop - Building Windows 8 - Site Home - MSDN Blogs[online]. 2011-08-31 [cit. 201403-31]. Dostupné z: . [32] MCGRENERE, Johanna a Gale MOORE. Are We All In The Same "Bloat"?. In The Proceedings of Graphics Interface 2000. pages 1–10, Montreal, 2000. [33] DOSTÁL, Martin. User Acceptance of the Microsoft Ribbon User Interface. In Proceedings of the 9th WSEAS international conference on Data networks, communications, computers (DNCOCO’10). pages 143–149, Stevens Point, Wisconsin, USA, 2010. World Scientific and Engineering Academy and Society (WSEAS). [34] DOSTÁL, Martin. WINDOWS USER GROUP BRNO. Příběh uživatelského rozhraní Microsoft Windows: Od Windows 1.0 přes Ribbon až k Windows 8 [Přednáška]. 2014-03-10. Brno, 2014. [35] WALOSZEK, Gerd. Short History of SAP’s Web Applications [online]. updated 2004-04-16 [cit. 2014-04-05]. Dostupné z: . [36] SAP AG. SAP Interaction Design Guide for Internet Application Components [online]. updated 2002-11-07 [cit. 2014-04-05]. Dostupné z: . [37] DOSTÁL, Martin. KATEDRA INFORMATIKY PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITA PALACKÉHO V OLOMOUCI. Základy tvorby uživatelského rozhraní. Olomouc, 2010. [38] Lidé, kteří tvořili historii. 1. vyd. Čestlice: Rebo, 2010, 224 s. ISBN 978-80-255-0429-1. 59
6. Závěr [39] LOOS, Adolf. Ornament a zločin. Řeči do prázdna: soubor statí o architektuře, bydlení, ústrojí a jiných praktických věcech, které uspořádal Dr. Bohumil Markalous. 2. vyd. Kutná Hora: Tichá Byzanc, 2001, 140 - 150. ISBN 80-86359-06-9. [40] SAFFER, Dan. Designing for interaction: creating innovative applications and devices. 2nd ed. Berkeley: New Riders, c2010, xv, 223 s. ISBN 9780321643391. [41] SOJKA, Eduard. Člověk a UI [online]. 2012 [cit. 2014-04-08]. Dostupné z: . [42] PAUKNEROVÁ, Daniela. Psychologie pro ekonomy a manažery. 3., aktualiz. a dopl. vyd. Praha, 2012, 259 s. Management (Grada). ISBN 97880-247-3809-3. [43] COOPER, Alan, Robert REIMANN a Dave CRONIN. About face 3: the essentials of interaction design. [3rd ed.], Completely rev. Indianapolis, IN: Wiley Pub., c2007, xxxv, 610 p. ISBN 04-700-8411-1. [44] CONOVER, Keith. Icons, Pedagogic Vectors, Forms Design and Posture [online]. 2010-02-11 [cit. 2014-04-15]. Dostupné z: . [45] O’REILLY, Tim. What Is Web 2.0 [online]. 2005-09-30 [cit 2014-04-22]. Dostupné z: . [46] DOSTÁL, Martin. MASARYKOVA UNIVERZITA V BRNĚ, FAKULTA INFORMATIKY. Dotyková zařízení [přednáška]. 2014-03-25. Brno, 2014. [47] FINDLATER, Leah a Joanna MCGRENERE. A comparison of static, adaptive, and adaptable menus. Proceedings of the 2004 conference on Human factors in computing systems - CHI ’04. New York, New York, USA: ACM Press, 2004, s. 89-96. DOI: 10.1145/985692.985704. Dostupné z: . [48] EICHLER, Zdenek a Martin DOSTÁL. Adaptive User Interface Personalization in ERP Systems. s. 49. DOI: 10.1007/978-3642-34228-8_6. Dostupné z: . 60
6. Závěr [49] ZAMAZALOVÁ, Marcela. Marketing. 2., přeprac. a dopl. vyd. V Praze: C.H. Beck, 2010, xxiv, 499 s. ISBN 978-80-7400-115-4. [50] STANTON, Neville A. Human factors methods: a practical guide for engineering and design. Burlington, VT: Ashgate Pub. Co., c2005, xx, 571 p. ISBN 07-546-4661-0. [51] DOSTÁL, Martin. MASARYKOVA UNIVERZITA V BRNĚ, FAKULTA INFORMATIKY. Metody 1: Walkthrough, Focus Group, Strukturované Interview a SUS. [přednáška]. 2014-04-23. Brno, 2014. [52] BRUNO Vince a Ghassan AL-QAIMARI. Usability Attributes: An Initial Step Toward Effective User-Centred Development. OzCHI 2004, Wollongong, NSW, 22-24. Dostupné z: . [53] DOSTÁL, Martin. MASARYKOVA UNIVERZITA V BRNĚ, FAKULTA INFORMATIKY. Metody hodnocení použitelnosti. [přednáška]. 2014-04-16. Brno, 2014. [54] HAYES, Nicky. Základy sociální psychologie. Vyd. 6. Praha: Portál, 2011, 166 s. ISBN 978-80-7367-909-5. [55] SNYDER, Carolyn. Paper prototyping: the fast and easy way to design and refine user interfaces. San Diego, CA: Morgan Kaufmann Pub., c2003, xxiv, 378 p. ISBN 15-586-0870-2. [56] SAURO, Jeff. Measuring Usability With The System Usability Scale (SUS) [online]. 2011-02-02 [cit. 2014-05-14]. Dostupné z: .
61
Další literatura KUMAR, Ajit. ADempiere 3.6 Cookbook. Birmingham: Pack Publishing, 2011. 316 s. ISBN 978-1-84951-338-8. RUKOVANSKÝ, Imrich. Principles of company information systems. Kunovice: Evropský polytechnický institut, s.r.o., 2010, 66 s., ISBN 97880-7314-198-1. PAUKNEROVÁ, Daniela. Psychologie pro ekonomy a manažery. 3., aktualiz. a dopl. vyd. Praha: Grada, 2012, 259 s. ISBN 978-80-247-3809-3. WROBLEWSKI, Luke. Web form design: filling in the blanks. Brooklyn, NY: Rosenfeld Media, c2008, xvii, 226 p. ISBN 978-193-3820-248. RUBIN, Jeffrey. Handbook of usability testing: how to plan, design, and conduct effective tests. New York: Wiley, c1994, xxii, 330 p. ISBN 04715-9403-2.
62
Příloha A
Scénář testování papírového prototypu Start 1.
Popište, co rozeznáváte na obrázku (obrazovce).
2.
Vyberte položku Faktury.
3.
Vyberte položku Dobropisy.
4.
Vyberte položku Zaměstnanci.
5.
Vyberte položku Adresář.
6.
Vyberte položku Faktury.
7.
Zavřete všechny záložky.
8.
Vyberte položku Dobropisy.
9.
Vyberte položku Export.
10.
Vyberte položku Faktury.
11.
Zavřete všechny záložky.
Personalizace 1.
Jak byste posunul/a Faktury na poslední místo v horizontálním menu?
2.
Jak byste do horizontálního menu přidal/a položku Pokladna?
3.
Jak byste z horizontálního menu smazal/a položku Adresář?
4.
Odhlaste se. 63
A. Scénář testování papírového prototypu
Závěr ∙
Jak se vám tento model používal?
∙
Bylo zde něco, co vás opravdu mátlo?
∙
Co pro vás bylo nejtěžší?
64
Příloha B
Scénář testování softwarového prototypu 1.
Popište, co vidíte na obrazovce.
2.
Otevřete položku Objednávky.
3.
Otevřete položku Střediska.
4.
Otevřete položku Faktury.
5.
Otevřete položku Ceník.
6.
Otevřete položku Faktury.
7.
Otevřete položku Nápověda.
8.
Otevřete položku Ceník.
9.
Přejděte na domovskou stránku.
10.
Zavřete Nápovědu.
11.
Přesuňte položku Ceník nalevo vedle položky Faktury.
12.
Zavřete všechny položky.
13.
Otevřete položku Zaměstnanci.
14.
Otevřete položku Faktury.
15.
Otevřete položku Dobropisy.
16.
Otevřete položku Daň z příjmu.
17.
Otevřete položku Přiznání DPH.
18.
Seřaďte horizontální menu tak, aby zůstaly jen tyto položky v následujícím pořadí: Daň z Příjmu, Přiznání DPH, Faktury, Objednávky.
19.
Odhlaste se.
65
Příloha C
Obsah elektronické přílohy v archívu IS MU 1.
Schéma typického průběhu rozhovoru metodou Focus Group [50]
2.
Mind mapa témat pro rozhovor metodou Focus Group
3.
Dotazník pro hodnocení metodou System Usability Scale
4.
Konečná verze softwarového prototypu
66
