Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze
Marcela Fišerová
Standardizace a návrh grafického uživatelského rozhraní nemocničního informačního systému
Bakalářská práce
2010
Čestné prohlášení: Prohlašuji, ţe jsem diplomovou bakalářskou práci na téma „Standardizace a návrh grafického uţivatelského rozhraní nemocničního informačního systému“ zpracovala samostatně a pouţila pouze zdrojů, které cituji a uvádím v seznamu pouţité literatury.
V Praze dne 28. 6. 2010
Podpis
Poděkování: Ráda bych na tomto místě poděkovala Ing. Richardu Řehořkovi za vedení této práce, přínosné podněty k tématu a cenné připomínky.
Abstrakt Práce se bude zabývat standardizací grafického uţivatelského rozhraní nemocničního informačního systému konkrétní společnosti. Jejím obsahem bude nejprve seznámení čtenáře s pojmem grafické uţivatelské rozhraní (Graphical User Interface), kde budou obecně popsány jednotlivé zásady, jak vytvořit „user-friendly“ prostředí pro uţivatele. Další část práce se bude věnovat jiţ konkrétním komponentám, které jsou k dispozici pro návrh grafického uţivatelského rozhraní. V první řadě se bude jednat o prvotní vzhled okna, dále bude práce pokračovat popisem a umístěním jednotlivých ovládacích prvků. Cílem práce je vytvořit podklady pro grafický návrh v podobě standardů aplikace (jejích částí) pro budoucí realizaci nového designu informačního systému.
Abstract This work deals with standards of Graphical User Interface of hospital information system of concrete company. First, it contents introduction to concept Graphical User Interface (GUI), where basic principles are described, how to create “user-friendly” environment for users. Another part of work is devoted to concrete components which are available to layout of GUI. First of all, this section solves primary look of window, further work continues with description and layout of control elements. Purpose of work is to create background papers for graphic layout as standards of application (its parts) for future implementation of the new design information system
Obsah ABSTRAKT ......................................................................................................................................... - 4 ABSTRACT ......................................................................................................................................... - 5 1.
ÚVOD ........................................................................................................................................... 8
2.
INFORMAČNÍ SYSTÉM PCS*CARE® [PCS] ....................................................................................10 2.1.
MODULY NIS PCS*CARE® DLE JEJICH FUNKCE ................................................................................. 10
3.
FÁZE PROJEKTU ...........................................................................................................................12
4.
UŽIVATELSKÉ PROSTŘEDÍ ............................................................................................................14
5.
GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ (GUI) ...................................................................................15 5.1.
PRAVIDLA PRO TVORBU GRAFICKÉHO UŽIVATELSKÉHO ROZHRANÍ............................................................ 15
5.1.1.
Cílená tvorba stereotypů .................................................................................................... 16
5.1.2.
Skupina uživatelů................................................................................................................ 16
5.1.3.
Zpětná vazba (Feedback) .................................................................................................... 17
5.1.4.
Navigace uživatele.............................................................................................................. 17
5.1.5.
Předcházet chybám ............................................................................................................ 17
5.1.6.
Předvídatelnost UI .............................................................................................................. 18
5.1.7.
Přehlednost aplikace .......................................................................................................... 18
5.2.
VIZUÁLNÍ ROZMÍSTĚNÍ OVLÁDACÍCH PRVKŮ........................................................................................ 18
5.3.
ZÁSADY PRO VIZUÁLNÍ ORGANIZACI OVLÁDACÍCH PRVKŮ....................................................................... 19
5.3.1.
Vyváženost okna ................................................................................................................. 19
5.3.2.
Souměrnost ........................................................................................................................ 19
5.3.3.
Pravidelnost a Předvídatelnost ........................................................................................... 20
5.3.4.
Následnost .......................................................................................................................... 21
5.3.5.
Barevnost............................................................................................................................ 21
5.3.6.
Účelnost .............................................................................................................................. 21
5.3.7.
Jednotnost .......................................................................................................................... 22
5.3.8.
Proporce ............................................................................................................................. 22
5.3.9.
Jednoduchost ...................................................................................................................... 22
5.3.10.
Seskupování (chunking) ................................................................................................. 23
6.
KONCOVÝ UŽIVATEL ....................................................................................................................24
7.
OKNO ..........................................................................................................................................26 7.1.
ZÁKLADNÍ ÚDAJE O PODOBĚ OKNA ................................................................................................... 26
7.2.
VELIKOST OKNA ........................................................................................................................... 26
7.2.1.
Fixní okna ........................................................................................................................... 26
7.2.2.
Okna, jejichž velikost je variabilní ....................................................................................... 26
5
7.3.
8.
PRIMÁRNÍ OKNO .......................................................................................................................... 27
7.3.1.
Rám .................................................................................................................................... 28
7.3.2.
Titulkový pruh (Title Bar) .................................................................................................... 28
7.3.3.
Tlačítka titulkového pruhu .................................................................................................. 28
7.3.4.
Stavový řádek (Status Bar) ................................................................................................. 29
7.3.5.
Posuvník (Scroll Bar) ........................................................................................................... 29
7.3.6.
Pracovní plocha .................................................................................................................. 29
7.4.
SEKUNDÁRNÍ OKNO ...................................................................................................................... 30
7.5.
DIALOGOVÁ OKNA ........................................................................................................................ 30
7.6.
TYPY HLÁŠENÍ (ZPRÁV) A JEJICH IKONY .............................................................................................. 32
7.6.1.
Kritická chyba ..................................................................................................................... 33
7.6.2.
Upozornění ......................................................................................................................... 33
7.6.3.
Oznámení ........................................................................................................................... 34
7.6.4.
Otázka ................................................................................................................................ 34
OVLÁDACÍ PRVKY ........................................................................................................................35 8.1.
PŘÍKAZOVÁ TLAČÍTKA (COMMAND BUTTONS) .................................................................................... 35
8.1.1.
Elipsa .................................................................................................................................. 36
8.1.2.
Standardní příkazové tlačítko ............................................................................................. 36
8.1.3.
Výchozí (defaultní) tlačítko ................................................................................................. 36
8.1.4.
Tlačítko „Procházet...“ ........................................................................................................ 37
8.1.5.
Tlačítko pro skrytí/zobrazení informací (Progressive disclosure button) ............................ 37
8.1.6.
Doporoučené rozměry tlačítka ........................................................................................... 37
8.2. 8.2.1. 8.3. 8.3.1. 8.4.
PŘEPÍNAČ (RADIO BUTTON, OPTION BUTTON) .................................................................................. 38 Doporučené rozměry přepínače: ........................................................................................ 40 ZAŠKRTÁVACÍ POLÍČKO (CHECK BOX) ................................................................................................ 40 Doporučené rozměry zaškrtávacího políčka ....................................................................... 42 SEZNAM (LIST) ............................................................................................................................ 42
8.4.1.
Doporučené rozměry Seznamu ........................................................................................... 43
8.4.2.
Jednoúrovňový seznam ...................................................................................................... 44
8.4.3.
Multivýběrový seznam ........................................................................................................ 44
8.4.4.
Rozbalovací seznam (Drop Down List) ................................................................................ 44
8.5. 8.5.1.
COMBO BOX ............................................................................................................................... 45 Doporučené rozměry Combo Boxu ..................................................................................... 46
8.6.
SPIN BOX.................................................................................................................................... 46
8.7.
TEXTOVÉ POLE (TEXT BOX)............................................................................................................. 47
8.7.1.
Klasický datový vstup.......................................................................................................... 48
6
8.7.2.
Formátovaný datový vstup ................................................................................................. 48
8.7.3.
Asistovaný datový vstup ..................................................................................................... 49
8.7.4.
Textový vstup ...................................................................................................................... 49
8.7.5.
Číselný vstup ....................................................................................................................... 50
8.7.6.
Vstup heslo nebo PIN .......................................................................................................... 50
8.7.7.
Validace vstupních dat ....................................................................................................... 51
8.7.8.
Doporučené rozměry textového pole.................................................................................. 51
8.8.
ZÁLOŽKY (TABS)........................................................................................................................... 51
8.9.
SKUPINOVÝ BOX (GROUP BOX) ....................................................................................................... 52
9.
TYPOGRAFIE ................................................................................................................................53 9.1.
POPISKY (LABELS)......................................................................................................................... 54
9.1.1.
Popisky tlačítek ................................................................................................................... 55
9.1.2.
Popisky přepínače ............................................................................................................... 56
9.1.3.
Popisky zaškrtávacího políčka ............................................................................................ 56
9.1.4.
Popisky Seznamu ................................................................................................................ 57
9.1.5.
Popisky rolovacího seznamu a Combo Boxu ....................................................................... 57
9.1.6.
Popisky textového pole ....................................................................................................... 57
10.
ZÁVĚR .........................................................................................................................................58
11.
SEZNAM LITERATURY ..................................................................................................................59
12.
SEZNAM OBRÁZKŮ ......................................................................................................................61
7
1. Úvod Práce se bude týkat projektu konkrétní společnosti, která se zabývá vývojem nemocničního informačního systému. V časovém období vzniku této práce je projekt v počáteční fázi a má za cíl uţivatelskou, technologickou a funkční inovaci stávajícího informačního systému (IS) do nové formy. Úvodní stránky práce se budou týkat stručného popisu konkrétního informačního systému a fáze, ve které se inovace projektu nachází. Dále se bude práce zabývat uţivatelským rozhraním, konkrétně grafickým. Budou zde zdokumentována pravidla, kterými by se vývojáři měli při tvorbě grafického uţivatelského rozhraní drţet, ale také standardy, které pocházejí spíše ze strany kognitivních věd a psychologie, jako například vizuální rozmístění prvků v okně ad. Další kapitolou práce bude stručná charakteristika poţadavků uţivatelů na informační systém. V tomto případě se jedná spíše o zachycení chyb, či nedostatků ve starém informačním systému, které stávající uţivatelé zaznamenali při jeho dosavadním uţívání, a v jejich běţné činnosti jim způsobují potíţe. Nejrozsáhlejší částí práce potom bude uţ samotné grafické uţivatelské rozhraní, resp. standardy, které by měl IS splňovat a dodrţovat. Vzhledem k obsaţnosti tohoto tématu, bude práce soustředěna pouze na základní komponenty okna, samotné okno a ovládací prvky, které se budou v okně nacházet. Další aspekty, které patří do grafického uţivatelského rozhraní (menu, ikony, celková barevná paleta IS ad.), nebudou zahrnuty (o jejich konkrétním návrhu vzhledu nebylo managementem společnosti ve chvíli vzniku této práce rozhodnuto). Výsledkem této práce by měla být doporučení pro tvorbu standardů konkrétního nemocničního informačního systému dané společnosti. Vzniklé standardy by neměly fungovat jako striktní pravidla, která musí být nutně pouţita, ale spíše jako obecné doporučení či návrh, který by měl usnadnit práci vývojářům a grafikům při sestavování konečných návrhů obrazovek celé aplikace. Návrhy na standardy vycházejí z obecně platných zvyklostí a doporučení uţivatelského ovládání v operačních systémech Windows (především Windows Vista a Windows 7). Na základě získaných teoretických informací a znalosti funkčnosti starého informačního
8
systému se práce nevěnuje všem ovládacím prvkům, které jsou k dispozici, ale jen těm, kterých bylo pouţito ve starém informačním systému a počítá se s jejich pouţitím i v novém. Další moţné prvky, které by IS mohl obsahovat, budou řešeny aţ v případě konkrétních návrhů obrazovek a formulářů.
9
2. Informační systém PCS*CARE® [PCS] Projekt je realizován společností PCS Systems spol. s r. o., která se zabývá vývojem nemocničního informačního systému (NIS). Od roku 1994 realizuje dodávání NIS PCS*CARE® do různorodých zdravotnických zařízení, jak na tuzemské úrovni, tak i na mezinárodní. Jelikoţ technické vybavení z roku 1994 je v dnešní době jiţ zastaralé a prakticky se na trhu dnes nepouţívá, byla firma donucena jít do projektu na inovaci starého NIS. Navíc stávající IS neodpovídal poţadavkům i po stránce funkčnosti a vzhledu, který působí zastarale, ale také z hlediska ovládání a komplikované interoperabilitě. Informační systém NIS PCS*CARE® podporuje veškerou činnost klinik, nemocnic a ostatních zdravotnických zařízení. Jedná se o otevřený modulární systém, který je vyvinut v databázovém prostředí Oracle (Oracle Forms, verze 6). Informační systém je tvořen z daného počtu modulů, které řídí pracovní postupy v nemocničním zařízení. Základem IS je jádro, které shromaţďuje funkce, které mají všechny moduly společné. Specialitou produktu firmy PCS Systems spol. s r.o. je moţnost pořízení transfůzního a lékárenského modulu (LIS PCS*CARE®, PIS PCS*CARE®) zvlášť, jako nezávislých informačních systémů. 2.1. Moduly NIS PCS*CARE® dle jejich funkce Celý informační systém NIS PCS*CARE® nabízí následující moduly:
Správce systému Běţná ambulance Preventivní centru Stomatologická ambulance Odborná (konziliární) ambulance Recepce odborných ambulancí Přípravná ambulance pro odborná vyšetření Stacionář chemoterapie Lůţková péče Centrální příjmová kancelář Kancelář na lůţkovém oddělení Recepce (vrátnice) Archiv chorobopisů Operační sál
10
Léčebná místnost (nechirurgická léčba nemedikamentózního typu) Recepce vyšetřoven zobrazovacích metod Přípravná ambulance pro vyšetření zobrazovacími metodami Dokumentátor zobrazovacích metod Laboratoře spolu s transfůzní stanicí Lékárny a sklady materiálu Vyúčtování lékařské péče Management a statistika Dispečink
Obrázek 1 - ukázka formuláře NIS PCS*CARE®
Obrázek 2 - ukázka formuláře NIS PCS*CARE®
11
3. Fáze projektu PCS Systems spol. s r. o. realizuje projekt v rámci programu ICT a strategické sluţby Výzvy II projekt „Nová generace nemocničního IS“. Program je součástí OPPI1, jehoţ řídícím orgánem je Ministerstvo průmyslu a obchodu ČR. Projekt je realizován za finanční spoluúčasti EU – Evropského fondu pro regionální rozvoj (ERDF). Jedná se o projekt v celkovém rozsahu 37.148.000 Kč, který byl podpořen z dotačního titulu ICT a strategické sluţby dotací ve výši 22.288.000 Kč. Jak vychází z předešlé kapitoly, je prezentační, business a aplikační logika dosavadního IS vybudována nad databázovým strojem Oracle. Oracle Forms je v dnešní době jiţ nevyhovující (zastaralá a nepodporovaná) technologie vývojového prostředí. Celý systém je zaloţený na jednoduchých formulářích s velkým mnoţstvím tlačítek, pomocí kterých se uţivatel můţe pohybovat v hierarchických strukturách systému. Toto řešení je jedním z důvodů, proč působí uţivatelům velké problémy ovládání této aplikace. V prvním stádiu projektu bylo tedy nutné vybrat programovací technologii, ve které se bude nový systém vyvíjet. Po analýze jednotlivých moţných technologií z hlediska jejich výhod a nevýhod, či pouţitelnosti pro nový IS, byly do uţšího kola vybrány dvě – Silverlight a WPF (Windows Presentation Foundation). Obě technologie pochází z dílny firmy Microsoft, coţ bude mít odraz i v celém grafickém uţivatelském rozhraní, které bude pro uţivatele vypadat jako aplikace, které pouţívají operační systémy Windows. Microsoft (MS) technologie byly zvoleny z důvodu dodavatelské podpory, jednotnosti prostředí a jeho dokumentaci. Obě jsou také zaloţeny na programovacím jazyku XAML2, který umoţňuje vytvoření bohatého uţivatelského rozhraní, zahrnující v sobě různé moţnosti z oblasti grafiky a animace. Aplikace bude v budoucnosti upravena tak, aby mohla běţet i v jiném prostředí neţ je jen MS. Nezávisle na tom bude mít aplikace také webové rozhraní, jako způsob rozšíření její funkcionality a přístupu z internetu. Při volbě vývojového prostředí nového IS bylo postupováno následovně: proběhly prezentace obou technik zástupci poboček v ČR, a následné zjišťování výhod a 1
OPPI – Operační program podnikání a inovace XAML – Extensible Application Markup Language, programovací jazyk uţivatelského rozhraní WPF [ŠTU] 2
12
nevýhod, které by mohly ovlivnit celý projekt vývoje nemocničního informačního systému. Zřetel byl brán hlavně na nevýhody, se kterými by se vývojáři mohli setkat, a mohly by pak zkomplikovat celý průběh projektu. Hodnoceny byly například moţnosti grafické úpravy ovládacích prvků, ale i celého uţivatelského rozhraní aplikace (barvy, animace, grafika). Dále se zkoumaly jednotlivé nejaktuálnější verze obou z technologií a porovnávaly se změny, které verze nabízely. Výsledkem této analýzy byl konečný výběr vývojářské technologie vrcholným managementem společnosti – WPF (Windows Presentation Foundation). V jednání managementu je také najmutí speciálního grafika, který by se podílel velkou částí na vývoji grafického uţivatelského rozhraní. Stále ale není rozhodnuto, zda se takový specialista vejde do rozpočtových nákladů a zda se vyplatí zaplatit za kvalitnější grafický layout od profesionálního grafika.
13
4. Uživatelské prostředí Jedním z klíčových faktorů kaţdé softwarové aplikace je kvalitní a dobře zpracované uţivatelské rozhraní. S rozvojem technologií vyvstala otázka, jak zajistit, aby je mohlo ovládat velké mnoţství uţivatelských skupin. Tato komunikace byla vytvořena na základě rozhraní. Jeho prostřednictvím uţivatel zařízení (počítač či samotnou aplikaci) ovládá, a naopak je mu následně dána moţnost zpětné vazby, jaké změny či chyby v systému nastaly. Průlomem v tomto oboru se stala věda nazývaná Human Computer Interaction (HCI). Tento vědní obor v sobě obsahuje několik aspektů, kterými se zabývá při řešení uţivatelských rozhraní. Patří sem znalosti z informační vědy, psychologie, sociologie, antropologie, designu, lingvistiky a také ergonomiky. Na základě těchto informací z jednotlivých vědních oborů je moţno vytvořit tzn. „user-friendly“ (přátelsky orientované) prostředí, tzn. prostředí aplikace (systému), které zaručí uţivateli jednoduchou a hlavně přirozenou a intuitivní práci s programem.[PAP] V dnešní době se uţivatel můţe setkat s několika druhy uţivatelského rozhraní:
Příkazový řádek Textové uţivatelské rozhraní Grafické uţivatelské rozhraní Multimediální grafické rozraní
Práce se bude soustředit pouze na oblast grafického uţivatelského rozhraní.
14
5. Grafické uživatelské rozhraní (GUI) Jedná se o uţivatelské prostředí, které zprostředkovává práci uţivateli s programem pomocí grafické prezentace. Jedná se především o problematiku grafické prezentace oken, dialogů, ovládacích prvků, menu, ale také základů chování a ovládání aplikací včetně navigační topologie rozloţení jednotlivých prvků v aplikačních formulářích. Uţivatel za pomocí klávesnice, myši či jiného ukazovacího zařízení manipuluje s tzv. objekty, které mají grafickou (či textovou nebo i zvukovou) podobu. Činnosti takto prováděné jsou nazývány akce. [DOS] Manipulace pomocí grafického uţivatelského rozhraní je přímá. Můţeme ji charakterizovat jako manipulaci, kde je systém vyobrazen jako rozšíření reálného světa. V tomto pojetí můţe uţivatel systém chápat jako metaforu reálného světa, a to pro něj zajišťuje jisté snadnější pochopení a lehčí orientaci. Dalším principem přímé manipulace je trvalá viditelnost objektů a akcí, která vede k okamţitě odezvě, jeţ je poskytnuta uţivateli. Poslední charakteristikou přímé manipulace je návratnost akcí, která zaručuje pro uţivatele moţnost vrátit zpět akci, která nepřinesla očekávaný výsledek. [DOS] Důleţitým aspektem GUI je schopnost komunikace člověka s počítačovým zařízením bez nutné znalosti příkazů a syntaxe. Je to uţivatel, který určuje jaká akce, v jakém pořadí a s jakými objekty, se bude provádět. Zatímco dříve byla interakce uţivatel – program zaloţena na pořadí akce – objekt, umoţňuje dnešní grafické prostředí postup operací zaměnit na objekt – akce, kde nejdříve uţivatel objekt vybere díky grafické prezentaci a následně volí akci. [PAP] Při dodrţení těchto základních pravidel, tzn. při vytvoření určitých standardů grafického uţivatelského rozhraní, je moţné docílit jistého zvýšení produktivity práce koncového uţivatele, jelikoţ takto vzniklé prostředí pro něj bude snazší na ovládání (user-friendly interface), a tím pádem umoţní růst jeho pracovní výkonnosti. 5.1. Pravidla pro tvorbu grafického uživatelského rozhraní Základem dobrého uţivatelského prostředí je vyvarovat se tomu, aby byla upřednostněna pohodlnost pro programátora před poţadavky uţivatele, proto se autor GUI vţdy řídí hlavně tím, co je dobré pro uţivatele a nezajímají ho poţadavky programátora.
15
Při vytváření dobrého GUI je také nutné dodrţovat tzv. „Form follows function“. Tato formule „Forma následuje funkci“ říká, ţe formu, nebo také vzhled a interakci věcí, určuje její funkce, tzn., ţe, co je funkční, je také hezké a správné. Proto je nutné dbát při tvorbě UI3 na funkčnost, která je hlavním cílem tvorby softwarové aplikace. Pro vývoj GUI to znamená vyvarovat se „ozdobám“ či ornamentům, které do správně funkčního uţivatelského prostředí nepatří. [DOS] 5.1.1. Cílená tvorba stereotypů
Stereotyp je snaha vytvořit stejné věci, které fungují stejně napříč celou aplikací či systémem. Patří sem například i stejná terminologie. Mělo by zde platit tzv. pravidlo konzistentnosti a organizovanosti. Pro uţivatele je jednodušší, pokud si nemusí nic pamatovat a jednotlivé kroky v aplikaci dělá po určité době uţ automaticky. Pokud se naskytne několik akcí, které jsou stejného charakteru, potom bude pro uţivatele logické, ţe se tyto akce budou ovládat stejně. Pokud by se tak nestalo, bude s tím mít uţivatel jisté problémy, které mohou vést ke sníţení pracovní výkonnosti nebo se mu práce s tímto programem můţe znelíbit a obtěţovat ho. Pokud jsou stereotypní pravidla vysvětlena jen jednou a uţivatel dál uţ pracuje s aplikací samostatně, dá se povaţovat toto grafické uţivatelské rozhraní za vydařené a konzistentní. Aplikace pracuje důsledně a její pouţívání nečiní uţivateli problémy. Pokud ale toto pravidlo není dodrţeno, setká se později například helpdesk s problémy, kdy uţivateli bude muset znovu krok po kroku vysvětlovat funkčnost jednotlivých částí aplikace. 5.1.2. Skupina uživatelů
Při tvorbě GUI je důleţité, jaké cílové skupině je systém určen. Autor GUI musí provést důkladný průzkum cílové skupiny uţivatelů, aby zajistil snadné a intuitivní ovládání celému spektru lidí, kteří budou daný software pouţívat. Musí zohlednit například to, zda se jedná o úplné začátečníky v pouţívání počítačů či naopak o profesionály, popř. jiné skupiny. V našem případě se bude jednat o specializovanou skupinu uţivatelů – zdravotnický personál. Stylů ovládání aplikace existuje několik, proto je důleţité, aby autor umoţnil alternativní způsoby, jako například stejnou moţnost pouţití myši i
3
UI – z angl. User Interface = uţivatelské rozhraní
16
klávesnice apod. Uţivatelé jsou nejdůleţitějším aspektem při vývoji celé aplikace, proto důkladná analýza zákazníka, je nezbytnou součástí projektu. Ne jinak je tomu i při tvorbě grafického uţivatelského rozhraní. V tomto případě se jedná o skupinu, kterou nebude zajímat zdrojový kód, jak aplikace pracuje, ale bude pro ně právě důleţitý design a grafika. (Viz kapitola 7. Koncový zákazník) 5.1.3. Zpětná vazba (Feedback)
Je důleţité, aby byla zajištěna zpětná vazba pro uţivatele. Ten potřebuje, aby jeho činnosti byly kontrolovatelné a monitorovatelné. Chce být informován, zda jeho činnost proběhla či neproběhla, zda byla úspěšně dokončena či došlo k nějakým chybám. Je ale také důleţité dbát na to, aby zpětná vazba nebyla pro uţivatele spíše přítěţí a neobtěţovala ho. Proto můţeme zpětnou vazbu rozdělit na dvě skupiny – silná a slabá. Silná zpětná vazba je vazba, na kterou uţivatel musí reagovat. Konat takto musí z toho důvodu, jelikoţ se jedná o informaci, která má zásadní význam. Uţivatel musí dát najevo, ţe danou zpětnou vazbu obdrţel, a pokud je to moţné, bude na ní reagovat. Slabá zpětná vazba je vazba, kterou uţivatel nemusí potvrzovat a nemusí reagovat na to, ţe získal nějakou informaci. Jedná se spíše o doplňující či vedlejší informaci, která nemá nijak závaţný význam pro další práci s aplikací. 5.1.4. Navigace uživatele
Pro uţivatele je nutné zajistit přehlednost pracovního postupu. Ten se často skládá z několika na sebe navazujících akcí, které je třeba nějakým způsobem přehledně propojit. Proto musí být jedním z úkolů autora GUI rozčlenit tyto akce na jednoduché logické kroky, které budou workflow kopírovat. 5.1.5. Předcházet chybám
Při jakékoli činnosti je moţné, ţe dojde k chybě. I zde tato situace můţe nastat, a proto by celý systém měl být vybudován tak, aby chybám uţivatele předcházel, nebo je aspoň co nejvíce eliminoval. Pokud uţ ale k nějaké chybě dojde, je nutné o tom uţivatele informovat, a to v jazyce uţivatele. Hlášení technického charakteru budou pracovníkovi zdravotnického zařízení naprosto zbytečné a svůj problém (chybu) nebude moci vyřešit. Příkladem předcházení chybám je zakazování určitých poloţek či ovládacích prvků v
17
oknech. 5.1.6. Předvídatelnost UI
Celé uţivatelské rozhraní by mělo být předvídatelné. Uţivatel by neměl být ten, který plní rozkazy aplikace, ale ten, který rozkazy aplikaci dává. Proto musí mít uţivatel nad aplikací nadvládu a aplikace musí jednotlivé budoucí kroky uţivatele předvídat. Do této části můţeme zařadit například snadné zpřístupnění k funkcím, které uţivatel často pouţívá. 5.1.7. Přehlednost aplikace
Poslední pravidlo se týká především grafického uţivatelského rozhraní. Vhodné umístění ovládacích prvků a dalších komponent GUI zapříčiní jednodušší ovládání celé aplikace. Uplatňuje se zde tzv. Pravidlo 7±24, které říká, ţe člověk si je schopen zapamatovat v krátkodobé paměti jen pět aţ devět údajů. [DOS] 5.2. Vizuální rozmístění ovládacích prvků Z hlediska grafické stránky s vazbou na funkcionalitu IS či softwarové aplikace je jedním ze základních kritérií rozmístění ovládacích prvků. Proto je důleţité, aby vývojář prostředí umístil prvky tak, aby pro uţivatele bylo snadné se v prostředí intuitivně pohybovat a nečinilo mu velké obtíţe se s aplikací seznámit a dále ji pouţívat. Z tohoto důvodu by měl autor grafického uţivatelského rozhraní brát v úvahu následující výchozí fakta o uţivateli:
Člověk (v našem případě konkrétní uţivatel IS) při práci s počítačem prohlíţí obsah monitoru (obrazovky) od levého horního rohu okna a pokračuje dále po směru hodinových ručiček
Jako obyvatelé evropského kontinentu (nebudeme nyní brát ostatní kontinenty v potaz) čte uţivatel text zleva-doprava a zároveň shora-dolů po jednotlivých řádcích. Tento aspekt by měl vývojář brát na vědomí z toho důvodu, aby se také zamyslel nad logickým uspořádáním prvků v okně, které bude minimalizovat dráhu očí sledující např. kurzor, jeţ je nutná právě pro pohyb v okně.
4
G. A. Miller, 1956
18
Neméně důleţitým faktem je promyšlené rozmístění prvků s ohledem na pracovní sled aktivit (workflow). Opět by se takto mělo činit z důvodu přehlednosti a co nejrychlejšího a nejjednoduššího způsobu zpracování aktuálního okna.
Tato fakta vedou k obecnému rozmístění ovládacích prvků. Prvním bodem umístění bude zmíněný levý horní roh. Zde se budou koncentrovat ty prvky, které jsou povaţovány za nejdůleţitější. Dalším faktorem je styl čtení textu. Z toho vyplývá, ţe další ovládací prvky by se měly uspořádat v rozloţení zleva-doprava. Ovšem rozsáhlé výzkumy tohoto problému ukázaly, ţe pro uţivatele je mnohem příjemnější zobrazovat informace pod sebou (shora-dolů). Informace, které mají krátký charakter a pro uţivatele je jednodušší je dostat do podvědomí, by měly být umístěny právě shora-dolů. Jediný případ, kdy bychom upřednostnili uspořádání prvků zleva-doprava, by byl souvislý text. [DOS] 5.3. Zásady pro vizuální organizaci ovládacích prvků Při tvorbě grafického uţivatelského rozhraní vţdy dbáme na poţadavky uţivatele, ale také musíme k tomu vyváţit uspořádanost, systém a jednoduchost. Těchto bodů docílíme stanovením jistých zásad, které zaručují právě zmíněný systém v tom, kam které prvky uspořádáme. 5.3.1. Vyváženost okna
Pro „uţivatelské oko“ je příjemné a akceptovatelné, kdyţ jsou jednotlivé prvky okna vyváţené, tzn., ţe jsou rovnoměrně rozmístěny v okně tak, aby horizontálně i vertikálně byly jednotné. 5.3.2. Souměrnost
Členění jednotlivých logických skupin ovládacích prvků v okně by mělo být rovnováţně rozmístěno v pravé i levé části okna. Zárukou takto dobře rozmístěných prvků bude adekvátní rozhraní, které nebude působit rozměrněji, jak je to u okna, kde souměrnost členění chybí. (Viz Obrázek 1)
19
Obrázek 3 – Souměrnost (vlevo) a Nesouměrnost (vpravo)
5.3.3. Pravidelnost a Předvídatelnost
Pravidelnost by měla prostupovat celý IS. Stejné ovládací prvky, ale i ostatní komponenty okna, by měly vypadat v celém IS stejně a fungovat stejně, pokud je to ţádoucí. Konkrétně se jedná o rozměry, barevnost, umístění i funkčnost prvků. Jednotná kostra a jednotný styl grafiky i textu dávají informačnímu systému jakýsi rytmus. Opakování není zde na závadu, ba právě naopak. Pro uţivatele se stejné pouţívání stejných prvků stane rutinou, která mu zaručí právě lehce zapamatovatelné a intuitivní ovládání. (Viz Obrázek 2 a 3)
Obrázek 4 – Pravidelnost (vlevo) a Nepravidelnost (vpravo)
Obrázek 5 – Předvídatelnost (vlevo) a Atypičnost (vpravo)
20
5.3.4. Následnost
Zásadou následnosti je jiţ zmíněné uspořádání prvků zleva-doprava a shora-dolů. Prvky, které mají největší důleţitost, umístíme do levého horního rohu a následně budeme pokračovat podle směru hodinových ručiček, přičemţ další prvky umístíme nejdříve ve stylu shora-dolů a aţ potom se zabýváme případným umístěním zlevadoprava. Následnost můţe také být podpořena tzv. prezentací. Ta je zaloţena na tom, ţe oko uţivatele snadněji chápe a lépe přijímá symbol neţ text a zároveň preferuje jednoduché a obvyklé tvary před sloţitějšími.
Obrázek 6 – Následnost (vlevo) a Náhodnost (vpravo)
5.3.5. Barevnost
Barevnost je důleţitým aspektem celého informačního systému. Barvy je nutné vybírat s velkým citem, protoţe můţe silně ovlivnit uţivatelovy pocity, sympatie, ale hlavně únavu a opotřebování lidského oka během práce s počítačem. Všeobecně je prokázáno, ţe lidé pouţívající počítače upřednostňují světlejší objekty před tmavšími, ale zároveň syté barvy před černobílým či jemným vzhledem. 5.3.6. Účelnost
Účelnost je charakterizována formulací Form follows function. Proto autor grafického uţivatelského prostředí se musí zdrţet určitých excentrických způsobu prezentace prvků. Pro popisky pouţívat jednoduchý font, který bude jednotný pro celou aplikaci, nepouţívat křiklavé barvy a nekombinovat velké mnoţství barev v jednom okně. (Viz Obrázek 6)
21
5.3.7. Jednotnost
Jednotlivé prvky v okně by měly tvořit kompaktní celek, aby pro uţivatele bylo jednoduché celou aplikaci zvládnout. Dochází zde tedy k propojení jednotnosti a pravidelnosti či předvídatelnosti, kdy uţivatel na základě dobrého GUI můţe například předpokládat, ţe „Zavřít“ bude vţdy označovat konec práce s aktuálním oknem apod. (Viz obrázek 7)
Obrázek 7 – Jednotnost (vlevo) a Fragmentace (vpravo)
5.3.8. Proporce
Jednotlivé objekty UI mají své vlastnosti, jako například rozměry. Existuje několik standardů rozměrů oken, které se v určitých případech pouţívají:
čtverec (1:1) je pro oko člověka zajímavý a přitahuje jeho pozornost
zlatý řez (1: ) odmocnina ze tří (1: ) další moţnosti jako například 1:2 či 1:3, ty uţ se ale nepouţívají 5.3.9. Jednoduchost
Uţivatel bude shledávat za jednoduchou aplikaci tu, která nebude mít velké mnoţství ovládacích prvků. Informační systém, jehoţ grafické rozhraní bude obsahovat na první pohled obrovské mnoţství funkcí skrz jednotlivé grafické prvky, bude vytvářet dojem sloţitosti a bude ztrácet na přehlednosti. První z kroků, které by si autor GUI měl rozmyslet, je, které funkce jsou často pouţívané a které jiţ méně (můţeme je nazvat pokročilými funkcemi). Pokud tyto funkce správně zmapuje a utřídí, bude dalším jeho krokem skrytí pokročilých funkcí. Kdyby tyto funkce byly dostupné například z panelu nástrojů, kde mají své místo ikony, jejichţ funkce pouţívá uţivatel nejčastěji, vedlo by to k zvýšení nároků na ovládání aplikace. Proto funkce, které můţeme povaţovat za
22
pokročilé, bychom měli samozřejmě zanechat, ale umístit je tak, aby byly vyvolány jen těmi, kteří o ně opravdu stojí. 5.3.10. Seskupování (chunking)
Dobrý celkový vzhled grafického rozhraní tvoří jednotlivé skupiny prvků. Tyto skupiny seskupují jednotlivé prvky se stejnými či podobnými vlastnostmi, nebo seskupují ty prvky, jeţ k sobě logicky patří.
23
6. Koncový uživatel Koncový uţivatel je důleţitým aktérem při vývoji uţivatelského rozhraní. V rámci nemocničního systému jako uţivatele zahrneme veškerý personál pracující ve zdravotnických zařízeních. Můţeme sem zahrnout lékaře, zdravotních sestry, technický personál, administrativní pracovníky ad. Dle jejich odborného zaměření se nejedná o počítačové odborníky v informačních technologiích, a počítač pro ně slouţí jako podpora, která by měla usnadnit jejich pracovní činnost. Z toho by také vývojáři uţivatelského rozhraní měli vycházet a vytvořit takové prostředí, které bude pro uţivatele příjemné. Analýza zákaznických potřeb spíše poukazuje na to, co uţivatelé nechtějí, neţ na to, co potřebují či poţadují. V oblasti vývoje informačních systémů samozřejmě nemají znalosti, aby mohli jasně popsat své poţadavky. S uţivateli proběhla řada jednání za účelem updatu uţivatelských poţadavků, které byly zahrnuty do analytického requirement modelu5 v podobě revize. Největším nedostatkem, se kterým se starý nemocniční informační systém potýká, je navigační nepřehlednost. Jak uţ bylo řečeno, kaţdý z modulů obsahuje velké mnoţství hierarchických struktur, v kterých se uţivatel musí umět orientovat. A právě tuto vlastnost starý systém postrádá. Pohyb po jednotlivých úrovních zaručuje pouze skupina pojmenovaných příkazových tlačítek. Pokud se uţivatel dostane hlouběji do systému, má velký problém se zorientovat, kde se nachází, a kam se chce vrátit. Musí se „proklikávat“ jednotlivými obrazovkami, aby se dostal do poţadovaného místa nebo zpět. Jak přesně bude struktura nového systému vypadat, je v časovém období vzniku této práce ještě v jednání, kaţdopádně se bude společnost snaţit právě tento nedostatek odstranit v rámci dosaţení jednoduššího ovládání uţivatelem. Dalším připomínkou ke starému IS je moderní vzhled. Vizuální struktura obrazovek starého informačního systému neodpovídá dnešním poţadavkům, proto uţivatelé ţádají novější, interaktivnější pracovní prostředí, které by také mělo napomoct zlepšení 5
Requirement model je základním podkladem pro dokumentaci při UseCase analýze [KUN]
24
uţivatelského rozhraní. Jedná se především o moţnosti barevné palety, různých ovládacích prvků, vzhled menu, pouţití grafických či audio prvků ad. Na druhé straně by návrh měl respektovat zastaralou infrastrukturu u zákazníků, kteří často pouţívají zastaralý hardware či software, který nemůţe být pouţit pro provoz nového IS z důvodu vyšších hardwarových a softwarových nároků moderních technologií. Jedním z dalších poţadavků, které je nutno vyřešit, je vyváţené ovládání aplikace, jak pomocí klávesnice, tak pomocí myši. Většina uţivatelů je zvyklá hlavně na pouţívání klávesnice a klávesových zkratek, kterými ovládá v podstatě celou aplikaci. Management musel rozhodnout, zda aplikaci opět přizpůsobit pouţívání specifických klávesových zkratek, na které je uţivatel zvyklý, nebo se zanechají jen typicky známé „windowsovské“ zkratky, které se pouţívají v celém systému Windows, a ostatní ovládání bude uzpůsobeno spíše k práci s myší. V chvíli vzniku této práce došlo k rozhodnutí pouţít obou způsobů ovládání.
25
7. Okno Okno je základním komunikačním prostředkem mezi informačním systémem a uţivatelem. Jedná se o základní grafický prvek celé aplikace, díky němuţ můţe člověk zadávat do systému vstupy a prezentací okna naopak obdrţí uţivatel výstupy procesu, které na základě vstupů proběhly. Součástí oken jsou potom základní ovládací prvky a nabídka. 7.1. Základní údaje o podobě okna Minimální podporovaná velikost okna u systému Windows je 800 x 600px.[MSW] Znamená to, ţe plný obsah okna je viditelně zobrazen při tomto minimálním rozlišení. Ve většině případů se ale vyuţívá pohodlnějších rozměrů, a to 1024 x 768px, proto se i tvůrci pro toto rozlišení rozhodli, především z hlediska funkčnosti a pouţívaných monitorů uţivateli. 7.2. Velikost okna Autor GUI musí s rozmyslem vytvořit okno tak velké, aby odpovídalo obsahu, který v něm bude umístěn. Neměl by se bát vyuţít většího výchozího nastavení i z hlediska toho, aby se aplikace vyhnula vyuţití posuvníků a aby data, která jsou v okně zobrazována, nebyla omezena. K tomuto řešení přispěje také vyuţití schopnosti okna měnit svou velikost. 7.2.1. Fixní okna
Jeho velikost nelze změnit, proto musí být rozměry dostačující tak, aby okno bylo dobře viditelné a hodilo se do celkové pracovní plochy. 7.2.2. Okna, jejichž velikost je variabilní
Okno by mělo mít schopnost přizpůsobit se většímu rozlišení, ale výchozí niţší rozlišení přináší lepší vlastnosti v další práci s oknem. Při vyuţití větších rozlišení jako výchozích je dobré si uvědomit, zda je velikost okna takto nutná. Proto by se autor GUI měl ujistit, ţe alespoň jedna část nebo jeden prvek má potřebu změny velikosti obsahu. Výchozí velikost okna by také měla vycházet z faktu, aby se nepřibliţovala stavu, kdy je okno přes celou obrazovku, tedy v reţimu full-screen. Pokud také stanovíme nejmenší moţnou velikost okna, uvaţujeme tak, aby obsah okna byl stále smysluplný a pouţitelný. S tímto faktem souvisí i stanovení minimální velikosti ovládacích prvků
26
jako např. nejmenší moţné rozměry sloupců seznamů apod. 7.3. Primární okno Tento druh okna se vyuţívá jako hlavní okno aplikace. Je třeba dbát na to, aby na sobě nezávislé akce aplikace nebyly děleny do více primárních oken, nebo naopak více nezávislých akcí nebylo realizováno jedním primárním oknem. Pokud aplikace obsahuje své menu, je právě primární okno tím, kdo toto menu realizuje. Mezi základní komponenty okna patří [MSW] (Viz Obrázek 6):
Rám Titulkový pruh Obsah titulkového pruhu Tlačítka Minimalizovat, Maximalizovat/Obnovit, Zavřít Nabídkový pruh Posuvníky Stavový řádek Panel nástrojů Táhlo Pracovní plocha Ovládací prvky Titulkový pruh
Minimalizovat
Maximalizovat Zavřít
Nabídkový pruh Panel nástrojů
Posuvník
Rám
Táhlo
Stavový řádek
Obrázek 8 - Komponenty primárního okna
Některým z nejdůleţitějších komponent se bude následující text věnovat podrobněji.
27
7.3.1. Rám
Rám vymezuje velikost okna – jeho rozměry a tvar. Pokud lze měnit velikost okna, můţe uţivatel pomocí prvku pro změnu velikosti okna, tzv. táhla, manipulovat s tvarem i rozměry okna po hranici, kterou dovoluje fullscreen (přes celou obrazovku). Pokud se nejedná o okno, jehoţ rozměry jsou pevně dané, vymezuje rám přesnou a nezměnitelnou velikost okna. 7.3.2. Titulkový pruh (Title Bar)
Nachází se při horním okraji okna pod rámem a jako pruh vyplňuje celou šířku okna. V tomto prvku je umístěna informace o obsahu okna. Slouţí také k identifikaci formuláře pro komunikaci mezi uţivatelem a dodavatelem. Jedná se především o hlášení chyb, poţadavky na úpravu stávající nebo nové funkčnosti. Mezi další prvky titulkového pruhu patří ikona, tlačítka pro změnu velikosti okna a tlačítko pro zavření okna. Kromě informování uţivatele o spuštěném programu, má funkci přesouvání okna – jeho uchycení. Vyuţitím klávesové zkratky „ALT+ mezerník“ se vyvolá z titulkového pruhu nabídka, která umoţní s oknem manipulaci, kterou lze v tomto případě ovládat pouze klávesami, nemusí vyuţít myši. Posledním funkcionalitou titulkového pruhu při pouţití doubleclicku je moţnost obnovení velikosti okna. Ikona titulkového prvku má rozměry 16 x 16px. Tuto ikonu bychom měli pouţít pouze v případě, kdy se nejedná o sekundární popř. dialogové okno. 7.3.3. Tlačítka titulkového pruhu
Zavřít („Křížek“) Kaţdé primární a sekundární okno, která má standardní titulkový pruh a celkově i rám, by mělo obsahovat tlačítko „Zavřít“. Pouţitím tohoto tlačítka dojde k uzavření okna a ukončí práci, která v okně byla prováděna.
Minimalizovat Kaţdé primární okno, popřípadě okno sekundární, jehoţ vyhodnocení trvá po určitou dobu (např. dialogové okno procesu ukládání apod.), by mělo obsahovat tlačítko minimalizovat. V případě pouţití tlačítka minimalizovat okno zredukuje svou velikost
28
do podoby „panelového tlačítka“ na liště, popř. v okně aplikace. Poté nese panelové tlačítko text titulkového pruhu.
Maximalizovat/ Obnovit U kaţdého okna, jehoţ rozměry jsou variabilní, lze pouţít tlačítka Maximalizovat/Obnovit. V případě, kdy chceme okno uvést do stavu full-screen, dojde k maximalizování okna. Zatímco pokud pouţijeme tlačítko Obnovit, změní se rozměry okna do předešlých rozměrů (nemusí to být nutně výchozí hodnoty). Správné rozmístění těchto tlačítek je následující: tlačítko Minimalizovat se musí nacházet vlevo od Maximalizovat/Obnovit a tlačítko Maximalizovat/Obnovit musí být nalevo od tlačítka Zavřít. 7.3.4. Stavový řádek (Status Bar)
Je umístěn ve spodní části okna podél celého jeho dolního okraje. Informuje uţivatele o aktuálním dění v okně, tzn., co je zobrazeno a jak, úkoly, které se dějí na pozadí (např. tisk), popřípadě zde můţe být zobrazen jistý způsob nápovědy např. speciální klávesové zkratky, které se v okně dají pouţít. Slouţí především jako zpětná vazba pro uţivatele o procesech v okně. Stavový řádek by neměl obsahovat zásadní informace, které by se měly prezentovat jiným způsobem. Ve stavovém řádku pouţíváme pro popis jen jednotlivé segmenty vět, ne celé věty a nepouţívám interpunkci. Dále nevyuţíváme moţností variability fontů či řezu písma (nepouţíváme kurzívu ani tučné písmo) ani barev. Titulkový pruh nemá lákat pozornost uţivatele, ale pouze mu poskytovat informace. 7.3.5. Posuvník (Scroll Bar)
Posuvníky umoţňují zobrazit uţivateli obsah okna, který na první pohled není vidět. Umoţní mu tak scrollovat (rolovat) náplň okna a pohybovat se po něm, pokud je obsah větší, neţ je velikost okna. Pouţít se dají dva druhy posuvníků horizontální a vertikální. Posuvník horizontální ale není moc vhodné pouţívat, pro uţivatele je jeho ovládání obtíţnější a zdrţuje ho od práce. Posuvníky by měly vzhledově odpovídat tomu, kde v okně se uţivatel nachází, aby byl schopen se podle nich orientovat. 7.3.6. Pracovní plocha
Pracovní plocha je místo, kde dochází k nejdůleţitější interakci uţivatele a IS. Právě do těchto míst umisťujeme ovládací prvky, jejichţ standardní vlastnosti budou sepsány v
29
další části textu. 7.4. Sekundární okno Jedná se o typ okna, které slouţí hlavně ke zpracování úloh, které jsou povaţovány za vedlejší, a tedy méně důleţité. Na rozdíl od primárního okna není zobrazováno na pruhu úloh (Task Bar), jelikoţ se vyskytuje jen jako přidruţené okno ke svému odpovídajícímu primárnímu oknu.[MSW] Vzhled sekundárního okna se od primárního okna liší. Má pevný rozměr a jeho velikost by měla být vţdy menší neţ velikost odpovídajícího primárního okna. Standardně okno tvoří rám, titulkový pruh a tlačítko pro ukončení práce s oknem („Kříţek“). Sekundární okna můţeme rozdělit celkem na dva druhy – modální a nemodální. V případě modálního okna jeho otevření zabrání uţivateli jakoukoli interakci s ostatními okny aplikace, dokud toto okno není obslouţeno. Provedené změny, které v okně uţivatel vykoná, budou viditelné aţ po potvrzení okna. Proto se tato okna pouţívají v kritických situacích, kdy by mohlo dojít k poškození dat nebo pro úkoly, které jsou jednorázové a potřebují okamţité řešení. Nemodální sekundární okno má vlastnost opačnou, kde je interakci s ostatním okny dovolena. Dává tak uţivateli na výběr, zda chce pracovat s dialogovým oknem anebo přímo s oknem aplikačním. Pouţívá se pro činnosti, které se často opakují. Jelikoţ je interakce mezi okny povolena, můţe tento druh oken obsahovat tlačítka titulkového pruhu – minimalizovat, maximalizovat. Provedené změny v dialogovém okně, které uţivatel provádí, se projevují uţ v průběhu práce s oknem, uţivatel nemusí čekat na schválení okna. Typickým příkladem sekundárních oken jsou okna dialogová, o kterých se práce bude zmiňovat na dalších stránkách. 7.5. Dialogová okna Dialogové okno je sekundární okno, které uţivateli umoţňuje provádět příkazy, ptá se jich na otázky ovlivňující průběh akce v aplikaci, podává důleţité informace a tím poskytuje uţivateli i zpětnou vazbu. Dialogové okno se skládá z titulkového pruhu, hlavní zprávy, plochy pro obsah, oblasti tlačítek a v některých případech i místa označovaného jako oblast pro poznámky. [MSW]
30
V titulkovém pruhu je umístěn titulek dialogového okna, který má uţivatele informovat o poţadavku nebo o aplikaci, od které poţadavek vzešel. V ţádném případě v titulkovém pruhu není typ zprávy. Titulkový pruh dále neobsahuje ikonu vztahující se k aplikaci, ale obsahuje vţdy tlačítko pro zavření dialogového okna. Hlavní zpráva obsahuje informaci, kterou chce program prostřednictvím dialogového okna uţivateli sdělit. Můţe ale také poskytovat další informace a některé ovládací prvky (např. odkazy). Další oblastí je oblast tlačítek. V těchto místech jsou umístěna příkazová tlačítka, ale pokud je to ţádoucí, umístí se zde i zaškrtávací tlačítko (Check Box) s textem „Příště tuto zprávu nezobrazovat“, která, jak fráze napovídá, zajistí, aby tento dialog nebyl při příští stejné akci opět vyvolán. V určitých situacích lze do této oblasti umístit i tlačítko zobrazující nadstandardní nebo také méně často vyuţívané funkce či vlastnosti okna. V poslední oblasti dialogu je místo pro poznámky. Často se jedná o jednoduchou nápovědu, která uţivateli poskytne pomoc obsluze okna. Dialogová okna by neměla obsahovat posuvníky, ani menu či stavový pruh. Doporučené rozměry dialogových oken:
výška: max. 263 DLU6 (395px) 218 DLU (327px) 215 DLU (323px) 188 DLU (282px) šířka: max. 263 DLU(395px) 252 DLU (378px) 227 DLU (341px) 212 DLU (318px)
Dialogová okna můţeme z hlediska interakce s uţivatelem dělit na ty s povinnou odezvou, volitelnou odezvou a potvrzovací. Dialogy s povinnou odezvou vyzývají uţivatele, aby zadal jistá data k provedení budoucí akce. Zatímco u volitelné odezvy, není uţivatel systémem nucen data zadávat, můţe ponechat původní nastavení a okno jen potvrdit nebo informace zadat. 6
DLU – Dialog Unit, vyuţívá se namísto fyzických pixelů (px), je nezávislá na zařízení [DOS]
31
Rozhodnutí je ponecháno na něm. Potvrzovací dialog slouţí jen k potvrzení. Uţivatel nemůţe ţádná data zadávat, pouze pouţitím tlačítek „Storno“ či „OK“ okno potvrdí. Velmi často jsou dialogová okna spojována s určitými druhy hlášení, které slouţí především jako zpětná vazba pro uţivatele, aby věděli, co se v IS odehrává a byli schopni nějakým způsobem na daný stav reagovat. V této práci budou řešena pouze dialogová okna tohoto typu. Základní pravidla, která by při vývoji těchto dialogových oken měla být dodrţována, se týkají především jejich obsahu, tzn. textu a ovládacích prvků. Podíváme-li se na strukturu textu sdělující určitý obsah zprávy, neměl by tento obsah být příliš sloţitý. Znamená to, ţe by se vývojáři měli vyhnout pouţívání slangových či odborných výrazů, kterým běţný uţivatel neporozumí, ale také by se měli vyhnout pouţívání zkratek, které také mohou obsah zprávy znehodnotit. Text by neměl být příliš dlouhý, v nejlepším případě pouze jedna věta. Struktura vět můţe být jakákoli, jsou povolena souvětí, ale jednoduché věty jsou pro uţivatele jednodušší na pochopení. Dalším společným kritériem je volba tlačítek. Dle jednotlivých moţností, jak uţivatel můţe na vzniklou situaci reagovat, musí být i správně zvolená tlačítka se správně zvoleným popiskem. Z hlediska bezpečného zachování dat, by kaţdé takové dialogové okno mělo mít tlačítko, jemuţ bude určena výchozí hodnota. S výchozí hodnotou se musí jednat velmi opatrně, neboť její špatné umístění můţe způsobit velké problémy v celém IS, a to především ztrátu citlivých dat. Pokud uţivatel nemá volbu, a nejedná-li se o chybu, pouţijeme typické příkazové tlačítko „OK“, kterým uţivatel dává systému najevo, ţe byl se situací obeznámen. Pokud se jedná o oznámení chyby, není dobrý přístup pouţít „OK“, jelikoţ chyba nikdy nemůţe být OK, a proto bychom v takovém případě měli pouţít tlačítko „Storno“. 7.6. Typy hlášení (zpráv) a jejich ikony
Obrázek 9 - Ikony hlášení v dialogových oknech
Jak Obrázek 9 napovídá, pouţívá se v dialogových oknech čtyř ikon označující hlášení,
32
přičemţ některá dialogová okna nemají ikonu ţádnou. Jedná se o kritickou chybu, upozornění, oznámení a dialogové okno s otázkou [DOS]. Text se věnuje hlavně prvním dvěma hlášením: kritické chybě a upozornění. 7.6.1. Kritická chyba
První ikoně zleva na Obrázku 9 odpovídá dialog s hlášením o kritické chybě. Tato zpráva upozorňuje uţivatele na chybu v systému a aplikace nedokáţe dále pracovat v plnohodnotném provedení akce. Kritická chyba oznamuje uţivateli fakt, ţe k chybě uţ došlo a je nutné ji opravit, jelikoţ její nevyřešení by mohlo mít váţné důsledky na chod aplikace (ztráta dat apod.). Efektivní chybové hlášení v sobě přináší informace, které uţivatel potřebuje, aby mu byla poskytnuta dostatečná zpětná vazba. Mělo by obsahovat oznámení o vzniklém problému, vysvětlení proč k němu došlo a návrh jeho řešení. Na základě těchto informací by měl uţivatel být schopen provést určitou akci anebo změnit své chování. Špatně konstruované a špatně pouţité chybové zprávy bývají jedním z nedostatků IS a zvyšují tak náklady na technickou podporu, ale i více zatěţují uţivatele. Pokud lze chybě předejít, mělo by se tak učinit, aby k pouţití chybového hlášení nemuselo dojít. To znamená, například opatřit ovládací prvky takovými vlastnostmi, jako je zákaz jejich pouţití v určitých situacích. V některých případech lze chybové hlášení napsat i do stavového řádku. Existuje několik základních standardů, kterých by se tvůrce GUI měl drţet, aby vzniklá dialogová okna s chybovými hlášeními byla uţitečná a poskytla uţivateli dostatečně rychlou a podstatnou zpětnou vazbu. V první řadě by měl být co nejpřesněji vystiţen problém a proč k němu došlo. Pokud uţivatel neví, jak s chybou naloţit, měl by zde být i stručný návrh toho, jak má chybu opravit. Dále by sdělená zpráva měla být relevantní a popsaný problém by se měl soustředit na uţivatele, tzn., neměl by mu oznamovat např. problémy v kódech, ale měl by mu laicky navrhnout, co s aktuální situací udělat, aby aplikace mohla dále pokračovat v plnohodnotném reţimu. 7.6.2. Upozornění
Označení pro upozornění je znázorněné na Obrázku 9 jako druhý objekt zleva. Jde o zprávu, která uţivatele upozorňuje o mimořádném stavu aplikace (akci), která při jejím provedení můţe mít váţné důsledky na chod aplikace (např. ztráta dat). Na rozdíl v
33
situaci u kritické chyby, zde má uţivatel ještě moţnost svým rozhodnutím pochybení zabránit, jelikoţ kritická situace ještě nenastala, ale v budoucnosti by mohla způsobit problémy. Moţnosti ztráty nebo pochybení jsou následující: únik dat obsahující interní a cenné informace (např. finanční nebo jiné podobně důleţité údaje), ztráta systémového přístupu či integrity a pochybení v oblasti osobních údajů a jejich kontroly. [MSW] Shrnutí charakteristik správného pouţití hlášení o upozornění by mělo vypadat následovně: zpráva by vţdy měla vyjadřovat nějaké riziko nebo nebezpečí pro uţivatele. Mělo by se jednat o aktuální problém, který musí být vyřešen hned, jinak není moţné pokračovat v práci dál. Rozhodne-li se uţivatel toto oznámení ignorovat, mělo by mu být ze zprávy jasné, jaké důsledky toto rozhodnutí bude mít na chod aplikace a jeho práci. Nakonec by se ale mělo uvaţovat o tom, zda je varování v podobě dialogového okna vůbec nutné pouţít, zda manipulace s tímto oknem nepřinese uţivateli více práce neţ je řešení samotného problému. 7.6.3. Oznámení
Oznámení, charakteristické ikonou s písmenem „i“ (viz třetí objekt z Obrázku 9), uţivateli poskytuje zpětnou vazbu na běţné sdělení. Uţivatel na ni musí reagovat výchozí akcí. 7.6.4. Otázka
V tomto případě je uţivatel vyzván, aby reagoval na otázku a došel k výběru nějaké z nabídnutých variant. Zvláštností u tohoto způsobu hlášení je především jeho struktura, jelikoţ je zakončeno otázkou, ale také tlačítka, která se zde pouţívají. Vţdy musíme pouţít minimálně dvě tlačítka, která doprovází variabilitu odpovědi na otázku pouţitou v hlášení. Nejčastěji se jedná o příkazová tlačítka s popisky „Ano/Ne“. V situacích, které jsou riskantní a mohou uţivateli přivodit určité problémy, které se jen těţko budou vracet zpět, pouţijeme tento typ hlášení, jeţ se bude dotazovat, zda si je uţivatel jist právě provedením dané akce. V hlavní části zprávy se dotazujeme na to, zda chce uţivatel v akci pokračovat, v doplňkových instrukcích by se mělo potom stručně popsat, co pokračování v této činnosti můţe způsobit. V tomto typu zprávy potom pouţijeme příkazová tlačítka „Ano“ a „Ne“, jelikoţ hlavní zpráva obsahuje otázku, na kterou musí uţivatel odpovědět.
34
8. Ovládací prvky Ovládací prvky jsou jednou z nejdůleţitějších částí celého vyvíjeného softwaru. To, jakým způsobem je navrhne pouţít vývojář GUI, rozhoduje o tom, jak dobře bude celá aplikace fungovat a jak dobře se bude uţivatelům ovládat. Na základě jednotlivých pravidel v úvodu práce budou tyto ovládací prvky pouţity a vhodně umístěny do poţadovaných oken. Jak by měly být pouţity, v kterých případech ano a v kterých nikoli, se bude věnovat práce na následujících řádcích. 8.1. Příkazová tlačítka (Command Buttons) „Tlačítko je ovládací prvek určený k přímému vyvolání akce“.[DOS] Tlačítka pouţijeme jen v těch případech, kdy chceme akci zahájit a v ţádném případě ne pro nastavené situace (tomu odpovídají jiné ovládací prvky, jako jsou Radio Button, Check Box apod.).
Obrázek 10 - Příkazové tlačítko
V systému existuje několik málo tlačítek, jejichţ pouţití se nemění v průběhu celé aplikace, tzn., ţe kdykoli jich pouţijeme v jakékoli části programu, budou mít pořád tu stejnou vlastnost. Mezi tato tlačítka patří:
„OK“, které zajistí uţivateli potvrzení vyvolávané akce „Storno“, které zastaví právě probíhanou akci „Pouţít“, které uloţí změny do IS, ale např. dialog nezavře „Zavřít“, které slouţí k ukončení práce s oknem „Nápověda“, která slouţí jako aktuální pomoc pro uţivatele
Autor GUI by měl dbát na to, ţe méně, je někdy více. Zdobení tlačítek, fontů popisků a manipulaci s rozměry by měl vynechat a snaţit se o jednotný vzhled v celé aplikaci. Je vhodné, pokud si situace neţádá něco jiného, pouţívat standardní rozměry tlačítek skrz celou aplikaci, a to platí i o jejich popiscích. Pokud se tvorba GUI bude ubírat tímto stereotypním způsobem, bude vzniklé uţivatelské rozhraní vypadat více profesionálně a stabilně.
35
8.1.1. Elipsa
Některá tlačítka nemají za úkol pouze zahájit určitou akci, ale mohou také vyvolat další okno, které bude ţádat zpracování uţivatelem. Takové tlačítko je opatřeno tzv. elipsou. K samotnému popisku tlačítka jsou doplněny tři tečky „…“ (viz Obrázek 11). Její schopnost je zaloţena na tom, ţe ke spuštění akce musí dojít ještě k podrobnějšímu nastavení, bez kterého by akce nemohla být zahájena. Aţ po obslouţení tohoto okna, můţe být akce provedena. Měla by se umístit k tlačítku pouze tam, kde vyvolání okna opravdu umoţňuje nastavení, bez jehoţ odsouhlasení by nebylo moţné akci provést do zdárného konce. Pouţití elipsy uţivateli napovídá, ţe okno, které elipsu obsahuje, je v podstatě nekompletní a vyţaduje jeho další aktivitu. [MSU]
Obrázek 11 - Použití elipsy
8.1.2. Standardní příkazové tlačítko
Jedná se o přesně nejvíce známý prototyp tlačítka, který vyvolá okamţitou akci. 8.1.3. Výchozí (defaultní) tlačítko
Výchozím tlačítkem je myšleno tlačítko, které se pouţije v okně, kde chceme mít nastavenou výchozí hodnotu, která po obslouţení okna povede k provedení akce, kterou můţeme brát také jako výchozí a byla přiřazena tomuto tlačítku. Výhodou této přednastavené hodnoty se nejlépe vyuţívá pro uţivatele, kteří pouţívají k obslouţení okna ve větší míře klávesnici neţ myš, jelikoţ nastavené výchozí tlačítko reaguje na pouţití klávesy „Enter“. Pouţití výchozí hodnoty tlačítka má ale také své úskalí. Je na autorovi GUI, kdy, kde a jak ji v okně nastaví, jelikoţ v některých případech můţe způsobit velké problémy, které mohou vést ke kritickým chybám či změnám, které si uţivatel ani nepřál. Vţdy ale platí, ţe v kaţdém okně smí být pouţito pouze jedno takovéto tlačítko s nastavenou výchozí hodnotou.
Obrázek 12 - Tlačítko s nastavenou výchozí hodnotou
36
8.1.4. Tlačítko „Procházet...“
Jak je vidět z názvu, obsahuje toto tlačítko elipsu, jeţ povede k vyvolání dalšího okna, které bude muset být uţivatelem obslouţeno. Je identické tím, ţe po jeho aktivaci se uţivateli otevře dialogové okno, které mu napomůţe vybrat validní hodnotu ze seznamu, který byl k tomuto účelu vytvořen (např. i z celé databáze). Často je v interakci s textovým polem, kde po výběru z dialogového okna se validní hodnota do Text Boxu zapíše. (viz Obrázek 11).
Obrázek 13 - Tlačítko „Procházet…“
8.1.5. Tlačítko pro skrytí/zobrazení informací (Progressive disclosure button)
Tyto tlačítka se vyuţívají v případech, kdy nechceme zobrazit všechny informace, které aktuálně otevřené okno obsahuje. Nechceme, aby byly zobrazeny např. z důvodu, ţe nejsou důleţité nebo je není nutné vyplnit. Pokud tedy informace nejsou frekventované, můţeme je skrýt a vyuţít tlačítka „Více >>“. Nastane-li situace, ţe toto tlačítko uţivatel aktivuje, dočasně skryté informace se v okně zobrazí, v ten samý okamţik mění tlačítko svůj popisek na „<< Méně“, a tím získává opačnou funkcionalitu, neţ mělo před tím. Pokud v tomto stavu bude uţivatel opět zobrazené informace chtít skrýt, vyuţije stejné tlačítko jako v opačném případě ovšem teď uţ s popiskem „<<Méně“ a zobrazené informace se opět skryjí a tlačítko změní svůj vzhled na „<< Více“.
Obrázek 14 - Tlačítka pro skrytí informací
8.1.6. Doporoučené rozměry tlačítka
šířka: min. 50 DLU (75px) výška: 15 DLU (23px) mezery mezi tlačítky: 4 DLU (6px)
37
Nevypadá pěkně, pokud pouţijeme více rozdílných šířek tlačítek v jednom okně. Měli bychom dbát na to, aby šířka u tlačítek v jednom okně byla stejná, a pokud toho není moţno z jakéhokoli důvodu docílit, je povoleno pouţít maximálně dvě odlišné šířky mezi tlačítky. 8.2. Přepínač (Radio Button, Option Button) Jednotlivé přepínače tvoří jeden komplexní ovládací prvek, díky němuţ jsou uţivatelé schopni vybírat a rozhodovat se při selekci z nabízených moţností. Nejlepším řešením je jednotlivé přepínače seskupit do jednotné skupiny, kde prvky mají mezi sebou určitou návaznost. Tuto interakci je vhodné doplnit ohraničujícím rámečkem (Group Box), který zcela viditelně skupinu vymezí a vytvoří jednotný celek Jedinečnost tohoto prvku spočívá v tom, ţe uţivatel musí vybrat vţdy jen jednu z moţností, na rozdíl od Check Boxu, který umoţňuje vybrat moţností více. Zvolením přepínače tedy omezujeme uţivatele tím, ţe se musí rozhodnout vţdy jen pro jednu alternativu. Zamezíme tak případným problémům, které by uţivatele mohly zmást, pokud by měl na výběr z více moţností. Jednotlivé přepínače je vhodné umístit ve vertikálním směru, tzn. pod sebe. Působí to na uţivatele lépe a přehledněji. Pokud to rozměry okna nedovolují, samozřejmě můţeme přepínače umístit i horizontálně, ale rozmístění vertikálním směrem je upřednostňováno. Také se snaţíme, aby jednotlivé přepínače byly nějakým způsobem seřazeny – dle nějakého logického klíče. Nejčastějším způsobem je řazení dle abecedy, popř. dle logické stránky voleb.
Obrázek 15 - upořádání vertikální
Obrázek 16 - uspořádání horizontální
38
Dalším standardem, který by měl být stanoven je minimální a maximální mnoţství moţností, které vytvořená skupina přepínačů můţe obsahovat. Ideální intervalem je 2 – 7 prvků, přičemţ větší mnoţství neţ sedm prvků působí uţ příliš chaoticky a dochází k přílišnému zaplnění pracovní plochy textem a prvky. Pokud tedy skupina překročí maximální mnoţství voleb, je vhodné skupinu přepínačů nahradit například rozbalovacím seznamem. Radio Button pouţíváme vţdy jen pro zvolení moţnosti ze zobrazené skupiny. Nikdy by neměl být pouţit pro vyvolání nějakého příkazu nebo zobrazení jiného okna. V takových případech pouţijeme jiných ovládacích prvků např. příkazových tlačítek, které mohou obsahovat i jiţ zmíněnou elipsu. Existují situace, kdy jednotlivé přepínače v sobě obsahují ještě další podruţné ovládací prvky. Autor GUI by měl zajistit, aby podřazené prvky nebyly uţivateli přístupné do té doby, neţ bude daná nadřazená moţnost zvolena. Tento jev „skrývání“ či zamezení manipulace s vnořenými přepínači, můţeme samozřejmě aplikovat i na další ovládací prvky, které do nadřízeného přepínače zařadíme. V případě, ţe tedy vnořené prvky pouţijeme, je vhodné je umístit napravo od nadřízených.
Obrázek 17 - Aktivní vnořené prvky (vlevo), Neaktivní vnořené prvky (vpravo)
V případě přepínače musí být vţdy nastavena výchozí defaultní hodnota celé skupiny. Tímto krokem zamezíme tomu, aby nedošlo k nechtěné ztrátě či chybě, která by mohla ohrozit chod aplikace či práci uţivatele. Z hlediska tohoto zabezpečení je důleţité s rozmyslem tuto výchozí hodnotu zvolit. Vývojář by měl vţdy za defaultní hodnotu určit tu, která zaručí největší stabilitu systému a jeho bezpečnost. Pokud taková hodnota ve skupině přepínačů neexistuje, zvolí se za výchozí defaultní hodnotu ta, kterou uţivatel pouţívá nejvíce a nejčastěji. V případě, ţe uţ vývojář defaultní hodnotu zvolil, mělo by
39
platit, ţe bude vţdy umístěna na prvním místě v ţebříčku celé skupiny. Pokud zde nastane moţnost, ţe by uţivateli nemusela vyhovovat ţádná z moţností, potom musí tato jednotná skupina obsahovat ještě jednu volbu - „Ţádné“ (Jsou povoleny různé alternativy popisků). Skupina tvořená přepínači bude vţdy obsahovat defaultní hodnotu. Nastane tak i v případech pokud nelze určit tu hodnotu, která je bezpečná nebo se pouţívá nejčastěji. Pokud bychom defaultní hodnotu nenastavili, uţivatel by došel k závěru, ţe ţádnou volbu provést nemusí, coţ v případě přepínačů není moţné, jelikoţ jeho pouţití je nastaveno vţdy tak, aby volba byla provedena. [MSU] 8.2.1. Doporučené rozměry přepínače:
Šířku přepínače v podstatě nelze určit, jelikoţ ho tvoří přepínač a jeho popisek, kterému se bude práce věnovat v jedné z kapitol. Měli bychom se ale snaţit vytvořit určitý blok, tzn. pouţít popisky, které budou přibliţně stejně dlouhé.
Výška: 10 DLU (17px) Vzdálenost mezi jednotlivými přepínači: 4 DLU (7px) Vzdálenost první volby od popisku rámečku či titulku celé skupiny (Group Boxu): 3 DLU (5px)
8.3. Zaškrtávací políčko (Check Box) „Zaškrtávací políčka jsou pouţívána k zobrazení a volbě ţádné, jedné nebo i více moţností současně.“.[DOS] Často se vyuţívá jako „částečný filtr“, který uţivateli slouţí k filtrování jen určité cílové skupiny dat, kterou si sám navolí. Jelikoţ se jedná o podobný prvek, jako je přepínač, existuje zde velké mnoţství stejných či podobných standardů, které ve zkratce opět zmíním v následujícím odstavci.
Obrázek 18 - zaškrtávací políčko
Mnoţství voleb by mělo odpovídat opět maximální hranici, tj. aţ 7 moţností. V případě, ţe by bylo nutné pouţít více moţných voleb neţ je maximum, zvolíme z hlediska lepší
40
přehlednosti a úspoře pracovní plochy moţnost Check Box List (Seznam se zaškrtávacími tlačítky). Přesněji se jedná o seznam poloţek opatřený (vertikálním) posuvníkem a zaškrtávacími políčky Check Boxů. Upřednostňujeme vertikální umístění před umístěním horizontálním. Jednotlivé poloţky by měly být opět systematicky seřazené dle nějakého klíče, tzn. podle abecedy (zde opravdu nejčastěji), popř. dle jiného logického systému. Stejně jako Radio Button nepouţíváme Check Box jako zástupný prvek pro vyvolání nějakého příkazu či vyvolání dalšího okna. Stejný přístup jako u přepínače bude i při vytváření sloţitějších a vnořených struktur. Vzhled zaškrtávacího políčka tvoří: samotný výběrový zaškrtávací prostor v podobě čtverečku a popisek dané volby. Pokud moţnost není zvolena, je zaškrtávací prostor prázdný, zatímco pokud moţnost zvolena je, objeví se v prostoru zatrţítko, které uţivateli názorně podává zpětnou vazbu o zvolení moţnosti. V případě, ţe nastane situace, kdy nechceme, aby bylo moţné nějakou volbu (popřípadě skupinu voleb) pouţít, potom provedeme taková nastavení vzhledu, aby to uţivateli bylo na první pohled jasné, a nesmí být prostor pro výběr opatřen zatrţítkem. Dle moţností, které uţivateli nastavíme, můţeme rozdělit výběry na několik druhů [MSU]:
individuální výběr nezávislý výběr závislý výběr smíšený výběr
V případě individuálního výběru má uţivatel pouze jednu moţnost, kterou můţe, ale nemusí zvolit. Nezávislý výběr zase uţivateli nabízí moţnost velké variability. Můţe vybrat všechny moţnosti, které jsou mu nabídnuty, můţe vybrat jen jednu či více, ale také nemusí vybírat ţádnou. Předposledním z moţných výběrů je závislý výběr. Tato selekce uţivatele omezuje v jednom směru, a to v tom, ţe vţdy musí být vybrána alespoň jedna z nabízených alternativ. Pokud tak uţivatel neučiní, bude dialogovým oknem na tento nedostatek upozorněn. Nakonec má autor GUI moţnost vyuţít i smíšený výběr. Ten se liší od ostatních uţ jen vizuálním vzezřením, kdy místo typického výběrového prostoru (čtvereček) nemá obvyklé zatrţítko, ale je vybarven (viz Obrázek 19). Tento jev má uţivateli napovědět, ţe zvolená moţnost není kompatibilní se všemi objekty, ale pouze s některými. Takto vzniklý stav by ale neměl být pouţit pro
41
poukazování na jinou cizí událost (např. ţe některá z funkcí není aktivována či nainstalována apod.).
Obrázek 19 - Smíšená hodnota
8.3.1. Doporučené rozměry zaškrtávacího políčka
Jelikoţ se jedná o podobný ovládací prvek jako je Radio Button, nebudou se lišit ani standardní rozměry, které se pouţívají pro vymezení zaškrtávacích políček. Opět lze pouţít variabilní rozměr šířky, jelikoţ nemůţeme ovlivnit, jak dlouhý popisek jednotlivé volby mohou mít, ale snaţíme se o efekt stejné délky popisku u kaţdé z voleb.
Výška: DLU (17px) Vzdálenost mezi jednotlivými zašrtávacími poloţkami: 4 DLU (7px) Vzdálenost první volby od popisku rámečku či titulku celé skupiny (Group Boxu): 3 DLU (5px)
8.4. Seznam (List) Seznam je ovládací prvek, který slouţí k výběru z nabízených moţností, které nejsou předem známy. První věcí, kterou musí mít autor GUI na paměti je, ţe seznam neslouţí k výběru akcí, ale pouze k výběru dat. Dále záleţí na tom, jakou pravomoc uţivateli dáme, zda bude moct volit více poloţek či pouze jednu. Od toho se následně odvíjí jednotlivé typy seznamů. Tento ovládací prvek bychom měli zvolit v případě, kdy máme dat větší mnoţství a dáváme uţivateli moţnost vybrat si z velkého mnoţství poloţek. Pokud bychom měli poloţek méně, je vhodné pouţít jiný ovládací prvek např. přepínač nebo zaškrtávací políčko. U seznamu je mnoţství umístěných poloţek neomezený, ale musíme opět dbát na to, aby seznam vypadal v okně přirozeně a nezabíral velké mnoţství pracovní plochy. Proto zde platí několik standardů, kterých by se vývojáři měli drţet. Prvním z nich je umístění minimálně tří a maximálně osmi poloţek v seznamu najednou. Pokud
42
existuje více voleb, které má seznam obsahovat, je nutné doplnit ho o posuvníky. Jedná se především o posuvníky vertikální, horizontálním se snaţíme vyhnout. Jelikoţ uţivatel upřednostňuje spíše pouţívání klávesnice, je nutné ovládací prvky zajistit i z tohoto hlediska. Pokud je seznam aktivní, uţivatel můţe vyuţít pouze klávesnice k jeho obslouţení. Měl by zde fungovat jakýsi filtr, díky němuţ se uţivatel velmi rychle dostane k poţadované a hledané poloţce. Pouţitím klávesové zkratky (resp. pouţitím klávesy s písmenem) by se měl uţivatel dostat v seznamu na první poloţku, jejíţ název začíná zmáčknutým písmenem. Dále se po seznamu můţe uţivatel pohybovat šipkami nahoru/dolů a vybranou poloţku potvrdí stisknutím klávesy Enter. V případě, ţe uţivateli nevyhovuje ţádná ze zobrazených moţností nebo naopak by rád vybral všechny moţnosti, měl by takovýto seznam obsahovat tzv. metavolby. Mezi metavolby můţeme zařadit dvě základní moţnosti: „Ţádný“ nebo „Vše“. V některých grafických rozhraních bývá zvykem uvádět místo označení prázdné volby „Ţádné“ pouze prázdný řádek. Toto řešení není příliš šťastné, jelikoţ můţe uţivatele zmást nebo nemusí tušit, k čemu tento prázdný řádek slouţí. Proto je lepší vţdy tuto metavolbu pojmenovat. Jako i předchozí dva ovládací prvky by i poloţky v seznamu měly být řazeny dle nějakého klíče – dle abecedy nebo podle jiného logického klíče. Jiným logickým klíčem v tomto případě můţe být řazení dle frekventovanosti pouţití volby uţivateli. V kaţdém případě, pokud se v seznamu vyskytuje více jak 12 voleb, je vhodné tuto skupinu poloţek vţdy řadit dle abecedy. Metavolby „Ţádný“ a „Vše“ umisťujeme nejčastěji na začátek seznamu jako první dvě poloţky. 8.4.1. Doporučené rozměry Seznamu
titulek: 3 DLU (5px) nad seznamem + stejné zarovnání výška: Windows Vista 14 DLU (21px) šířka seznamu: 1,3násobek textu nejdelší poloţky seznamu
U šířky seznamu by se měl brát ohled na nejdelší text poloţky. Ale v případě, ţe některá se svou délkou vůči ostatním extrémně vymyká, uvidí uţivatel v prostoru vymezeném pro seznam jen tu část textu, která odpovídá šířce seznamu. Můţeme ho doplnit o posuvník horizontální, ale jeho pouţití není vhodné, jelikoţ v okně vypadá nepřirozeně a uţivateli se hůře ovládá.
43
V případě vzájemného zarovnání popisku a prostoru seznamu, zarovnáváme obě části na stejné úrovni. 8.4.2. Jednoúrovňový seznam
V tomto případě je uţivatel velmi svázán pouţitím tohoto seznamu. Zaprvé musí provést volbu a vybrat si z nabízených moţností. Zadruhé vţdy tato volba smí být jen jedna. Tento seznam by se měl pouţít v případech, kdy se jedná o vzájemně se vylučující moţnosti. V případě, ţe by byl seznam tvořen hierarchickou strukturou, není pouţití jednoúrovňového seznamu dobrou volbou, jelikoţ zde poloţky mají všechny stejnou váhu, a proto by místo tohoto ovládacího prvku měla být pouţita Stromová struktura (Tree View). [MSU]
Obrázek 20 - Jednoúrovňový seznam
8.4.3. Multivýběrový seznam
Jedná se o druh seznamu, který uţivateli umoţňuje vybrat více poloţek, ale také nemusí vybrat ţádnou. Pro výběr více poloţek najednou se zde nabízí vyuţití Check Boxu, ale jelikoţ se jedná o velmi objemný ovládací prvek z hlediska jeho rozměrů a zabrání pracovní plochy, je v případech, kdy existuje na výběr velké mnoţství poloţek, vhodné pouţít právě multivýběrový seznam. Pro uţivatele je občas velmi těţké přijít na to, ţe zrovna tento seznam umoţňuje výběr více poloţek. Proto by tato skutečnost měla být uţivateli někde na očích. Nejlepším řešením je tuto informaci napsat jako instrukci k danému seznam. 8.4.4. Rozbalovací seznam (Drop Down List)
Liší se od obyčejného seznamu tím, ţe je zobrazena vţdy jen jedna moţnost a to ta, která je aktuálně vybrána. Z toho vyplývá, ţe nejde provést vícenásobnou selekci jako v předchozím případě. Jeho největší výhodou z hlediska grafického uţivatelského rozhraní je nenáročnost na prostor. Rozbalovací seznam má stejné vlastnosti jako seznam obecně. Dobře se vyuţívá v
44
případech, kdy vývojář ví, ţe některá z voleb je preferovanější více neţ ostatní, a proto zůstane ve výběru jen tato moţnost a ostatní jsou skryté. Stejně jako obyčejný seznam i tento rozbalovací seznam by měl obsahovat metavolby „Ţádný“ a „Vše“. Standardní rozbalovací seznam je základní a nejtypičtější druh rozbalovacího seznamu. Po výběru poloţky je rozbalovací seznam schován. Pouţitím šipky (klávesnicí šipkou nahoru/dolu) se seznam otevře a jsou zobrazeny všechny nabízené poloţky. Uţivatel se můţe po seznamu pohybovat pomocí šipek, kde je mu opět podána zpětná vazba v podobě označení poloţky, na které se právě nachází. Pokud si danou poloţku vybere, provede výběr buď kliknutím levého tlačítka myši, nebo potvrdí výběr stisknutím klávesy Enter.
Obrázek 21 - Rozbalovací seznam
8.5. Combo Box Jde o speciální rozbalovací seznam, který uţivatel smí editovat. Tvoří ho kombinace textového pole a rozbalovacího seznamu, přičemţ textové pole je závislým ovládacím prvkem na seznamu. Jeho práce je zaloţena na snadnějším zpracování poţadavku, kdy uţivatel začne vepisovat text do textového pole a na něj navázaný seznam okamţitě začne rolovat na odpovídající poloţku. Vyuţívá se z důvodu urychlení práce se seznamem, ale v první řadě musí uţivatel vědět, co chce za poloţku v seznamu vybrat a také to od něj očekává práci navíc, tj. vepisování textu.
Obrázek 22 - Combo Box
45
Jelikoţ se jinak jedná o typický seznam, platí u něj veškeré standardy jiţ popsané v kapitole Seznam (List). V případě Combo Boxu se ale snaţíme co nejvíce limitovat velikost vstupního pole. Jako příklad zde uvedu: Pokud pouţijeme Combo Box jen pro čísla, kdy největší z nich bude např. 999, tzn. trojmístné, zvolíme šířku textového pole jen pro tři místa znaků. [MSU] A kdy preferovat tento editovatelný rozbalovací seznam před klasickým rozbalovacím seznamem? V případě, kdy bude uţivatel preferovat zadání hodnoty před výběrem z jiţ nastavených moţností, přičemţ ale neustále musíme mít na paměti, ţe obsluha Combo Boxu je sloţitější neţ u obyčejného seznamu. 8.5.1. Doporučené rozměry Combo Boxu
šířka seznamu: 1,3násobek textu nejdelší poloţky seznamu výška: Windows Vista 14 DLU (21px)
8.6. Spin Box Tento ovládací prvek sem zařazuji z důvodu toho, ţe uţivatelé IS často pouţívají hodnoty číselné pro zadávání různých mnoţství a jednotek. Pro tento účel se zde nabízí vyuţití Spin Boxu. Slouţí především pro číselné hodnoty. Pro jiný typ hodnot (text) je lepší pouţít jiný ovládací prvek, např. rozbalovací seznam. Je tvořen textovým editorem a prvkem obsahující šipky. Vţdy by textové pole a šipky měly tvořit jednotný celek, tzn., ţe šipky jsou umístěny uvnitř Text Boxu. Šipky
Textové pole Obrázek 23 - Spin Box
Spin Box pouţijeme v situaci, kdy nabízené hodnoty v textovém poli jsou zaloţené na posun o nějaký interval či jednotku. Pokud všechny hodnoty nejsou takto validní, tzn., jedná se o specifické hodnoty vyčnívající z intervalu, není Spin Box vhodným řešením situace, a na místo něj by se měl pouţít jiný ovládací prvek např. rozbalovací seznam. Hlavní výhodou Spin Boxu jsou jeho rozměry. Je relativně malý, pouţívá se jen pro menší číselné hodnoty (nejčastěji do hodnoty 100 [MSU]), a tudíţ v okně šetří volné místo. Je vhodné pouţít ho pro uţivatele, kteří dávají přednost klávesnici před pouţíváním myši.
46
Pokud nastane situace, ţe Spin Box nemá být aktivní (např. pokud se stane vnořeným ovládacím prvkem k prvku, který nebyl zvolen), musí být neaktivní v tom smyslu, ţe nelze přepisovat obsah textového pole, ale nesmí fungovat ani pouţití šipek, jelikoţ šipky tvoří podruţnou část celého Spin Boxu. Základem dobrého Spin Boxu je stanovení posunu o danou jednotku. Kaţdá šipka musí mít nadefinováno, o jakou část se hodnota změní. Šipka nahoru posouvá hodnotu o jednu jednotku nahoru a šipka dolů posouvá hodnotu o jednu jednotku dolů. Nejčastěji je jednotka definována jako 1, ale samozřejmě je povoleno nastavení posunu i o jiný počet jednotek. Ale kaţdé pouţití šipky, posune hodnotu o stejný počet jednotek nahoru či dolů. V případě, ţe dojde uţivatel aţ na konec platných hodnot, měla by u Spin Boxu fungovat metafora „kolečka“. Ta funguje tak, ţe pokud se dostane uţivatel na hranici platných hodnot a pouţije tu samou šipku ještě jednou, dostane se opět na původní hodnotu, kde numerická škála začíná. Musíme ale předem rozhodnout, zda se to v konkrétním případě hodí a zda pouţití této metafory není nesmyslné. Spin Box se často pouţívá u hodnot jako je datum či čas. V těchto případech můţe textové pole obsahovat i oddělovače v podobě např. dvojteček či tečky. V takovéto situaci je ţádoucí zajistit moţnost více moţných vstupů do pole, s kterými se bude moci samostatně manipulovat. 8.7. Textové pole (Text Box) Jedná se o jeden z nejpodstatnějších a nejvyuţívanějších ovládacích prvků formulářů. Slouţí k vstupu a výstupu textu. Do textového pole je vţdy vpisován nebo vypisován neformátovaný text. Proto bychom měli vţdy dávat pozor na to, co dovolíme uţivateli do pole vpisovat. Vývojáři by měli zvolit určitý přístup, který bude korigovat vstupní data tak, aby nedošlo k zanesení nepřípustných hodnot. Zajištění této bezpečnosti lze nejlépe provést následujícími omezeními: určení minimálního a maximálního počtu vepsaných znaků a určení formátu, který lze do pole zapisovat. Protoţe v některých případech je pro uţivatele obtíţné takovéto omezení zaznamenat, je vhodné doplnit takto omezený Text Box o kontextovou nápovědu (např. při pouţití špatného formátu vstupu). Vţdy musí být uţivatel informován jistou formou hlášení (často chybového), ţe zadaná hodnota nebyla validní. Pokud uţivatele nechceme stresovat či děsit takovými hlášeními, je moţné k titulku textového pole doplnit poznámku (čistý statický
47
text), která uţivateli přiblíţí, jaké hodnoty do pole můţe zadávat. Otázkou je, kdy správně pouţít textové pole pro vypisování textu. Pokud totiţ potřebujeme vypsat více hodnot najednou, ne pouze jednu, je vhodné místo textového pole vyuţít ovládací prvek nějakého druhu seznamu. V případě, ţe chceme pouţít textové pole pro hodnotu numerickou, bude text, resp. číslice formátována zarovnáním doprava, na rozdíl od textu, který je vţdy v textovém poli zarovnán doleva. Zarovnání textu v textovém poli na střed se nepřipouští. Je dobré uţivateli napomáhat při zadávání textu do textového pole. V tomto případě můţeme pouţít v podstatě jistý druh seznamu, který automaticky podle prvních vepsaných znaků nabídne uţivateli auto-seznam, jiţ někdy zaznamenaných textových řetězců. Uţivatel nemusí vepisovat celý text, ale jen část, a pokud v rozevíracím seznamu existuje moţnost, která by odpovídala vstupu, který poţaduje, stačí vybrat poloţku ze seznamu a potvrdit (Enter, myš). Nepouţívá se v oblasti hesel a PINů, jelikoţ by mohlo dojít k porušení bezpečnosti a zneuţití osobních dat. Aktivní textové pole je vyznačeno blikajícím kurzorem, který je v poli umístěn. Pokud uţivatel chce napsaný text editovat, posunuje se kurzorem v poli šipkami doprava/doleva, popř. můţe pouţít myš a kliknutím přesunout kurzor, kam potřebuje. V případě označení textu, je textové pole obarveno, aby označení bylo patrné. Provést označení textu můţe uţivatel doubleclickem myši, taţením myši popř. klávesovými zkratkami. [MSU] Z hlediska toho, k čemu a jak jsou jednotlivá textová pole pouţívána hlavně z hlediska textových vstupů, se dělí na několik forem: 8.7.1. Klasický datový vstup
Jedná se o typický příklad textového pole, kam uţivatel můţe vepisovat text bez nějakého zvláštního omezení. 8.7.2. Formátovaný datový vstup
V tomto případě uţ má uţivatel nadefinována určitá pravidla, která musí při vyplňování textového pole dodrţet. Můţe se jednat např. o omezení maximálního počtu znaků. Zajímavým prvkem související právě s tímto formátovaným textovým polem je funkce „auto-exit“. Jedná se o pomůcku pro uţivatele, usnadňuje mu práci a posun po
48
formuláři. Pokud je textové pole obsazeno maximálním počtem povolených znaků, přeskočí kurzor, označující aktivní textové pole, do dalšího Text Boxu, aby bylo patrno, ţe v původním bylo vyplněno maximální moţné mnoţství přípustných znaků. Do takto formátovaného textového pole můţeme zařadit i pole, které v sobě obsahuje jiţ předvolené znaky. Typický příkladem můţe být Text Box, do něhoţ se zapisuje emailová adresa. Pro některé uţivatele můţe být obtíţné vzpomenout si na klávesovou zkratku, jejíţ pomocí se píše typický znak pro emailové adresy, tzv. „@“. V takových případech je vhodné zformátovat textové pole tím způsobem, ţe jako přednastavenou hodnotu vloţíme do pole právě zmíněný „@“. Pro uţivatele uţ bude „hračkou“ takové pole obslouţit, zatímco bez tohoto vloţeného znaku by mu to mohlo způsobit velké problémy. 8.7.3. Asistovaný datový vstup
Jedná se o typ textového pole, který kooperuje s jiným ovládacím tlačítkem. Jako příklad zde můţeme pouţít jiţ zmíněné tlačítko „Procházet...“. (viz Obrázek 13). V tomto případě dojde po zvolení poloţky pomocí výběrového tlačítka „Procházet...“ její přepsání právě do textového pole. Dochází zde tedy ke vzájemné spolupráci příkazového tlačítka a Text Boxu z důvodu zadání či úpravy textových řetězců, přičemţ tlačítko slouţí jako pomocník při výběru správné a platné hodnoty. 8.7.4. Textový vstup
Často má textové pole, do něhoţ se bude vpisovat text, více neţ jednu řádku. Slouţí tedy k vkládání delšího textového řetězce, kterému by nedostačovala typicky jen jedna řádka. Mnoţství vepsaného textu můţeme opět omezit, ale pokud zvolíme rozměr a mnoţství vloţených znaků nesymetricky, potom musíme takové textové pole opatřit posuvníkem, aby měl uţivatel přehled o celém vepsaném textovém poli. Pokud je to moţné a rozměry okna to dovolují, zvolíme raději větší prostor pro textové pole tak, aby pouţití posuvníků nebylo nutné. Jako samozřejmost bereme, ţe nikdy neumisťujeme posuvníky k jednořádkovému textovému poli.
Obrázek 24 - jednořádkový textový vstup
49
Obrázek 25 - víceřádkový textový vstup
8.7.5. Číselný vstup
Jak název napovídá, jedná se o textové pole, které přijímá znaky jen v podobě číslic. Často ho spojujeme s šipkami a dohromady následně tvoří Spin Box. U číselných hodnot, které se do textového pole budou vepisovat nebo vypisovat je nejlepší zpětnou vazbou doplnit do popisku jednotky validních hodnot, aby byl uţivatel jasně informován, co daná hodnota. Jedním z typických standardů patřící číselnému vstupu je zarovnání číslic doprava. V případě pouţití více číselných Text Boxů umístěných pod sebou, které budou obsahovat čísla s desetinnými čárkami, zarovnávají se čísla právě dle desetinné čárky. 8.7.6. Vstup heslo nebo PIN
V těchto případech má textové pole, resp. znaky umístěné (vepsané) do textového pole, zvláštní a jedinečné vlastnosti. Místo reálného vpisovaného textu se zobrazuje v textovém poli sada zástupných znaků. Nejčastěji se jedná o puntíky, hvězdičky apod. Díky tomu, aby byla zaručena bezpečnost systému, mívají hesla různé poţadavky. Mezi klasické poţadavky patří: pouţití malých i velkým písmen, číslic a speciálních znaků (#,*,?, ad.). Pokud uţivatel takové heslo nemá, měl by být na to upozorněn. Samozřejmě bude upozorněn i v případě, kdy zadá špatné heslo.
Obrázek 26 - Textové pole se zástupnými znaky
50
8.7.7. Validace vstupních dat
Aby se předešlo problémům, které by mohly způsobit nevalidní data, je nutné Text Boxy kontrolovat, aby byla zaručena bezpečnost celého systému. Prvním ošetření špatného vstupu do textového pole, v případě, kdy uţivatel vepíše špatný znak, měl by uţivatel být upozorněn na tuto situaci pomocí „Ballon Tipu“ či jiného druhu kontextové nápovědy, který uţivatele na nekorektní zadání upozorní a připomene mu, jaké znaky validní jsou. V případě, kdy uţivatel zadá špatné hodnoty, neměl by se mu text po zobrazení upozornění vymazat, aby ho uţivatel mohl upravit. Existuje ale situace, kdy se toto vymazání hodí, a to v případě špatně zadaného hesla či PINu, jelikoţ tento text, skrytý pod zástupnými znaky je těţko kontrolovatelný a opravitelný. 8.7.8. Doporučené rozměry textového pole
Šířka je variabilní, záleţí na omezení délky textového řetězce, popř. bychom ji měli přizpůsobit dle ostatních textových polí či jiných ovládacích prvků, tak aby okno vypadalo konzistentně a komplexně.
výška jednoho řádku: 14 DLU (23px) výška dvou řádků: 24 DLU (39px)
Mezery:
vzdálenost mezi popiskem a textovým boxem je: 3 DLU (5px) vzdálenost dvou textových polí umístěných pod sebou: na úrovni jednoho řádku, tzn. 14 DLU (23px)
8.8. Záložky (Tabs) „Záloţky jsou určeny k rozčlenění dialogu do více na sobě nezávislých částí pomocí záloţkových karet.“[DOS] Pouţití záloţek zajišťuje především úsporu místa v okně. Počet umístěných záloţek by neměl být příliš vysoký, jelikoţ uţivatel poté ztrácí přehled. Pouţít můţeme celkem dva typy umístění záloţek v okně – buď horizontální, nebo vertikální. V případě horizontálních záloţek by neměl jejich počet v jednom okně přesáhnout hodnoty 7. V případě vertikálních záloţek je počet omezen na maximálně 8. Pokud budeme pouţívat vnořené záloţky, není vhodné kombinovat horizontální i vertikální dohromady. [MSU]
51
U záloţek není vhodným řešením uţivateli napomáhat s porozuměním obsahu karty pomocí ikony. U tohoto ovládacího prvku není tento způsob doporučen, jelikoţ většinou stejně uţivateli příliš neobjasní situaci a navíc zabírá podstatně velké mnoţství pracovní plochy, která by se dala vyuţít lepším způsobem. U popisku záloţek postupujeme dle stejných pravidel jako u ostatních ovládacích prvků, ale popisek není ukončen dvojtečkou. 8.9. Skupinový Box (Group Box) Jedná se o ovládací prvek, který nemá ţádnou jinou vlastnost neţ vizuálně seskupovat jiné ovládací prvky, které mají stejné či podobné vlastnosti, nebo spolu nějakým způsobem souvisejí. Uţívání těchto „rámečků“ má ale i své nevýhody. Jejich přílišné pouţívání působí chaos v celém okně. Vytváří těţký dojem celé aplikace, a proto by se měl pouţívat střídmě a s rozmyslem. V ţádném případě nevnořujeme Group Boxy do sebe, jelikoţ by to nepůsobilo graficky dobře na uţivatele. Také nepouţíváme Group Boxy jen jako okrasné rámečky. Pokud se rozhodneme je pouţít, vţdy za účelem seskupení určitého počtu ovládacích prvků. Jako dobrým a uţitečným ovládacím prvkem ho můţeme nazvat v případě, kdy uţivatel preferuje pohyb po okně pomocí klávesnice, protoţe jednotlivé prvky, které jsou ukotveny ve skupinovém boxu, jsou ovladatelné pomocí klávesy TAB. To znamená, ţe je upřednostněn pohyb nejdřív po jednotlivých prvcích v Group Boxu a aţ potom se přechází na další skupinový box či jiné ovládací prvky. [MSU] Podobnou funkci jako Group Boxy mají i oddělovače. Jedná se o horizontální čáry, které splňují stejně jako skupinový box, pouze vizuální vlastnost, a to seskupit jednotlivé komponenty okna, aby bylo na první pohled patrné, co spolu souvisí, a kde se přechází uţ do jiné oblasti řešení. V oblasti popisku skupinového boxu opět platí stejná základní pravidla, ţe nepouţíváme pro popsání skupiny věty, ale fráze, nejlépe jedno slovo, a nepouţívá interpunkci, tzn., ţe popisek není ukončen interpunkčním znaménkem.
52
9. Typografie I v tomto případě budou typografické standardy zaloţené na standardech vycházejících z OS Windows (Windows Vista, resp. Windows 7). Prvním standardem, kterým je potřeba se zabývat, je volba systémového fontu. Tento typ písma by měl procházet celým informačním systémem. Pokud vyuţijeme moţnosti OS Windows Vista, stane se systémovým fontem nemocničního informačního systému Segoe UI. Tohoto fontu se vyuţívá standardně při vytváření formulářů a dialogů. Byl vytvořen speciálně pro uţivatelské rozhraní, proto jeho pouţití v nemocničním informačním systému, je více neţ vhodné. Společnost Microsoft tento druh písma vyvíjela několik let a výsledkem jejich práce je zlepšení čitelnosti na obrazovkách (v dnešní době především na LCD displejích). V porovnání se systémovým fontem pouţívaným ve Windows XP – Tahoma, je Segoe UI lépe přizpůsoben ClearTypu7, coţ zaručuje systému lepší čitelnost a lepší celkový vzhled. Základní klasický text fontu Segoe UI bez jakéhokoli zvýraznění má velikost 9 bodů (ang. jedn. pt) na rozdíl od XP fontu Tahoma, které má velikost 8,25 bodu. I to je zárukou lepší čitelnosti textu na monitoru počítače. Dalším aspektem, proč vybrat zrovna tento systémový font je vlastnost písma – bezpatkovost. Jelikoţ potřebujeme, aby vzhled aplikace byl čistý a přehledný, proto je vhodné pouţít spíše bezpatkové písmo, které i u monitorů s niţším rozlišením tyto vlastnosti zajistí. Dalším standardem, který bychom v závislosti typografie měli dodrţovat, je kontrast. Obliba uţivatelského rozhraní závisí na vytvoření kontrastu mezi psaným textem a pozadím. Kontrast tedy můţeme vytvořit dvěma způsoby. Umístěním světlého textu na velmi tmavý podklad anebo umístění tmavého textu na světlý podklad. V případě vytváření grafického uţivatelského rozhraní, které má působit přátelsky a pozitivně, přichází v úvahu tedy pouze varianta číslo dvě – tmavý text na světlém pozadí. O jaké barvy se u nemocničního informačního systému bude jednat, není zatím vyřešeno. Samozřejmě zde existuje moţnost úpravy textu, tak, aby vzhled okna byl pro uţivatele přitaţlivý. To znamená, ţe lze měnit velikosti písma, jejich barvy, ale i řezy. Například 7
ClearType - technologie zobrazení počítačových písem slouţící k dosaţení čistého a hladkého písma
[WIN]
53
tučné písmo pouţijeme v případě zdůraznění, kdyţ budeme uţivatele na dané slovo (sousloví) upozornit apod. Dále pak můţe autor GUI pouţívat kurzívu či podtrţení. Nikdy by ale neměl zvýraznit text pomocí tučné kurzívy, jelikoţ tento styl se nepouţívá a povaţuje se za příliš hrubý. Podtrţení by se autor měl také vyhnout kromě jedné výjimky, kterou tvoří odkazy např. v budoucím webovém rozhraní. Základní velikost písma by ale měla být ponechána na 9 bodech a v případě nějakých nadpisů (např. v dialogových oknech) je moţné pouţít průměrné velikosti aţ 12 bodů. Jedním z hlavních objektů, na kterých se projevují typografická pravidla, jsou popisky jednotlivých ovládacích prvků. Proto se následující podkapitola popiskům bude věnovat, jak z hlediska obecných standardů, které platí pro všechny ovládací prvky, ale také konkrétních pravidel, které jsou typické pro jednotlivé ovládací prvky. 9.1. Popisky (Labels) V prvém případě platí, ţe kaţdý ovládací prvek musí mít svůj popisek, a to za kaţdé situace. Kaţdý prvek musí být jednoznačně a jasně identifikovatelný, aby uţivatel mohl ihned poznat, k čemu a za jakým záměrem byl prvek pouţit. Popisek vţdycky začíná velkým písmenem, ostatní jsou malá. Dalším standardem, který by měl vţdy platit, je formát popisku. Autor GUI by se měl snaţit kaţdý ovládací prvek pojmenovat tak, aby jeho název netvořila věta a nebyl příliš dlouhý. Ideálním stavem je, pokud je prvek charakterizován jedním slovem, popř. slovním spojení či frází. [DOS] Obsah popisku by měl být vţdy jednoznačný a jasně definovaný, aby uţivatel o jeho pouţití neměl pochybení. Jedná se hlavně o ovládací prvky, které nejčastěji v aplikacích vytváří nějaké skupiny, tzn. Radio Button, Check Box apod. Jelikoţ je uţivatel v těchto případech nucen provést volbu, která mu přinese nějaké následky, je důleţité, aby se dle popisku uměl správně rozhodnout. Autor GUI, který umístí do okna ovládací prvky, které budou sdruţeny do určité skupiny, by se měl snaţit, aby popisky těchto prvků měly přibliţně stejnou délku. V některých případech to opravdu není reálné, ale podobná délka popisků prvků v takovéto skupině vytváří kompaktnější celek, který vizuálně na uţivatele působí uspořádaně a jednodušeji. Pokud v takovéto skupině prvků autor GUI nalezne v popisku všech stejné slovo, je vhodné toto slovo z popisků vyjmout a umístit ho jako např. popisek Group Boxu, který tak pojmenuje celou skupinu vzájemně propojených prvků. 54
Z hlediska interpunkce se některá typografická pravidla jednotlivých prvků liší. V ţádném případě není ţádný ovládací prvek ukončen tečkou. Existují dva způsoby ukončení popisku ovládacího prvku. Prvním z nich je, ţe ovládací prvek není ukončen ţádným interpunkčním znaménkem. Děje se tak v případě příkazového tlačítka, přepínače, zaškrtávacího tlačítka, záloţky a Group Boxu. Druhou moţností je ukončení ovládacího prvku dvojtečkou. Tento způsob pouţijeme především u všech druhů seznamu a také u ovládacího prvku Combo Box a textového pole. V případě, kdy některý z prvků, jejichţ popisek není ukončen dvojtečkou, bude obsahovat ještě další podmnoţinu podřadných prvků, pouţije autor GUI dvojtečku u popisku, který ho obvykle nemívá, aby tím uţivateli naznačil, ţe jeho výběr bude mít pokračování a s akcí ještě neskončil. V některých případech je nutné některý z prvků, či skupinu prvků, opatřit poznámkou či nějakým bliţším vysvětlení (pouţití, důsledky apod.). Takovýto text umístíme vţdy pod ovládací prvek. Zde uţ můţe být pouţito vět, ale stále bychom se měli vyvarovat pouţívání sloţitých souvětí. Interpunkce uţ je v těchto situacích zapotřebí, tudíţ věty jsou klasicky ukončeny tečkou. 9.1.1. Popisky tlačítek
Text, kterým jsou tlačítka opatřena, vycházejí ze standardního fontu pouţitého v celé aplikaci. Z hlediska pouţití správné gramatiky nebo také správné formy slova se vychází z toho, ţe nejsrozumitelnější pro uţivatele je označení tlačítka podstatným jménem či slovesem. Vţdy ale musí být uveden v základním tvaru, tzn. podstatné jméno v prvním pádě a sloveso v infinitivu. Existují samozřejmě výjimky, kde lze jako popisek tlačítka pouţít i jiný slovní druh např. příslovce apod. Patří sem například tlačítka označená jako: „Více“, „Méně“, „OK“, „Zpět“, „Vpřed“ ad. Pokud nastane situace, kdy je nevyhnutelně nutné pouţít delší označení tlačítka a pouţít více slov pro lepší objasnění funkcionality takového tlačítka, nejčastěji pouţijeme podstatné jméno a sloveso. Takto vzniklý popisek bude mít pořadí slov následující: první bude sloveso v infinitivu a aţ potom bude následovat podstatné jméno. Pokud by nastala situace, kdy by bylo nutné pouţít popisek funkčnosti více jak pěti slovy (aby uţivatel přesně věděl, k čemu akce povede), nahradí se tlačítko standardním odkazem.
55
Kaţdé tlačítko by mělo být ošetřeno z hlediska specifické klávesové zkratky, která je uţivateli graficky znázorněna podtrţením identifikujícím písmenkem. Toto specifické označení nemusí mít tlačítka jako „OK“ a „Zavřít“, jelikoţ u nich se přepokládá automatické a defaultní přiřazení kláves „Enter“ a „Esc“. Vzhled tlačítka ale můţe být i více interaktivní. Nemusí se vţdy jednat o obyčejné tlačítko s popiskem. Dnešní doba si vyţaduje větší vizualizaci, proto je dnes na denním pořádku pouţívat tlačítka, která obsahují buď jen ikonu, nebo dokonce ikonu i popisek. Pouţijeme-li pouze ikonu, je vhodné opatřit tlačítka jiným způsobem popisku. V těchto případech vyuţijeme popisek, který se zobrazí pouze při najetí kurzoru myši nad toto tlačítko (zvláštní způsob kontextové nápovědy). Jedním z posledních společných standardů je řazení prvků ve skupině či v seznamu. Ovládací prvky vţdy musí nějakým klíčem seřadit. Nejčastěji se jedná o řazení dle abecedy vzestupně, popř. u některých prvků můţeme upřednostnit řazení dle jiného logického klíče, například dle četnosti pouţívání uţivatelem apod. 9.1.2. Popisky přepínače
Přepínače se většinou vyskytují ve skupinách. Pojmenování jednotlivých prvků v takovéto skupině by mělo být co nejvíce diferentní, aby uţivatel lehce rozpoznal vzájemnou výlučnost voleb. Jak bylo zmíněno ve vlastnostech přepínače, vţdy je nastavena jedna defaultní hodnota. Tato hodnota je vţdy spojena s doporučením vývojáře, aby z jakéhokoli hlediska uţivateli usnadnila výběr. Pokud se jedná tedy o hodnotu, která je opravdu doporučena (např. z hlediska bezpečnosti dat a systému), je vhodné za popisek takového přepínače umístit do závorky informaci „(Doporučeno)“. 9.1.3. Popisky zaškrtávacího políčka
Stejně jako přepínač se zaškrtávací políčko vyskytuje nejčastěji ve skupinách. Proto i zde bychom měli dát hlavní důraz na to, aby pojmenování voleb bylo slovně jednoznačně určeno, jelikoţ stejný či podobný význam fráze popř. slova, by uţivatele mohl mást a nevěděl by, kterou z moţností zvolit. V případě závislého výběru, kdy je uţivatel nucen vybrat minimálně jednu z nabízených moţností, měl by být na to upozorněn. Vhodným umístěním takovéto poznámky je
56
místo nacházející se za titulkem ohraničující celou skupinu Check Boxů. 9.1.4. Popisky Seznamu
Na rozdíl od Check Boxu a Radio Buttonu zde v kaţdém případě uvádíme za popisek dvojtečku, která uvozuje následující výběr poloţek(ky). Popisek seznamu i jednotlivé názvy poloţek začínají velkými písmeny a nejsou ukončeny tečkou. Také se vţdy snaţíme o to, aby názvy poloţek seznamu měly vţdy co nejvíce podobnou délku, aby seznam vypadal kompaktně a dodrţoval pravidlo konzistence. V případě, ţe by se seznam nacházel jako vnořený ovládací prvek např. k přepínači či Check Boxu, a bude-li nadřízený prvek označen dvojtečkou, potom samotný seznam svůj popisek nemá, jelikoţ jeho funkce vyplývá jiţ z ovládacího prvku mateřského. Pokud nastane situace, kdy potřebujeme seznam nějakým způsobem uvést, jeho funkčnost zdůraznit ještě neţ začne uţivatel provádět volbu dat, umístíme tento text nad popisek seznamu a instrukce ukončíme tečkou opět jako běţný statický text. 9.1.5. Popisky rolovacího seznamu a Combo Boxu
Jelikoţ se jedná o v podstatě stejné ovládací prvky, které jsou zaloţené na stejné funkčnosti, mají hodně společných vlastností, nevyjímaje vlastnosti popisků. Vţdy tyto ovládací prvky ukončujeme dvojtečkou a popisek začíná velkým písmenem. Pokud budeme pouţívat např. v Combo Boxu jen čísla, která nám vyznačují nějaké jednotky, je vhodné tyto jednotky doplnit jako statický text k popisku, který je tomuto ovládacímu prvku určen. Poskytneme tím uţivateli dostatečné informace o tom, co vlastně vybírá a volí. Text jednotlivých poloţek samozřejmě také začíná velkým písmenem a vţdy se musíme snaţit o to, aby názvy byly zcela unikátní a uţivatel tak věděl, jakou z moţností zvolit. 9.1.6. Popisky textového pole
Popisky textového pole vycházejí především z obecných pravidel pro všechny ovládací prvky, ale jako u seznamu, je popisek Text Boxu ukončen dvojtečkou, která samotný Text Box uvozuje.
57
10.
Závěr
Vybraná doporučení, zde zpracovaná, se budou aplikovat na konkrétní aplikační software, který je ve chvíli vzniku této práce ve fázi vývoje. Jedná se o dlouhodobý projekt, a tak se standardy vycházející z doporučení budou pro tento projekt dále nastavovat. Pro momentální potřeby programátorů jsou ale zatím postačující. Projekt těchto standardů nemusí vyuţít prozatím jako striktní pravidla, která se musí pouţít, ale spíše doporoučení, které by jim mělo usnadnit práci při vývoji systému. Zda se dodrţí všechna zmíněná pravidla, se projeví aţ během průběhu vývoje projektu, kdy se obecná pravidla budou přesněji definovat na konkrétní místa a případy. Změny budou zaznamenány a standardy upraveny. Případné najmutí profesionálního grafika situaci opět můţe dramaticky pozměnit a vzniklé standardy nemusí být vyhovující. Jak úvod práce naznačoval, nejsou v této práci zachyceny veškeré komponenty grafického uţivatelského rozhraní, které tvoří kompaktní celek informačního systému. Standardy nezmíněných prvků jako např. menu, vzhled ikon, audio prvky, barevné palety textu, pozadí okna apod. budou dotvářeny průběţně v dalších etapách projektu, aţ bude jejich potřeba aktuální. Pro získání informací pro tuto práci jsem postupovala v první fázi testováním starého informačního systému a analyzováním jeho nedostatků. V další fázi jsem shromaţďovala materiál, který zmíněné nedostatky vysvětloval a opravoval, popř. materiál, který zdokonaloval určité obecné zvyklosti ve starém IS. Tento materiál jsem potom induktivně setřídila a pouţila pro vytvoření dokumentace obecných standardů, které by měl nový IS dodrţovat pomocí klasifikační analýzy. Následně jsem řešila i vzájemnou interakci mezi jednotlivými ovládacími prvky a to z hlediska analýzy vztahové – v jakém vzájemném vztahu prvky mohou být a jaká pravidla jejich vzájemná interakce můţe mít. V budoucí fázi projektu by se pak tyto standardy měly deduktivně aplikovat na konkrétní obrazovky nově vzniklého nemocničního informačního systému. Tyto a další standardy napomohou při tvorbě celého informačního systému, jelikoţ jejich účelem je zaručit kompaktnost a jednotnost celé aplikace, jejichţ správná aplikace se pak odrazí na spokojenosti uţivatele s uţíváním IS.
58
11.
Seznam literatury
Literatura [DOS] DOSTÁL, Martin. Základy tvorby uživatelského rozhraní. Olomouc, 2007. 67 s. Učební text. Přírodovědecká fakulta Univerzita Palackého v Olomouci. [KUN] KUNC, Pavel. Beneta. 2005 [cit. 2010-06-26]. Project Management Requirement engineering. [MSU] Microsoft Corporation. Windows User Experience Interaction Guidelines for Windows® 7 and Windows Vista®. Redmond: Microsoft Press, 2009. 876 s. [MSW] Microsoft Corporation. Windows User Experience Interaction : Official Guidelines for User Interface Developers and Designers. Redmond: Microsoft Press, 2009. 537 s.
59
Elektronické zdroje [HOB] HOBART, James. Classic System Solutions [online]. 1995 [cit. 2010-06-24]. Principles of Good GUI Design. Dostupné z WWW:
. [JAN] JANSEN, Bernard J. Jim Jansen [online]. 1998 [cit. 2010-06-24]. The Graphical User Interface: An Introduction. Dostupné z WWW: . [KAU] KAUFMANN, Jeff. GUI Bloopers : Don'ts and Do's for Software Developers and Web Designers. San Francisco : Morgan Kaufmann Publishers, 2000. 559 s. [KRE] KREJČÍ, Richard. Grafika [online]. 2002 [cit. 2010-06-24]. PDF formuláře: Popis formulářových prvků. Dostupné z WWW: . [PAP] PAPÍK, Richard. Vyhledávání informací II. : Uţivatelské rozhraní a vlivy oboru “human-computer interaction”. Národní knihovna: Knihovnická Revue [online]. 2001, 2, [cit. 2010-06-24]. Dostupný z WWW: . [PCS] PCS Systems, spol s r. o. [online]. 2006, 30. 4. 2010 [cit. 2010-06-26]. Dostupné z WWW: . [SOF] SOFTEC [online]. 2009 [cit. 2010-06-24]. Role designu a ergonomie při návrhu SW aplikací. Dostupné z WWW: . [SYM] SYMBIO [online]. 2009 [cit. 2010-06-24]. GUI Bloopers. Dostupné z WWW: . [ŠTU] ŠTURALA, Aleš . Vyvojar.cz [online]. 2007 [cit. 2010-06-26]. WPF - Hello 'XAML' World. Dostupné z WWW: . [WIN] Microsoft Corporation. Windows [online]. 2009 [cit. 2010-06-26]. Technologie ClearType: nejčastější dotazy. Dostupné z WWW: .
60
12.
Seznam Obrázků
Obrázek 1 - ukázka formuláře NIS PCS*CARE ............................................................ 11 Obrázek 2 - ukázka formuláře NIS PCS*CARE ............................................................ 11 Obrázek 3 – Souměrnost (vlevo) a Nesouměrnost (vpravo) ........................................... 20 Obrázek 4 – Pravidelnost (vlevo) a Nepravidelnost (vpravo) ......................................... 20 Obrázek 5 – Předvídatelnost (vlevo) a Atypičnost (vpravo) ........................................... 20 Obrázek 6 – Následnost (vlevo) a Náhodnost (vpravo) .................................................. 21 Obrázek 7 – Jednotnost (vlevo) a Fragmentace (vpravo) ............................................... 22 Obrázek 8 - Komponenty primárního okna .................................................................... 27 Obrázek 9 - Ikony hlášení v dialogových oknech ........................................................... 32 Obrázek 10 - Příkazové tlačítko ...................................................................................... 35 Obrázek 11 - Pouţití elipsy ............................................................................................. 36 Obrázek 12 - Tlačítko s nastavenou výchozí hodnotou .................................................. 36 Obrázek 13 - Tlačítko „Procházet…“ ............................................................................. 37 Obrázek 14 - Tlačítka pro skrytí informací ..................................................................... 37 Obrázek 15 - upořádání vertikální................................................................................... 38 Obrázek 16 - uspořádání horizontální ............................................................................. 38 Obrázek 17 - Aktivní vnořené prvky (vlevo), Neaktivní vnořené prvky (vpravo) ......... 39 Obrázek 18 - zaškrtávací políčko .................................................................................... 40 Obrázek 19 - Smíšená hodnota ....................................................................................... 42 Obrázek 20 - Jednoúrovňový seznam ............................................................................ 44 Obrázek 21 - Rozbalovací seznam .................................................................................. 45 Obrázek 22 - Combo Box ............................................................................................... 45 Obrázek 23 - Spin Box .................................................................................................... 46 Obrázek 24 - jednořádkový textový vstup ...................................................................... 49 Obrázek 25 - víceřádkový textový vstup ........................................................................ 50 Obrázek 26 - Textové pole se zástupnými znaky............................................................ 50
61
