Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta
Nové postupy uplatňované při návrhu uživatelsky přívětivých informačních systémů Disertační práce
Vedoucí práce: Doc. Ing. Arnošt Motyčka, CSc.
Brno 2005
Ing. Hana Netrefová
Poděkování Na tomto místě bych ráda poděkovala osobám, které se přímo či nepřímo podílely na vzniku této práce a podporovaly mě v době mého doktorského studia. • Svému školiteli Doc. Ing. Arnoštu Motyčkovi, CSc. za rady a připomínky k této práci a za podporu v době mého doktorského studia, která nemusela být vždy samozřejmostí, • kolegovi RNDr. Ing. Milanu Šormovi za neocenitelnou spolupráci při výzkumu prováděném v této práci a za řadu podnětů, • kolegyni Mgr. Jitce Machalové, Ph.D. za podporu a povzbuzování při psaní práce a za závěrečné korektury, • kolegům z vývojového týmu Univerzitního informačního systému za pomoc při realizaci praktických výsledků práce v UIS, • mamince RNDr. Bohumile Černé za cenné připomínky a korektury této práce, • manželovi Pavlu Netrefovi za trpělivost, vstřícnost a pochopení.
Prohlašuji, že jsem tuto práci vypracovala samostatně s použitím literatury, jejíž seznam uvádím v závěru a kterou řádně cituji v textu.
4 Abstrakt Netrefová, H. Nové postupy uplatňované při návrhu uživatelsky přívětivých informačních systémů. Disertační práce. Brno, 2005. Využití informačních systémů a informačních technologií proniká v dnešní době do nejrůznějších oblastí lidské činnosti. Díky tomu jsou na informační systémy kladeny stále vyšší nároky a přirozený vývoj směřuje k budování kvalitnějších a komplexnějších systémů. Jedním z významných aspektů informačních systémů je uživatelská přívětivost. Systémy musí být pro uživatele jednoduché a přehledné a práce s nimi intuitivní, samozřejmě za dodržení předpokladu poskytování všech požadovaných operací. Zdánlivě jasná definice uživatelské přívětivosti však zahrnuje řadu hledisek, které je třeba brát v potaz. Mezi dva základní přístupy řadíme pohled uživatele a pohled tvůrce systému. Zatímco uživatel nejčastěji požaduje, aby se mu se systémem dobře pracovalo, autor musí navrhnout celý systém tak, aby splňoval požadavky uživatelů a současně plnil roli uživatelské přívětivosti podle názoru jeho tvůrců. Teoretická východiska práce týkající se obou zmíněných pohledů jako portálové řešení informačních systémů, jejich architektura, systémová integrace, doporučení pro tvorbu uživatelského rozhraní systémů a používané metody jsou diskutovány v první části práce. Následuje stěžejní druhá část, kde je zkoumána a navrhována metodika pro tvorbu nové generace webových informačních systémů. Jsou zde definovány parametry uživatelské přívětivosti a významně je začleněna personalizace, osobní přizpůsobení systému potřebám a požadavkům uživatelů. Je definována metodika nazvaná Component boxing model pro návrh komponentově orientovaného informačního systému. Na základě této metodiky je pak vytvořen model uživatelského rozhraní informačního systému v podobě hierarchického stromu komponent. Pro jeho sestavení jsou definovány pojmy představující typy komponent – box, obsah boxu, design boxu, vizuální prvek, dále nalezeny komponenty stránky a stanoveny povinné, volné, vázané prvky a typy vazeb mezi nimi. Pro rozložení stránky do komponent a složení výsledného výstupu jsou určena a popsána jednoznačná pravidla. Třetí část práce se týká uplatnění navrhované metodiky v praxi. Na příkladu implementace variantních designů v univerzitním informačním systému je prokázáno, že komponentový přístup je možné použít na úrovni prezentační vrstvy. Tím se otvírají další možnosti použití – zobecnění na všechny úrovně webového informačního systému či na jiné typy systémů. Ze způsobu implementace dále vyplývá, že komponentově orientované informační systémy významně podporují personalizaci, pružnost, rozšiřitelnost a vzájemnou integraci, což jsou vlastnosti požadované od informačních systémů dnešní doby a jsou známkou jejich uživatelské přívětivosti.
5 Abstract Netrefová, H. New methods used for designing user-friendly information systems. Dissertation thesis. Brno, 2005. The use of information systems and information technologies nowadays penetrates through various domains of human activities. Therefore, constantly growing demands are made on the information systems and the natural development is aimed at building systems of higher quality and complexity. One of the important aspects is the user-friendliness. For the users the systems must be simple and transparent and the work with them must be intuitive. Naturally, the pretension of providing all the required operations must be sustained. However, the apparently clear definition of the user-friendliness consists of a number of aspects that must be consulted. Among the two basic approaches we rank the view of a user and of a system author. While the user’s most frequent requirement is that the work with the system is comfortable for him or her, the author must design the information system in the way that it answers the users’ wishes and fulfills the role of user-friendliness according to the system developers at the same time. The theoretical outlines of the thesis that cover both the approaches mentioned including the portal solution of information systems, their architecture, the system integration, the recommendations for the user interface building and the methods used, are discussed in the first part of the thesis. The fundamental second part follows, where the methodology for building the new generation of web information systems is examined and designed. The parameters of the user-friendliness are defined. The personalization is emphasized as a way of personal adjustment of users’ needs and requirements. The methodology called the Component boxing model intended for the design of a component oriented information system is specified. On the basis of this methodology, the model of the user interface is created as a hierarchical component tree. For its composition the concepts representing the component types are defined – box, box content, box design, visual element; further the page components are found, and the obligatory, optional and latent elements, as well as the relationships among them are determined. For the page decomposition into components and the reverse composition of the output, the explicit rules are determined and described. The third part of the thesis deals with the use of the designed methodology in practice. The example of the variable designs in the University information system shows that the component approach can be used on the presentation layer level. Thus further possibilities of the use are opened – the generalization of the methodology on all the levels of the information system or in other types of systems. Another outcome of the implementation technique is that the component oriented information systems significantly support the personalization, flexibility, extensibility and integration – the characteristics required of the modern information systems, and they are the mark of their user-friendliness.
18 Patnáctero uživatelsky přívětivého IS 19 Závěr 19.1 Shrnutí dosažených výsledků práce . . . . . . . . . . . . . . . . . . 19.2 Přínosy práce pro teorii a praxi . . . . . . . . . . . . . . . . . . . . 19.3 Doporučení k dalšímu pokračování práce . . . . . . . . . . . . . . .
8 113 115 . 115 . 117 . 117
Literatura
119
Publikace autora vztahující se k tématu
122
Přílohy
124
A Seznam použitých zkratek
125
B Ukázky designů UIS
126
1
ÚVOD A CÍL PRÁCE
1 1.1
9
Úvod a cíl práce Úvod
V dnešní době dochází k rychlému rozvoji informačních technologií (IT) a ruku v ruce s tím i k nasazování informačních systémů v různých oblastech lidské činnosti. Bez kvalitního informačního systému se v současné době neobejdou ani nejmenší firmy, o velkých organizacích ani nemluvě. Do styku s počítačově orientovanými informačními systémy nyní přichází stále větší část populace. Velice důležitou vlastností informačního systému se stává jeho uživatelská přívětivost. Tuto vlastnost ocení nejen počítačoví odborníci, ale právě i široká veřejnost, která je dobou více či méně nucena s informačními systémy pracovat a využívat je. To platí i v oborech lidské činnosti, které jsou světu IT značně vzdáleny. Otázku uživatelské přívětivosti není jednoduché specifikovat. Odpověď je třeba hledat na straně uživatelů a samozřejmě i na straně vývojářů (autorů) informačních systémů. Základním požadavkem každého uživatele informačního systému je, „aby se mu se systémem dobře pracovaloÿ. Pro vývojáře to znamená, že musí navrhnout takové uživatelské rozhraní, jehož ovládání bude jednoduché, přehledné a intuitivní. Současně takový informační systém musí splňovat podmínky efektivnosti, bezpečnosti a dalších faktorů, které jsou běžným uživatelům skryty. Historické ohlédnutí V krátké historii informačních technologií změnilo pojetí uživatelské přívětivosti značně svůj význam (Sundgren, 2003). Na konci 60. let dvacátého století byly tehdejší výrazové prostředky (programovací jazyky ALGOL, COBOL, FORTRAN a další) považovány za vysoce uživatelsky přívětivé. Uživateli těchto prostředků však byli pouze aplikační programátoři. Na počátku 70. let se začali někteří uživatelé počítačů zapojovat do vývoje aplikací vlastními silami, používali softwarové balíky řízené neprocedurálními příkazovými jazyky. O něco později začaly být počítače přístupné přes obrazovkové terminály a příkazové jazyky byly nahrazeny systémem menu (nabídek). Ačkoliv tyto nabídkově orientované systémy byly vytvořeny více či méně „odolnéÿ vůči méně zkušeným uživatelům, stále se jevily přehnaně hierarchické a značně počítačově řízené. Terminálově orientované systémy projevovaly svoji uživatelskou přívětivost v tom smyslu, že prakticky kdokoliv se mohl naučit je bezpečně a efektivně ovládat. Současně však postrádaly důležitý prvek: flexibilitu. Zkušený uživatel chtěl být schopen používat v systému „zkratkyÿ a mnoho uživatelů si přálo zvolit si vlastní cestu při průchodu systémem, aniž by měli pocit, že jsou počítačem neustále řízeni. Představení databázové orientace na konci 70. let v jistém smyslu flexibilitu a uživatelskou přívětivost zvýšilo. Oddělení aplikačních programů od ukládání dat usnadnilo rozmach vývoje informačních systémů. Přidávání nových aplikací se stalo poměrně jednoduché a nedotýkalo se stávajících aplikací či společné databáze. Vývoj
1.1
Úvod
10
aplikací ad hoc byl usnadněn novými metodami jako modelování dat a také novými vývojovými prostředky jako generátory aplikací. Tyto metody a prostředky byly často spojovány do souvislostí s databázemi. Informační systémy však byly stále centrálně řízeny kvůli používané technologii založené na velkých sálových počítačích i kvůli přísně centralizovanému managementu informačních technologií ve společnostech. Až s rozmachem osobních počítačů na počátku 80. let mohl být management počítačových technologií, informačních systémů a IT–organizací „normalizovánÿ v tom smyslu, že se tyto disciplíny začaly považovat za stejně důležité, jako ostatní aspekty obchodu. Úroveň odpovědnosti a řízení IT–záležitostí byly postaveny na stejnou úroveň s odpovědností a řízením ostatních zdrojů a aktivit. Nové technologické přístupy umožnily dalekosáhlou decentralizaci rozhodování v této oblasti a vytvořily pro kreativní pracovníky v organizacích možnosti zkoušet a prosazovat nová řešení. Současně relativní otevřenost a standardizace, charakterizující tehdejší počítačový trh, umožnily vrcholovým řízením organizací, aby situaci zvládly. Bylo možné kombinovat rozmanitost s jednotností. Informační systémy v této době stále sdílejí centrální bázi dat a aplikační logiku, ale vzniká možnost vytvářet odlišná rozhraní pro jednotlivé uživatele. Objevuje se model třívrstvé architektury, kde jsou od sebe odděleny vrstvy datová, aplikační a prezentační. V tomto všeobecně rozšířeném modelu dochází ke striktnímu oddělení způsobu úschovy a přípravy dat od metod pro operace s těmito daty. Vrstva datová je předem definovaným rozhraním propojena na vrstvu aplikační, která zajišťuje veškerou aplikační logiku nad daty poskytovanými právě datovou vrstvou. Komunikace s uživatelem je výsadou vrstvy prezentační, jejímž úkolem je zajistit kompaktnost rozhraní, jeho uživatelskou přívětivost, a současně maximálně zpřehlednit a zpřístupnit všechny funkce aplikační logiky. Na druhou stranu komunikuje prezentační vrstva s aplikační vrstvou voláním jednotlivých funkcí (příp. metod objektů) aplikační logiky. V třívrstvé architektuře není striktně nutné, aby všechny vrstvy byly provozovány na jednom počítači. Právě prostředí počítačové sítě umožňuje zcela oddělit oblast datové vrstvy (specializovaný databázový server, storage area networks apod.) od aplikační vrstvy (superpočítače, masivní aplikační clustery, webové farmy) a od prezentační vrstvy (uživatelský webový prohlížeč, který umožňuje interpretaci popisu přenášených údajů nezávisle na aplikační vrstvě). V souvislosti s rozvojem výpočetní techniky bylo možné v 80. letech minulého století přejít od textového ke grafickému uživatelskému prostředí a od ovládání klávesnicí k ovládání pomocí pohyblivých ukazatelů (myš, joystick, světelné pero, dotyková obrazovka, tablet PC, graffiti na kapesních počítačích1 ). To umožnilo přiblížení rozhraní jednotlivých aplikací běžnému spotřebnímu uživateli. Pro ovládání aplikace na přehrávání hudby není nutné složitě vybírat z připravených nabídek ani 1
Graffiti jsou sady ovládacích znaků na displeji kapesního počítače. Představují zjednodušenou abecedu, pro zápis textu pomocí speciálního pera.
1.1
Úvod
11
užívat složitých klávesových kombinací. Je možné přehrávač na obrazovce zobrazit v podobě skutečné HiFi věže a dotykem na příslušné ovládací tlačítko (dotyková obrazovka či jiný ukazatel) přehrávat hudbu, vyhledávat skladby či vysunout CD. V průběhu 90. let vidíme, jak nová technologie umožňuje vyvíjet informační systémy, které kombinují standardizaci a přizpůsobivost a přinášejí nový druh uživatelské přívětivosti. Uživatelé chtějí mít svůj počítač pod kontrolou, nepřejí si být řízeni. Při ovládání informačních systémů se chtějí řídit vlastními pocity a využívat dostupné funkce a data v jiných informačních systémech, čímž zvýší funkčnost vlastního informačního systému. A to všechno chtějí provádět v prostředí, ve kterém se cítí jako doma. Navíc nestačí, když informační systém vyhovuje jednomu uživateli, naopak, všichni uživatelé by měli mít pocit, že je systém přizpůsoben právě jejich vlastním požadavkům. Jenže různí uživatelé mají velmi často velice odlišné požadavky a preference. Jednou z možností, jak dosáhnout takové přizpůsobivosti, je použití standardizovaných rozhraní uvnitř a mezi subsystémy informačního systému. Internet a některé operační systémy představují konkrétní příklady, jak lze s pomocí nové technologie uskutečnit to, co bylo před několika lety považováno za neuskutečnitelné. S nástupem masivního rozšíření světové počítačové sítě Internet v posledních letech minulého století se do popředí uživatelského zájmu dostává myšlenka distribuovaných aplikací (aplikací „na vyžádáníÿ), kdy uživatel předá příkaz ke spuštění aplikace světové síti (distribučnímu serveru) a je mu zobrazena základní aplikace s jednoduchými funkcemi. Pokud potřebuje užít pokročilou funkci, požádá uživatel prostřednictvím základní aplikace světovou síť (pravděpodobně distribuční server nebo server poskytovatele aplikace) o doručení pokročilé funkce a uživatel ji může využít. Má tedy k dispozici právě to množství funkcí, které využívá. Většina dokumentů i aplikací na Internetu využívá principu hypertextu, kdy pomocí odkazů v běžném multimediálním dokumentu (kombinace textu, obrázků a dalších multimediálních objektů) lze propojit několik různých dokumentů dohromady, odkazovat se na externí zdroje či zajistit „dynamičnostÿ příslušného dokumentu (provázání s výkonnými aplikacemi či jejich částmi). Současnost Na počátku 21. století nastupuje rychlý vývoj informačních systémů využívajících uvedených vlastností. Díky vrstvené architektuře a síťovému prostředí lze (za dodržení podmínek kompatibility) systémy vzájemně integrovat a uplatněním myšlenky portálových aplikací vytvářet jednotné a vysoce uživatelsky přívětivé rozhraní celých integrovaných systémů.
1.2
1.2
Cíl práce
12
Cíl práce
Ve své disertační práci se zabývám problematikou informačních systémů, a to hlediskem jejich uživatelské přívětivosti. Oba termíny, informační systém i uživatelská přívětivost je třeba blíže specifikovat, neboť jsou to pojmy velmi široké. Svoji pozornost budu dále soustředit na informační systémy provozované v prostředí Internetu, a to na webové informační systémy. V problematice uživatelské přívětivosti vycházím z obecných pojmů a dále se zaměřuji na oblast personalizace, tedy osobního přizpůsobení a nastavení systému uživatelem. Tato odjakživa intuitivní myšlenka (přizpůsobit si ať už pracovní nebo jiný nástroj tak, aby práce s ním byla co nejjednodušší a nejpříjemnější) v sobě nese řadu možností. Uživatelům informačního systému je třeba vytvořit odpovídající pracovní prostředí (informační systém je pro mnohé pracovním nástrojem), které pokryje požadavky široké škály uživatelů – od počítačových laiků až po zkušené odborníky. Je nutné jim poskytnout prostředek, který bude přinášet užitek a zvyšovat efektivnost jejich práce. Výchozím bodem je samozřejmě vhodný informační systém splňující požadovaná kritéria, nedílnou součástí takového systému je jeho uživatelské rozhraní. Celá práce je členěna do tří logických celků řešících následující úkoly: • V úvodní části práce je potřeba zanalyzovat současný stav řešené problematiky týkající se informačních systémů obecně, přičemž se zaměřit zejména na složku jejich uživatelského rozhraní. • Na základě podkladů z první části a vlastních poznatků formulovat metodiku formalizace komponent informačního systému, definovat a zpracovat metody komponentového přístupu k informačnímu systému a navrhnout uplatnění této metodiky v praxi. • Na praktické ukázce demonstrovat použití uvedené metodiky při generování uživatelského rozhraní webového informačního systému. • V závěru definovat na základě výzkumu a poznatků z této práce doporučení pro tvorbu uživatelsky přívětivých informačních systémů.
1.3
Struktura práce
Práce je rozdělena do následujících částí: Kapitola 1: Úvod a cíl práce Úvodní kapitola obsahuje uvedení do problematiky, pohled na vývoj informačních systémů zejména z pohledu interakce s uživatelem a jejich uživatelské přívětivosti. Součástí je rovněž specifikace cílů práce a její struktury.
1.3
Struktura práce
13
Kapitola 2: Základní pojmy Zde jsou shrnuty základní pojmy, které se prolínají celou prací, pro lepší porozumění dalšímu textu práce. Teoretická východiska práce Část Teoretická východiska práce zahrnuje šest následujících kapitol, kde jsou přiblíženy již známé skutečnosti, které částečně tvořily podklady pro zpracování zkoumané problematiky. Kapitola 3: Portálové řešení informačního systému Kapitola popisuje současný pohled na portálově řešené informační systémy, neboť portály představují moderní pojetí informačních systémů dnešní doby. Kapitola 4: Systémová integrace V dnešní době spěje vývoj k jednotnému a integrovanému řešení, proto se tato kapitola zabývá systémovou integrací, jejími složkami a úrovněmi. Kapitola 5: Architektura informačního systému Každý informační systém je vybudován na základě určité architektury. Typy architektur a zejména podrobná charakteristika třívrstvé architektury jsou předmětem této kapitoly. Kapitola 6: Metodika návrhu informačního systému Kapitola se věnuje základním pravidlům, která je třeba dodržovat při návrhu informačního systému obecně i při návrhu jeho uživatelského rozhraní. Kapitola 7: Uživatelské rozhraní Kapitola podrobně rozebírá uživatelské rozhraní informačního systému a charakterizuje jeho tři základní vlastnosti – čitelnost, snadnost prohlížení a snadnost vyhledávání v systému. Poslední část kapitoly se zabývá návrhem vrstvy uživatelského rozhraní. Kapitola 8: Architektura MVC Model-View-Controller paradigma bylo jednou z inspirací pro tvorbu nové metodiky návrhu komponentového informačního systému. Kapitola obsahuje shrnutí myšlenky MVC paradigmatu.
1.3
Struktura práce
14
Vlastní řešení Část Vlastní řešení zahrnuje pět kapitol, kde je na základě teoretických podkladů a vlastního výzkumu definována metodika nového přístupu k návrhu uživatelsky přívětivých informačních systémů. Kapitola 9: Uživatelská přívětivost informačních systémů V kapitole je popsán pohled na uživatelskou přívětivost informačních systémů pro stanovení dalšího směru výzkumu. Kapitola 10: Personalizace Vyšším stupněm uživatelské přívětivosti je personalizace, tedy nastavení systému a jeho přizpůsobení osobním požadavkům. I tu je třeba jistým způsobem vymezit, a tím se zabývá tato kapitola. Kapitola 11: Struktura webového informačního systému Jedna ze stěžejních kapitol práce. Ze známých principů jako je třívrstvá architektura a událostní cyklus, je odvozena nová metodika návrhu komponentově orientovaného webového informačního systému nazvaná Component boxing model. Kapitola 12: Rozbor komponent prezentační vrstvy Další ze stěžejních kapitol. Popisuje podrobný rozbor komponent prezentační vrstvy, rozklad uživatelského rozhraní do komponent a pravidla jejich skládání při sestavování výstupu pro uživatele. Kapitola 13: Uplatnění komponentového přístupu Kapitola se zabývá uplatněním komponentového přístupu při realizaci úloh prezentační vrstvy informačního systému. Praktické výsledky Část Praktické výsledky se skládá ze čtyř kapitol, kde je demonstrováno uplatnění navrhované metodiky v praxi. Kapitola 14: Vývoj uživatelského rozhraní IS MZLU v Brně Kapitola nastiňuje vývoj uživatelského rozhraní Fakultního a poté Univerzitního informačního systému PEF resp. MZLU v Brně.
1.3
Struktura práce
15
Kapitola 15: Novodobý design UIS Kapitola popisuje novodobý design Univerzitního informačního systému MZLU v Brně, možnosti nastavení uživatelského rozhraní a přípravu na generování designů. Kapitola 16: Generování uživatelského rozhraní Zde jsou popsány konkrétní postupy a aplikace umožňující zavedení variabilních designů v Univerzitním informačním systému. Kapitola 17: Obecné generování uživatelského rozhraní Problematika generování grafického designu je rozšířena na další složky uživatelského rozhraní informačního systému. Závěrečné shrnutí a přínosy práce Tato část obsahuje oddíly se závěrečným shrnutím, doporučeními a vlastní závěr. Kapitola 18: Patnáctero uživatelsky přívětivého IS Na základě problematiky zkoumané v práci je zde formulováno patnáctero uživatelsky přívětivého informačního systému složené z pohledu tvůrce i uživatele informačního systému. Závěr Závěr shrnuje dosažené výsledky práce, přínosy pro teorii a praxi a doporučení pro další pokračování práce. Přílohy První příloha obsahuje seznam zkratek použitých v této práci, v druhé příloze jsou představeny ukázky generovaných designů v rámci Univerzitního informačního systému.
2
2
ZÁKLADNÍ POJMY
16
Základní pojmy
Pro lepší pochopení následujícího výkladu jsou zde vysvětleny některé pojmy a spojitosti využívané dále v práci. Jednotlivé pojmy jsou podány podle všeobecné encyklopedie (Čermák a kol., 2001–2002) a doplněné podle jejich chápání osobou s informatickým vzděláním. Informační systém Informační systém (IS) je identifikovatelný funkční celek zabezpečující cílevědomé a systematické shromažďování, zpracovávání, uchovávání a zpřístupňování informací uložených na hmotném nosiči v údajových základnách a reprodukovatelných technickými prostředky. Informační systém zahrnuje informační základnu (data), technické a programové prostředky, technologie, finanční prostředky, procedury a pracovníky. Informační systém může a nemusí zahrnovat počítačový systém nebo subsystém. Informační systémy tvoříme na základě současné informační a komunikační technologie. Informační technologie Pojem informační technologie (IT) představuje soubor nástrojů, metod a znalostí sloužících k činnostem, k nimž je informační systém určen (sběr, zpracování, uchování, přenos a prezentace informací). Informační technologie rovněž zahrnují zákonitosti vývoje a výroby informačních produktů – tedy především informačních systémů. Často tento pojem také představuje základní směr myšlení jedné epochy nebo jedné kultury (informační generace, informační kultura, informační společnost). Technologie je správný název pro to, čemu dnes někdy nesprávně říkáme technika (technika jsou pouze hmotné prostředky sloužící určité technologii k dosažení cíle). Internet Internet představuje celosvětový systém propojených počítačových sítí (tzv. síť sítí), které jsou schopny si navzájem vyměňovat informace pomocí protokolu TCP/IP a přenášet tak data mezi prakticky libovolnými místy na Zemi. Umožňuje komunikaci mezi lidmi a přístup k širokému spektru služeb a informací. Jedná se o zcela převratný prostředek komunikace na celém světě. Sítě založené na stejném principu jako Internet nazýváme internety a dělíme na extranety (sítě mimo firmy) a intranety (sítě uvnitř firem). Nejvýznamnější službou internetových sítí je world wide web. World wide web World wide web (WWW, web) představuje nejrozšířenější službu na internetu. Jedná se o graficky orientované prostředí hypertextových dokumentů zvaných www
2
ZÁKLADNÍ POJMY
17
stránky, využívá moderní multimediální techniky (obrázky, zvuky, animace). Hypertextový dokument umožňuje pomocí odkazů propojit významově blízké dokumenty. Stránky mohou být statické (předem připravené) nebo dynamické (generované v okamžiku požadavku např. webovým informačním systémem). Pro zobrazení informací na webových stránkách se používá internetový prohlížeč. Webový informační systém Podle teorie webových informačních systémů (Šorm, 2003b) by se dalo zjednodušeně říci, že webový informační systém (WIS) je klasický informační systém provozovaný v podmínkách world wide webu. Ovšem tato jednoduchá definice by potom zahrnovala i jednoduché aplikace provozované právě v uvedeném prostředí. Tyto aplikace lze však vytvářet jednodušším způsobem, bez nutnosti nalézat složité postupy pro řešení celé řady aspektů vyplývajících z odlišnosti informačních systémů na webu a v prostředí klient/server. Proto definujeme webový informační systém jako parametrizovaný informační systém, který je provozován v nelineárním nestavovém síťovém prostředí (a nabízí tudíž svým uživatelům v maximální míře přizpůsobení jeho chování pomocí nastavení parametrů). Takový systém pak mj. řeší problematiku autentizace, auditování, modularizace, serializace, oprávnění, proměnlivého datového modelu, personalizace, hierarchického zařazení uživatelů a samodokumentace. Teorie webových informačních systémů poskytuje celou řadu modelů, pomocí kterých lze modelovat a realizovat uvedené požadavky. Tyto modely jsou nezávislé na zvolených softwarových a hardwarových prostředcích. Portál Informační portál je aplikací, jejíž rolí je poskytovat uživatelské rozhraní k informačnímu systému. Představuje vstupní bránu, jednotný a zároveň personalizovaný přístup k informačním službám a obsahu, které jsou zaměřené na všechny účastníky interakce se systémem – na zákazníky, zaměstnance, dodavatele nebo partnery – a to s ohledem na dostupné komunikační prostředky. Portál pomocí uživatelských profilů cíleně nabízí jednotlivým uživatelům informace a služby, které potřebují pro svou další činnost nebo k uspokojení svých individuálních informačních potřeb. Uživatelská přívětivost Pojem uživatelské přívětivosti je velmi široký a každý si pod ním může představit něco jiného. Slovník říká, že uživatelsky přívětivá je taková ergonomicky propracovaná aplikace, která na uživatele klade minimální nároky související se svojí obsluhou a nezpůsobuje jeho dezorientaci. Uživatelsky přívětivý informační systém je pak takový systém, který poskytuje svým uživatelům maximální komfort při jeho používání. Uživatelská přívětivost má dva základní aspekty. Prvním je pohled uživatelů, kteří vyžadují komfortní uživatelské rozhraní a mají určité požadavky a představy,
2
ZÁKLADNÍ POJMY
18
jak má toto rozhraní vypadat, jaké má mít funkce a chování. Druhým hlediskem je pak pohled vývojářů realizujících informační systém. Sem zahrnujeme rozsáhlou oblast metodiky tvorby aplikací týkajících se uživatelského rozhraní a jejich zakomponování do architektury celého systému. Personalizace Personalizace obecně znamená přizpůsobení určitého objektu osobním potřebám a zvyklostem. V oblasti informačních systémů představuje personalizace vyšší stupeň uživatelské přívětivosti, poskytující možnost individuálního přizpůsobení vzhledu a chování systému jednotlivým uživatelům.
3
PORTÁLOVÉ ŘEŠENÍ INFORMAČNÍHO SYSTÉMU
19
Teoretická východiska práce 3
Portálové řešení informačního systému
V současné době může být velmi často užívaný pojem portál v oblasti moderních informačních systémů a technologií pojat dvěma způsoby – ve smyslu internetového portálu nebo podnikového portálu (enterprise information portal). Přestože je dnes nutné tyto dva pojmy rozlišovat, je vhodné podotknout, že mezi oběma pojmy existuje určitá paralela, neboť internetový portál se stal předchůdcem portálu podnikového. Zpočátku představoval internetový portál jednoduchý přehled kategorizovaných informací s možností vyhledávání. Postupem času se v oblasti internetových portálů vytvořily dvě základní skupiny. První skupinu tvoří portály s vyhledávacím katalogem a snažící se o to, aby uživatel v co největší míře využíval informací, které portál zastřešuje. Zástupci této skupiny v současnosti jsou například Centrum, Seznam či zahraniční Yahoo. Do druhé skupiny spadají portály, které staví na vlastním obsahu, jenž je zpravidla o třídu bohatší než u předchozí skupiny, a snaží se uživatele dotlačit k tomu, aby v maximální míře používal pro zjištění informací tento obsah. Příkladem může být český zpravodajský server iDnes. Podrobněji se internetovými portály zabývá např. článek (Čírtek, 2002). Dále se zaměříme na portál podnikový.
3.1
Podnikový portál
Podnikové portály vznikly na základě integrace nejen podnikových informací, ale i integrace aplikací do jednoho celku. Podnikový portál pak můžeme podle (Manhartsberger, 2001) definovat jako víceúrovňový technologický systém, který integruje procesy, aplikace a data, a vytváří jedno celistvé prostředí, jež umožňuje společnostem poskytnout jednotný komunikační kanál všem, kdo se chtějí zúčastnit jejich aktivit. Podle této definice může podnikový portál používat každý, kdo má zájem zúčastnit se aktivit podniku (např. zákazníci, obchodní partneři nebo zaměstnanci) a prostřednictvím podnikového portálu si vyměňovat informace a provádět transakce s dalšími stranami. Může se zdát, že se jedná o ambiciózní koncepci, nicméně se řada společností již nastíněnému ideálu přibližuje2 . 2
Výzkum provedený ve Velké Británii počátkem roku 2002 ukázal, že podnikové portály se rychle dostávají na přední místa podnikových strategií a plánů. Ze zpracovaného přehledu 100 nejúspěšnějších společností ve Velké Británii provozovalo portál pouze 6 % telekomunikačních společností, ale 19 % jej zavádělo v podobě pilotního projektu, což je nejvíce ze všech zkoumaných oblastí. 32 % telekomunikačních společností plánovalo využívat portály v roce 2002.
3.2
Architektura podnikového portálu
3.2
20
Architektura podnikového portálu
Při vytváření portálu každá organizace usiluje o to, aby bylo podporováno co nejrozsáhlejší spektrum uživatelů a současně byla zpřístupněna co nejširší škála informací. Z hlediska těchto faktorů je důležité stanovit strategii budování portálu. Bez jasně definované strategie se může projekt rozmělnit do několika více nebo méně nezávislých systémů, čímž vyvstanou problémy s integrací informací a potlačí se klíčová vlastnost portálu – poskytnutí jednoho rozhraní pro přístup ke všem informacím a službám. Zabránit tomuto nebezpečí je možné pouze na základě volby architektury, jež pro skutečně integrované prostředí vytvoří potřebnou infrastrukturu. Architekturu podnikového portálu lze rozdělit do tří základních kategorií: integrace, služby a aplikace. Této problematice se podrobně věnuje (Schiller, 2000). Integrace Pro maximální využití potenciálu všech informací v organizaci a tím i investic je potřeba propojit izolované datové zdroje celého podniku. Podnikový portál je schopen efektivně integrovat data, aplikace a události, ať už se jedná o systémy klient/server, mainframe systémy, nestrukturovaný text, e-mailové systémy aj. Technologie podnikového portálu poskytuje: • jednotný integrovaný pohled na všechna data distribuovaná po celé organizaci, • jednotný integrovaný způsob řízení, správy a automatizace obchodních procesů uvnitř organizace, • jednotný integrovaný způsob využití externích služeb, • jednotný integrovaný způsob řízení a sledování událostí v celém systému. Služby Důležitou komponentou robustního portálového systému jsou služby. Hlavním úkolem služeb je integrace operativních systémů, nestrukturovaných dokumentů a procesních informací a poskytnutí integračních služeb prostřednictvím modifikovatelného aplikačního rozhraní. Jako příklad služeb je možno uvést zabezpečení, katalog metadat, indexování, autorizace atd. Tyto aplikace musí poskytnout infrastrukturu schopnou spolupracovat s velkými podnikovými systémy a splňující vysoké nároky na spolehlivost, dostupnost a škálovatelnost. Základem technologie pro zajištění služeb je: • robustní a škálovatelný aplikační server (schopnost škálovatelnosti s růstem uživatelů), • nepřetržitá dostupnost (výpadek systému může znamenat nejen ztrátu zákazníků, ale i poškození pověsti organizace), • flexibilita a otevřenost (možnost jednoduše provádět úpravy systému).
3.3
Horizontální a vertikální členění portálů
21
Aplikace Aplikační vrstva podnikového portálu představuje softwarové moduly, se kterými uživatel komunikuje, ve většině případů s použitím standardního webového prohlížeče. Aplikace portálu poskytují integrované uživatelské prostředí, optimalizované pro efektivní poskytování požadovaných informací. Aplikace musí splňovat několik základních kritérií: • snadné použití i pro příležitostného a nezkušeného uživatele, • snadná upravitelnost a možnost přizpůsobení konkrétnímu uživateli nebo kategorii uživatelů (personalizace), • jednoduchý způsob třídění, vyhledávání a filtrování informací, • přijatelná cena a podpora mobilních uživatelů.
3.3
Horizontální a vertikální členění portálů
Někdy se setkáváme s odlišným pojetím členění portálu – horizontálním a vertikálním dělením. Horizontální portály představují hlavní struktury, na kterých je portál vybudován. Vertikální portály jsou stavěny na horizontální vrstvě, reprezentují speciální instanci portálu, obyčejně definovanou předmětem či doménou (Hrnčárek, 2002). Horizontální infrastruktura se skládá z několika modulárních subsystémů: • Prezentační vrstva – WWW rozhraní uživatele spolu s podporou mobilních a přenosných zařízení. • Personalizace – schopnost dynamické odezvy uživateli, vycházející z jeho osobního profilu. • Spolupráce – sada nástrojů, umožňující výměnu e-mailů, skupinové debaty, sdílená místa. • Portlety – kostra pro jednoduché připojování softwarových modulů (portletů) a služeb. • Aplikace a workflow – integrace odvozených a nových aplikací. • Hledání a navigace – zavedení kategorií v repozitářích informací a vyhledávání odpovídajících informací. • Tvorba nových prvků – možnost vytvořit novou položku s novým obsahem a prezentovat ji nebo nabízet ostatním uživatelům. • Administrativa a bezpečnost – základní služby webového sídla, jako např. návrhy stránek, monitory výkonů, služby pro clustery a správa metadat. • Integrace – sdílení metadat, XML, standardy apod. Pod pojmem vertikální členění chápeme instance jednotlivých částí podnikového portálu, pokrývající specifickou doménu (propojení dat, aplikací a uživatelů v příslušné oblasti ať už pracovně či funkčně specifické). Obvykle bývá vertikální členění vytvořeno na vrcholu horizontální infrastruktury portálu.
3.4
Přínosy portálového řešení
22
Portlety Z hlediska uživatele jsou portály rozděleny na komponenty, ze kterých se skládá pracovní okno aplikace. Portlety představují samostatné funkční jednotky, které mohou po vytvoření pracovat na libovolné stránce portálu. Jsou to vícenásobně použitelné komponenty sloužící pro zobrazování obsahu. Jednou vytvořená komponenta tvoří celek, který smí být umístěn kdekoliv na stránce, jedná se o oblast reprezentující informační zdroj standardizovaným, konzistentním a bezpečným způsobem. O výhodách portletů ve spojení s databází Oracle9i se zmiňuje např. (Malina, 2002).
3.4
Přínosy portálového řešení
Přínos portálového řešení spočívá zejména v jednotném vzhledu a chování všech částí celku, čímž uživateli zjednodušuje práci s celým informačním systémem. Uživatelé nemusí podstupovat školení na jednotlivé části systému, je možné je obeznámit v jednom školení s principy uživatelského rozhraní a pak se soustředit pouze na výklad konkrétních obsahových a datových aplikací. V případě podnikových portálů uvádí (Manhartsberger, 2001) několik úrovní uplatnění a výhod portálu v organizaci. První úroveň tvoří komunikace uvnitř organizace. Využití technologie podnikového portálu může zlepšit schopnost vedení podniku komunikovat se svými zaměstnanci, jedná se tedy o vztah mezi firmou a zaměstnancem (business to employee, B2E). Množství dostupných informací v moderních podnicích exponenciálně stoupá. Pro zaměstnance je stále těžší vědět o všem, co se ve vlastní firmě děje. Klíčovým rysem podnikového portálu je schopnost personalizovat3 informace pro různé uživatele a doručit je přesně tam, kde jsou potřeba. Personalizace a doručení nejen že dramaticky zkracuje čas, který zaměstnanci stráví hledáním potřebných informací, ale také zvyšují produktivitu těchto zaměstnanců. Portál je schopen přinést zaměstnancům kvalitativně novou úroveň práce, neboť se mohou rozhodovat na základě informací, o kterých dříve nevěděli. Práce se tak stává zajímavější a přináší více uspokojení, což zvyšuje snahu zaměstnanců. B2E ale není jedinou úrovní, jež přinese z podnikového portálu rychlý užitek. Trendem poslední doby je vytváření aliancí a partnerství mezi podniky, a proto je další rovinou, na kterou má portálová aplikace dopad, oblast vztahů mezi firmou a jejími partnery (business to partner, B2P). Podnikový portál lze velmi efektivně využít jako filtr a distribuční mechanismus, který dodá partnerům s podobnými zájmy (např. dodavatelům, zákazníkům, spolupracovníkům) přesně ty informace, jež pro svou činnost potřebují. V souladu s touto koncepcí může podnik vytvořit a rozvíjet různá „zájmová společenstvíÿ, podle kterých bude moci své partnery členit. Je důležité si uvědomit, že kdokoli se začlení do některého ze zájmových společenství, definuje si vzápětí své vlastní zájmy a vytvoří si vlastní informační profil, který 3
Pojem personalizace bývá v literatuře chápán dvěma způsoby: jako přizpůsobení portálu rolím a právům uživatele, nebo jako přizpůsobení portálu osobním zvyklostem. Zatím zůstaňme u obecného pojmu, personalizaci se podrobně věnujeme v kapitole 10.
3.4
Přínosy portálového řešení
23
je pro něj jedinečný. Technickou pomůckou pro toto řešení je komponenta jménem „meta-repositoryÿ, což je vlastně informační základna, mapující podniková data k jednotlivcům, kteří o ně mají zájem. Příkladem komplexně zpracovaného řešení enterprise portálu je Oracle Portal společnosti Oracle (Greenwald a Milbery, 2001).
4
SYSTÉMOVÁ INTEGRACE
4
24
Systémová integrace
Cílem systémové integrace je vytvoření a permanentní údržba integrovaného informačního systému, který optimálně využívá potenciálu dostupných technologií k maximální podpoře podnikových cílů (Voříšek, 1997). Informační systém podniku je pak řešen a realizován jako komplexní integrovaný systém podporující všechny významné podnikové procesy a všechny potřebné lokality podniku. Je vyvíjen pomocí jednotné metodiky a má jednoduchou, řešitelům i uživatelům srozumitelnou architekturu.
4.1
Vývojová stadia a složky systémové integrace
Obsahová náplň a způsob realizace systémové integrace se v čase vyvíjely v závislosti na potřebách vznikajících zejména na základě rozvoje softwarových a technologických prostředků. Datová integrace Potřeba uplatnění datové integrace se projevila již na počátku 80. let, kdy bylo pro podniky typické centralizované zpracování dat. S rostoucím počtem oblastí, které informační systém pokrýval, začaly vznikat problémy s duplicitním uložením a zpracováním stejných dat. Reakcí na tento problém byla snaha o datovou integraci, tj. o propojení datových základen různých aplikací. Integrace aplikací Rozšiřující se podpora podnikových procesů přinesla další potřebu integrace – vzájemné propojování funkcí různých aplikací. Protože v té době docházelo k propojování aplikací základní (operativní) úrovně podnikového řízení, hovoříme o horizontální integraci aplikací. Integrace aplikací vyžaduje integraci: • funkcí IS v rámci podnikového procesu – musí být určeny funkce a pořadí, v jakém se mají v rámci procesu vykonat, a o jaké funkce z jakých aplikací (subsystémů) jde, • softwarovou – programy, realizující jednotlivé funkce IS musí být vzájemně volatelné, tj. program realizující jednu funkci musí být schopen vyvolat spuštění programu realizujícího funkci související či následnou, • datovou – aplikace musí sdílet společná data. Integrace podnikových procesů a funkcí IS Integrace aplikací postupně přecházela do dalšího typu integrace – integrace podnikových procesů a funkcí informačních systémů. Úroveň tohoto typu integrace vypovídá o míře podpory podnikových procesů informačními technologiemi.
4.1
Vývojová stadia a složky systémové integrace
25
Při zohlednění organizačního hlediska podniku rozlišujeme v integraci podnikových procesů tyto stupně: 1. jednotlivé procesy částečně podporované funkcemi informačních systémů, 2. podpora procesů v jednotlivých organizačních útvarech, 3. podpora procesů přecházejících hranice útvarů stejné úrovně řízení (horizontální integrace), 4. podpora procesů přecházejících hranice útvarů různé úrovně řízení (vertikální integrace), 5. komplexní podpora procesů v podniku, 6. podpora procesů probíhajících mezi podnikem a jeho externími partnery – dodavateli, odběrateli, bankami atd. (externí integrace). První stupeň této integrace byl v podnicích typický v 70. letech, druhý a třetí v průběhu 80. let a o čtvrtý až šestý stupeň podniky usilují v současné době. Integrace uživatelských rozhraní aplikací Význam tohoto typu integrace se zvyšoval s růstem počtu aplikací, s kterými uživatel komunikoval. V případě, že se forma komunikace s jednotlivými aplikacemi výrazně lišila, měli uživatelé značné problémy s ovládáním aplikací. Proto se objevila snaha tvůrců informačního systému o sjednocení principů komunikace pro všechny aplikace. Tato integrace zahrnuje zejména: • jednotný význam funkčních kláves, • jednotný tvar výběrových menu a nápověd, • jednotnou manipulaci s okny na obrazovce, • jednotné pojmenování stejných objektů zpracovávaných v různých aplikacích atd. Integrace metodická Metodická integrace představuje vytvoření a používání jednotné metodiky tvorby, dokumentace a rozvoje informačních systémů a znamená posun charakteru tvorby informačních systémů od práce „individuálníÿ k práci „týmovéÿ. Vrcholem v této oblasti je snaha o integraci různých metodik a s nimi souvisejících metod a nástrojů. Tím je umožněno efektivní provozování a řízení vývoje aplikací, jež byly vyvinuty různými metodikami, hovoříme pak o tzv. metasystémech. Integrace hardwarová a technologická Hardwarová integrace souvisí se vzájemným propojováním hardwarových komponent různých výrobců do jedné podnikové počítačové sítě a s případnými komplikacemi vyplývajícími z jejich nekompatibility. V současné době díky hlubší propracovanosti komunikačních standardů a zvýšení spolehlivosti jednotlivých komponent
4.2
Úrovně systémové integrace
26
již hardwarová integrace nepatří ke kritickým problémům při návrhu a zavádění podnikových informačních technologií. Technologická integrace řeší problémy vzniklé propojováním heterogenních hardwarových komponent v oblastech datových základen, základního a aplikačního softwarového vybavení i v oblasti uživatelského rozhraní. Významným rysem tohoto typu integrace je řešení distribuované datové základny (datová základna je rozdělena do několika počítačů vzájemně propojených v rámci lokální nebo rozlehlé počítačové sítě). Dalším typickým znakem technologické integrace je distribuované zpracování transakcí (jednotlivé kroky transakce mohou být zpracovány různými programy běžícími na různých počítačích sítě). Při distribuovaném zpracování transakcí se využívá architektura klient/server, prostřednictvím které zpracování dat v počítačových sítích překračuje hranice podniku a může se v rámci Internetu odehrávat na kterémkoliv počítači ve světě. S tím stoupá nutnost sjednocování uživatelského rozhraní, které pak musí být realizováno mezinárodními normami a standardy.
4.2
Úrovně systémové integrace
Pro dosažení co nejvyššího efektu systémové integrace je třeba jednotlivé složky vzájemně propojit do jednotné koncepce řešení informačních technologií v podniku. Touto jednotící myšlenkou jsou celopodnikové cíle, jež jsou základním kritériem efektivnosti každé činnosti podniku. Vlastní integrace se uskutečňuje na několika úrovních, které postupně zajišťují promítání podnikových cílů a priorit až do technologické úrovně. Jednotlivé složky jsou znázorněné na obrázku č. 1 a popsané v dalších odstavcích.
Obr. 1: Úrovně systémové integrace
4.2
Úrovně systémové integrace
27
Integrace vizí Integrace vizí je proces, v němž se spojují pohledy jednotlivých členů vrcholového vedení na význam a priority informačních systémů podniku. Primárním cílem je zajistit angažovanost vrcholového vedení a sjednotit názory vrcholových manažerů na klíčové otázky (např. na podporu konkurenceschopnosti podniku pomocí informačních technologií, výběr prioritně podporovaných procesů apod.). Integrace podniku s okolím Integrace podniku s okolím je druhým stupněm systémové integrace. Její cíle můžeme shrnout do následujících bodů: • optimálně přizpůsobit chování podniku měnícímu se hospodářskému prostředí, případně iniciovat v okolí takové změny, které jsou pro podnik výhodné, • navázat úzké informační vztahy s významnými externími partnery (zákazníci, dodavatelé, banky, poskytovatelé informačních služeb), • pomocí Internetu poskytovat okolí vhodné informace o podniku a z okolí získávat relevantní informace pro řízení podniku. Integrace podnikových procesů Integrace podnikových procesů zefektivňuje interní podnikové procesy a jejich vazby. Je zaměřena zejména na: • zkrácení doby jednotlivých procesů, aby se zajistila rychlejší reakce podniku na externí události (např. rychlejší vyřízení došlé objednávky), • zefektivnění jednotlivých procesů, aby vyžadovaly minimum podnikových zdrojů, zejména zdrojů deficitních, • optimalizaci procesů, aby se zajistila vysoká kvalita produktu nebo poskytované služby. Integrace technologická Poslední úrovní systémové integrace je složka technologická. Ta v sobě zahrnuje integraci: • datovou – vytvoření jednotné základny podniku, která je sdílena různými aplikacemi a všemi uživateli, • hardwarovou – sloučení jednotlivých hardwarových komponent do jednotné počítačové sítě podniku, • softwarovou – vzájemné propojení aplikací zajišťujících automatizaci různých podnikových aktivit, • uživatelského rozhraní – dosažení stavu, kdy principy ovládání různých aplikací jsou stejné.
4.3
Efekty a rizika systémové integrace
28
Metodická integrace Metodická integrace je zaměřena na propojení všech metod, technik a nástrojů, užívaných v ostatních úrovních systémové integrace tak, aby na sebe navazovaly a tvořily jednotnou metodiku vývoje informačních technologií podniku.
4.3
Efekty a rizika systémové integrace
Je třeba zdůraznit, že integrovaný informační systém není konečným cílem, ale pouze prostředkem k dosažení efektivního fungování podnikových procesů. Integrovaný informační systém může přispět k efektivnějšímu fungování podniku zejména v těchto oblastech: • zkrácení celkové doby reakce podniku na podněty z okolí, • využití progresivních metod řízení podnikových zdrojů a procesů na základě vyšší dostupnosti a komplexnosti informací ze všech oblastí činnosti podniku, • efektivní působení na trhu sledováním a vyhodnocováním tržní situace, propojením s hlavními zákazníky, dodavateli a finančními ústavy, • snížení chybovosti a nekonzistence informací minimalizací jejich duplicitního zpracování nebo uložení. Uvedené (a případně další) přínosy integrace IS/IT jsou pro její uplatnění rozhodující. Na druhou stranu je však třeba znát rizika, která jsou spojena s tvorbou a provozem komplexních integrovaných systémů: • vyšší závislost podniku na externích dodavatelích komponent a služeb, na kvalitě jejich práce, na jejich stabilitě a serióznosti, • vyšší složitost systémů a s tím související nároky na projekci a přípravu řešitelů, • stoupající nároky na uživatele, zejména pochopení všech relevantních vazeb, jejich významu a důsledků, • větší a rychlejší dopad případných havárií a výpadků systému, virového ohrožení a chyb lidského faktoru. Rizika neznamenají omezení integrace, ale především nové nároky na řízení informačních technologií v podniku. Systémová integrace není stav, ale neustále probíhající proces. Stejně jako se mění hospodářské prostředí a neustále se vyvíjejí informační technologie, musí totéž platit o informačním systému podniku a jeho integritě.
5
ARCHITEKTURA INFORMAČNÍHO SYSTÉMU
5
29
Architektura informačního systému
V oblasti informačních technologií představuje pojem architektura proces sestavování a specifikaci celkové struktury, logických komponent a logické vazby mezi všemi prvky informačního systému (Voříšek, 1997).
5.1
Podstata a účel architektur IS
Význam architektury informačních systémů a technologií úzce souvisí s integračními tendencemi při vývoji informačního systému, neboť s rostoucí komplexností systémů roste nutnost hledat jednoduchá schémata pro vyjádření složité reality. Architektura informačního systému by měla podporovat následující vlastnosti informačního systému podniku (Voříšek, 1997): • strategickou orientaci – informační systém musí být schopen podporovat dosažení strategických cílů podniku, • adekvátní funkční spektrum – systém musí pokrývat všechny uživatelské požadavky na funkce IS/IT, které jsou ve shodě se strategickými cíli podniku, • integrovanost – systém musí být integrován z hlediska funkčního, datového, softwarového, hardwarového i z hlediska uživatelského rozhraní, • otevřenost – systém musí být schopen postupně přijímat další nové technologické a softwarové komponenty, datové zdroje apod., aniž by se narušila jeho provozuschopnost, • jednoduchost – systém musí být relativně snadno pochopitelný a průhledný pro uživatelskou sféru, • flexibilitu – systém musí být parametrický tak, aby byl schopen v provozu pružně reagovat na nové požadavky uživatelů; flexibilita vzhledem k očekávaným změnám (např. změna organizační struktury, úprava vnitřních směrnic apod.) musí být realizovatelná bez zásahu do programového vybavení aplikace, • snadnou údržbu – systém musí být vytvořen pomocí mocného vývojového prostředí a musí být dobře zdokumentován, aby případné úpravy programů byly relativně snadné a přijatelně nákladné, • efektivní provozuschopnost – systém musí zajistit přijatelnou dobu odezvy funkcí, funkční spolehlivost, bezpečnost dat před výpadky systému a ochranu dat před neautorizovaným užitím. Při řešení integrovaných informačních systémů je architektura IS/IT významná z těchto hledisek: • Architektura vytváří relativně stabilní rámec řešení IS/IT, do něhož se v průběhu doby vývoje postupně začleňují jednotlivé aplikace a další komponenty. • Architektura je významným komunikačním prostředkem mezi vedením podniku, projektanty a návrháři při formulaci základních představ o IS/IT a o prioritách řešení. Zajišťuje vzájemné porozumění investorů, uživatelů a řešitelů ohledně toho, které aplikace, data a rozhraní budou v daném čase implementovány.
5.2
Vertikální a horizontální struktura IS
30
• Pokud je architektura navržena jako dostatečně otevřená a předvídající předpokládané změny, zajišťuje stabilitu vývoje IS/IT i při rychlém technologickém vývoji IT. Nevyhovující stavební bloky IS/IT musí být možné nahradit novými, aniž by došlo k zhroucení celé stavby IS/IT. • Z ekonomického pohledu architektura umožňuje minimalizovat náklady na chybně zadané projekty nebo dokonce náklady na rekonstrukci celého řešení v důsledku nemožnosti jeho další údržby. Architekturou informačního systému rozumíme jak pohled na vnitřní strukturu informačního systému (architektura vertikální, horizontální, příp. kombinace obou), tak i strukturu jednotlivých implementačních vrstev, které umožňují přenášet systém mezi různými prostředími. Toto pojetí se nazývá vrstvená architektura (Šorm, 2002).
5.2
Vertikální a horizontální struktura IS
Vertikální dimenze informačního systému představuje jeho hierarchickou strukturu z hlediska poskytovaných služeb různým úrovním managementu podniku, příp. běžným uživatelům. Základní členění představují tři klasické vrstvy členění podle rozdělení činnosti managementu na úroveň strategického plánování (vrcholové řízení), úroveň taktického řízení (střední úroveň řízení) a úroveň operativního řízení (řízení transakcí a technologických procesů). Druhým pohledem na strukturu informačního systému je pohled jednotlivých složek organizace, která tento systém využívá (obvykle jednotlivá oddělení a útvary podniku) – tomuto pohledu říkáme horizontální členění. Pokud je organizace členěna do čtyř základních útvarů (divizí), hovoříme o čtyřech základních subsystémech. Další vnitřní členění divizí vytváří další subsystémy jednotlivých subsystémů (a tvoří tak hierarchickou stromovou strukturu). Kombinací obou výše uvedených pohledů na strukturu informačního systému získáme komplexní pohled na modulární informační systém, jehož jednotlivé subsystémy jsou specifické jak z pohledu úrovně řízení, tak z pohledu organizační struktury. Dostaneme tak horizontálně–vertikální pohled na informační systém; takový systém lze pak jednoduše modulárně vyvíjet a integrovat do celopodnikových potřeb.
5.3
Třívrstvá architektura informačního systému
Nejstarší vrstvenou architekturou byla jednovrstvá architektura systému, kdy příslušný systém řešil všechny operace na úrovni jediného subsystému. Později (v 80. letech) vznikají první dvouvrstvé systémy klient/server, které odlišují databázové operace (databázová vrstva) na straně serveru a klientské aplikační a prezentační operace (na aplikační vrstvě). Tato architektura byla dána poměrně standardizovaným prostředím klientů (řádkové prostředí, jednoduchá grafická prostředí, standardizovaná grafická API4 ). 4
API je zkratka z anglického Application Program Interface, aplikační programové rozhraní.
5.3
Třívrstvá architektura informačního systému
31
S postupem času vznikala stále složitější grafická prostředí, vzrůstal počet operačních systémů, ze kterých bylo možné k informačnímu systému přistupovat, a řada informačních systémů začala zpřístupňovat svá data i prostřednictvím jiných zařízení, než jsou klasické síťové terminály (např. kiosky, mobilní telefony, kapesní počítače – palmy apod.). Tento posun si vyžádal vznik nového pojetí – třívrstvé architektury. Základní schéma třívrstvé architektury je znázorněno na obrázku č. 2.
Obr. 2: Třívrstvá architektura
Nejnižší, datová vrstva, zajišťuje napojení na systém řízení báze dat a základní datově-funkční operace realizující ukládání, výběry, agregace, předzpracování, integritu a audit dat. Tím je možné využívat společnou datovou vrstvu několika různými systémy v integrovaném informačním systému. Prostřední vrstva se označuje jako vrstva aplikační nebo funkční. Tvoří prostředníka mezi obecnou prezentační vrstvou (vstupy a výstupy uživatelů) a datovou vrstvou. Její hlavní úlohou je provádění transformace dat mezi vstupně-výstupními požadavky a bází dat. V komerční sféře jsou informační subsystémy této vrstvy označovány jako aplikační servery. Nejvyšší vrstvu představuje vrstva prezentační, která zajišťuje vstup požadavků uživatele a prezentaci výsledků (zobrazení, jednoduché datové transformace, filtry, výběry, třídění a agregace). Obvykle existuje několik prezentačních vrstev pro různé druhy zařízení, platformy a prostředí. U webových informačních systémů může tato vrstva degradovat na formátování výstupu (aplikace designu) a lehký klient (prohlížeč webových stránek). V rámci třívrstvé architektury dochází dále k podrobnému členění, které např. striktně odděluje základní datovou vrstvu od metadatové vrstvy (určené k předzpracování dat), nebo naopak vytváří dvě úrovně prezentační vrstvy – prezentační a zob-
5.3
Třívrstvá architektura informačního systému
32
razovací. Prezentací je myšlena příprava výsledných údajů a zobrazením vlastní tvar výstupu údajů. Základní smysl třívrstvé architektury však zůstává. Z uvedených specifik této architektury vyplývá, že je ideální pro tvorbu otevřených, distribuovaných a flexibilních informačních systémů, které lze pružně přizpůsobovat aktuálním požadavkům, ať už změnám na trhu s hardwarem i základním softwarem, nebo požadavkům uživatelů na funkce a uživatelské rozhraní aplikace. Třívrstvá architektura je typická pro celopodnikové rozlehlé aplikace dynamického charakteru.
6
METODIKA NÁVRHU INFORMAČNÍHO SYSTÉMU
6
33
Metodika návrhu informačního systému
Při návrhu informačního systému obecně i při návrhu uživatelského rozhraní tohoto systému je třeba vycházet z řady aspektů a dodržovat jisté zásady pro tvorbu informačních systémů. Tím zajistíme, že náš systém bude splňovat svůj účel a bude uživatelsky přívětivý. Tyto aspekty si nyní probereme podrobněji.
6.1
Pojetí informačního systému
Při návrhu, vývoji a implementaci informačního systému je nutné si nejprve ujasnit několik zásadních bodů, které mají pro životnost a úspěšnost informačního systému zásadní význam: • čemu bude informační systém sloužit – v jakém oboru lidské činnosti se bude používat, • komu bude informační systém sloužit – kdo a jací budou jeho uživatelé, • způsob realizace informačního systému – kde a jak bude systém provozován. Předmět zájmu informačního systému Výchozím bodem při návrhu každého informačního systému je vymezení oboru lidské činnosti, které se bude informační systém týkat (univerzitní IS, podnikový IS, IS v nemocnici, veřejný webový portál atd.). Tento krok představuje logický základ celého budovaného informačního systému a vycházejí z něj všechny ostatní výše uvedené aspekty. Uživatelé informačního systému Uživatelé informačního systému hrají jednu z nejdůležitějších rolí, neboť pro ně je systém tvořen. Právě uživatelé jsou totiž zpětnou vazbou a zejména oni určují úspěšnost používaného informačního systému. Skladba uživatelů informačního systému úzce souvisí s jeho předmětem. Musíme vědět, zda uživateli našeho informačního systému budou profesionálové z oblasti informačních technologií či naopak lidé, kterým je svět počítačů značně vzdálen. Skutečnost však není v naprosté většině případů takto černobílá. Informační systémy se zpravidla zaměřují na širší okruh uživatelů, mezi nimiž jsou zástupci jedné či druhé strany, ale jinak se zkušenosti a počítačové znalosti potenciálních uživatelů pohybují někde mezi těmito dvěma póly. Proto by měl být informační systém navržen tak, aby práci s ním zvládli víceméně intuitivně i nezkušení uživatelé, a naopak, aby odborníci nebyli zdržováni záležitostmi, které jim připadají samozřejmé a jasné (podrobná nápověda, systém navigací apod.). Proto je vhodné systém navrhovat parametricky a s možností nastavení chování systému uživatelem (viz kapitola 10).
6.1
Pojetí informačního systému
34
Způsob realizace Různých typů informačních systémů je celá řada, proto i rozhodnutí o způsobu realizace a použitých prostředcích patří mezi výchozí body návrhu systému. Podle zjednodušené definice můžeme říci, že informačním systémem je libovolná sada dat, nesoucích nějakou hodnotu (informaci). Informačním systémem je tedy například i kniha, knihovna, palubní deska automobilu či webový server. Dnes však obecně předpokládáme pod pojmem informační systém počítačově orientovaný systém. Ten může být provozován na lokálním počítači, v lokální síti, v síti Internet (veřejně či s určitými restrikcemi), případně formou kombinující předchozí způsoby. Použitá technologie Volba technologie úzce souvisí s předcházejícím bodem. V celém dalším textu již uvažujme informační systémy provozované v prostředí world wide webu. Počítačové sítě propojují počítače po celém světě a technicky umožňují komunikaci s libovolným vzdáleným strojem (Pazdziora, 2001b). Kromě technické infrastruktury, jako jsou kabely, routery atd., přispěly k dnešnímu rozmachu síťové komunikace zejména dva standardy W3 konsorcia – HyperText Transfer Protokol (HTTP) a HyperText Markup Language (HTML) (HTTP, 2005), (HTML, 2005). Webová technologie definuje protokoly a formáty, které jsou založeny na funkčním oddělení serveru a klienta. Na serverech jsou uložena data a probíhají procesy, klienti (webové prohlížeče) se používají pro zasílání požadavků, zpětnou komunikaci a zobrazování odpovědí serverů na zaslané dotazy. Protože je toto rozhraní standardizováno, mohou být servery budovány s předpokladem, že uživatelé již znají a disponují potřebným klientským softwarem nebo že jej mohou snadno a zdarma získat z dostupných zdrojů. Vyřizování požadavků klientů obstarávají CGI skripty, což jsou programy uložené na serveru (Sedláček, 1999). Využívají rozhraní CGI – Common Gateway Interface, které umožňuje do HTML stránek zapojit (volat) externí programy. CGI skripty potom poskytují uživateli dynamický výstup, tzn., že se zobrazí vždy současný stav jeho požadavku. Každý informační systém musí být postaven na datové bázi. Proto je jeho důležitou součástí výkonný databázový systém, kde jsou uložena všechna potřebná data. Bezpečnost IS Web a Internet jsou často považovány za nebezpečná média. Tyto obavy vznikají zejména kvůli široké škále a počtu uživatelů majících k informačnímu systému přístup z míst, o kterých organizace nemá přehled. Podstata problému a způsoby řešení jsou stejné, ať už provozujeme informační systém pro několik desítek uživatelů místní sítě nebo přístupný milionům uživatelů Internetu.
6.1
Pojetí informačního systému
35
Technické řešení problému bezpečnosti spočívá v důsledném použití kryptovaných kanálů pro přístup z webu (HTTPS – Secure HTTP) i pro přímý přístup managementu a vývojářů systému (ssh – Secure Shell). Jasně definovaná osobní odpovědnost jednotlivých uživatelů za data a operace a auditování všech prováděných operací jsou důležitou součástí bezpečnostní politiky v boji proti zneužití systému. Přístup do informačního systému Webové informační systémy mohou být ve své podstatě navrženy jako: • veřejné – umožňují přístup komukoliv (webové portály, e-shopy apod.), • uzavřené – umožňují přístup pouze určitému uzavřenému okruhu uživatelů (vnitropodnikové IS, nemocniční IS apod.), • kombinované – některé části informačního systému jsou dostupné veřejnosti, ale větší část systému je určena jen pro oprávněné uživatele. Příkladem může být informační systém univerzity – v podstatě slouží uživatelům spojeným s danou univerzitou (studentům, učitelům a ostatním zaměstnancům), kteří jej používají pro provádění vlastních operací, agend a aktivit, k nimž nemá přístup nikdo neoprávněný (přihlašování na zkoušky, vyplňování zkušebních zpráv, evidence studentů atd.). Na druhé straně poskytuje systém i veřejně přístupné informace pro ostatní uživatele (informace o studijních programech, katalog předmětů, možnost vyplnění elektronické přihlášky ke studiu apod.). Pro přístup k neveřejným informačním systémům nebo k neveřejným částem systémů se používají metody autentizace a autorizace – tedy zjištění a prokázání totožnosti. Uživatel se musí přihlásit svým uživatelským jménem a heslem. Komunikace s uživateli Při vývoji i provozu informačního systému je nutné neustále spolupracovat s uživateli (Bušek, 2001) a získávat od nich cenné informace, které pomohou při tvorbě a zdokonalování systému. Pro tuto zpětnou vazbu můžeme použít několik metod: • osobní setkání, • kontaktní e-mail, infolinka, linka podpory apod., • systémy na řešení správy požadavků, • dotazník, • logování uživatelských operací, • školení. K osobním setkáním zástupců uživatelů (nejčastěji odpovědného managementu) se zástupci vývoje systému dochází zejména v prvních fázích vývoje nového systému a v případech, kdy je potřeba projednat klíčová rozhodnutí dalšího postupu. Nejpřirozenější způsob komunikace mezi uživateli zavedeného informačního systému a jeho tvůrci, případně správci, je použití kontaktního e-mailu (případně telefonické infolinky či linky podpory). Tento komunikační kanál uživatelé používají zejména tehdy, když jim není něco jasné, neví si s něčím rady nebo něco nepracuje
6.1
Pojetí informačního systému
36
podle očekávání. Pro vývojáře je to první impuls, aby chyby opravili a aby se zamysleli nad vylepšením nejasných částí systému. Často totiž postup, který se zkušenému vývojáři může zdát naprosto logický, nezkušeného uživatele zaskočí. Uživatelé však kontaktní e-mail nepoužívají jen jako „linku pomociÿ, ale někteří zasílají i návrhy na vylepšení, zpříjemnění práce v systému apod. Tyto ohlasy jsou velmi důležité, neboť informační systém není jen prací vývojářů, ale měl by být výsledkem spolupráce jeho vývojářů a uživatelů (Brandejs, 2000). Pokročilejší způsob komunikace mezi uživateli a správci systému na bázi e-mailů nebo webového rozhraní představují systémy na řešení správy požadavků. Tyto systémy pomáhají řešit problémy, umožňují snadnou orientaci a zpětnou on-line kontrolu požadavků. Žádost zaslaná uživatelem je zpracována a oznámena množině správců. Současně je uživateli potvrzeno přijetí požadavku. Odpovědná osoba úkol převezme a vyřeší. Pak jej označí v systému jako vyřešený, čímž informuje ostatní správce, případně i uživatele. Odpadá zde problém, kdy správci nevědí, zda je požadavek v řešení, kým a jak postupuje jeho zpracování, v horším případě, kdy správci nejsou vůbec o požadavku informováni. Příklad takového systému popisuje (Urbanec a Okrouhlý, 2002). Tvůrci informačního systému však nemohou (nebo by alespoň neměli) spoléhat pouze na reakce uživatelů. Získat potřebné informace od uživatelů je možné například pomocí dotazníku. Dotazník v elektronické formě se umístí přímo na stránky informačního systému. Pokud to povaha systému umožňuje, je dobré uživatele nějakým způsobem motivovat k jeho vyplnění (nabídkou bonusu, výhodnějšího nákupu, losování apod.). U systémů orientujících se na určitý uzavřený okruh uživatelů (univerzitní, podnikový IS) lze uživatele požádat o vyplnění klasického tištěného dotazníku. Každý informační systém by měl provádět logování uživatelských operací. To umožňuje sledovat posloupnost práce jednotlivých uživatelů, jak z hlediska podpory uživatelů, tak i z hlediska bezpečnosti. Často opakované sekvence kroků pak lze nahradit zástupnou aplikací. U systémů s autentizovaným přístupem (kdy známe i totožnost uživatele) můžeme tápající uživatele nasměrovat, proškolit, případně jim nabídnout alternativní řešení problému. V případě specializovaných informačních systémů je vhodné čas od času pořádat školení uživatelů, na kterých se vysvětlují a předvádějí nové či složitější aplikace. Pokud je dostatečný zájem uživatelského publika, mohou se pořádat i školení, kde se probírá obecná problematika a formou diskuze se objasňují a řeší připomínky a nejasnosti.
7
UŽIVATELSKÉ ROZHRANÍ
7
37
Uživatelské rozhraní
Efektivita informačního systému se přímo vztahuje k jeho velikosti a ke schopnosti uspokojovat potřeby uživatelů. Tato efektivita je charakterizována mj. čitelností informačního systému, snadností prohlížení a snadností vyhledávání v systému – viz Readability, Browsability, Searchability v (Morgan, 2001). Tyto tři vlastnosti (čitelnost, prohlížení a vyhledávání) nemusí být zastoupeny ve všech systémech rovnocenně. S růstem množství informací v systému nabývají různé aspekty těchto vlastností na významu. Proto míra čitelnosti, způsobu prohlížení a vyhledávání v systému závisí na typu a kvalitě shromážděných dat, stejně tak jako na informačních potřebách uživatelské klientely. Převážná část této kapitoly je zpracována podle (Satrapa, 1997) a (Gray, 1999) s využitím materiálu (Lynch a Horton, 2001).
7.1
Čitelnost informačního systému
Čitelnost informačního systému představuje spojení přitažlivého grafického designu a správného rozvržení stránky. Všechny informační systémy bez ohledu na jejich velikost by měly dodržovat principy dobrého grafického designu. Velmi snadno lze odradit mnoho uživatelů, pokud nejsou data prezentována vizuálně přitažlivě a přehledně a logicky správně. Při návrhu systému je proto nutné dodržovat řadu zásad a pravidel pro tvorbu kvalitních webových stránek. Shodný vzhled stránek Používání konzistentního vzhledu stránek v informačním systému zjednoduší uživatelům orientaci. Užitečné je vytvoření souboru s šablonou, který obsahuje standardní záhlaví a zápatí, logo, nastavení poslední modifikace, případně podpis a ostatní používané stylistické prvky. Krátké stránky Ergonomické studie ukázaly, že čtení z obrazovky je přibližně o 25 % pomalejší než z papíru (Satrapa, 1997). Řada lidí pociťuje při čtení z obrazovky jisté nepohodlí a mnozí to dělají vysloveně neradi. Také posouvání obrazovky není vítané. Všechny uvedené důvody vedou ke společnému závěru: snaze o stručnost. Krátkými stránkami můžeme zvýšit či lépe udržet pozornost uživatelů. Praktická měřítka pro rozsah jsou zhruba následující: • Textová stránka by neměla překročit rozsah dvou až tří běžných obrazovek. • Jedná-li se o stránku navigační, obsahující sadu odkazů na jiné stránky, je vhodné ji udržet na jedné, nanejvýš dvou obrazovkách. Ideálem pro každou stránku je samozřejmě rozsah jedné obrazovky, pokud však v textu potřebujeme sdělit něco netriviálního, jedna obrazovka zpravidla nestačí.
7.1
Čitelnost informačního systému
38
Přehlednost a strukturovanost Dlouhé monotónní pasáže jsou pro čtenáře těžko srozumitelné. Webové prohlížeče zpravidla vytvářejí široké řádky, při jejichž čtení oči musí hledat začátek dalšího řádku při přechodu z řádku předcházejícího. Musíme proto stránky strukturovat a vyznačovat – poskytnout opěrné body a vodicí linie. Ideální délka odstavců je tři až pět řádků, horní limit pak zhruba deset. Při tvorbě stránky jde samozřejmě o hrubý odhad, neboť dopředu nevíme, jak který klient (v závislosti na jeho nastaveních a velikosti obrazovky) stránku zobrazí. Je vhodné stránku rozčlenit prostřednictvím dvou až tří úrovní nadpisů, které poskytují oku velmi výrazné orientační body. Jejich formulaci je dobré věnovat dostatečnou péči, z textu nadpisu by měl uživatel poznat, o čem daná část stránky pojednává. Ideální jsou krátké a výstižné texty. Cenné orientační body poskytnou také vyznačená slova či části textu, například tučným písmem, kurzívou či barvami. Vyznačování slouží ke zvýraznění důležitých pojmů, kterých by si měl uživatel snadno všimnout. Jeho hlavní kouzlo spočívá ve vzácnosti. Používá-li se vyznačovaní příliš často, stránka se naopak „rozbijeÿ a znepřehlední. Při více než jednom vyznačení v odstavci bychom se měli zamyslet, zda je to tak správné a chtěné. Dalšími prvky ke strukturování stránky jsou dále všechny značky pro vytváření seznamů, tabulek, případně vodorovných čar apod. Svoji důležitou roli v přehlednosti stránek hrají i tzv. bílá místa. Jimi jsou myšlena prázdná místa na stránce, která vytvářejí kontrast a prostor pro odpočinutí očí. V rozumné míře použitá bílá místa nejsou plýtváním, ale naopak. Ze stejného důvodu je dobré se vyvarovat textů složených z velkých písmen (verzálek). Tato písmena jsou obvykle stejně vysoká a široká a vytvářejí tak blokový efekt, který redukuje bílá (negativní) místa kolem písmen. Naproti tomu kombinace malých a velkých písmen tato bílá místa rozšiřuje. Posledním bodem, který stojí za zmínku v odstavci o přehlednosti stránek je jejich vizuální uspořádání. Související pojmy by měly vždy tvořit jednu skupinu. Jestliže stránka obsahuje více než jeden typ informací (skupin), je vhodné je od sebe oddělit za použití výše zmíněných stylistických prvků. Velmi často i zde platí zlaté pravidlo, že méně je někdy více. Univerzalita Stránky by měly být rozumně použitelné v libovolném klientovi (webovém prohlížeči). Prohlížeče se mírně liší svými vlastnostmi danými výrobci. Znatelných odlišností od „standardního chováníÿ může dosáhnout i sám uživatel místním nastavením prohlížeče (vlastní nastavení fontů písma, barev, Javy, JavaScriptu, akceptováním obrázků či cookies atd.). Zcela jistě celá naše uživatelská klientela nebude mít k dispozici nejnovější hardware a software, spíše naopak musíme počítat se starším vybavením. Navíc důvody, proč uživatel používá konkrétního klienta, mohou být velmi zásadní a v podstatě neovlivnitelné.
7.1
Čitelnost informačního systému
39
Proto je třeba koncipovat stránky tak, aby byly zobrazitelné a bez problémů použitelné na všech typech klientů. Nelze sice zajistit naprosto shodné zobrazení stránek v odlišných prohlížečích, ale můžeme dosáhnout maximální podobnosti používáním standardizovaných prvků pro zajištění výše uvedených vlastností, zejména přehlednosti. Rychlost Mezi rozhodující aspekty úspěchu webové prezentace patří i přiměřená odezva webu, tedy rychlost. Nejúčinnějším způsobem, jak zrychlit stránku je zmenšit její velikost. Čím pomalejší je načítání stránky, tím více uživatelů ztratí trpělivost. Nejčastější způsoby plýtvání (tedy zařazování nevhodných prvků) jsou například grafické oddělující čáry, příliš velké ikony, zbytečná grafická menu, neoptimalizovaná grafika nebo grafické nápisy. Vyčerpáme-li všechny dostupné prostředky na zrychlení stránek, můžeme ještě využít technik, jejichž účinky by se daly charakterizovat spíše jako „optickéÿ zrychlování. Stránka se stahuje ze serveru přibližně stejnou rychlostí, avšak uživatel z ní bude mít dříve užitek. Lze využít následující techniky: • optimalizace pozadí, • definice rozměrů vkládaných prvků (např. obrázků, apletů), • používání krátkých tabulek, • optické zrychlení serveru (rychlé úvodní stránky), • prezentace obsahu metodou „obrácené pyramidyÿ (viz dále), • předběžné načítání obrázků. Obrácená pyramida Prezentování obsahu metodou obrácené pyramidy znamená, že podstatu řekneme již na začátku. Dále v textu již dříve řečené rozebíráme do detailů a podepíráme argumenty. Je to způsob užívaný např. v novinách a dalších médiích, kde je nedostatek místa a je potřeba čtenáře rychle zaujmout. Obrácená pyramida je v protikladu k běžnému způsobu psaní, na který jsme zvyklí z odborných publikací. Tam se zpravidla nejprve nastíní problém, poté následuje diskuze možných způsobů řešení, popíše se autorův vlastní přístup a nakonec se dospěje k závěru. Naproti tomu obrácená pyramida začne závěrem, poté uvede nejzákladnější argumenty, které jej podporují a teprve v závěrečné části textu se věnuje podrobnějšímu popisu problému. Barvy Jednou z důležitých položek při návrhu stránek je zvolit vhodnou barevnost. Je faktem, že při naší orientaci v tomto světě hrají barvy významnou úlohu a nejinak je tomu i na webu. Problematikou barev v prostředí WWW se podrobně zabývá např. (Satrapa, 1997).
7.1
Čitelnost informačního systému
40
Značnou nepříjemností při práci s barvou na počítači jsou nejrůznější technická omezení. Při použití pestrých barevných odstínů se může stát, že se zobrazí různě na různých zařízeních a někdy se značně liší od původně zamýšleného odstínu. Systémové řešení spočívá v používání tzv. bezpečných barev, tj. barev, které mají k dispozici všichni nejdůležitější klienti ve všech operačních systémech. Tím je zajištěno, že nedojde k jejich ditherování5 či nahrazení nejbližší dostupnou barvou, a tudíž k degradaci. Bezpečné barvy jsou rozloženy po celé barevné škále. Vnímání barev Lidé přisuzují barvám určité významy a nechávají je na sebe působit. Avšak významy barev závisí na celé řadě faktorů – na uživateli, situaci, ve které se momentálně nachází, jeho sociálním prostředí apod. Jednou z mála věcí, na které se v oblasti vnímání barev téměř všichni shodnou, je jejich rozdělení na teplé a studené. Teplé barvy se nacházejí v okolí červené – červená, oranžová, hnědá, okr. Naopak tóny, v nichž převládají zelené a modré složky, jsou považovány za studené. Další shoda panuje v tom, že studené barvy uklidňují a působí dojmem vzdálenosti. Teplé barvy jsou dynamické, a mají tendenci vystupovat do popředí. Proto se doporučuje používat pro pozadí stránek studené barvy a pro popředí teplé, využije se tak a zvýrazní jejich vlastní působení. Konkrétní význam, který lidé přisuzují jednotlivým barvám, je věcí zcela individuální. Touto problematikou se zabývá vědní disciplína zvaná psychologie barev. Zůstaňme však u základního návrhu stránky, kde musíme respektovat charakter jednotlivých barev a vhodnost pro zpracovávanou tematickou oblast. Harmonie a kontrast Hlavní důraz při práci s barvou spočívá na vytvoření vhodných barevných kombinací. Je třeba vybírat barvy harmonické, tedy takové, které spolu ladí a vytvářejí příznivý dojem. Na druhé straně je vhodné využívat i barevný kontrast, který umožní zvýraznit určité prvky a vyzdvihnout je tak z jejich okolí. Harmonie barev se vyhýbá jakékoliv definici, je potřeba se řídit hlavně vlastním citem. Obecně platí, že podobnější barvy se snášejí lépe (např. kombinace pastelových barev bude z hlediska barevného příjemná). Obdobně lidé zpravidla mají rádi kombinace, které znají ze svého okolí (směs přírodních barev, složená především ze zelených, modrých a hnědých). Ve vyvážené barevné kompozici má své nedílné místo kontrast. Příbuzné, podobné a umírněné barvy totiž poměrně rychle začínají nudit. Využitím kontrastu se oživí celkové působení, výsledek je zajímavější a přirozenější. Na rozdíl od harmonie jsou barevné kontrasty dobře zmapovány a popsány. Výtvarníci rozlišují celkem sedm druhů kontrastů: 5
Dithering je metoda nahrazení nedostupného barevného odstínu. Souvislá plocha dané barvy je nahrazena pestrobarevnou směsí bodů barev příbuzných. Jsou voleny tak, aby při pozorování z větší vzdálenosti splynuly a vytvořily tak původní barvu.
7.1
Čitelnost informačního systému
41
• Světlostní kontrast – lidské oko jej rozpoznává nejsnadněji, protože na změny světlosti je citlivější, než na změny barvy. Vzniká mezi světlou a tmavou barvou. Nejmarkantnější je mezi šedými odstíny (extrémním příkladem jsou bílá a černá). Takové barvy se vzájemně zdůrazňují. Světlostní kontrast je velmi důležitý, neboť nezanedbatelné procento lidí trpí poruchou barvocitu. Proto by mezi textem stránky a jejím pozadím měl být vždy výrazný světlostní kontrast. Díky němu je text srozumitelný i pro čtenáře s horším vnímáním barev. • Tónový kontrast – vzniká mezi barvami, které jsou od sebe na barevném kruhu vzdáleny. Nejvýraznější a nejznámější je speciální případ tohoto kontrastu, pojmenovaný komplementární. Ten nastává mezi barvami ležícími v barevném kruhu přesně proti sobě. Jelikož každá z nich má tendenci indukovat v protější barvě svou doplňkovou barvu – tedy právě tu, která tam již je – barvy se vzájemně posilují a zvýrazňují. Jak taková kombinace dopadne, záleží na konkrétní dvojici barev. • Simultánní kontrast – podobný kontrastu tónovému, ale s odlišným účinkem. Vzniká mezi dvěma nepřesně doplňkovými barvami, tedy takovými, které leží na barevném kruhu téměř proti sobě. Simultánní kontrast zpravidla vyvolává dojem pohybu a neklidu na hranici barev, což působí unavujícím a zneklidňujícím dojmem. Rozhodně není vhodné, aby vznikal mezi písmem a jeho podkladem, jinak je text obtížně čitelný. Nežádoucí efekt simultánního kontrastu obvykle zmizí, přidá-li se k němu některý z dalších kontrastů (např. světlostní či sytostní). • Teplotní kontrast – vzniká, hraničí-li teplá barva se studenou. Barvy opět mají tendenci vzájemně posilovat svůj účinek – studená barva zatepluje teplou a naopak. Teplá barva má navíc tendenci vystupovat do popředí. • Sytostní kontrast – lze jej najít mezi dvěma barvami, které se výrazněji liší ve své sytosti. Dává vyniknout barvě syté, kontrast s barvou málo nasycenou ji zvýrazní. • Proporční kontrast – velikostní kontrast je málo známý a v praxi obtížně uplatnitelný. Na druhé straně je však jediný, který lze vyjádřit vzorcem. Podle něj vznikne barevně vyvážená kompozice, pokud jsou jednotlivé barvy zastoupeny v poměru: žlutá : oranžová : červená : zelená : modrá : fialová 3 : 4 : 6 : 6 : 8 : 9 Teplé barvy mají větší tendenci ovládnout pole, a proto by měly zabírat menší prostor. • Elementární kontrast – vzniká, když jsou v barevné kompozici použity pouze syté elementární barvy (jako typický příklad bývá uváděna žlutá, červená, zelená a modrá), případně doplněné černou. Barvy jsou natolik rozdílné, že se navzájem neovlivňují a nedochází k neklidu, známému ze simultánního kontrastu. Na druhé straně se však vzájemně neposilují. Výsledkem bývá živá a jasná barevná kompozice.
7.2
Snadnost prohlížení informačního systému
42
Ve většině případů se uplatňuje několik kontrastů současně. Např. mezi žlutou a modrou barvou najdeme kontrast světlostní, komplementární a teplotní. Důležitou roli ve většině kontrastů hraje skutečnost, že na rozhraní dvou barev má každá z nich tendenci indukovat ve své sousedce svou barvu komplementární. Například na hranici šedé a purpurové naše oko vytváří dojem, jako by šedá měla nazelenalý nádech. Závěrečné doporučení by se dalo formulovat následovně: v oblasti barev zůstat umírnění. Agresivní, nápadné, syté, teplé a světlé barvy přitahují pozornost více, a proto by jim měl být věnován menší prostor. Použití barev na stránkách Chceme-li použít na stránkách vlastní barvy, je třeba postupovat důsledně a předepsat kompletní barevné nastavení. To je tvořeno pěti atributy: • pozadí, • text, • nenavštívené odkazy, • navštívené odkazy, • aktivní odkazy. Navrhnout barevnou kombinaci pro stránku je poměrně obtížné. Je třeba nalézt barvy navzájem dostatečně odlišné, avšak dohromady dobře vypadající. Základ stránky (pozadí a prostý text) by neměl být příliš barevný. Mezi pozadím a textem by měl být silný světlostní kontrast. Barva pro nenavštívené odkazy by měla být výrazná, naopak barva pro odkazy, které uživatel už navštívil, by se měla pohybovat mezi barvou textu a nenavštívených odkazů, nemusí být nápadná. Barva aktivních odkazů je méně podstatná, neboť ji uživatel vidí jen zlomek vteřiny, v okamžiku klepnutí myši. Lidé mají přirozenou tendenci považovat stejnobarevné věci za spřízněné či související. Díky tomu lze použít na stránkách barevnou strukturu, která uživateli usnadní orientaci. Tuto myšlenku rozvíjí koncepce portálů (více v kapitole 3). Jako všude jinde, i v případě barev je na místě umírněnost. Barevné ladění by mělo vycházet z povahy a účelu stránek a jejich uživatelské klientely. Je třeba vytvářet „univerzálníÿ stránky, aby přitáhly co nejvíce uživatelů a vyhovovaly většině z nich. Pokud ale půjdeme dále, popsaná problematika barev může sloužit jako výchozí bod, přesuneme-li volbu barevného prostředí z autora stránek na uživatele. Tím se otvírají další možnosti využití a zpříjemnění informačních systémů. Této problematice se podrobně věnujeme v kapitole 10 o personalizaci.
7.2
Snadnost prohlížení informačního systému
Snadnost prohlížení informačního systému je dána logickým tříděním dat a informací. S růstem velikosti systému roste i potřeba logického uspořádání dat v systému
7.2
Snadnost prohlížení informačního systému
43
obsažených. To zahrnuje seskupování podobných pojmových skupin. Důležitou roli hrají i vhodně zvolené navigační prvky v systému. Snadno prohlížitelný informační systém má řadu výhod: • uživatelé vidí zběžně celý systém už „na první pohledÿ, • není nutná znalost speciální slovní zásoby, • podobné položky tvoří jednu skupinu, • jednoduchá navigace v systému, • systém podporuje myšlení uživatelů. Na druhou stranu se však výhradně „prohlížitelnýÿ systém neobjede bez určitých nevýhod: • uživatel se může lehce „ztratitÿ, • klasifikace systému může být uživateli cizí, • klasifikace se narušuje s růstem kvality informací, • klasifikace se může časem měnit. Obecně vzato je každý snadno prohlížitelný systém logicky roztříděn podle obsažených témat. Důležité pravidlo pro tvůrce každého informačního serveru (a přenositelné na tvůrce každého informačního systému) zní: Efektivní organizace informací je pro úspěch serveru rozhodující. Má-li se náš server stát účinným informačním prostředkem a mají-li jej uživatelé často používat, musí být vhodně organizován. Filozofie třídění informací vychází z nutnosti organizování informací, jako součásti lidského bytí. Je vhodné se řídit zásadami, které si probereme v dalším textu. Znalost uživatelského publika Základním předpokladem pro úspěšný informační systém je jasné stanovení uživatelské skupiny, pro kterou je systém určen. Organizační struktura systému musí být uživatelům srozumitelná. Je třeba zamyslet se nad lidmi, kteří budou náš informační systém používat. Budeme-li vědět, pro jaké uživatele systém navrhujeme, jaké je jejich zázemí, co od systému požadují či jakou terminologii užívají, můžeme lépe odhadnout způsob jejich myšlení, a ten zakomponujeme do struktury informačního systému. Většině uživatelů pak bude organizační schéma našeho systému pochopitelné. Po zjištění, kdo a jací budou naši uživatelé, je vhodné používat jejich terminologii. Tak se uživatelé lépe ztotožní s informačním systémem a budou jej raději a častěji využívat. Vysvětlující texty Systém by měl obsahovat co nejvíce vysvětlujících (nápovědných) textů. Těmito texty nejsou myšleny soubory s nápovědou, ale vysvětlivky přímo umístěné na stránkách popisující organizaci systému, způsoby použití, nápovědu k prováděným operacím atd. Přesto je nutné zařazovat vysvětlující texty s určitou mírou, aby nebyla narušena dobrá čitelnost systému.
7.3
Snadnost vyhledávání v informačním systému
44
Navigační prvky Aby se uživatel v systému neztratil, je nutné stránky vybavit navigačními prvky. Na každé stránce by měl uživatel dostat k dispozici základní sadu odkazů, jež mu umožní rychlý a efektivní pohyb v systému a využívání nástrojů, které se nabízejí. Navigační struktura by měla být snadno pochopitelná. Uživatel by si měl být schopen rychle vytvořit představu o tom, kam jej zavedou jednotlivé odkazy, a kudy bude možné pokračovat dále. Při sestavování navigací není potřeba hledat jedinečnost, naopak, uživatelé ocení prostý a známý či snadno pochopitelný mechanismus. Důležitá je konzistence jednotlivých stránek a shodné uspořádání jejich základní části, pak se uživatelé po seznámení s několika prvními stránkami dokáží orientovat i na stránkách ostatních. Hierarchický systém pojmů Základem hierarchického systému myšlenek (pojmů) jsou široké termíny, které se pak dělí do užších pojmových skupin. Nelze definovat dokonalou hierarchii pojmů, je však možné se co nejvíce přiblížit myšlení uživatelské klientely.
7.3
Snadnost vyhledávání v informačním systému
Možnost snadného vyhledávání v systému znamená pro uživatele možnost přímého přístupu k informacím. Rozsáhlejší informační systémy musí obsahovat vyhledávací služby. Tyto služby pomáhají překlenout nedostatky špatně prohlížitelného systému. Mají několik jasných výhod: • vytvářejí alternativní logické třídění informací, • zjednodušují vyhledávání známých položek, • pracují nezávisle na velikosti systému. Pojetí tvůrců informačního systému nemusí být nutně shodné s chápáním uživatelů. Při seskupování logicky souvisejících pojmů se může uvažování uživatelů lišit. Systém podporující vyhledávání však pomáhá tyto rozdíly překonat. Možnost snadného vyhledávání vybízí k přímému vyhledání známých položek a je v takových případech vhodnější než dlouhý seznam nabídek v prohlížeči, mezi nimiž uživatel hledá požadovanou informaci. Stejně tak v případech, kdy uživatel jednou použije určitou položku, ale nezapamatuje si její umístění. Pokud je však k dispozici vyhledávací mechanismus, snáze se k dané položce dostane. Vyhledávání informací pracuje nezávisle na velikosti systému. Kvalita snadno prohlížitelných systémů se snižuje s rostoucí velikostí systému, ale efektivita vyhledávání není velikostí systému přímo narušena. Je však nutné připustit, že vyhledávání může mít pro uživatele, zejména ty méně zkušené, i své nevýhody. Uživatelé musí • znát syntaxi vyhledávání, • vědět, co hledají – frázi, pojem atd.,
7.4
Návrh vrstvy uživatelského rozhraní
45
• znát strukturu dat. Aby mohli uživatelé účelně prohledávat informační systém, je nutné znát dotazovací jazyk vyhledávacího prostředku. Ten může zahrnovat například booleovské či unixové regulární výrazy. Pro běžné uživatele je tento způsob použití systému, jenž vyžaduje „nadstandardníÿ znalosti, překážkou. Možnost prohledávat informační systém předpokládá, že uživatel ví, co chce nalézt. To může často představovat problém. Uživatel musí vyhledávat podle konkrétních výrazů nebo pojmů, které popisují žádaná data. Může se však stát, že se místo zadaných pojmů naleznou pouze jejich synonyma, z kterých je někdy obtížné vybrat ta pravá. Systémy zaměřené pouze na vyhledávání často požadují po svých uživatelích také znalost datové struktury, například zda jsou data rozdělena do skupin, případně jakých, aby bylo možné správně formulovat dotaz k získání žádaných dat. Stejně jako v případě předcházejících vlastností uživatelského rozhraní informačního systému i v případě vytváření snadno prohledávatelného systému je vhodné dodržovat některé principy. Nápovědné texty Nápovědné texty jsou pro snadno prohledávatelný systém nezbytné. Popisují charakteristické znaky a omezení systému, strukturu dat v systému včetně oblastí pro vyhledávání a obsah těchto oblastí. Nápovědné texty také uvádějí příklady pro vyhledávání a vysvětlují, jak má uživatel pokračovat, je-li na jeho dotaz nalezeno příliš mnoho či příliš málo položek. Vzájemné propojení položek Poté, co vyhledávací mechanismus systému nalezne příslušné položky, uživatelé často vyžadují vyhledání dalších podobných položek. Proto je vhodné ke každé nalezené položce připojit odkaz (odkazy) na položky podobné. Jednoduché i mocné vyhledávací mechanismy Jednoduchý vyhledávací mechanismus je nejužitečnější pro začátečníky a příležitostné uživatele. Bohužel právě tento způsob vrací často příliš mnoho či příliš málo výsledků. Tuto nevýhodu lze vyvážit poskytnutím mocného vyhledávacího mechanismu (prohledávání oblastí, booleovské výrazy, omezení počtu položek atd.).
7.4
Návrh vrstvy uživatelského rozhraní
Během vývoje aplikací výpočetní techniky se vyčlenily základní skupiny tvůrců a uživatelů informačního systému (Voříšek, 1996). Základní vrstvy tvůrců a uživatelů jsou zachyceny na obrázku č. 3.
7.4
Návrh vrstvy uživatelského rozhraní
46
Obr. 3: Základní vrstvy tvůrců a uživatelů
Obrázek je z důvodu přehlednosti zjednodušen. Každá ze základních vrstev obrázku je ve skutečnosti dílem týmů sestavených z různých profesí. Např. aplikační programátory dnes dělíme na databázové programátory (provádějí analýzu a implementaci datového schématu), aplikační programátory (analýza, návrh a implementace aplikací), designéry (analýza, kreslení a implementace uživatelského rozhraní), dokumentátory a další. Z obrázku vyplývá, že každá skupina je uživatelem práce vrstvy předcházející a současně tvůrcem pracovních nástrojů pro vrstvu následující (např. aplikační programátor využívá práci systémového programátora a je tvůrcem nástrojů pro konečného uživatele). Jednotlivé skupiny se od sebe navzájem liší cíli své práce, typem problému, který řeší, používanými metodami a typem pohledu na IT. Cílem práce technika je vytvořit spolehlivý a výkonný hardware. Mikroprogramátor tvoří nad technickým vybavením nejvhodnější strojový jazyk, optimalizací mikroprogramů se snaží nejlépe využít funkčních možností technického vybavení. Systémový programátor programuje základní software, který optimálně využívá zdroje počítače a současně je vhodným nástrojem pro tvorbu aplikačních programů. Za návrh uživatelské vrstvy je přímo zodpovědný aplikační programátor. Primárním cílem aplikačního programátora je návrh a implementace příslušné aplikace tak, aby byla co nejvíce platná koncovému uživateli. Řeší např. to, jak nejlépe integrovat informační systém podniku se systémem řízení podniku, jak zajistit aktuálnost dat v datové základně, jak nejlépe v rámci aplikace komunikovat s uživatelem apod. Cílem koncového uživatele není počítač či jeho software, ale vhodné použití počítače pro řešení problému reálného světa. Musí se starat o to, jak správně interpretovat data poskytovaná počítačem, jak tato data využít jako podkladu pro svá rozhodování apod. Hlavním cílem a současně kritériem hodnocení každého tvůrce je tedy vytvoření podmínek pro efektivní práci navazujícího uživatele. To ve svých důsledcích
7.4
Návrh vrstvy uživatelského rozhraní
47
znamená, že pro celou hierarchii tvůrců je hlavním kritériem práce splnění požadavků sféry koncových uživatelů. Dosavadní úvahy můžeme shrnout do následujících bodů: • při návrhu uživatelské vrstvy vycházet z důkladné analýzy potřeb uživatelů a respektovat, co je základním kritériem práce uživatele příslušné vrstvy, • věnovat vysokou pozornost návrhu vrstvy uživatelského rozhraní, neboť špatně navržené uživatelské rozhraní může znehodnotit celou práci, • umožnit uživatelům řešení jednoduchých problémů jednoduchými prostředky. Pokud je nutné vzhledem k požadavkům uživatelské sféry navrhnout rozsáhlé uživatelské rozhraní, tj. rozhraní s velkým počtem funkcí, je vhodné uspořádat funkce rozhraní hierarchicky, neboť uživatel většinou potřebuje pouze určitou podmnožinu funkcí; ta se mu pak bude jevit jako jeden celek. Navrhovatel vrstvy Návrh uživatelské vrstvy je nutné rozdělit do dvou základních etap na návrh uživatelského rozhraní a návrh architektury uživatelské vrstvy. Za návrh architektury uživatelské vrstvy je zodpovědný výhradně tvůrce vrstvy. Současně zodpovídá za to, aby architektura vrstvy byla navržena flexibilně a uživatel při využívání funkcí vrstvy nemusel o její architektuře nic vědět. Při návrhu uživatelského rozhraní jsou východiskem návrhu požadavky uživatele na funkci vrstvy. Občas se vyskytují situace, kdy koncový uživatel není schopen formulovat reálné požadavky a limity. V tomto okamžiku je na tvůrci vrstvy, aby informoval uživatele o přínosech, které mu vybudování vrstvy přinese, aby v uživateli inicioval reálné požadavky a aby ve spolupráci s uživatelem nebo i sám navrhl uživatelské rozhraní. Naopak příliš velká aktivita uživatelů v této oblasti může mít za následek vytvoření příliš komplikovaného a nekonzistentního rozhraní. To se stává v situaci, kdy tvůrce bez hlubší analýzy přijímá všechny návrhy uživatelů a snaží se je do rozhraní zabudovat. Tvůrce musí provést důkladnou analýzu uživatelských požadavků a pak vytvořit a trvale udržovat jasnou a jednoduchou koncepci uživatelského rozhraní. Další požadavky uživatelů na úpravu rozhraní by pak měl přijímat pouze tehdy, jsou-li reálné a v souladu s koncepcí. Přijímání jiných požadavků má za následek narušení koncepce, a tím i devalvaci celého řešení. Teprve po nashromáždění většího počtu požadavků, které jsou v rozporu s koncepcí rozhraní, má smysl přejít k přehodnocení návrhu a k vytvoření nové koncepce. Uvedené doporučení lze snadněji respektovat při tvorbě základního softwaru než při tvorbě aplikačního softwaru, kde je typická vysoká variabilita uživatelských požadavků. Dalším faktorem, který ovlivňuje jednoduchost a adekvátnost koncepce uživatelského rozhraní, je organizace práce tvůrců vrstvy. Zkušenosti z různých projektů popsané v literatuře ukazují, že není vhodné, aby se na tvorbě koncepce uživatelského rozhraní podílel příliš velký počet pracovníků.
7.4
Návrh vrstvy uživatelského rozhraní
48
Způsob návrhu uživatelské vrstvy Uživatelské rozhraní vrstvy je hlavním faktorem ovlivňujícím náklady užití a efektivnost práce uživatele vrstvy. Uživatelské rozhraní vrstvy je dáno třemi vzájemně souvisejícími komponentami, které jsou k dispozici nadřízenému uživateli jako nástroj řešení jeho problémů. Těmito třemi komponentami jsou datové struktury, operace nad datovými strukturami a jazyk. Jazyk rozhraní určuje komunikační formu, v níž jsou jednotlivé datové struktury a operace dané vrstvy uživateli zpřístupněny. Uživatelské rozhraní vytváří pro uživatele prostředí, ve kterém jsou determinovány metody a nástroje řešení požadavků a problémů uživatele. Tím uživatelské rozhraní současně předurčuje rozsah, kvalitu a náklady řešení daných problémů. Kvalitní uživatelské rozhraní může otevřít nové náhledy na realitu. Například vyspělý typový aplikační software, který byl vytvořen na základě požadavků mnoha podniků z různých zemí, v sobě obsahuje tzv. „best practiceÿ, který může být vhodným vodítkem pro návrh podnikových procesů i pro méně zkušený řešitelský tým. Návrh funkcí uživatelského rozhraní Funkce uživatelského rozhraní, tj. datové struktury a operace vrstvy rozhraní, musí vycházet z důkladné funkční a datové analýzy datové oblasti. S ohledem na pohodlí a efektivnost práce uživatele, pro kterého je rozhraní vytvořeno, je nutné navrhnout množinu funkcí tak, aby minimálním počtem funkcí bylo možné pokrýt všechny oprávněné požadavky uživatele. Návrh jazyka uživatelského rozhraní Jazyk rozhraní je prostředek, který zpřístupňuje funkce vrstvy. Špatně navržený jazyk rozhraní může způsobit znehodnocení dobrého návrhu ostatních komponent rozhraní. Při návrhu kvalitního jazyka rozhraní je vhodné respektovat následující zásady: 1. Syntaxe a sémantika jazyka vrstvy musí být maximálně jednoduché a konzistentní pro všechny zpřístupněné funkce. 2. Zprávy poskytované vrstvou uživateli musí být jasné a jednoznačné a v souladu s úrovní, na které se uživatel pohybuje. 3. Jazyk uživatelského rozhraní musí odstínit všechny implementační charakteristiky nižších vrstev. Typickou chybou je případ, kdy např. aplikační programátor předpokládá u koncového uživatele znalosti o výpočetní technice a vyžaduje po něm rozhodování v pojmech kterým uživatel nerozumí (např. „Mám ukládat data v plném nebo komprimovaném tvaru?ÿ). 4. Jazyk uživatelského rozhraní by měl umožňovat uživateli vytvářet jeho vlastní uživatelské vrstvy (definice). Vhodným prostředkem je např. využívání makrojazyka. 5. Jazyk by měl obsahovat jednoduché prostředky pro testování vytvořených programů (týká se spíše nižších vrstev).
7.4
Návrh vrstvy uživatelského rozhraní
49
6. V případě integrovaného systému skládajícího se z několika subsystémů, je nutné navrhnout uživatelské rozhraní jednotlivých subsystémů tak, aby mělo maximální počet shodných funkcí a velmi obdobný jazyk. 7. Při návrhu komunikace mezi uživatelem a systémem je nutné vhodně zvolit mezi člověkem řízenou nebo počítačem řízenou komunikací. V systémech, které jsou určeny pro koncové uživatele, je nutné preferovat počítačem řízenou komunikaci, neboť ta umožňuje odstínit uživatele od všech technických detailů řešení a často i od algoritmu řešených úloh. 8. Jazyk interaktivního uživatelského rozhraní by měl obsahovat příkazy pro návrat do předcházejících stavů komunikace. Tyto příkazy umožňují uživateli v komunikaci experimentovat, přičemž mu zaručí, že v případě chybného rozhodnutí může vrátit komunikaci a data do stavu před tímto rozhodnutím. 9. Uživatelské rozhraní musí disponovat vhodně (nejlépe hierarchicky) zpracovanou dokumentační příručkou a nápovědou.
8
ARCHITEKTURA MVC
8
50
Architektura MVC
Praktické uplatnění třívrstvé architektury v ovládání grafického uživatelského rozhraní představuje architektura MVC (Model-View-Controller paradigma)6 . Historie MVC se datuje již do 70. let minulého století, autorem této myšlenky je Trygve Reenskaug7 . Prvním z velkých projektů využívajících MVC architekturu je programovací jazyk Smalltalk-80 (Smalltalk, 2005).
8.1
Základní pojmy MVC
Podle architektury MVC jsou uživatelské vstupy, modelování vnějšího světa a zobrazování výstupů od sebe výlučně odděleny a ovládány třemi typy objektů specializovanými pro jednotlivé operace (Burbeck, 1992). Architekturu MVC tvoří tři základní prvky: • Objekt view (pohled) – zajišťuje vnější prezentaci (tzn. transformuje výstup aplikací do grafické či textové formy zobrazované uživateli na výstupním zařízení – obrazovce). • Objekt controller (ovladač) – zpracovává vstup od uživatele (nejčastěji z myši nebo klávesnice) a zajišťuje propojení příslušných modelů a pohledů. • Objekt model (model) – obstarává logiku aplikace (aplikační chování a datovou složku), reaguje na požadavky o stavových informacích (obvykle od pohledu) a na instrukce o změně stavu (obvykle od ovladače). Chování objektů MVC lze dědit, přidávat a modifikovat podle potřeby, a tak získat velmi pružný a výkonný systém. Pro efektivní využití MVC paradigmatu si musíme objasnit rozdělení práce mezi trojici základních prvků MVC. Všechny tři části komunikují spolu navzájem a současně s dalšími aktivními pohledy a ovladači. Vzájemnou komunikací a spoluprací objektů lze zajistit sdílení hardwarových prostředků uživatele (jedné myši, jedné klávesnice a jednoho zobrazovacího zařízení) mezi jednotlivými aplikacemi či jejich částmi. Ve světě WWW tak dochází ke sdílení jednoho webového prohlížeče s jedním portálem ve všech aplikacích či částech portálu. Pohledy ovládají zobrazovací zařízení (obrazovku, webový prohlížeč, portálový kontejner) a zobrazují na ní text či grafiku. Ovladače musí spolupracovat s pohledy a zajistit, aby náležitý ovladač zpracoval vstup od uživatele ze vstupního zařízení (klávesnice, myš, webový formulář, URL – většinou lze ovladač zvolit podle aktivního pohledu – např. se nad ním nachází kurzor nebo se jedná o jednu sadu webových formulářů či aktivní URL). Protože vstupy a výstupy jednotlivých aplikací 6 Kvůli absenci dostupné české literatury o MVC paradigmatu, vycházím z anglických textů. Pro srozumitelnější popis a lepší vyjadřování v českém jazyce zavádím české pojmy model – pohled – ovladač. 7 Trygve Reenskaug pochází z Norska, v 80. letech navrhl a jako první implementoval MVC paradigma (Reenskaug, 2002).
8.2
Komunikace mezi trojicí prvků MVC
51
mají obdobné chování, většinu vlastností dědí pohledy a ovladače z tzv. generických objektových tříd – View a Controller. Naproti tomu modely nemohou být jednotné, neboť téměř každý objekt může být považován za objekt typu model. Proto se základní vlastnosti modelů, které jsou součástí MVC paradigmatu, dědí z objektové třídy Object, jež představuje základní třídu pro všechny možné modely.
Obr. 4: Základní schéma architektury MVC
8.2
Komunikace mezi trojicí prvků MVC
Model, pohled a ovladač tvořící trojici MVC architektury spolu musí komunikovat, aby aplikace mohly zajistit souvislou interakci s uživatelem. Komunikace mezi pohledem a s ním spojeným ovladačem je přímá, neboť třídy View a Controller jsou určeny pro vzájemnou spolupráci. Na druhou stranu modely komunikují poněkud odlišným způsobem. Pasivní model Jako nejjednodušší případ modelu, na který pro zařazení do MVC trojice neklademe žádné nároky, si můžeme představit například libovolný WYSIWYG8 editor. V takovém editoru vypadá text stejně jako jeho tiskový výstup (např. MS Word, OpenOffice Writer). To znamená, že pohled musí být jasně informován o každé změně textu, aby jej mohl správně zobrazit. Model nepřebírá odpovědnost za zobrazení těchto změn, neboť jsou zadávány uživatelem. Ovladač tlumočí požadavky uživatele a přebírá odpovědnost za informování pohledu o všech provedených změnách. Buď 8
What You See Is What You Get – co vidíš, to dostaneš.
8.2
Komunikace mezi trojicí prvků MVC
52
pouze upozorní pohled, že se něco změnilo – a pohled potom požádá model o aktuální stav řetězce, nebo ovladač přímo specifikuje pohledu, co se změnilo. V obou případech je model řetězce zcela pasivní nositel informace o textu (řetězci), který je obsluhován pohledy a ovladači. Model pouze přidává, odstraňuje či nahrazuje části textu podle požadavků ovladače a na základě dotazů pohledu vrací příslušné podřetězce. Takový model si naprosto „není vědomÿ existence pohledů a ovladačů, ani účasti v MVC trojici. Toto odloučení není způsobeno jednoduchostí modelu, ale faktem, že se takový model mění pouze na základě příkazu jednoho z dalších členů trojice. Zapojení modelu do MVC trojice Většinou však modely nejsou tak pasivní, jako ve výše uvedeném příkladu. Představme si, že datový objekt – např. zmiňovaný řetězec – se mění na základě „zprávyÿ poslané jiným objektem, než je pohled nebo ovladač. Potom musí být pohled informován o změně stavu příslušného modelu, aby mohl datový prvek správně zobrazit. Model a pohled musí být propojeny, neboť pouze model sleduje všechny změny stavu. Toto spojení zajišťuje globální mechanismus základní třídy Object, sledující závislosti mezi objekty (např. právě model – pohled) a zaznamenávající všechny existující vztahy. Všechny modely dále disponují mechanismem pro správu závislostí, který sleduje vztahy mezi modely uspořádanými v určité hierarchii. V atributu instance modelu jsou uloženy informace o závislých prvcích (žádný, jeden nebo více závislých modelů). Model z nově vytvořené MVC trojice je pak zařazen do této hierarchie. Pohledy jsou informovány mechanismem závislostí o všech změnách modelu. Je-li nově vzniklému pohledu přiřazen příslušný model, je automaticky zaregistrována závislost pohledu na jeho modelu. Naopak, je-li pohled zrušen, vazba závislosti také pozbývá platnosti. Tato nepřímá komunikace mezi závislými prvky probíhá podle aktualizačního předpisu. Příkladem může být otevření okna na obrazovce. Všem závislým prvkům příslušného modelu je zaslána zpráva o změně modelu a příkaz k aktualizaci podle této změny. Tento mechanismus změny/aktualizace tedy představuje způsob komunikace mezi modelem a jeho pohledy. Jeden model může patřit současně do více MVC trojic. Každý pohled je pak spojen se svým ovladačem. Je-li změněn model, jsou informovány všechny závislé pohledy. Pokud se provedená změna týká jen některých pohledů, předává model současně se zprávou o změně ještě další oznámení (parametr), definující typ změny, aby mohly reagovat pouze příslušné pohledy. Propojení pohledů a ovladačů Na rozdíl od modelu, jenž může být součástí několika MVC trojic, je každý pohled jednoznačně spojen s jedním ovladačem a naopak. Atributy instance objektu pohled
8.3
Pohledy
53
zahrnují ukazatel na příslušný ovladač, atributy instance objektu ovladač zase zahrnují ukazatel na konkrétní pohled. Protože navíc oba objekty komunikují se svým modelem, oba obsahují atribut ukazující na příslušný model. Mohou tedy posílat zprávy mezi sebou navzájem a svému modelu.
8.3
Pohledy
Hierarchie pohledů a vnořených pohledů Pohledy jsou určeny ke vzájemnému vnořování. Každé okno je ve skutečnosti tvořeno nejméně dvěma navzájem vnořenými pohledy. Vnější pohled spravuje horní lištu okna s názvem. Ovladač spojený s tímto pohledem řídí pohyb, minimalizaci, maximalizaci či zavření okna, tedy operace dostupné pro okna nejvyšší úrovně. Každý pohled nejvyšší úrovně obsahuje jeden nebo více vnořených pohledů a s nimi sdružených ovladačů, které řídí operace dostupné v těchto pohledech. Vnořené pohledy mohou obsahovat další jim podřízené pohledy. Vztahy mezi nadřízenými a podřízenými pohledy jsou zaznamenány v atributech instance pohledu. Každý pohled obsahuje atributy instancí ukazující na nadřízené a vnořené pohledy. Všechny pohledy tak tvoří hierarchickou stromovou strukturu vycházející z hlavního okna obrazovky, kterou lze procházet díky zmíněným vazbám mezi jednotlivými pohledy. Zobrazování pohledů Každý pohled potřebuje vlastní zobrazovací předpis. Tento předpis se užívá pro úvodní zobrazení pohledu a pro překreslení objektu, nahlásí-li příslušný model změnu (a eventuálně pro překreslení po změně vyvolané ovladačem). Změny zobrazování řídí transformační předpisy. Spojují příslušná okna a výřezy zajišťováním např. změny měřítka apod. Okno představuje pravoúhelník na abstraktní zobrazovací ploše a je vstupem do transformace. Výřez okna pak představuje určitou pravoúhlou oblast obrazovky, ke které se abstraktní okno váže. Transformační předpisy lze skládat, složené naopak rozkládat. Pohledy pak využívají transformací k řízení umísťování vnořených pohledů.
8.4
Ovladače
Ovladače zpracovávají podněty od uživatele zadávané pomocí myši nebo klávesnice. Pohyb a kliknutí myši spustí posloupnost vnitřně řízených akcí. Jednotlivá řídicí vlákna jsou spravována vzájemnou spoluprací ovladačů spojených s různými aktivními pohledy. Ve skutečnosti může být aktivní v jednom okamžiku pouze jeden ovladač.
8.4
Ovladače
54
Komunikace mezi ovladači Prvotní princip organizace ovladačů zajišťující, že správný ovladač přebírá kontrolu ve správném čase, je dán faktem, že aktivní ovladače vytvářejí hierarchický strom. Na vrcholu tohoto stromu stojí „manažer ovladačůÿ. Větvením pak druhou úroveň stromu tvoří ovladače nejvyšší úrovně jednotlivých aktivních oken a dodatečný ovladač, řídící hlavní systém pozadí obrazovky. Protože každý pohled je sdružený s jedinečným ovladačem, existují k jednotlivým hierarchickým stromům pohledů paralelní hierarchické stromy ovladačů. Řízení je pak předáváno z ovladače na ovladač v rámci větvení tohoto stromu. Jednoduše řečeno, tok řízení vyžaduje spolupráci ovladačů, které přebírají řízení právě v okamžiku, kdy se jejich pohled stane aktivní. Po převzetí řízení se ovladač pokouší předat řízení dále ovladačům vnořených pohledů. Vrcholový „manažer ovladačůÿ se ptá všech ovladačů pohledů nejvyšší úrovně, zda přebírají řízení. Kladně odpovídá pouze ovladač spjatý s aktivním pohledem. Proces se cyklicky opakuje – ovladač se ptá všech svých vnořených ovladačů. Tak se nalezne nejvnitřnější vnořený pohled obsahující kurzor a ovladač tohoto pohledu si ponechává řízení, dokud se kurzor nepřemístí jinam. Velmi důležitá úloha ovladačů způsobuje, že nemůže existovat pár model – pohled, aniž by k němu byl přidružen ovladač. Pokud by toto bylo možné, mezera způsobená chybějícím ovladačem by přerušila tok řízení. Mohou se však vyskytnout případy, kdy potřebujeme, aby nějaká množina vnořených pohledů byla řízena jedním společným ovladačem. Pak musíme použít speciální ovladač určený pro tyto zvláštní případy. Jednoduchým příkladem předávání řízení mezi pohledy na obrazovce je například zvýraznění aktivního okna. Okno, v kterém se právě nachází kurzor má zvýrazněnou (zpravidla modrou nebo jinak barevně odlišenou) horní lištu. Kliknutím (či jiným přesunutím) uživatele jinam se zvýraznění horní lišty přesouvá do nově aktivovaného okna. Vstup a výstup z toku řízení Popisovaná posloupnost předávání toku řízení je neustále probíhající proces. Je tedy třeba nalézt způsob, jak do něj začlenit nově vzniklou MVC trojici, a jak ji zrušit v případě ukončení platnosti. Toto zajišťují ovladače pohledů nejvyšší úrovně. Ty pak dále předávají řízení ovladačům vnořených pohledů (které ve skutečnosti vykonávají většinu práce v typické aplikaci). Všechny ovladače nejvyšší úrovně musí vycházet z vrcholového manažera ovladačů. Jemu potom nahlásí změnu a nová MVC trojice bude tvořit další větev hierarchického stromu vycházející z vrcholu. Analogicky je tomu při ukončení platnosti MVC trojce. Typickým příkladem může být otevření či uzavření okna na obrazovce.
8.5
8.5
Rozšířené uplatnění MVC
55
Rozšířené uplatnění MVC
Dokonalost MVC paradigmatu je podtržena faktem, že i po více než dvaceti letech od svého vzniku lze na základě této architektury řešit aktuální problematiku moderních informačních systémů. Myšlenku MVC využíváme i při návrhu rozboru komponent informačního systému (kapitola 11).
9
UŽIVATELSKÁ PŘÍVĚTIVOST INFORMAČNÍCH SYSTÉMŮ
56
Vlastní řešení 9
Uživatelská přívětivost informačních systémů
Informační systémy a informační technologie jsou v dnešních podnicích nepostradatelné. Úlohu informačních systémů a technologií v činnosti hospodářských subjektů, stejně jako jejich vývoj a jeho důsledky podrobně popisuje (Voříšek, 1997). Bez kvalitního informačního systému se v současné době neobejdou ani nejmenší firmy, o velkých organizacích ani nemluvě. Do styku s počítačově orientovanými informačními systémy nyní přichází stále větší část populace. A právě z tohoto důvodu se důležitou vlastností informačního systému stává jeho uživatelská přívětivost. Pro většinu uživatelů je počítač či informační systém „pouzeÿ pracovním nástrojem, který jim má pomoci při vykonávání denní rutiny, má zvýšit kvalitu a efektivnost jejich práce. Většinu uživatelů informačních systémů netvoří dnes odborníci z oblasti informačních technologií, ale lidé nejrůznějších profesí, často velice vzdálených této oblasti, kde mohou být špičkoví odborníci, ale problém může nastat, jsou-li postaveni před nutnost využívat určitý informační systém. Přijetí takové změny je velmi individuální a záleží na každém člověku, jak se s ní vyrovná. Vytvořit informační systém takový, aby maximálně splňoval požadavky uživatelů (uspokojoval uživatele náročné, vyhovoval uživatelům neutrálním a snažil se přesvědčit uživatele nespokojené), je pak úkolem autorů a vývojářů informačního systému. Do následujících bodů se pokusíme shrnout vlastnosti uživatelsky přívětivého systému. • Základním požadavkem každého uživatele informačního systému je přehledné, příjemné a intuitivní ovládání, tedy vhodné uživatelské rozhraní. • Systém musí jednoduchou formou nabízet uživateli všechny jemu dostupné funkce. • Komunikace uživatele se systémem musí být taková, aby uživatel v každém okamžiku věděl, kde se právě nachází a co má dělat. • Vstupy požadované od uživatele musí být jasně definované, aby netápal a věděl, jaké hodnoty má zadávat. • Je nezbytné zabezpečit, aby po případně nesprávně zadaných údajích aplikace nehavarovala, ale aby se vypsala zpráva upozorňující na nesprávnost a podávající znovu, pokud možno podrobněji, informaci o správném tvaru odpovědi. • Je užitečné povolit, aby co největší počet zadávaných položek mohl uživatel vynechat (v tom případě se dosadí automaticky nějaká konkrétně definovaná hodnota, uživatel však musí být jasně informován, jakou hodnotu za něj systém dosazuje). • Výstupy musí být poskytovány přehlednou formou a ve vhodných formátech pro další využití uživatelem.
9.1
Prostředí dnešních IS
57
• Pokročilým uživatelům systém může nabízet další funkce a možnosti využití, které ale nebudou nijak ovlivňovat (a „znepokojovatÿ) uživatele ostatní. Už v publikaci (Kopeček a Kučera, 1989) se autoři zmiňují o dialogu s počítačem podle svých praktických zkušeností s programováním a formulují zásady pro komunikaci s počítačem, z nichž některé jsou uvedeny ve výše uvedeném výčtu. S lehkou nadsázkou zde dělí programy podle způsobu komunikace s uživatelem do čtyř kategorií na programy typu sangvinik, flegmatik, cholerik a melancholik. Podle tohoto třídění je tedy evidentní, že nás zajímají programy typu sangvinik.
9.1
Prostředí dnešních IS
V současné době hraje významnou roli celosvětová počítačová síť Internet, jejíž rozvoj a dostupnost značně urychlily rozmach tzv. distribuovaných aplikací a celých distribuovaných informačních systémů. Většina dokumentů i aplikací na Internetu využívá principu hypertextu, kdy pomocí odkazů v běžném multimediálním dokumentu (kombinace textu, obrázků a dalších multimediálních objektů) lze propojit několik různých dokumentů dohromady, odkazovat se na externí zdroje či zajistit „dynamičnostÿ příslušného dokumentu (provázání s výkonnými aplikacemi či jejich částmi). Třívrstvá architektura informačních systémů oddělením datové, aplikační a prezentační části dále prohlubuje možnosti využití informačních systémů. V třívrstvé architektuře není nutně vyžadováno, aby všechny vrstvy byly provozovány na jednom počítači. Prostředí počítačové sítě umožňuje oddělit jednotlivé vrstvy a zvyšuje tak efektivitu takto provozovaného systému. Situace u WIS Při vývoji webových informačních systémů je často opomíjena ergonomická stránka jejich využívání. Přizpůsobování těchto systémů potřebám jejich uživatelů je obvykle realizováno pouze několika málo volbami zabývajícími se většinou pouze barvou pozadí či velikostí použitého fontu. Je nutné se hlouběji zamyslet nad principy, metodami a možnými realizacemi odlišného přístupu k návrhu a vývoji informačního systému, kde není hlavním cílem pouze detailní propracovanost systému, ale především použitelnost systému uživatelem. Pod pojmem uživatelsky přívětivý informační systém si můžeme představit nejen systém umožňující přizpůsobení jeho funkcí potřebám uživatele, ale i myšlenky zabývající se hledáním toho, co uživatel od systému očekává, příp. požaduje. Je nutné hledat obecné zásady a metody, na kterých může být prakticky realizováno budování rozsáhlých webových informačních systémů.
10
PERSONALIZACE
10
58
Personalizace
V obecném pojetí znamená personalizace individuální přístup neboli individuální přizpůsobení vlastním potřebám. Konkrétní definici personalizace je těžké stanovit, neboť každý si pod tímto pojmem představí něco jiného. Slovo „personalizaceÿ je velmi široké a otevřené mnoha různým interpretacím. V článku (Riecken, 2000), úvodu k srpnovému vydání časopisu Communications of the ACM v roce 2000 zaměřeného na personalizaci, sám autor obchází jednoznačnou odpověď již výstižným nadpisem Personalized Views of Personalization (Personalizované pohledy na personalizaci). Autoři jednotlivých článků pak přinášejí různé pohledy na personalizaci od témat jako strukturování webových stránek přes ručně přizpůsobitelné portály až po přirozený dialog systému s uživatelem. Na personalizaci lze také nahlížet podle zájmových skupin uživatelů – personalizace systémů určených k obchodu a podnikání, personalizace z pohledu „lidského prvkuÿ, hlubší pohled pak přináší zamyšlení nad vedlejšími efekty personalizace či nad technologiemi, které ji umožňují. Co tedy znamená, když je informační systém personalizovatelný? Zůstanemeli v prostředí WWW, vidíme, že personalizace je interpretována mnoha způsoby. Například některá webová sídla, zejména zprostředkovávající elektronický obchod, si pamatují osobní data uživatelů (např. adresu, číslo kreditní karty). Jiná sledují chování uživatele (pohyb v systému), jeho preference, tato data vyhodnocují a podle toho zákazníkům doporučují specifické výrobky a služby. Setkáváme se s podporou prohlížení webových stránek, např. nabídkou sady nejčastěji používaných odkazů. Samozřejmě existuje mnoho způsobů studia personalizace, např. úroveň přizpůsobení obsahu, relevnantnost informací zobrazovaných uživateli, rychlost přístupu k informacím nebo i kvalitativní kritéria jako užitečnost a spokojenost uživatelů. Saverio Perugini (Perugini, 2004) zase ve své disertační práci představuje personalizaci jako přizpůsobení vzájemné komunikace systému s uživatelem a modeluje tuto úroveň vztahů. Pro potřeby této práce je třeba zaujmout k personalizaci jednoznačné stanovisko a definovat úhel zkoumané problematiky.
10.1
Stanovení pohledu na personalizaci
U webových informačních systémů se v praxi setkáváme s dvěma poněkud odlišnými pojetími personalizace. Někteří provozovatelé informačních systémů považují za personalizaci poskytnutí autentizovaného vstupu (přihlášení uživatele jménem a heslem), po přihlášení uživateli nabízejí či zpřístupňují jemu relevantní údaje. Navíc někteří provozovatelé umožňují uživatelům osobní nastavení některých komponent. V chápání personalizace je však třeba jít dále. Autentizace uživatelů je samozřejmostí, neboť pro nepřihlášené (tedy neznámé) uživatele není možné evidovat jakákoliv osobní data a nastavení (nejvýše lze využívat cookies v prohlížeči). To, co bylo v předcházejícím odstavci chápáno jako personalizace, nyní chápeme pouze
10.2
Navigační systém
59
jako formulaci práv a rolí uživatele v příslušném systému. Rozdíl mezi oprávněním a rolí je dán pohledem na problematiku určování rozsahu přidělení pravomocí. Zůstaneme-li např. v prostředí informačního systému univerzity, je oprávnění explicitně udělováno (odpovědná osoba určuje, kdo má jaká oprávnění, obvykle pouze deleguje některé své oprávnění v plné nebo snížené síle dál). Role vzniká zařazením uživatele do univerzitní hierarchie (oprávněná osoba pouze definuje uživatele, role je implicitní oprávnění osoby). Typicky lze mezi práva řadit např. právo vydávat identifikační karty (explicitně uděleno systémovým integrátorem – provozovatelem systému – příslušným osobám na fakultách a rektorátu), mezi role pak roli učitele (osoba je učitelem z titulu svého zaměstnání na akademickém pracovním místě), roli studenta apod. Jednotlivým odkazům na konkrétní dokumenty či aplikace jsou přiřazeny informace (strukturované záznamy) popisující, kteří uživatelé smějí tento odkaz užívat. Nemůže se tedy stát, že uživatel vidí řadu odkazů, kde se mu však při kliknutí zobrazí chybové hlášení upozorňující na nemožnost přístupu. Rozšíříme-li toto pojetí, skutečná personalizace přichází v okamžiku, kdy si uživatel může sám nastavovat určité parametry vzhledu či chování systému. Základním nastavením může být například povolení nebo zákaz zobrazování určitých informací o uživateli ostatním, případně si uživatel může o sobě doplnit údaje další, jako např. kontakty, konzultační hodiny, klíčová slova pro snadnější vyhledávání apod. Do personalizace řadíme i nastavení systémových politik, které souvisí s chováním systému. Uživatelé si mohou například definovat tiskárny (směrování tiskových výstupů), nejčastěji používané výstupní formáty apod. Žádanou vlastností (a dosud velmi málo nabízenou) je možnost tzv. skrývání nápověd. Nápovědné texty, které jsou součástí každé aplikace, jsou pro uživatele velmi důležité, neboť obsahují informace o aplikaci a postup, jakým se má uživatel ubírat. Na druhé straně jsou-li tyto texty příliš dlouhé, stránku prodlužují a ta se stává méně přehlednou. Skrývání nápověd využijí zejména zkušenější uživatelé, pro které je práce s určitou aplikací rutinou. Pokud tuto možnost zvolí, nápovědné texty se jim nezobrazují přímo, ale jsou dostupné kliknutím na ikonku s nápovědou. Dalším stupněm osobního přizpůsobení systému jsou pak nastavitelný navigační systém, volba designů či možnost vytváření zástupných aplikací; tyto možnosti jsou podrobně rozepsány dále. Portálové řešení integrovaného informačního systému otevírá další možnosti personalizace, vycházející z kombinace uvedených hledisek.
10.2
Navigační systém
Navigační systém představuje základní jednotící prvek pro všechny aplikace. Je organizován stromově a jednotlivými listy jsou odkazy na konkrétní dokumenty či aplikace příslušných informačních systémů. U každého odkazu je definováno, kteří uživatelé smějí na základě svých práv a rolí tento odkaz užívat (samozřejmě je možné
10.3
Variabilní design
60
zpřístupnit odkazy všechny, ale portál, kde dvě třetiny odkazů zobrazí informaci o nedostatku práv uživatele velmi brzo omrzí). Z definice práv a rolí uživatelů by mohlo plynout, že definici odkazů musí provádět systémový integrátor (provozovatel portálu), protože jinak by bylo možné definovat si odkaz s libovolnými oprávněními. Skutečně základní množina obsahu portálu musí být stanovena explicitně mimo vlastní uživatele. Avšak uživatelé mohou tuto skupinu odkazů rozšiřovat o další, uživatelsky definované odkazy a ty zařazovat ve svém, skupinovém nebo všeobecném portálu (portál má určité části zaměřené na konkrétní uživatele, skupiny definované především získanými rolemi a všeobecnou část určenou všem uživatelům). Tím se množina odkazů stává otevřená i pro běžné uživatele minimálně v části svého uživatelského portálu. Fakt, že uživatel sám si může ovlivnit obsah portálu (definicí a zařazením odkazů) a jeho strukturu (vlastní organizací odkazů do stromové struktury s možností definovat si části a sekce doplněné vhodnými grafickými navigačními značkami – např. ikonami) umožňuje přizpůsobit si informační systém každodenní potřebě. Uživatel tak může umístit nejpoužívanější funkce do nejvyšší úrovně hierarchie a směrem k začátku seznamu odkazů, naopak nepoužívané funkce do úrovně nejnižší, na konec seznamu, příp. je úplně vyřadit. Přitom není nutné stanovit použitelnost odkazu direktivně (rozhodnutím provozovatele), ale lze vše ponechat na vůli a chuti uživatelů. Vedlejším efektem takto provozovaného navigačního systému je možnost sledovat, které odkazy jsou nejpoužívanější (provozovatel dopředu zná strukturu uživatelů a vymezení jejich pravomocí, ale nedokáže popsat jejich postupy práce ani četnost jimi prováděných akcí) a také periodicitu používání některých odkazů. Tím lze zjistit celou řadu faktorů – na které aplikace se zaměřit, které aplikace přednostně vylepšovat či zjednodušit, které aplikace dále nerozvíjet, jakou část aplikací přesunout do automatizovaného centra dlouhodobých úkolů (periodicky spouštěné statistiky lze uživateli generovat mimo běžné pracovní prostředí a zasílat je např. e-mailem). Celé přizpůsobování obsahu a struktury portálu lze částečně automatizovat zavedením dynamického modifikování jednotlivých portálových sekcí. Často používané odkazy se mohou postupně „stěhovatÿ vzhůru v hierarchii portálu, méně používané odkazy níže, až posléze mizí v implicitně skryté části systému. Takto lze systém dynamicky přizpůsobit běžnému chování uživatele bez nutnosti školit jej v konfiguraci vlastního portálu. Zjištěné výsledky různých uživatelů lze porovnávat a pro standardizované kategorie uživatelů (odvíjející se od rolí a oprávnění) pak definovat standardní šablony rozložení prvků portálu – i nový uživatel tak dostane portál ve stavu velmi se blížící jeho běžné práci, nemusí se v systému „učitÿ způsobu práce.
10.3
Variabilní design
Každý uživatel má své zvyklosti v grafickém pojetí oblíbených aplikací. Postupný vývoj několika informačních systémů ukázal, že řadě uživatelů vyhovuje tmavší pozadí, řadě naopak světlejší (vznikají dokonce bouřlivé rozepře mezi zastánci tmavých
10.4
Sjednocení obsahu a vzhledu portálu
61
a světlých barev). Někteří preferují organizaci běžných aplikací v pořadí prezentace stávajících údajů – prezentace nových údajů – další operace, jiní naopak vyžadují přidání nových údajů v přední části stránky a další operace v levé navigační části, pro řadu uživatelů je přidání údajů dokonce další operace a nemá být v úvodní stránce vůbec. Zkušenější uživatelé nepotřebují v denně používaných aplikacích číst stále stejné vysvětlující texty (které jsou ale nezbytností pro uživatele jiné), rádi nápovědu skryjí pod jednu ikonku s možností kdykoliv si ji opět vyvolat. Aby bylo možné vyhovět všem požadavkům a zajistit pro uživatele standardizaci systému s jeho zvyklostmi, je nutné vytvářet všechny informační systémy striktně v koncepci třívrstvé architektury. Aplikace využívají komponent, u kterých definují chování (aplikační logiku). Způsob prezentace a vzájemného složení komponent musí ponechat na prezentační vrstvě. Prezentační vrstva představuje souhrn objektových komponent s mnoha vlastnostmi a nástroje pro jejich kombinaci (např. některé komponenty musí být nutně v určitém významovém sledu). Uživatelé si pak mohou stanovit jak popis vzhledu jednotlivých aplikací (složení komponent), tak grafické (tedy nejen barevné) rozložení a design všech aplikací. Je možné definovat design v závislosti na aplikaci (a tak barevně rozlišit aplikace různých systémů) či naopak využívat homogenní design ve všech aplikacích všech systémů. Je možné vytvořit si několik designů a střídat je při různých příležitostech (roční období, významné světové události, státní svátky apod.). Velmi podnětným krokem je umožnit soutěž uživatelů o návrh vlastních designů – řada tvořivých uživatelů vytvoří designy, které ostatní převezmou a užívají. Je tak možné i pro nové uživatele připravit rozsáhlý výběr designů jak pro používání, tak pro inspiraci. Do popisu designů je nutné zahrnout nejen základní vzhled celého portálu a barevné ladění jednotlivých komponent, ale i designové prvky jednotlivých komponent – navigační a dekorační ikony, tvary prvků, barevné střídání řádků v tabulkách, vzdálenosti a proklady jednotlivých komponent, způsob odrážek seznamů, zarovnání odstavců s textem, vzhled formulářových prvků apod. Je vhodné naslouchat uživatelům, kteří přicházejí s novými nápady. Ukazuje se, že je vhodné sledovat vývoj designů jednotlivých uživatelů, protože ti při svém návrhu hledají často techniky, jak obejít nějaké omezení systému. Vytvořením prvků, které umožní korektně řešit uvedené obcházené situace se jednak zlepšují stávající designy, ale také se otvírají cesty pro nové nápady a díla.
10.4
Sjednocení obsahu a vzhledu portálu
Ideálním předpokladem pro vybudování uživatelsky přívětivého a současně personalizovatelného systému je stanovení jednotlivých komponent systému s popisem jejich vlastností, chování a vzájemného provázání. Na obdobném principu jsou postaveny například Oracle Application Server Portal (Carter, 2004), (Greenwald a Milbery, 2001) či velmi oblíbený webový portál Yahoo! (Manber, Patel a Robinson, 2000).
10.4
Sjednocení obsahu a vzhledu portálu
62
Ze zkušeností získaných tvorbou portálových IS, užíváním portálů, a na základě poznatků nastudovaných z literatury, lze formulovat následující doporučení: • Portál se skládá z mnoha modulů, uživatelé si vybírají, které moduly si přejí mít ve svém vlastním, personalizovaném portálu. • Obsah jednotlivých modulů je automaticky aktualizován, uživatelům jsou tedy dostupné vždy nejnovější informace týkající se dané oblasti. • Personalizovat je možné nejen skladbu modulů, ale i jejich obsah. Příkladem může být modul zobrazující televizní program, každý uživatel si v rámci tohoto modulu může vybrat pouze ty kanály, které ho zajímají. Na druhou stranu existují moduly, které jsou obecnější a uživatelé nemohou ovlivnit skladbu jejich obsahu, například nejnovější zprávy ze světa. • Vedle obsahu modulů lze přizpůsobovat samozřejmě i jejich vzhled. • Chování systému a prostředí pro nastavování uživatelských preferencí musí být transparentní a uživatelsky přívětivé, tzn. intuitivní a jednoduché na ovládání. • Vždy musí existovat možnost, kdy je systém bude plně funkční a nabízí základní sadu služeb, aniž by uživatel musel cokoliv nastavovat. Takový systém pak poskytuje všem uživatelům bez ohledu na jejich zkušenosti s ovládáním systému, na jejich čas a potřeby vždy odpovídající úroveň prostředků. Mnoho uživatelů ve skutečnosti využívá základní nastavení systému a nezabývá se možnostmi přizpůsobování. Proto je třeba na implicitní vzhled a chování systému klást velký důraz. • Nikdy nepodceňovat zkušené uživatele. Tito uživatelé jsou opakem výše zmíněných uživatelů a jsou schopni vyzkoušet i tu poslední možnost, kterou systém nabízí, nemluvě o tom, že budou prověřovat, co vše systém „vydržíÿ. Velkou chybou je omezovat systémové funkce s odůvodněním, že takovéto operace uživatelé nebudou využívat. • Pro ukládání dat o uživatelích je vhodné používat jeden centrální datový sklad. Jen tak jsou preferenční data dostupná uživatelům odkudkoliv a kdekoliv, ať už uživatelé pracují se systémem v práci, doma či na cestách. To samozřejmě zvyšuje odpovědnost za bezpečné nakládání s uchovávanými daty. Ochrana osobních údajů by dnes měla být samozřejmostí každého systému. • Tvořit celý systém tak, aby odrážel požadavky a odpovídal schopnostem všech typů uživatelů, pro které je určen. • Na závěr jedno důležité doporučení: učit se od uživatelů. Je vhodné stále sledovat záznamy o jejich operacích v systému a podle vzorků chování systém vylepšovat, aby co nejvěrněji odrážel potřeby těch, pro které je tvořen, potřeby uživatelů. Získávání podkladů pro personalizaci Rozhodneme-li se pro tvorbu personalizovatelného systému, je nutné stanovit, jakým způsobem budeme údaje pro personalizaci získávat a jaké vlastnosti systému bude možné upravovat.
10.4
Sjednocení obsahu a vzhledu portálu
63
Některé portály, např. už zmíněné Yahoo!, připravují pro uživatele již přizpůsobený obsah jednotlivých modulů. Informace, podle kterých stránky automaticky nastavují, čerpají např. z uživatelského profilu (místo bydliště, zájmy, profese apod.) nebo na základě předchozího chování uživatele (mapují, které odkazy navštívil, jaké tématické oblasti jej zajímají apod.). S touto technikou je však třeba zacházet velmi opatrně, někteří uživatelé mohou toto chování ocenit, jiní však mohou mít pocit, že jsou sledováni, chtějí mít věci ve svých rukou a naopak je odradí, když jim někdo říká, co se jim vlastně líbí. Podle způsobu získávání podkladů pro personalizaci se webové systémy dnes dělí do tří základních kategorií (Mobasher, Cooley a Srivastava, 2000): • Systémy s jednoduchými rozhodovacími pravidly – umožňují administrátorům webových sídel určovat pravidla pro zobrazování stránek na základě demografických a statických údajů, které uživatelé zadávají při registraci, nebo na základě záznamů o pohybu uživatelů v systému. Tato pravidla pak ovlivňují obsahovou stánku dat prezentovaných konkrétnímu uživateli. • Systémy předpovídající preference uživatelů – zpracovávají explicitně získané informace od uživatelů a využitím korelačních mechanismů vracejí data, o kterých předpokládají, že nejlépe odpovídají preferencím uživatelů. • Systémy založené na obsahu – využívají podobnosti obsahu webových dokumentů a osobních profilů získaných implicitně nebo explicitně od uživatelů. Zejména ve druhé a třetí kategorii systémů se začíná využívat výsledků data miningu pro výzkum personalizace webových informačních systémů. Více podrobností o tomto směru výzkumu je možné nalézt v (Mobasher, Cooley a Srivastava, 2000) nebo (Mulvenna, Anand a Büchner, 2000). V našich úvahách o personalizaci se zaměříme zejména na možnosti nastavování parametrů systému uživatelem bez ohledu na předpovídání jeho preferencí na základě více či méně propracovaných algoritmů. Věnovat se budeme také tomu, jak tuto nastavitelnost ve skutečnosti umožnit z pohledu tvorby systému. O této stránce personalizace již literatura mluví méně. I když na webu najdeme mnoho personalizovatelných systémů, mnoho z nich si své tajemství drží pod pokličkou nebo používá technologie, které pro použití v našich podmínkách a pro naše účely nejsou optimální. Náplní dalších kapitol je rozbor námi vypracované metodiky, která na základě komponentového generování informačního systému umožňuje začlenění personalizačních prvků mezi vlastnosti informačního systému.
11
STRUKTURA WEBOVÉHO INFORMAČNÍHO SYSTÉMU
11 11.1
64
Struktura webového informačního systému Třívrstvá architektura
Naprostá většina webových informačních systémů je vyvíjena na základě třívrstvé architektury (podrobnosti v teoretické části v kapitole 5.3). Problematika řešená v této práci se týká převážně vrstvy prezentační, přesto je v této části nutné připomenout některé skutečnosti, které jsou pro pochopení celého problému podstatné. Ve webových informačních systémech lze snadno rozlišit datovou vrstvu, představovanou některým relačním nebo objektovým databázovým systémem, dále aplikační vrstvu, představovanou aplikacemi nebo komponentovými aplikačními servery a vrstvu prezentační, která je tvořena různými technologiemi, počínaje od klasických klient/server technologií, až po tenké klienty v podobě webového prohlížeče. Podrobněji se popisem třívrstvého webového informačního systému zabývá (Šorm, 2004).
11.2
Událostní cyklus
Nejdůležitějším odlišujícím prvkem webových informačních systémů od ostatních systémů na bázi klient/server je zejména existence základního událostního cyklu v podobě dvojice otázka – odpověď (akce a reakce na tuto akci). Základní schéma tohoto cyklu mezi tenkým klientem a vlastním informačním systémem (serverem) je znázorněno na obrázku č. 5.
Obr. 5: Událostní cyklus
Iniciující stranou, a tedy původcem otázky i celé události, je tenký klient. Ten je představován obvykle webovým prohlížečem a pro naše účely představuje prakticky neměnnou stranu dialogu. Zahájení událostního cyklu je způsobeno aktivací
11.2
Událostní cyklus
65
webového prohlížeče uživatelem (přechod na požadovanou stránku vybráním URL, zvolením odkazu ve stránce, odesláním formuláře tlačítkem v prohlížeči). Otázka představuje požadavek uživatele na určitou akci serveru (zobrazení stránky, uložení dat do databáze apod.). Obsahuje komplexní sadu jednoznačných informací (parametrů), podle kterých server provede požadovanou akci a tím transformuje otázku na odpověď. Ta je pak zaslána klientovi. Formát odpovědi opět obsahuje jednoznačnou sadu informací pro klienta, obvykle je to HTML stránka v libovolném formátu, kterému prohlížeč rozumí. Mezi jednoznačné parametry počítáme i parametry neúplné, kdy dojde z nějakého důvodu k chybnému předávání dat a server není schopen provést „skutečnýÿ požadavek. Server pak vrací chybové hlášení, i to je však jednoznačná odpověď na otázku za daných podmínek. Pro vytvoření opakujícího se transformačního cyklu je potřeba zajistit dvě základní transformace: • transformace na straně serveru, kdy je z otázky vytvářena odpověď, často za přispění datového skladu (informační systém postavený na třívrstvé architektuře zajišťuje propojení odpovědi s daty pomocí datové vrstvy) a • transformace na straně klienta, kde je nutné zajistit načtení uživatelských dat a korektní zobrazení odpovědi, poté jako reakci uživatele na odpověď sestavit novou otázku. Klasický a komponentový přístup Současné informační systémy jsou zpravidla vyvíjeny klasickou metodou, kdy odpovědnost za zpracování vstupních dat a odeslání dat výstupních leží nejvíce na aplikačních programátorech, kteří ve svých aplikacích zajistí komunikaci jednak s uživatelským rozhraním a jednak s databází (samozřejmě ve spolupráci s datamanažery obsluhujícími datovou základnu systému a s designéry navrhujícími design) (Pazdziora, 2001a). V klasickém webovém informačním systému jsou odpovědi událostního cyklu nestrukturované a tvořené přímo aplikacemi, kde se formuje jak obsahová, tak designová složka výstupu. Aby se vývoj informačních systémů zefektivnil, objevila se myšlenka oddělit od sebe jednotlivé komponenty systému, jasně je definovat a stanovit pravidla komunikace těchto komponent mezi sebou. Oddělením obsahu od způsobu prezentace dat přecházíme ke komponentově orientovanému systému. V rámci formování odpovědi v cyklu otázka – odpověď se zpracovává odděleně aplikační a prezentační část cyklu. Aplikační programátoři se pak mohou věnovat pouze logice aplikační a formát a způsob zobrazení je řešen až ve vrstvě prezentační. Odpověď zde můžeme rozdělit na tři podčásti: 1. Zpracování požadavků předaných klientem. V této fázi probíhají akce, které mění stav systému (např. vkládají či aktualizují data v databázi) na základě předaných „akčníchÿ parametrů. Nejsou zde generována běžná výstupní data, pouze informace o průběhu zpracování, které jsou ukládány do speciálních sou-
11.3
Component boxing model
66
borů či struktur. Mohou být vrácena chybová hlášení oznamující uživateli neúspěšný průběh operace. 2. Generování prostých výstupních dat ve formátu nezávislém na způsobu prezentace. 3. Prezentace výstupního proudu zformátovaného podle příslušných požadavků (design, uživatelské preference, typ klienta).
11.3
Component boxing model
Dva výše uvedené principy (třívrstvá architektura IS a událostní cyklus) společně s teoretickými poznatky a praktickými zkušenostmi s vývojem webových informačních systémů v univerzitním prostředí byly podkladem pro návrh a následné vypracování metodiky pro komponentové generování webových informačních systémů. Metodika byla nazvána Component boxing model (CBM) podle dvou paradigmat, jež obsahuje, a byla také prezentována na mezinárodní konferenci EUNIS 2004 (Šorm, Netrefová a Motyčka, 2004). Princip boxů Nejprve se zaměřme na princip boxů (boxing principle), který tvoří rámec pro jednotlivé objekty. Představme si konečnou podobu odpovědi – je to v podstatě jedna dlouhá stránka, pravoúhlý čtyřúhelník. Pro podobnost celého schématu s krabicovým schématem říkejme tomuto objektu box 9 . Tento box tvořící stránku může být dále dělen do dalších pravoúhlých čtyřúhelníků, také zvaných boxy. Každý box je tvořený dvěma složkami: obsahem a designem. Obsahem boxu může být buď další vnořený prvek nebo funkční komponenta (např. statický text, formulář, obrázek). Tyto boxy pak tvoří hierarchickou strukturu (strom), kde výsledná stránka představuje kořen tohoto stromu a obsahem jednotlivých listů jsou funkční komponenty, významové prvky, které se již dále nedělí do dalších boxů. Designem boxu je konkrétní popis vzhledu boxu, je logicky přizpůsoben typu obsahu boxu (jiná designová pravidla mají funkční komponenty a jiná vnořené boxy). Při sestavování odpovědi musíme postupovat od nejnižší úrovně stromu, podle konkrétního předpisu sestavit z obsahu jednotlivých listů boxy vyšší úrovně, až se dostaneme ke kořeni stromu, máme sestavenou výslednou stránku. Jednoduché dělení stránky do boxů je znázorněno na obrázku 6. Tento princip umožňuje znovupoužití jednotlivých částí stránek v jiných aplikacích. Můžeme vytvořit typické části stránek jako záhlaví, zápatí, navigační panel, panel nástrojů a ty pak libovolně kombinovat při sestavování výsledných odpovědí. Oddělením obsahu boxu od jeho designu dosáhneme možnosti upravovat vzhled portálu, aniž bychom ovlivnili jeho obsah či strukturu. Jednotlivé typy aplikací pak 9
anglicky krabice = box
11.3
Component boxing model
67
Obr. 6: Jednoduché dělení stránky do boxů
mohou (nebo naopak nemusí) vypadat různě, ale jejich chování (obsah, funkce) zůstávají stále stejné. Princip komponent Zatímco princip boxů se zabývá vertikální linií (tzn. rozkladem otázky a složením odpovědi v rámci spolupráce všech tří vrstev architektury IS), princip komponent (component principle) se týká linie horizontální. Na úrovni každé vrstvy hledá a definuje konkrétní komponenty, které se v systému opakují či řeší standardizovanou úlohu, a usnadňuje tím jejich znovupoužitelnost. Podle pravidel objektově orientovaného programování lze vytvořit strom komponent s jasně definovanými vlastnostmi a dědičnými závislostmi. Tento princip je odvozen z RAD paradigmatu (Rapid Application Development – rychlý vývoj aplikací s použitím prototypů), podobně jej používá programovací jazyk Delphi, C++Builder, prostředky .NET a další. Lze jej také spatřit v budování jednotlivých komponent ve všech třech vrstvách zmíněné třívrstvé architektury. První skupina tvořených komponent musí zahrnovat datové komponenty pro přístup do datových struktur jako dotazy na data, definice nových objektů a jejich vlastností, např. užití šablonování či kvalifikačních mechanismů nad daty, nebo komponenty pro aktualizování informací se správným voláním triggerů, procedur a funkcí, zajišťujících dodržení podmínek konzistence datového skladu. Druhou důležitou skupinou komponent jsou komponenty aplikační vrstvy, která zahrnuje množství operací jako např. autentifikace, audit, logování operací, tisk dokumentů (tvorba výstupu v požadovaných formátech – PDF, PostScript), tvorba
11.4
Komponenty jednotlivých vrstev
68
a užití formulářů, generování výstupních sestav, OLAP funkce, vytváření grafů apod. Díky dědičnosti stačí vytvořit typické a standardizované prvky a s jejich použitím pak tvořit specializované doplňky. Třetí třídu komponent představuje prezentační vrstva s prvky pro jednotlivé designové komponenty, dále prostředky pro přidávání designu, tvorbu navigačního systému, přípravu jiných viditelných částí aplikace (dekorace, ikony, nápovědné texty, odkazy na manuálové stránky aj.). Složení obou principů Při budování IS získáváme kombinací obou výše uvedených pravidel systém, který je znovupoužitelný (díky komponentovému pojetí), personalizovatelný (díky boxům) a snadno rozšiřitelný (kombinací obou vlastností). Tyto tři vlastnosti umožňují pohlížet na komponentově generovaný systém jako na typ systému portálového. Aplikace můžeme považovat za portálové aplikace. Pak je již jednoduché rozšiřovat portál o nové portálové aplikace a využívat části již dříve vytvořených sekcí či portletů. Užívání a rozšiřování portálu může být i v rukou uživatelů, kdy si uživatelé mohou definovat svůj oblíbený design, přizpůsobovat strukturu obsahu a ovládat jednotlivé komponenty podle svých zvyklostí.
11.4
Komponenty jednotlivých vrstev
Na základě třívrstvé architektury je možné nalézt komponenty odrážející jednotlivé vrstvy této architektury. Dostaneme tak tři základní typy komponent (Šorm, 2004): • Datové komponenty – reprezentují třídy objektů pro manipulaci s daty a vyšší metody abstrakce zapouzdřující jednotlivé přístupy k datům (operace definice, modifikace a zjišťování dat). Tyto komponenty nemohou být přímo použity při definici odpovědi jako součást výsledné stránky. • Aplikační komponenty – představují logiku chování celé aplikace – jedná se o komponenty přímo používané při procesu sestavování odpovědi v událostním cyklu. Tyto komponenty by neměly vytvářet vlastní design (vzhled) aplikace. • Prezentační komponenty – zajišťují vlastní vizuální provedení aplikací i celého webového informačního systému. Datové komponenty Původní myšlenka tvorby datové vrstvy vychází z možnosti vytvořit obecný popis metadat, která jsou schopna generovat celý webový informační systém. Datová vrstva obsahuje informace, které jsou potřebné pro korektní implementaci aplikační vrstvy, neboť zahrnuje přesný popis obsahu informačního systému (dat, se kterými systém pracuje). Pro správnou funkci aplikační vrstvy je nutné základní data rozšířit o sémantické informace (význam dat). Pro korektní uložení všech informací je nutné nejprve nalézt dynamickou reprezentaci dat užívaných informačním systémem. Praxe implementace informačního
11.4
Komponenty jednotlivých vrstev
69
systému na MZLU v Brně ukazuje, že vhodnou implementací dynamické reprezentace dat je myšlenka šablonování (Šorm, 2003a). Její výhoda spočívá především v jednoduché implementaci šablonování v původním statickém modelu dat (který užívají dnešní relační a objektové databázové systémy) a v nahrazení původních operací pro definici dat (DDL) operacemi pro modifikaci dat (DML). Tato náhrada operací způsobuje odstranění základní nevýhody původního statického modelu (např. ERD) – neměnnosti struktury datového modelu v čase. Přitom moderní informační systémy mohou získávat nové informace prostřednictvím svých aplikací a tyto informace mohou ovlivnit sémantiku původních či budoucích dat (jejich smysl a tedy i strukturu jejich uložení, pokud vyjádříme sémantiku pomocí způsobu uložení údajů). Příkladem datové komponenty může být například komponenta Student, která vrací údaje o studentovi či studentech. Nad komponentami datových zdrojů lze vytvářet nadstavby. Příkladem může být agregace dat (souhrnný výběr údajů) pomocí nástrojů OLAP či kvalifikace objektů (výběr údajů na základě definovaných kritérií). Obecná kvalifikace objektů UIS MZLU v Brně pomocí soustavy předem definovaných nebo proměnlivých podmínek je detailně zpracována v diplomové práci (Kutín, 2004). Aplikační komponenty Aplikačními komponentami rozumíme vlastní aplikace a jejich součásti. Vzhledem k existenci dynamického systému popisujícího datovou vrstvu informačního systému lze jednotlivé aplikace definovat jako posloupnost transformací nad daty uspořádanými v tomto dynamickém systému. Generovat aplikační vrstvu je tedy možné tehdy, dokážeme-li popsat jednotlivé základní transformace této struktury. Posloupnost těchto transformací je pak vlastností jednotlivých objektů a jim příslušných šablon, představuje tedy sémantický výklad pro manipulace s daty šablonování. Prezentační komponenty Prezentační vrstva představuje samostatný problém, kde musí být řešena řada komplexních otázek týkajících se zejména implementace technologie boxů, variabilního designu, správy zdrojů, navigačních systémů, tvorby zástupných aplikací, definice vzhledu a chování portálu aj. Základem pro tvorbu prezentační vrstvy jsou vyšší obecné komponenty pro tvorbu designu, umožnění personalizace, dále propojení jednotlivých komponent, definice pravidel rozkladu apod. Protože je prezentační vrstva a potažmo uživatelské rozhraní hlavním tématem této práce, rozebereme si tuto problematiku podrobně v samostatné kapitole pojednávající o prezentační vrstvě (kapitola 12).
11.5
Serializace výstupu
11.5
70
Serializace výstupu
Dříve než se budeme věnovat pouze prezentační vrstvě, zmiňme se krátce o tom, jak spolu souvisejí jednotlivé části této kapitoly a jak spolupracují jednotlivé komponenty v rámci celého informačního systému. Průběh transformace otázky na odpověď je možné rozdělit do dvou částí. Prvním krokem je zpracování požadavků relace, kdy jednotlivým komponentám ve stromu je nutné nabídnout všechny předané parametry otázky, aby mohla být provedena požadovaná operace. Druhým krokem je pak příprava odpovědi, kdy jsou vytvořeny nové výstupní údaje, nové formuláře a texty, a ty jsou připraveny na zobrazení. I v této části bývají využity parametry otázky upravené o příslušné změny provedené v předchozím kroku společně s parametry formujícími výstup. Hlavní roli zde hrají aplikační komponenty, které spolupracují jak s datovou, tak s prezentační vrstvou. Datové vrstvě předávají parametry s požadavky na provedení operací, přijímají odpověď (výstup) datových komponent, tu obalují aplikační logikou a předávají dál vrstvě prezentační. Zde je k aplikačnímu výstupu přidán design a celá odpověď je zaslána uživateli. Protože komponenty jednotlivých vrstev netvoří lineární, ale stromovou strukturu, je výsledek sestavován podle pravidel definujících vzájemné závislosti komponent v rámci každé vrstvy. Výstupem (odpovědí) celého procesu generování jedné stránky aplikace webového informačního systému je tedy souvislý dokument. Aby bylo možné tento dokument vygenerovat, je nutné serializovat jednotlivé komponenty stromové struktury, z nichž je dokument vytvořen. Znamená to nalezení jednoznačného průchodu stromem po všech komponentách všech vrstev systému a sestavení odpovídající výstupní sekvence.
12
12
ROZBOR KOMPONENT PREZENTAČNÍ VRSTVY
71
Rozbor komponent prezentační vrstvy
Dosud jsme hovořili o obecných vlastnostech informačního systému a o metodice pro tvorbu nové generace webových informačních systémů. Nyní se podívejme podrobněji na problematiku prezentační vrstvy. Pro ujasnění pojmů je třeba si prezentační vrstvu definovat a určit její složky. Jak již bylo zmíněno v kapitole 5.3, prezentační vrstva je nejvyšší vrstvou modelu třívrstvého informačního systému, zajišťuje vstup požadavků uživatele a prezentaci výstupních dat. Při podrobnějším pohledu můžeme dále tuto vrstvu rozdělit na složku přípravnou a zobrazovací. Schéma prezentační vrstvy je znázorněno na obrázku 7.
Obr. 7: Schématické znázornění složek prezentační vrstvy
Přípravná složka prezentační vrstvy komunikuje s vrstvou aplikační a jejím úkolem je připravit konečný formát výstupních dat zobrazovaných uživateli. V této složce se odehrává veškerá logika prezentační vrstvy. Zobrazovací složka vrstvy je představována lehkým klientem uživatele – prohlížečem webových stránek pro příslušné zobrazovací zařízení (platformy, prostředí). Obě složky se společně podílejí na komunikaci uživatele s informačním systémem, můžeme tedy říci, že prezentační vrstva je shodná s pojmem uživatelské rozhraní. prezentační vrstva = uživatelské rozhraní Protože zobrazovací složku vrstvy nemůžeme při tvorbě informačního systému nijak ovlivnit (závisí pouze na výstupním zařízení a programovém vybavení uživatele), budeme dále v této práci používat pojmy prezentační vrstva či uživatelské rozhraní jako synonyma pro přípravnou složku prezentační vrstvy.
12.1
72
Komponenty uživatelského rozhraní
12.1
Komponenty uživatelského rozhraní
Princip boxů v component boxing modelu hovoří o rozkládání a opětovném skládání stránky z komponent. V terminologii následujících kapitol používáme slovo komponenta jako synonymum k termínu prvek, element. Nejsou jím myšleny striktně komponenty ve smyslu standardizovaných prvků vrstev informačního systému, jak jsou definovány na str. 67. Prvním předpokladem úspěšného užití CBM při implementaci informačního systému je nalezení vhodného způsobu rozvrhování stránky do boxů. Nyní se v našich úvahách omezme na jednu stránku informačního systému. Uživatelské rozhraní webového informačního systému je pak tvořeno pravoúhlou stránkou s informacemi, kterou lze dále rozložit na sadu významově podobných pravoúhlých oblastí (např. záhlaví, zápatí, navigační menu, odstavce textu, části formulářů), ty mohou obsahovat další vnořené oblasti. Rozklad končí, nalezneme-li nejmenší jednotku, která se již dále nedělí. Jako příklad jednoduchého dělení stránky si zopakujeme obrázek ze strany 67.
Obr. 8: Jednoduché rozdělení stránky IS
Definice typů komponent Box (B) je pravoúhlá oblast stránky, skládající se ze dvou částí – obsahu (O) a designu (D). B(O, D) Obsah boxu (O) je představován dalším boxem nebo vizuálním prvkem (VP). O(B k VP )
12.2
73
Nalezení komponent stránky
Vizuální prvek (VP) je reprezentován dále nedělitelným obsahem boxu. Designem boxu (D) rozumíme atributy nesoucí informace o způsobu vykreslení boxu. Design představuje způsob prezentace obsahu. Při podrobnějším pohledu lze i design popsat dvojicí hodnot – grafické prvky (G) a popisné prvky (P), kde grafické prvky jsou reprezentovány barvami, typy písma, typy grafických prvků, popisné prvky jsou dále složeny z rozměrů (R) a umístění (U). D(G, P ) kde P (R, U ) Tyto definice jsou potřebné pro vytvoření stromu jednotlivých komponent stránky. Nyní se na tuto problematiku podívejme z praktického úhlu a definujme prvky, z kterých je složena stránka reálného informačního systému.
12.2
Nalezení komponent stránky
Při hledání jednotlivých komponent stránky si lze položit následující otázky, jejichž zodpovězení pomůže najít hledané objekty a závislosti mezi nimi. • Jak rozdělit stránku do komponent? • Objevují se na stránce typické útvary? • Existují typické podstromy stromů skládaných z komponent? • Je možné zobecnit rozdělení každé stránky? Zkusme se podívat na několik různých stránek informačního systému. Vzhledem k tomu, že typy prezentovaných dat se liší podle tematického zaměření systému, začneme u nám blízkého prostředí informačního systému univerzity. Na obrázku 9, 10 a 11 jsou ukázky obrazovek Univerzitního informačního systému Mendelovy zemědělské a lesnické univerzity v Brně (dále Univerzitní informační systém, UIS). Za prvek nejvyšší úrovně, tedy kořen stromu, můžeme považovat celou stránku. Na stránce je jednoznačně určené záhlaví, zápatí a tělo stránky. Záhlaví je tvořeno lištou s logem Univerzitního informačního systému a dvěma úzkými lištami nad a pod hlavní lištou. Horní lišta obsahuje dvě části – sadu informačních a navigačních prvků, stejně jako dolní lišta, jejíž obsah se však mění podle kontextu, v němž se nacházíme. Informační a navigační prvky lze dále rozložit na ikonu a text, není však povinné, aby obsahovaly obě tyto položky současně. Podle předchozích definic představují ikony a texty příslušné vizuální prvky, všechny ostatní nadřazené komponenty jsou představiteli boxů. Zápatí, na uvedených příkladech nejjednodušší, se dále skládá z jednoho nebo více zpětných odkazů, uzavírací lišty s kontaktními odkazy a případně poznámky nesoucí další doplňující informace. Lišta představuje dále se dělící komponentu, ostatní objekty reprezentují vizuální prvky zápatí. Tělo stránky je komponentou nejsložitější. Obsahuje v podstatě všechny významové informace zobrazené na stránce. Podle povahy informačního systému nebo
12.2
Nalezení komponent stránky
74
Obr. 9: Příklad stránky UIS – úvodní strana
podle zobrazovaných informací lze tělo stránky dělit dále do menších významových (např. menu, oblast pro zadávání vstupních dat, zobrazování výsledků) i vizuálních (formulář, tabulka, odstavec) celků. V libovolné úrovni hierarchického stromu komponent se pak dostáváme k vizuálním prvkům (nadpis, nápovědný text, položka portálového menu, položka formuláře, odesílací tlačítko ve formuláři apod.). Při komponentovém rozkladu stránky tedy vidíme, že kombinujeme dva přístupy: logický a vizuální. Z logického pohledu dělíme stránku na celky, které jsou odvozené od typu informačního systému (stránky) a prezentovaných informací. Z pohledu vizuálního je stránka tvořena prvky určujícími, jak se bude daná informace prezentovat. Tyto prvky mohou být odvozeny např. ze značek jazyka HTML. Z uvedeného příkladu je zřejmé, že se komponenty mohou dělit na povinné, volitelné a vázané. • Mezi povinné komponenty zařazujeme stránku, záhlaví, zápatí a tělo stránky. • Ostatní komponenty jsou volitelné, jejich případný povinný výskyt však může být vynucen povahou předkládané informace na stránce. • Vázané komponenty jsou takové, které jsou sice volitelné, ale nemohou stát samostatně (např. textové pole pro vyhledávání a tlačítko „Dohledatÿ by jeden bez druhého neměly smysl).
12.2
75
Nalezení komponent stránky
Obr. 10: Příklad stránky UIS – vyhledávání předmětů v katalogu
Vázané prvky Jak jsme se zmínili dříve, některé objekty na stránce spolu mohou souviset a zobrazení jednoho objektu bez druhého postrádá smysl. Dobře viditelné je to na příkladu webového formuláře, kdy jednotlivé položky formuláře musí být logicky zakončeny odesílacím tlačítkem nebo naopak toto tlačítko postrádá smysl, když nemá co odesílat. Vázané prvky můžeme rozdělit na obousměrně a jednosměrně vázané: • Obousměrně vázané jsou takové prvky A, B, které nemohou stát jeden bez druhého, a to v obou směrech. Příkladem je výše uvedený případ s webovým formulářem. A⇔B • Jednosměrně vázané prvky A, B jsou pak takové, kde jeden prvek potřebuje ke své existenci prvek druhý, ale opačně to neplatí. Například nadpis kapitoly a odstavec textu. Nadpis kapitoly nemůže (nebo by alespoň neměl) stát samostatně, text bez nadpisu je však přípustný. A⇒B Vázanost jednotlivých prvků (obousměrně i jednosměrně vázaných) lze definovat jako pevnou a volnou: • Pevná vázanost je taková, kdy existuje vazba mezi dvěma přesně danými prvky A, B. Příkladem jednosměrné pevné vazby může být ikona v záhlaví předsta-
12.2
76
Nalezení komponent stránky
Obr. 11: Příklad stránky UIS – úvodní stránka subsystému workflow
vující datum a čas, která je pevně vázána s textem popisujícím aktuální datum a čas (i když obráceně to platit nemusí). A⇔B event. A⇒B • Volná vázanost představuje častější případ, kdy se obecně libovolný prvek Ai z jedné skupiny váže k libovolnému prvku Bi ze skupiny jiné. Zůstaneme-li u příkladu s formulářem, libovolná formulářová položka může být doplněna potvrzovacím tlačítkem nebo tlačítkem pro smazání údajů (příklad obousměrné volné vazby). (A1 k A2 k A3 k . . . k An ) ⇔ (B1 k B2 k B3 k . . . k Bn ) event. (A1 k A2 k A3 k . . . k An ) ⇒ (B1 k B2 k B3 k . . . k Bn )
12.3
Popis rozkladu stránky
12.3
77
Popis rozkladu stránky
Při rozkladu stránky postupujeme tak, že procházíme jednotlivé prvky stromu od kořene až k listům, přičemž pro potřeby rozkladu si všímáme pouze složky obsahové. Design komponenty se uplatňuje při operaci opačné, tedy při skládání stránky do výsledného výstupu, proto jej prozatím ponechme stranou. Nyní si probereme podrobně rozklad do stromu komponent. Základní prvky Jak bylo uvedeno v předcházející kapitole, základními prvky každé stránky, jež považujeme za kořen stromu, jsou tři komponenty: záhlaví, tělo stránky a zápatí (obrázek č. 12.
Obr. 12: Základní komponenty stránky
Kořenovým objektem je tedy objekt Stránka, který musí být typu box. Jeho tři povinné složky jsou Záhlaví, TěloStránky a Zápatí. Záhlaví Komponentu Záhlaví (obrázek č. 13) je možné rozložit do tří složek: horní a dolní lišty a pole s názvem (případně logem) informačního systému. Objekty HorníLišta a DolníLišta se dělí dále, objekt PoleSNázvem je listem stromu, jeho obsahem je tedy vizuální prvek, nikoli další box.
Obr. 13: Záhlaví stránky – základní rozklad
12.3
78
Popis rozkladu stránky
Komponenta HorníLišta (obrázek č. 14) je tvořena čtyřmi podsložkami: sadou odkazů Odkazy a přepínačem jazyka Jazyk, které představují vizuální prvky, a dále dvěma boxy: indikátorem data a času DatumČas a zobrazením jména, které slaví jmeniny Svátek. Protože komponenty DatumČas a Svátek jsou tvořeny vždy ikonkou a textem, obě komponenty lze dále rozdělit na dva listové prvky Ikona a Text.
Obr. 14: Horní lišta záhlaví stránky
Komponenta DolníLišta (obrázek č. 15) je nejsložitější komponentou záhlaví. Jako jediná se také zobrazuje rozdílně (je složena z různého počtu vnořených prvků) v závislosti na kontextu. Ve veřejné části informačního systému je dolní lišta velmi jednoduchá, neboť obsahuje pouze jeden vnořený box Navigace, který je tvořen vizuálními prvky Nahoru a Domů. Podle aplikace, ve které se v informačním systému nacházíme, může být přítomen třetí vizuální prvek Zpět. Uživatel přihlášený do systému má dolní lištu obohacenu o další komponenty. Vizuální prvek Uživatel zobrazuje jméno přihlášeného uživatele. Prvek Služby zahrnuje tři odkazy představované ikonami, které umožňují změnu identity uživatele (ZměnaUživ), odhlášení uživatele ze systému (Odhlášení) a nastavení tiskového subsystému (NastavTisku). Na stejné úrovni s komponentou Služby stojí prvek Subsystémy, nabízející přímý přechod do některých subsystémů informačního systému: do poštovní schránky (Pošta), Dokumentového serveru (DS) a workflow systému zvaného TODO (TODO). Tyto tři komponenty jsou představovány boxy, které se skládají ze dvou vizuálních prvků Ikona a Text. Uvedený rozklad popisuje současný stav záhlaví informačního systému. Pro dosažení maximální variability, lze bez ztráty informací připustit následující úpravy: • Jednotlivé komponenty představující konečné prvky stromu mohou být tvořeny ikonou, textem nebo obojím. • Komponenty horní a dolní lišty lze kombinovat. • Není nutné striktně dodržovat významové seskupení komponent (např. ikony služeb, odkazy do subsystémů).
12.3
79
Popis rozkladu stránky
Obr. 15: Dolní lišta záhlaví stránky
Na základě logického pohledu na záhlaví lze jednotlivé prvky rozdělit do dvou kategorií, na povinné a volitelné. Povinné prvky mají svůj pevný význam a není možné je vynechat. Bez prvků volitelných by se nezměnil význam ani kontext nadřazené komponenty systému, je proto možné je obměňovat, přidávat či ubírat. Záhlaví lze poté zjednodušit na výčet komponent uvedených v tabulce č. 1. Zápatí Základní rozklad objektu Zápatí (obrázek č. 16) je tvořen dvěma komponentami – sadou zpětných odkazů ZpětnéOdkazy a uzavírací lištou Lišta. Box ZpětnéOdkazy se dále rozkládá na jeden nebo více konkrétních textů se zpětnými odkazy, jež vedou zpravidla do nadřazených aplikací systému, jejich tvar a počet se liší dle aktuální aplikace. Druhý prvek Lišta je trvale složen ze dvou odkazů – na úvodní stránku informačního systému Domů a kontaktu na vývojový tým VývojTým. Komponenty zápatí je opět možné označit za povinné či volitelné. Ze schématu a z logiky přítomných komponent je zřejmé, že některé typy prvků se mohou opakovat – takové prvky nazvěme násobné. Příkladem je objekt zpětných odkazů, může být reprezentován jedním nebo více konkrétními odkazy.
12.4
80
Typy stránek informačního systému
Část systému
Veřejná a soukromá
Soukromá
Komponenta Pole s názvem Přepínač jazyka Navigace (nahoru, domů, příp. zpět) Sada odkazů s texty Datum a čas Svátek Indikace uživatele Změna identity Odhlášení Nastavení tisku Odkaz do pošty Odkaz do DS Odkaz do TODO
Povinnost ano ano ano ne ne ne ano ne ne ne ne ne ne
Tab. 1: Komponenty záhlaví – shrnutí
Aplikováním stejného pravidla pro zjednodušení výčtu komponent jako u záhlaví získáváme přehled uvedený v tabulce č. 2. Část systému Veřejná a soukromá Soukromá
Komponenta Zpětné odkazy Vývojový tým Domů Dodatečné informace
Povinnost ano ano ano ano
Násobnost ano ne ne ano
Tab. 2: Komponenty zápatí – shrnutí
Tělo stránky Popsat rozklad záhlaví a zápatí informačního systému bylo poměrně jednoduché a jednoznačné. Chceme-li stanovit podobným obecným způsobem tělo stránky, zjistíme ovšem, že nelze jednoznačně určit společné komponenty nacházející se na všech stránkách. Tělo stránky je závislé na svém obsahu. Proto nejprve definujme typy stránek informačního systému.
12.4
Typy stránek informačního systému
Při rozkladu stránek informačního systému a hledání obecného modelu můžeme definovat dva druhy dělení stránek. Dělení svislé a dělení typové. Svislé dělení souvisí s definicí prvků na stránce a je závislé na dělení typovém, které říká, jaké typy stránek informační systém obsahuje.
12.4
Typy stránek informačního systému
81
Obr. 16: Zápatí stránky
Index (nabídka) Základním a nejjednodušším typem stránky je stránka typu index, můžeme ji nazvat také nabídka. Jedná se o typickou úvodní stránku obsahující odkazy do dalších částí systému. Tyto odkazy jsou zpravidla seskupeny pro větší přehlednost do významových sekcí. Typickými představiteli indexů jsou úvodní stránka systému, Osobní administrativa, ale i některé „vnořenéÿ rozcestníky, např. agenda studijního oddělení, kolejní administrativa apod. Formulářová aplikace Velmi rozšířeným typem aplikací jsou tzv. formulářové aplikace. Příchod formulářů v UIS představoval krok kupředu ve vývoji systému (více v kapitole 14.2 o genezi UIS). Formulářové aplikace obsahují standardizované komponenty s typickým vzhledem a chováním. Stránky zobrazující tento typ aplikací zahrnují zobrazovací, přidávací a editační formulář – tyto komponenty jsou povinné. Dále zpravidla obsahují také prohlížecí formulář, případně podle kontextu i odkaz na formuláře pro prohlížení a editaci šablon, včetně těchto komponent.
12.4
Typy stránek informačního systému
82
Vstupní filtry k aplikacím Dalším často užívaným typem stránek jsou stránky uvozující některé aplikace, které můžeme souhrnně nazvat vstupní filtry k aplikacím. Podle typu aplikace a kontextu, ve kterém se nacházejí, lze definovat různé typy filtrů: • Velká loga fakult – představují typický výběr fakulty (přesněji pracoviště na úrovni fakulty) v aplikaci, která pracuje nad všemi fakultami (nebo jejich podmnožinou), uživatel však může pracovat pouze s jednou fakultou v jednom okamžiku. Filtr je tvořen klikatelnými logy fakult seřazenými zpravidla do dvou, ale i více či méně řádků. • Dohledání hodnot – vstupní filtr je tvořen textovým polem pro zadání hledaného vzorku, po stisknutí tlačítka pro dohledání se vyhledají odpovídající údaje. Pokud je výsledek hledání jednoznačný, provede se přímo předání výsledku, v opačném případě je zobrazen klikatelný seznam vyhovujících údajů pro další výběr. Tyto filtry jsou používány zejména pro dohledávání osob v evidenčních aplikacích, dohledávání číselných kódů apod. • Vstup do portálu – stránka zpravidla obsahuje tabulku se seznamem položek konkrétního typu (podle portálu, který uvozuje), podstatný je odkaz na výběr jedné položky a předání této položky jako parametr pro vstup do portálu. Položku představuje například předmět v Záznamníku učitele, projekt v Záznamníku výzkumníka apod. • Výběr parametru – filtr je používán zejména při výběru časového období, studia apod., tedy při výběru konkrétního parametru, s nímž pracují další aplikace, kterým se parametr předává. Lze nalézt jistou analogii s filtrem pro vstup do portálu, typ výběr parametru však bývá zpravidla jednodušší. U některých typů filtrů je výhodné (a uživatelům značně usnadňuje práci), pamatuje-li se poslední hodnota filtru, kterou každý uživatel nastavil. Ten si totiž zpravidla nastaví obor hodnot, který jej zajímá, a vyhne se tak opakovanému výběru z dlouhého a někdy nepřehledného seznamu všech možných položek. Je však třeba rozhodnout, kde má „pamatování siÿ poslední hodnoty význam a kde ne. Diskutovat lze také přednabízení poslední použité nebo nejčastěji použité hodnoty parametru. Evidenční aplikace Evidenčními aplikacemi rozumíme zejména aplikace pro evidenci osob. Tyto aplikace můžeme rozdělit do dvou stránkových podtypů. Prvním podtypem je výběr hledané osoby; jedná se o vstupní filtr popsaný výše. Druhým podtypem pak je zobrazení stránky vyhledané osoby včetně údajů a sady ikon představující odkazy na operace, které lze provádět. Lze tedy vidět, že typy aplikací lze do sebe vzájemně vnořovat. Díváme-li se však pouze na typy stránek z pohledu generování objektů stránky, pak se můžeme bez ztráty významu omezit na typický druhý podtyp – zobrazení údajů o osobě.
12.5
Svislé dělení stránek
83
Představiteli evidenčních aplikací jsou například aplikace pro správu osob nebo studijní evidence. Za jednodušší variantu lze považovat i stránku se základními údaji o každém uživateli UIS. Velké portálové aplikace Velké portálové aplikace, stejně jako předcházející Evidenční aplikace, navazují na stránku se vstupním filtrem. Po výběru parametru pro vstup do portálu (předmět, projekt, pracoviště apod.) se dostáváme do portálových aplikací, které mají společné horizontální menu (záložky) pod názvem portálu. Toto menu spojuje všechny související aplikace v portálu, jedná se o odkazy na jednotlivé stránky. Menu lze považovat za samostatnou komponentu, zbytek stránky můžeme definovat jako tělo stránky a zde opět určovat typ stránky podle typologie popsané výše. Představiteli portálových aplikací jsou například Záznamník učitele, Záznamník výzkumníka (vědeckovýzkumný portál), Dokumentový server či Portál SIF a OSSA. Shrnutí Je možné říci, že zhruba 75 % stránek je zařaditelných do některého z výše uvedených typů. Zbývajících 25 % jsou stránky specifických aplikací, které díky jedinečnosti řešené problematiky mají svůj vlastní design a je třeba je ošetřit samostatně. Může se také jednat o starší aplikace, vyvinuté před zavedením jednotné koncepce uživatelského rozhraní a většinu z nich je možné převést je do současného standardu.
12.5
Svislé dělení stránek
Svislé dělení představuje druhý typ dělení stránek. Abychom mohli pokračovat v rozkladu stránky z kapitoly 12.3, definujeme nyní komponenty, které mohou tvořit tělo stránky. Jak je z předchozího výkladu zřejmé, na stránce se podle kontextu mohou vyskytovat libovolné objekty. Tyto objekty jsou opět logicky uspořádány do stromové struktury, mezi jednotlivými prvky je nutné definovat logické závislosti. Počet úrovní hierarchie objektů je různý v závislosti na složitosti daného objektu. Tato složitost je určena: 1. Informační hodnotou – informací či posloupností dat, kterou daný objekt přináší uživateli. V logické závislosti na tom, jaká data objekt zobrazuje (sděluje uživateli), může být počet potomků jednoho typu objektu různý. Uveďme jako příklad tabulku. Ta se zpravidla skládá z řádků a sloupců, obsahuje záhlaví a buňky zobrazující data. Jestli však budou přítomny všechny objekty, v jakém počtu a co bude jejich obsahem, je určeno kontextem umístění tabulky v rámci informačního systému. Tabulka může být tvořena záhlavím, pěti řádky a třemi sloupci, ale také záhlaví ani řádky nemusí obsahovat vůbec a může sloužit jako formátovací prvek pro zarovnání údajů do sloupců. Stejně tak se podle kontextu
12.6
Sestavení výstupu
84
liší i data zobrazovaná v elementárních prvcích tabulky – v buňkách. Součástí jedné buňky může být atomický (dále nedělitelný) vizuální prvek, ale i další vnořená tabulka, odkaz či jiný složený objekt. 2. Způsobem vyjádření – způsobem, jak daný objekt zobrazujeme na stránce a nastavením vlastností objektu. Zde vycházíme z HTML popisu objektu a jeho atributů, opomenout nelze ani logicky správné zobrazení objektu (viz vázané komponenty v kapitole 12.2). Například zadávací formulář pro získání údajů od uživatele obsahuje alespoň jeden z typů vstupních polí (textové pole, zaškrtávací políčka, rozbalovací nabídku atd.), dále je nutné přidat odesílací tlačítko, bez kterého by celý formulář postrádal smysl. Vhodné je též připojit uvozující text, který říká, co vlastně uživatel zadává. Tento text může stát samostatně jako nápověda před formulářem, ale také může přímo stručně uvozovat formulářovou položku. Nejtypičtější složené objekty vyskytující se na stránkách informačního systému jsou: • obecné tabulky zobrazující údaje (záhlaví, řádky, sloupce, jednotlivé buňky), • formuláře na vkládání dat, • portálové menu (horizontální záložky), • skupiny nabídek (klasické menu), • legenda. Při rozkladu těchto složených objektů se po konečném počtu kroků dostaneme k elementárním prvkům: • text (obyčejný, nápovědný, nadpis), • obrázek, • odkaz, • doplňující grafické prvky (např. vodorovná čára). Proveďme nyní úplný rozklad těla stránky podle obrázku č. 17. Při vykreslování stránky postupujeme shora dolů, bereme posloupnost jednotlivých komponent. Konkrétní prvky a postup jejich rozkladu je zachycen v tabulce č. 3. Uvedeným rozkladem stále popisujeme obsahovou stránku dat, nikoli designovou. Jinak řečeno, máme nyní definováno co zobrazujeme, ale ne jak to zobrazujeme. Design začíná být důležitý v okamžiku sestavování výstupu pro uživatele.
12.6
Sestavení výstupu
Sestavení výstupu pro uživatele je opakem operace rozkladu a je řízeno vlastními pravidly. Stránka, jež je zasílána uživateli na výstup, je tvořena na základě průchodu stromem komponent. Způsobem, jakým jsme popsali rozklad v předcházejících kapitolách, jsme vytvořili uspořádaný strom komponent, proto pro sestavení odpovídajícího a správného výstupu stačí pouze projít všechny prvky stromu podle obecných pravidel pro průchod stromem, od nejlevějšího listu levého podstromu po
12.6
Sestavení výstupu
85
Obr. 17: Příklad těla stránky pro úplný rozklad
nejpravější větev stromu (úhel pohledu je samozřejmě relativní, stejně tak je možné procházet strom shora dolů, a kopírovat tak přesně směr rozkladu v tabulce č. 3). Vždy se prochází listy daného předka, tyto listy představují podřazené komponenty. Skládají se dohromady komponenty v jedné větvi na stejné úrovni, přičemž se postupuje od nejnižší úrovně a zleva. Posledním krokem je složení výsledného výstupu (kořene stromu) z jeho přímých potomků. Průchod stromem je zobrazen na obrázku č. 18, čísla v uzlech znázorňují pořadí průchodu jednotlivými prvky. V okamžiku, kdy narazíme na dále nedělitelnou komponentu, podle naší terminologie na vizuální prvek (viz kapitola 12.1), přidáme k obsahu prvku jeho design, tzn. atributy nesoucí informace o způsobu vykreslení prvku. Prvek, skládající se z obsahu a designu, pak tvoří box. Tento box je předán svému předchůdci ve stromové hierarchii, kde představuje obsahovou složku tohoto nadřízeného prvku. K té je přidán design daného prvku a celý postup se opakuje. Pokud neexistuje žádný další předchůdce v příslušném podstromu, je větev považována za kompletní a skládání pokračuje od následujícího levého podstromu. Sestavením výstupu z poslední pravé větve stromu a sloučením výsledků všech větví stromu je celá stránka kompletní a je odeslána uživateli.
12.6
86
Sestavení výstupu
• • • • •
Text nadpisu Vodorovná čára Text nápovědný Text tučný Filtr na omezení dostupné množiny hodnot – Text obyčejný – Rozbalovací menu – Odesílací tlačítko • UIS formulář (kombinace tabulky a zadávacího formuláře) – Tabulka s vnořeným formulářem ∗ Záhlaví tabulky · Buňky (text) ∗ Řádky tabulky · Buňky (zaškrtávací políčko, text obyčejný, odkaz – ikona/text) – Text nápovědný – Odesílací tlačítko • Pokračování dalších objektů na stránce . . . Tab. 3: Rozklad těla stránky do komponent
Stupně definice designů Doposud jsme hovořili o rozkladu obsahu stránek do jednotlivých komponent, mluvili jsme také o tom, že každá komponenta má kromě svého obsahu i vlastní design. Tento design doplňuje obsah komponenty při skládání výstupu (odpovědi uživateli). Existuje několik způsobů, jak lze pracovat s designem. Vedle typu zobrazovaných dat má na mechanismus připojování designu vliv zejména typ a způsob uložení designových atributů. • Design tvořený na aplikační úrovni – nejjednodušší, ale nejméně obecný způsob definice vzhledu komponent. Určování designu na úrovni jednotlivých aplikací je v rukou aplikačních programátorů, dochází k nejednotnosti a značné roztříštěnosti celkového vzhledu. Lepší variantou definice designu na aplikační úrovni je umístění popisu jednotlivých komponent do programových modulů, které jsou využívány jednotlivými aplikacemi. Popisné atributy jsou tak soustředěny na jednom místě a jejich použití je v rámci celého systému jednotné. Ani jeden z uvedených způsobů však nelze doporučit z pohledu celkové koncepce informačního systému. Zakomponování designu jako celku do aplikační úrovně znemožňuje jakékoliv nastavení či ovlivnění designu uživateli a de facto je v rozporu s komponentovým pojetím systému.
12.6
87
Sestavení výstupu
Obr. 18: Průchod obecným stromem
• Typ zobrazovaných dat – do programových modulů je naopak vhodné zařazovat popis způsobu vyjadřování obsahu komponent, určovat pravidla pro skládání závislých a vázaných prvků. Jako příklad můžeme uvést funkci na zobrazení tabulky, která obsahuje vnořený vstupní formulář, okolo jsou popisky, pod tabulkou odesílací tlačítko. V závislosti na parametrech, s jakými je funkce volána z konkrétní aplikace, je schopná splnit požadavky na zobrazení jednoho typu dat v různých kontextech. • Definice stylů – pokud chceme oddělit obsah dat a způsob jejich zobrazování, je vhodné použít styly, které definují designové atributy jednotlivých prvků. Optimální je použití kaskádových stylů. Tyto styly mohou být v podobě textových souborů uloženy na disku nebo jako textové položky v databázi (např. CLOB – Character Large Object). Uchovávání stylu v databázi podporuje koncepci personalizovatelného přístupu k uživatelskému rozhraní. Uživatelům se otvírají možnosti vytváření vlastních kaskádových stylů a jejich jednoduchá správa (samozřejmě za předpokladu, že je toto podporováno jádrem informačního systému). • Definice komponent stránky a uživatelských polí – jednotlivé stránky jsou rozděleny do polí, které popisují strukturu zobrazovaných objektů na stránce. XML předpisy pro jednotlivá pole stanovující jejich atributy mohou být uloženy, stejně jako kaskádové styly, v textových souborech nebo lépe přímo v datové vrstvě v databázi, což umožňuje opět větší variabilitu systému. • Definice obrázků a jejich mapování – stránky informačního systému jsou samozřejmě doplněny obrázky, ať už významovými nebo dekorativními. Všechny obrázky jsou uloženy ve skladu obrázků, kde jsou tematicky roztříděny do kategorií. Používání obrázků v rámci informačního systému je jednotné, pro analo-
12.6
Sestavení výstupu
88
gické operace v různých aplikacích se používají stejné ikony. Každý obrázek má atribut mapování, který udává, zda je povoleno tento obrázek „přemapovatÿ, tzn. zda uživatel může všechny jeho výskyty nahradit obrázkem vlastním. Z uvedeného popisu vyplývá, že čím více a čím efektivněji je oddělen design od vlastního obsahu, tím jednodušší je také z pohledu vývojářů přizpůsobování systému různým změnám, doplňování nových funkcí a komponent, a tím i variability systému. Na základě kvalitního návrhu je pak uživatelům nabízen vysoký stupeň personalizace systému. Složení designu a obsahu komponent Tak, jak jsme v předchozích kapitolách definovali podrobný rozklad stromu komponent (rozbor komponent 12.1 a rozklad stránky 12.3), se nyní podívejme na rozbor opačného procesu, a tím je složení obsahu a designu jednotlivých komponent a sestavení výstupu dle návazností ve stromové struktuře určené rozkladem. Schéma vzájemného skládání boxů je na obrázku č. 19. Skládání začíná od nejnižší úrovně hierarchie, na obrázku je znázorněno shora dolů. Skládání stromu začíná u nejlevějšího vizuálního prvku (listu) levého podstromu. Vezme se jeho obsah a k němu se přidají všechny designové prvky (rozměry, umístění a grafické prvky). Takto je vytvořen box, který je předán jako obsahová složka svému nadřazenému boxu (přímému předchůdci v hierarchii). V nadřazeném boxu se spojí podřízené boxy ze všech vnořených větví, přidá se případný obsah vlastního boxu, a tím je vytvořena obsahová složka. K té jsou opět přidány designové prvky a box je sestaven a předán svému předchůdci. Tento postup se opakuje, dokud nejsou sestaveny všechny větve stromu. Z prvků nejvyšší úrovně hierarchie je pak sestaven výsledný výstup podle stále stejného algoritmu. Obsah boxu představují konkrétní data, která se objeví ve výsledném výstupu. Původ těchto dat může být v datové i aplikační vrstvě, pro nás to však není podstatné, neboť do prezentační vrstvy přicházejí jako data předaná vrstvou aplikační s příznakem, že představují obsahovou složku. Jinými slovy říkají, co bude zobrazeno na výstupu. Design boxu je na rozdíl od jednoduchého obsahu tvořen několika položkami: • rozměry komponenty, • umístěním komponenty v rámci boxu, • grafickými prvky. U grafických prvků musíme rozlišovat informace vztahující se ke konkrétní komponentě (říkají, jak má být zobrazen obsah daného prvku) a informace přebírané z globálního nastavení designu. Přednost mají přímá nastavení komponent, globální prvky jsou dosazeny za chybějící lokální atributy. Design boxu tedy říká, jak bude výstup zobrazen.
12.6
89
Sestavení výstupu
Obr. 19: Schéma vzájemného skládání boxů
13
UPLATNĚNÍ KOMPONENTOVÉHO PŘÍSTUPU
13
90
Uplatnění komponentového přístupu
Využití komponentového přístupu při analýze a návrhu informačních systémů přináší nový způsob jejich vývoje a implementace. Je zřejmé, že obdobným způsobem, jakým jsme v předchozích kapitolách popsali podrobný rozklad a pravidla skládání uživatelského rozhraní, lze analyzovat i aplikační a datovou vrstvu systému a nalézt komponenty těchto vrstev včetně vazeb mezi nimi a pravidel pro jejich vzájemnou komunikaci.
13.1
Realizace úloh prezentační vrstvy
Zůstaneme-li u prezentační vrstvy, jejím úkolem je zajištění veškerých operací souvisejících s uživatelským rozhraním, prezentací údajů, realizováním osobních nastavení atd. Zabezpečuje jednak komunikaci s uživatelem (zobrazování dat a reakce na události zadané uživatelem), tak i komunikaci s vrstvou aplikační, které předává požadavky na aplikační zpracování a přijímá výstupy pro zobrazení. Mezi hlavní úkoly prezentační vrstvy patří: • struktura portálu, • realizace designu, • správa zdrojů, • správa šablon a obsahu komponent, • navigační systém, • vícejazyčnost, • personalizace. Bez komponentového pojetí informačního systému by byla řada z uvedených úloh obtížně proveditelná, některé pouze se značnými omezeními. Podívejme se nyní na přínosy komponentového přístupu pro realizaci úloh prezentační vrstvy. Struktura portálu Mechanismus rozkladu a skládání komponent popsaný v předchozí kapitole umožňuje prezentovat jak jednoduché stránky či dokumenty, tak i údaje z informačních systémů nebo dokonce skládat jednotlivé informační systémy do integrovaných portálových aplikací. Po stránce prezentační se jedná o stále stejný princip, což přináší řadu nových možností, zejména ve znovupoužitelnosti jednotlivých komponent a personalizace. Realizace designu Oddělením obsahové a designové složky jednotlivých komponent je možné dosáhnout naprosto nezávislého způsobu prezentace obsahu a formy dat. V první fázi jde o oddělení aplikační a prezentační logiky zobrazovaných dat. Z toho následně vyplývá fakt, že stejný obsah může být formován různými designovými předpisy. Tím
13.1
Realizace úloh prezentační vrstvy
91
lze dosáhnout stavu, kdy volba výsledného zobrazení závisí přímo na zobrazovacím zařízení, na preferencích uživatele či na implicitním nastavení systému (případně na kombinaci uvedených skutečností). Není pak problém používat různé designy při práci s informačním systémem a implementovat škálu variabilních designů, jak bylo popsáno v kapitole 10.3. Správa zdrojů Správa zdrojů úzce souvisí s realizací designů a zajišťuje ji tzv. resource manager (manažer zdrojů). Je to nástroj prezentační vrstvy zajišťující veškerou evidenci používaných designových komponent (barev, písem, obrázků, kaskádových stylů, JavaScriptových kódů apod.). Jednotlivé kategorie jsou členěny do menších celků, a tím je dosaženo snadné orientace a manipulace s jednotlivými komponentami (např. zakládání, editace, rušení). Správa šablon Jednotlivé boxy Component boxing modelu představují samostatné celky, lze si je však představit jako objekty patřící do tříd (kategorií), které mohou v závislosti na kontextu dědit (nebo mít společné) některé vlastnosti. Proto je výhodné pro tyto logické celky definovat šablony, které je možné opětovně používat buď přímo nebo se změnou chování v závislosti na předaných parametrech. Tento princip je opět přenositelný (díky standardnímu chování) na libovolné části stránky (designu). Pomocí šablon můžeme vytvářet jednotnou „kostruÿ komponent, a tím značně zjednodušovat operace s designovými prvky. Navigační systém Navigační systém můžeme chápat dvěma způsoby – jako systém tlačítek, které nám umožňují pohodlnou, rychlou a jasnou navigaci, nebo jako hierarchickou strukturu jednotlivých odkazů, z nichž je informační systém sestaven. První způsob je spíše záležitostí designovou, jedná se o ikonky a jejich umístění. Navigace ve smyslu stromové struktury odkazů na jednotlivé aplikace je problémem hlubší povahy, stejně jako další úroveň navigačního systému v podobě uživatelských menu (v návaznosti na kapitolu 10.2). Aplikační komponenty dávají formu navigačním sadám odkazů, ať už předdefinovaným či uživatelským a ve spolupráci s prezentační vrstvou vytvářejí navigační systém celého informačního systému. Vícejazyčnost Podpora vícejazykového prostředí není také pouze úkolem prezentační vrstvy, ale spíš vrstvy aplikační a datové. Přesto považuji za vhodné ji zde krátce zmínit, neboť z pohledu uživatelů se funkce vícejazyčnosti může jevit jako záležitost uživatelského rozhraní.
13.2
Personalizace
92
Vícejazyčnost systému lze realizovat opět díky oddělení jednotlivých komponent zejména aplikační a prezentační logiky. Se vstupním požadavkem od uživatele je předána jako parametr prostředí i jazyková mutace. Potom je tedy záležitostí aplikační, aby byla zajištěna správná interpretace jazyka a komunikace se správnou datovou bází. S jednotlivými jazykovými mutacemi se pracuje naprosto shodným způsobem, zpracování dat i jejich prezentace jsou nezávislé na obsahu. Pro přidání dalšího jazyka je třeba zajistit pouze jeho patřičný obraz v databázi.
13.2
Personalizace
Rozklad stránek na jednotlivé komponenty představované samostatnými boxy nesoucími veškeré informace o způsobu zobrazení a generování výsledného výstupu skládáním těchto boxů přináší vysoký stupeň personalizace systému. Lze říci, že personalizace je nadstavbou všech výše uvedených úloh prezentační vrstvy. Je-li informační systém schopen zajistit tyto úlohy pomocí komponentového generování, k personalizaci systému zbývá jen malý krůček. Aby bylo možné podporovat personalizaci systému, je třeba zajistit následující požadavky: • Sklad uživatelských a předdefinovaných komponent – spadá do datové vrstvy. Všechny objekty jsou ukládány v databázi v datovém schématu odpovídajícím povaze komponent. • Mechanismy podporující užití personalizovaných částí systému – tuto problematiku můžeme rozdělit na dvě oblasti. První tvoří prostředky pro nastavení personalizovaného uživatelského rozhraní a výběr preferovaných vlastností. Do druhé oblasti patří mechanismy, které zajistí spojení vybraných vlastností systému pro konkrétního uživatele a jejich použití na správných místech v systému. Zjednodušeně lze říci, že všechna osobní nastavení uživatele jsou uložena v databázi a na základě autorizace uživatele se automaticky pracuje s jeho preferencemi. V závěru považuji za důležité podotknout, že personalizační možnosti jsou příjemnou nadstavbou systému, avšak uživatelé nejsou nuceni je využívat. Pokud jim vyhovuje standardní chování systému nebo se obávají jakýchkoliv zásahů do nastavení, je aplikováno standardní, plně funkční nastavení. I toto je však svým způsobem vyjádření „personalizaceÿ systému.
14
VÝVOJ UŽIVATELSKÉHO ROZHRANÍ IS MZLU V BRNĚ
93
Praktické výsledky 14
Vývoj uživatelského rozhraní IS MZLU v Brně
Vývoj informačních systémů provozovaných v prostředí WWW začal na Mendelově zemědělské a lesnické univerzitě v Brně rokem 1999, kdy se několik pracovníků a demonstrátorů na Ústavu informatiky Provozně ekonomické fakulty začalo věnovat řešení rozsáhlého projektu fakultního informačního systému. Tento systém sloužil zpočátku jako informační systém Provozně ekonomické fakulty. Po dobrých zkušenostech a pochopení významu tohoto systému bylo vedením univerzity rozhodnuto o jeho rozšíření na celou univerzitu. Po přijetí rozhodnutí o celouniverzitním provozu začala skupina vývojářů v roce 2001 systém přepracovávat, aby vyhovoval rozšířeným požadavkům na něj kladeným. Původní Fakultní informační systém byl novým systémem postupně nahrazován a od září roku 2002 byl nový informační systém nasazen v celouniverzitním měřítku s názvem Univerzitní informační systém MZLU v Brně. Středem našeho zájmu v této kapitole bude sledování vývoje uživatelského rozhraní obou systémů. Pro pochopení komplexnosti problematiky uživatelského rozhraní si na začátku každé části přiblížíme i pohled na architekturu, vlastnosti a chování celého systému. Zájemce o celou evoluci těchto systémů můžeme odkázat na (Šorm a kol., 2001), (Šorm, 2001) nebo (Šorm, 2002) a na dokumentaci k Univerzitnímu informačnímu systému, kterou lze nalézt na domovské stránce UIS – http://is.mendelu.cz.
14.1
Fakultní informační systém
Fakultní informační systém (FIS) byl navržen jako webový informační systém provozovaný v prostředí klient/server. Počítalo se s velmi silným aplikačním a datovým serverem a lehkým, nenáročným, pokud možno zcela obecným a snadno dostupným klientem – webovým prohlížečem, který byl nejen běžně dostupný, ale měl i jednoduché a většině uživatelů známé ovládání. Byla zvolena modulární a objektová architektura, kde je každý modul složen ze základního objektu, který může využívat objekty další. Moduly byly rozděleny z hlediska funkčnosti, což se zdálo nejvýhodnější pro vývoj, protože bylo možné snadno přidávat nové vlastnosti a funkce do systému. Bylo nutné stanovit jednotné rozhraní pro přístup k databázi, stejně jako jednotné rozhraní pro výstup, které umožnilo snadno předdefinovat chování systému vzhledem k uživateli a stanovit design tohoto výstupu. Velký důraz byl kladen na znovupoužitelnost kódu, protože tímto způsobem bylo možné rychle vyvíjet nové moduly a přidávat obvyklé funkce. Navíc se tím vytvářelo analogické jednotné chování v celém systému, které uživatelům usnadňovalo
14.1
Fakultní informační systém
94
používání. Tuto znovupoužitelnost velmi zjednodušilo využití objektového návrhu systému. Vizuální stránka uživatelského rozhraní FIS Z vizuálního hlediska byly všechny zobrazovací metody zapouzdřeny do řídícího objektu miniFIS, který byl využíván všemi aplikacemi pro zobrazování výstupu. Všechny zobrazovací prvky byly pevně stanoveny. Změna designu systému by znamenala přepracování velké části jádra systému. Přes všechnu snahu navrhnout a používat uživatelské rozhraní vyhovující co největšímu počtu uživatelů bylo pochopitelné, že se kvůli designovým vlastnostem objevily i negativní ohlasy. Nebylo to nutné pokládat za záporný postoj uživatelů, neboť grafické cítění různých lidí se liší. Někteří uživatelé byli se vzhledem systému spokojení, jiní si stěžovali například na celkové barevné ladění objektů či velikost písma. Implicitně nabízel informační systém rozhraní ve stylu barev PEF, světlé písmo na modrém pozadí a k tomu vhodným způsobem laděné ostatní grafické prvky. Alternativním rozhraním bylo také rozhraní „bez designuÿ, klasické černé písmo na bílém podkladě a bez grafických prvků. Tvůrci fakultního informačního systému zprovoznili i experimentální rozhraní W@P pro mobilní telefony, toto rozhraní však nebylo příliš používáno a v dalším vývoji informačního systému již nebylo dále podporováno. Jak již bylo uvedeno výše, veškeré designové funkce a popis vzhledu stránky byl stanoven funkcemi modulu miniFIS.pm, který byl při vracení výstupu volán všemi aplikacemi. Jednalo se o ruční vložení kódu HTML popisujícího design stránky a jednotlivých objektů do řetězcových proměnných, které byly posílány na výstup. Základní objekty byly definovány v kaskádovém stylu pef.css, který byl při zobrazování stránky využíván. Následuje ukázka funkce section z modulu miniFIS.pm, která zobrazovala nadpis sekce na stránce. sub section { my ($obj,$nadpis) = @_; if ($obj->{section_started}) { $obj->add(q!
!); $obj->{section_started} = 1; } Ukázka záhlaví stránky Fakultního informačního systému, jak byl prezentován uživatelům v běžném zobrazovacím režimu, je na obrázku č. 20 (autentický snímek obrazovky již bohužel není k dispozici).
Obr. 20: Ukázka záhlaví stránky Fakultního informačního systému
Personalizace chování uživatelského rozhraní FIS Pod logickým pohledem na uživatelské rozhraní si představme chování systému a možnost jeho parametrizace, tedy možnost nastavení uživatelského nastavení. Fakultní systém nabízel několik málo voleb, které uživatelé mohli ovlivnit. • Přezdívka – vedle uživatelského jména, které bylo každému uživateli přiděleno a představovalo identifikační číslo uživatele v systému, si mohl každý nastavit vlastní přezdívku, kterou pak používal při přihlašování do systému. • Tiskárny – uživatelé měli možnost do systému zavádět tiskárny, na které zasílali tiskové výstupy. Jednalo se například o tiskárny v kancelářích uživatelů, na kterých běžně tiskli, či možnost nastavení virtuální tiskárny a při pokynu k tisku získávat výstupy ve formátu souboru PS nebo PDF. • Banner zpráv – systém obsahoval jednoduchý systém nástěnek, na které mohli uživatelé podle svého oprávnění umísťovat příspěvky a krátká sdělení. Všichni uživatelé vlastnící právo na čtení příslušné nástěnky byli vždy o novém příspěvku informováni. Ve svých preferencích pak mohli nastavit, zda si přejí být informováni bannerem (pruhem) s příslušným oznámením nebo zda chtějí zobrazovat všechny nové příspěvky v úvodní stránce po přihlášení do systému. • Zobrazování fotky – každý uživatel si mohl zvolit, zda si přeje či nepřeje zobrazovat vlastní fotografii ostatním uživatelům systému, a to ve třech režimech (zobrazovat vždy, zobrazovat pouze přihlášeným uživatelům, nezobrazovat nikdy). • Konzultační hodiny – učitelé mohli v případě zájmu vyplnit konzultační hodiny, tento údaj se pak zveřejňoval na stránce s osobními údaji.
14.2
Univerzitní informační systém
96
• Doplňující údaje – pokud si uživatelé přáli zveřejňovat o sobě další doplňující údaje jako číslo mobilního telefonu, adresu bydliště, další kontakt, případně se blíže charakterizovat klíčovými slovy či vložením poznámky, byla jim k dispozici aplikace pro nastavení osobních preferencí. Všechny tyto údaje se stejně jako konzultační hodiny zobrazovaly na stránce se základními daty každého uživatele.
14.2
Univerzitní informační systém
Převedení jádra stávajícího fakultního informačního systému na univerzitní se ukázalo nemožné a bylo třeba vybudovat jádro nové. Jedním z důvodů byla skutečnost, že stávající fakultní systém byl psán v té době již zastaralou technologií a nebyl tak rozsáhlý, aby nebylo možné přeprogramovat jádro systému včetně modulů a aplikací. Ještě podstatnějším důvodem však bylo zjištění, že univerzitní systém musel splňovat požadavky, které na stávající bázi fakultního systému bylo možné dodržet velmi těžce nebo vůbec. Jednalo se zejména o datovou základnu, která se ve stávajícím systému ukázala být navržena velmi ploše a nemohla být tak použita ani v rozšířené podobě jako základ systému univerzitního. Dalším závažným důvodem byl právní systém, který v rámci univerzity musel být rozšířen, aby odpovídal hierarchickému členění podle subjektů, které v rámci fakulty nemusely být brány v potaz. Základní změny mezi FIS a UIS Jak již bylo zmíněno, došlo ke kompletnímu přepracování jádra systému. Stejně jako jádro původního systému, bylo i jádro nového systému tvořeno programovými moduly, oproti systému původnímu bylo však značně rozšířeno. Každý modul definoval jednu třídu objektů. Při jejich definici byla snaha o značnou obecnost. Díky velkému množství parametrů jednotlivých metod bylo možné v široké míře ovlivňovat jejich chování. Modul miniFIS.pm byl nahrazen modulem UIS.pm, který se stal základním stavebním kamenem celého jádra. Na existenci této třídy objektů nyní závisí správný chod všech skriptů, neboť implementuje všechny metody nezbytně nutné pro korektní běh aplikací. Třída UIS poskytuje základní rozhraní mezi ostatními třídami objektů jádra systému od konkrétních použitých programových prostředků. Při změně některé z podpůrných částí dojde pouze k úpravě třídy UIS bez nutnosti zásahu do ostatních tříd. Třída UIS integruje řadu dalších perlovských modulů, volně dostupných z CPAN10 . Mezi další významné třídy, tvořící jádro UIS, řadíme třídy Formular, Sablony, Vyber a Tisk. Tyto třídy obsahují základní metody odrážející chování a vlastnosti systému a prolínají se podle logiky řešené problematiky všemi aplikacemi systému. 10
Comprehensive Perl Active Network – rozsáhlá sbírka perlového software a dokumentace (http://www.cpan.org).
14.2
Univerzitní informační systém
97
Ostatní moduly (třídy jádra) implementují funkce vždy konkrétní logické či aplikační oblasti. Jejich počet se stále rozšiřuje s rozšiřováním celého Univerzitního informačního systému. Podrobný popis všech tříd ve své době implementovaných, jejich rozhraní a metod lze nalézt v (Dařena, 2002). Třída UIS Metody třídy objektu UIS je možné rozdělit podle poskytovaných funkcí do několika kategorií: • Základní funkce jsou nezbytné pro správnou funkčnost aplikací a používají se v každé instanci objektu. • Designové funkce odstiňují autora aplikace od designu jednotlivých prvků stránky a od zápisu HTML kódu přímo v aplikaci. Jejich použití zajišťuje jednotný vzhled standardních prvků stránky. Při změně designu je pak možné upravit pouze tyto funkce a není třeba opravovat všechny aplikace. • Databázové funkce zjednodušují komunikaci s databází v porovnání s přímým použitím rozhraní DBI. • Funkce právního systému poskytují informace o oprávněních, která byla uživateli přidělena s bližším určením subjektů, ke kterým se tato oprávnění vztahují. • Kontrolní a bezpečnostní funkce umožňují zaznamenávat údaje do auditních záznamů v databázi a poskytují funkce implementující serializaci. • Funkce získávající jednoduché informace slouží pro zobrazení běžných informací jako jméno uživatele na základě předaného uživatelského čísla nebo název zadaného pracoviště s hypertextovým odkazem na podrobné informace o pracovišti. • Ostatní funkce nezařazené v předchozích kategoriích. Třída Formular Třída Formular je jednou ze základních částí jádra informačního systému. Zahrnuje metody, podporující zjednodušení určitých stále se opakujících operací. Výchozím podnětem bylo zjednodušení aplikací, které prováděly správu číselníků (číselníkových tabulek – např. univerzitní období, formy studia, studijní programy, obory atd.). Jednalo se o stále stejný typ operací – zobrazení tabulky buď celé nebo podléhající nějakému výběru na základě daného kritéria, přidání položky, mazání položky a editace. Při programování dalších aplikací se ukázalo, že formulářové metody je možné zobecnit z operací nad číselníky na operace nad libovolnou tabulkou uloženou v databázi. Výhody, které plynou z tohoto zobecnění, přinášejí zejména jednotný styl zobrazování výstupu uživateli, jednotnou logiku chování všech aplikací. Pro vývojáře se zjednodušuje programování nových aplikací díky použití předpřipravených metod.
14.2
Univerzitní informační systém
98
Třída Sablony Třída Sablony podporuje použití techniky zvané šablonování. Při šablonování je základní tabulka doplněna o tabulku se specifikací dodatečných údajů (atributů) a tabulku obsahující hodnoty atributů příslušné jednotlivým záznamům ze základní tabulky. Tento způsob uložení umožňuje dynamicky měnit evidované atributy, tedy například pokud je nutné u uživatele evidovat další hodnotu, je velmi jednoduché přidat do definice šablony další atribut a není nutné přidávat nový sloupec do základní tabulky. Metody obsažené v třídě Sablony poskytují programové rozhraní k mechanismu šablonování. Jsou k dispozici metody zjišťující základní údaje o šabloně a jednotlivých atributech, metody umožňující zobrazení a ukládání jednotlivých atributů a metody na vysoké úrovni abstrakce poskytující jednotné rozhraní pro zobrazení a editaci všech atributů objektu. Třída Vyber Třída objektu Vyber implementuje operace pro manipulaci s údaji z rozsáhlých číselníků podle zadaného vyhledávacího vzorku. Stejně jako předcházející třídy obsahuje metody, které zajišťují jak operace směrem k datové vrstvě (zejména výběry z databáze), tak operace zajišťující prezentaci údajů. Třída Tisk Třída Tisk zajišťuje tiskové výstupy z Univerzitního informačního systému, sazbu dokumentu a odeslání výstupu uživateli v předvoleném formátu. Nejčastěji se jedná o výstup PDF nebo PostScriptového souboru či odeslání dokumentu na tiskárnu uživatele. Další třídy jádra Ostatní třídy jádra můžeme shrnout do jednoho celku. Jedná se o třídy, vytvořené pro zapouzdření funkcí řešících určitou specifickou problematiku. Tyto třídy často odpovídají subsystémům Univerzitního informačního systému, ale i oblastem v podobnějším logickém členění řešené problematiky. Samozřejmě jsou podle potřeby tyto třídy využívány i v ostatních aplikacích, kde je výhodné použít již připravené funkce. Vizuální stránka uživatelského rozhraní UIS Univerzitní informační systém se představil v novém designu. Modrou barvu pozadí (barvu PEF) vystřídalo univerzální pozadí světle žluté s tmavým písmem, novým záhlavím, logem a dekoracemi. Ze strany uživatelů opět přišly ohlasy, jak bylo možné předpokládat, některé kladné, jiné záporné. Protože však design nebylo možné měnit
14.2
Univerzitní informační systém
99
či střídat, postupně si uživatelé zvykli. Původní design Univerzitního informačního systému ukazuje obrázek č. 21.
Obr. 21: Původní design UIS – převzato z (Šorm, 2002)
Vzhled celého systému, stejně jako objektů na stránce, byl tvořen výhradně metodami, poskytovanými modulem UIS. Výstupní HTML kód byl zapouzdřen do těchto metod (obdobně jako na ukázce funkcí z modulu miniFIS). Aplikační programátoři pak výsledný výstup aplikací sestavovali výhradně voláním těchto funkcí, což představovalo jeden z nejvýznamnějších rozdílů mezi Fakultním a Univerzitním informačním systémem. Ve FIS byl výstup formován kombinací funkcí a HTML kódu vkládaného přímo do výstupního proudu aplikace, v UIS se tvořil již pouze dostupnými funkcemi, které všechny potřebné prvky s jejich vlastnostmi zapouzdřovaly. Nové jádro systému tedy přineslo, jak je z předchozího výkladu patrné, sjednocení vzhledu a chování většiny aplikací. Zejména třídy Formular a Sablony byly průlomem pro tvorbu aplikací a jejich výstupy, neboť představovaly vyšší stupeň abstrakce zapouzdřením jednotlivých funkcí z UIS.pm.
14.2
Univerzitní informační systém
100
Postupně se začalo s vývojem tzv. portálových aplikací, kdy se pod záhlavím stránky určité rodiny aplikací (subsystému) nachází horizontální menu s odkazy do souvisejících aplikací. Tato portálová menu jsou součástí jednotlivých modulů, protože jsou specifická pro jednotlivé subsystémy. Díky sdílení kódu a spolupráci vývojářů jsou však menu jednotná, co se týče vzhledu i chování. První portálovou aplikací byl záznamník učitele (učitelský portál), viz obrázek č. 22.
Obr. 22: Portálová aplikace záznamník učitele – převzato z (Bartík, 2003)
Logická stránka – personalizace chování uživatelského rozhraní UIS Druhým pohledem na uživatelské rozhraní UIS je pohled logický. Chování systému se stalo jednotné díky novému jádru a již popsaným modulům a metodám v nich definovaným. Typické operace prováděné uživateli v systému byly stejné, uživatelé nemuseli ztrácet čas učením se aplikace používat. Po prvním seznámení s jednou aplikací již snadno zvládli analogické operace v jiném místě systému. Kromě sjednocení chování většiny aplikací nabízel UIS rozšířené možnosti parametrizace (uživatelského nastavení systému). Vycházelo se z modelu FIS, který byl přizpůsoben novým podmínkám, upraven a rozšířen. Volby pro režim zobrazování fotografie, nastavení tisku, konzultační hodiny a některé doplňující údaje zůstaly beze změn. Kvůli zavedení systému jednotné autentizace byly zrušeny přezdívky.
14.2
Univerzitní informační systém
101
Také systém nástěnek byl kompletně přepracován a vznikl nový komplexní content management systém. Nové preferenční možnosti UIS představovaly zejména rozšíření osobních údajů, které si uživatelé přáli o sobě zveřejňovat: e-maily, adresy webových stránek, doplňující osobní údaje a kontakty apod. Postupem času byly přidávány další volby, ty nejvýznamnější, posunující systém do kategorie personalizovatelných systémů, probereme v dalších kapitolách.
15
102
NOVODOBÝ DESIGN UIS
15
Novodobý design UIS
Ruku v ruce s vývojem systému jako celku se vyvíjí i jeho uživatelské rozhraní. V této kapitole si přiblížíme novodobý design UIS a zanalyzujeme kroky, které jsou potřeba zajistit pro přechod na plně variabilní a personalizovatelný design. Stav popisovaný v této kapitole můžeme po FIS a první verzi UIS označit jako třetí generaci informačního systému na naší univerzitě.
15.1
Změny ve stavbě uživatelského rozhraní
Změnou patrnou na první pohled byla obměna designu a jeho sjednocení s univerzitní webovou prezentací. Náhled osobní administrativy UIS v novém designu je na obrázku č. 23.
Obr. 23: Nový design UIS
Zobrazování obrázků Dalším evolučním krokem ve vývoji Univerzitního informačního systému byla změna způsobu volání a vykreslování obrázků. Veškeré ikony byly dosud uloženy v adresáři
15.1
Změny ve stavbě uživatelského rozhraní
103
na disku, nyní však došlo k přesunu všech obrázků do databáze. Nový způsob práce s obrázky přinesl následující výhody: • Roztřídění do kategorií – jednotlivé obrázky je nutné zařadit do kategorií, které pak usnadňují vyhledávání a práci s obrázky. • Uložení veškerých údajů o obrázku – všechny potřebné údaje o obrázcích jsou uloženy v tabulce v databázi, s kterou se dále pracuje. • Jednotné používání obrázků v aplikacích – díky běžné „formulářové aplikaciÿ dostupné vývojářům, lze jednoduchým způsobem přidávat jak nové kategorie obrázků, tak nové obrázky do kategorií, snadno lze obrázky vyhledávat. To podporuje jednotné používání standardních navigačních ikon v aplikacích (např. base-read – ikona pro čtení údajů, base-write – ikona pro zápis údajů, base-op – další operace). • Zobrazování obrázků voláním funkce – všechny obrázky jsou do výstupního proudu vkládány metodou obrazek() třídy UIS. Tato metoda zajistí korektní zobrazení obrázku a podle zaslaných parametrů provede další požadované úkony (zarovnání, nastavení alternativního popisu obrázku a další). Využití funkce pro zobrazování obrázků umožňuje zavést další mechanismy: – cachování – řeší problém rychlého vracení obrázků klientovi, – změnu obrázku podle designu – při volání funkce se podle systémového identifikátoru obrázku vybere příslušný obrázek přemapovaný do jiného designu (příprava pro zavedení variantních designů – více v kapitole 16). Přechod na XHTML/CSS Jádro systému bylo postupně očišťováno od vizuálního formátování. Metody zajišťující výstupní formát byly přepisovány na generování XHTML11 kódu, který využíval kaskádových stylů s veškerými formátovacími a grafickými informacemi. Soubory CSS byly uloženy na pevném disku, později přesunuty do databáze. Rozvoj portálových aplikací Z pohledu vývojářského i uživatelského slavily úspěch tzv. portálové aplikace, jejichž průkopníkem byl záznamník učitele (viz str. 100). Horizontální menu, provázející vždy celou sadu aplikací patřících do portálu, se stalo typickým pro řadu subsystémů: dokumentový server, poštovní subsystém, workflow nástroj TODO, záznamník výzkumníka, portál SIF a OSSA a další. Horizontální portálové menu uspořádané do několika sloupců je definováno vždy v programovém modulu příslušejícím dané skupině aplikací a je zobrazováno pomocí metody z této třídy. Uživatelům usnadňuje orientaci a použití jednotlivých aplikací portálu, má jednotný vzhled i chování – aktivní aplikace je zobrazena tučně, ostatní 11
XHTML – eXtensible HyperText Markup Language je doporučením W3C navazujícím na předchozí specifikace HTML. Přeformulováním HTML 4.01 jako XML aplikace se možnosti HTML spojily sílou XML (Marchal, 2000), (XHTML, 2002).
15.2
Rozšíření personalizace
104
odkazy v portálu jsou klikatelné. Samozřejmostí je, že portál nabízí pouze odkazy, které jsou uživateli dostupné na základě jeho oprávnění v příslušné aplikaci. Srovnání portálu záznamníku výzkumníka a dokumentového serveru je patrné z obrázků č. 24 a 25.
Obr. 24: Portálové menu záznamníku výzkumníka
Obr. 25: Portálové menu dokumentového serveru
15.2
Rozšíření personalizace
Již od počátků návrhu Univerzitního informačního systému se hovořilo o tom, že systém bude uživatelsky přívětivý a v maximální míře personalizovatelný. Víme, že uživatelská přívětivost je záležitost subjektivní, personalizace se však dá měřit objektivně. Po několika málo volbách, které UIS nabízel zpočátku, se parametrizace systému postupně rozšiřovala.
15.2
Rozšíření personalizace
105
Nastavení parametrů poštovní schránky Poštovní subsystém je nedílnou, přesto samostatnou součástí Univerzitního informačního systému. Každému uživateli UIS poskytuje poštovní schránku, postavenou na bázi webového poštovního klienta. V této části se o nastavení poštovního systému zmiňujeme i přes to, že se nejedná přímo o parametrizaci systému jako celku. Poštovní systém však představuje jeden ze subsystémů UIS, proto je nutné sem zařadit i možnosti jeho nastavení. V poštovní schránce se pod záložkou nastavení skrývá několik voleb, obdobných jako můžeme nalézt u běžných webových poštovních klientů. Jedná se o: • správu složek, • nastavení přeposílání pošty, • volbu počtu zpráv vypisovaných na jedné stránce, • volbu, zda ukládat či neukládat odeslanou poštu, • definici signatury, která se bude připojovat k odesílaným e-mailům. Všechna nastavení jsou logická a velmi jednoduchá. Za podrobnější zmínku stojí správa složek, která nabízí založení libovolného množství uživatelských složek. Složky je možné řadit dle přání uživatele, abecedně nebo využít tzv. implicitního řazení. Zasílání informačních e-mailů Díky tomu, že je poštovní subsystém integrovaný do UIS, je možné jeho služeb využívat i v jiných rodinách aplikací. Jedná se o mechanismus zasílání informačních e-mailů, který je vestavěn v celé řadě aplikací (vypisování termínů na zkoušky, záznamník učitele, dokumentový server, workflow a další). Informační e-maily jsou zasílány v případě, že dojde v daném systému ke změně, jež se uživatele týká, samozřejmě pouze má-li uživatel nastaveno, aby mu informace o daném typu změny byly zasílány. Například ve workflow systému si může každý zvolit, zda si přeje být informován o změnách v úkolech pouze osobních, všech úkolech nebo si nepřeje být informován vůbec. Toto nastavení je možné zvolit globálně pro všechny uživateli přístupné workflow bloky nebo pouze pro blok aktuální. Kombinací nastavení zasílání informací z různých aplikací UIS dosáhne uživatel maximální informovanosti v minimálním čase a s minimálním úsilím. Nemusí tak vyhledávat informace na různých místech systému a kontrolovat, zda došlo k nějaké změně, ale může se spolehnout, že o všech podstatných záležitostech bude včas informován univerzitní poštou. Nastavení dokumentového serveru Dokumentový server představuje další významný subsystém Univerzitního informačního systému, je zástupcem nástroje CMS (Content Management System – systém pro správu obsahu). Podívejme se na možnosti osobního přizpůsobení vzhledu a chování tohoto komplexního nástroje.
15.2
Rozšíření personalizace
106
K základnímu nastavení dokumentového serveru patří: • počet dokumentů a složek na stránce, • zasílání informací o vložení dokumentu do složky, • vzhled a hloubka dokumentového stromu (hierarchického uspořádání složek), • správa uživatelských složek, • správa automatických složek při vlastnictví superpráva. Významnou vlastností dokumentového serveru je možnost nastavení vzhledu a hloubky dokumentového stromu. Všechny složky dokumentového serveru tvoří hierarchickou strukturu, podobnou například struktuře adresářů operačního systému (není již nutné zdůrazňovat, že každý uživatel vidí pouze ty složky, na které má oprávnění). Složky se do sebe mohou vnořovat, ke složkám v nižší úrovni stromu se uživatel dostane rozbalením příslušné větve (kliknutím na znaménko + před složkou obsahující podsložky). Analogicky je možné větev opět sbalit stiskem znaménka −. Systém si pamatuje vzhled dokumentového stromu pro každého uživatele i po opuštění aplikace. Další nabízenou volbou je možnost zobrazit si dokumentový strom od určité složky, čímž dojde k dalšímu zpřehlednění. Hodnota tohoto parametru je opět zapamatována. U složek, kde uživatel nemá přiděleno právo na složku automaticky (nevyplývá přímo z jeho univerzitních rolí), je možné zakázat zobrazování složky, pokud o ni uživatel nemá dále zájem. Kombinací uvedených vlastností si mohou uživatelé nastavit pro ně nejefektivnější a nejpřehlednější podobu svého úložiště dokumentů. Ve větvi dokumentového stromu, určené pro osobní složky uživatelů, si uživatelé mohou založit libovolné množství vlastních podsložek. Vlastník osobní složky disponuje právem správce této složky, tím je oprávněn řídit použití této složky (může určit charakter složky, udělovat oprávnění dalším uživatelům apod.) Automatické složky jsou zakládány implicitně podle existence pracovišť a předmětů na univerzitě, práva k těmto složkám jsou přidělována na základě postavení uživatele v rámci daného subjektu. Možnosti nastavení těchto složek jsou vzhledem k tomu, že se jedná o automatické složky, podmnožinou operací popsaných výše. Filtry ukládající nastavení Dalším významným krokem ke zvýšení uživatelské přívětivosti UIS bylo zavedení filtrů, které si v aplikaci pro každého uživatele pamatují svoji poslední hodnotu, a při opětovném použití aplikace tuto hodnotu použijí jako výchozí. Jedná se v podstatě o analogii zobrazování stromu dokumentů dokumentového serveru. Filtry jsou použity na zobrazení podmnožiny z nějaké množiny hodnot. Používají se zejména u výpisu dlouhého seznamu položek (omezení na výpis hodnot vyhovujících dané podmínce) nebo u povinného nastavení výchozí volby (parametr ovlivňující chování aplikace). Práce filtrů je postavena na ukládání hodnoty filtru do databáze, tím je zajištěno uchování jeho hodnoty i po opuštění a opětovném navštívení aplikace. Dříve bylo možné řídit restrikci zobrazení jen pomocí parametrů předávaných v rámci několika
15.2
Rozšíření personalizace
107
souvisejících skriptů, po přechodu na jiné místo systému však byla hodnota ztracena. První použití filtrů se objevilo ve workflow aplikaci, kdy se nastavením filtru řídí výpis seznamu zobrazovaných úkolů. Po osvědčení filtrů ve workflow bylo proprietární řešení zobecněno a byl vyvinut modul Filter.pm. Ten obsahuje dvě hlavní metody – uložení a získání hodnoty filtru – které je možné využít v libovolné aplikaci. Tyto metody pracují nad obecným číselníkem filtrů a konfigurační tabulkou pro konkrétní filtr, uživatele a případné další rozlišení. Volba designu Prvním krokem k personalizaci designu informačního systému byla podpora dvou typů designů – klasický design s obrázky a design bez obrázků, tzv. quick, který se využíval pro zrychlení práce s informačním systémem (při pomalém připojení k Internetu, v dobách velké zátěže systému – např. při registracích a zápisech studentů) nebo při práci s informačním systémem na koncovém zařízení s omezeným zobrazovacím prostorem (kapesní počítače aj.). Podle typu výstupního zařízení byl jeden z designů určen jako implicitní (kapesní počítače – režim quick, jinak běžný režim). Přepínání mezi těmito designy řídil sám uživatel kliknutím na odkaz pro změnu. Personalizace systému po stránce variantního designu byla jedním z cílů od počátků budování Univerzitního informačního systému. Ke zmíněným dvěma poskytovaným možnostem rozhraní začaly přibývat další (původní design UIS a FIS, design pro prezentace s velkými písmeny a další). Výsledná podoba výstupu byla tvořena metodami jádra, které na základě zaslaného designového parametru vracely příslušný výstup. Dalším vývojovým úkolem bylo zcela oprostit tyto metody jádra od vizuálního formátování. Tím se nejen usnadnilo přidávání dalších systémových designů, ale připravila se půda pro podporu designů definovaných uživateli.
16
GENEROVÁNÍ UŽIVATELSKÉHO ROZHRANÍ
16
108
Generování uživatelského rozhraní
Metodiku rozkladu a skládání komponent uživatelského rozhraní informačního systému (kapitola 12) postavenou na principu Component boxing modelu (kapitola 11) předvedeme v této kapitole na příkladu personalizovaných designů v Univerzitním informačním systému.
16.1
Podpora designů v UIS
V souvislosti se snahou poskytovat uživatelům Univerzitního informačního systému maximální komfort při práci, po logické personalizaci ve smyslu chování systému na základě určitých osobních nastavení (popsaných v kapitolách 14 a 15 o Fakultním a Univerzitním informačním systému) přichází ke slovu i personalizace vizuální, na které lze nejlépe demonstrovat sílu komponentového pojetí systému. Od možnosti nabízet uživatelům několik vestavěných designů, z nichž si jeden mohou vybírat pro práci, byl už jen krůček k umožnění tvorby uživatelských designů a jejich následného zapojení do užívání v rámci systému. Obecně lze říci, že přístup k tvorbě designu, ať se jedná o design předdefinovaný či uživatelský, je stále stejný. U uživatelských designů navíc probíhá proces schvalování a následného zařazení mezi společné designy. Také je potřeba zajistit korektnost a kontrolu uživateli vytvářených designů. Tvorba designu Vytvoření nového designu není zpravidla jednoduchá záležitost, vyžaduje od uživatele alespoň základní orientaci v tvorbě WWW stránek. Proces vytváření probíhá v oblasti soukromých designů, dokud autor nepožádá o zařazení své práce do společné kategorie, nemá nikdo jiný k jeho rozpracovaným ani hotovým designům přístup. Vytvoření nového designu zahrnuje čtyři kroky, z nichž některé jsou povinné a některé volitelné. Každý krok se týká jedné designové komponenty. 1. Založení instance nového designu. Provádí se buď vytvořením prázdného nebo zkopírováním existujícího designu (a to jak z kategorie společných designů, tak některého z vlastní tvorby). Povinná komponenta. 2. Vytvoření kaskádového stylu (CSS) designu. Opět lze vytvořit nový styl nebo upravit stávající. Styl ovlivňuje zejména grafickou úpravu jednotlivých objektů na stránce. Volitelná komponenta, kaskádový styl může být prázdný. 3. Definice polí, z kterých je složen výstup. Nejobtížnější fáze definice nového designu. Zde je třeba určit XML předpisy pro zobrazování jednotlivých objektů výstupního proudu. Tyto předpisy musí odpovídat definici typu dokumentu, aby bylo možné celý výstup transformovat do podoby HTML srozumitelné prohlížeči. Povinná komponenta, definice polí musí obsahovat minimálně předpis pro zobrazení stránky . Počet a složitost dalších elementů závisí na
16.1
Podpora designů v UIS
109
schopnostech a preferencích uživatele, pouze se zde nesmí vyskytnout elementy, které nejsou zahrnuty v definici dokumentu. K podporovaným prvkům patří například , , a další). Příkladem pole může být XML předpis popisující zobrazení oddělovací čáry ve stránce: . 4. Mapování obrázků. Systémové obrázky, které jsou volány aplikacemi, lze ve většině případů zaměnit za obrázky vlastní. Kromě položek, kde by použití jiného obrázku změnilo původní význam (např. screenshot v návodu k prvnímu přihlášení), mohou uživatelé nastavit, kterým vlastním obrázkem nahradí obrázek systémový – tedy provést mapování jednotlivých obrázků. Volitelná komponenta, je možné plně využívat předdefinovaných systémových obrázků. Takto vytvořený design po kontrole, zda obsahuje všechny nezbytné náležitosti, lze prohlásit za hotový a jeho autor jej může používat. Nechce-li si tvůrce svůj design nechat pouze pro sebe, nabídne jej ke schválení a zařazení mezi designy společné (sdílené). Správce designů pak design zkontroluje a rozhodne o jeho zařazení do kategorie společných designů, pokud nejsou dodrženy náležitosti této kategorii, má právo návrh zamítnout. Aplikace pro tvorbu designu Aplikace související s tvorbou designů můžeme rozdělit na dvě skupiny. Servisní aplikace určené vývojářům a provozovatelům UIS ke správě obrázků pro designy a dále uživatelské aplikace pro konkrétní práci s designy. Do servisních nástrojů řadíme aplikace: • Evidence kategorií obrázků v designech – aplikace, kde se evidují (zakládají, upravují, ruší) kategorie obrázků v designech (kategoriemi rozumíme např. aplikační ikony, navigační prvky, dekorativní obrázky apod.). • Správa individuálních kvót pro obrázky v designech – aplikace, pomocí které lze spravovat individuální kvóty uživatelů pro soukromé obrázky používané v designech. Uživatelé mají přidělenu určitou kvótu (místo na disku), kterou při vkládání obrázků nesmí přesáhnout. Do soukromé kvóty se počítají pouze obrázky (celkový objem dat představovaný těmito obrázky), které nejsou použity ve společných designech. Aplikace na vlastní prototypování designu jsou sdruženy do portálového menu a zahrnují: • Společné designy – aplikace umožňující prohlížení parametrů společných designů UIS. Libovolný design lze zkopírovat do designů soukromých a tam dále upravovat. K dispozici je funkce náhledu stránky ve zvoleném designu (obrázek 26). • Soukromé designy – vlastní aplikace pro vytváření designu. Zahrnuje funkce pro vytvoření všech potřebných komponent nového designu, včetně náhledu prototypovaného designu (obrázek 27).
16.1
Podpora designů v UIS
110
• Schvalování designů – aplikace dostupná pouze oprávněným osobám a slouží ke kontrole designů navržených na zařazení do kategorie společných. Pokud splňuje navrhovaný design všechny potřebné náležitosti, je návrh schválen. • Správa obrázků v designech – aplikace sloužící k evidenci uživatelských obrázků a jejich zatřiďování do kategorií. Se svými obrázky může uživatel manipulovat za předpokladu, že obrázek není označen jako společný (není součástí některého ze společných designů). • Nápověda – nezbytná nápověda k ovládání aplikací a zejména průvodce vytvořením nového designu.
Obr. 26: Společné designy (aplikace z pohledu běžného uživatele)
Obr. 27: Soukromé designy (portálové menu z pohledu správce designů v UIS)
16.1
Podpora designů v UIS
111
Použití volitelných designů Je-li vše připraveno, zbývá poslední krok, a tím je výběr preferovaného designu a jeho použití. K tomu slouží aplikace Volba pracovního designu patřící do množiny nástrojů pro nastavení systému, kde jsou zobrazeny náhledy všech dostupných (předdefinovaných, uživatelských společných a soukromých hotových) designů a je umožněn výběr designu pro práci. Ukázky současných designů jsou uvedeny v příloze B.
17
17
OBECNÉ GENEROVÁNÍ UŽIVATELSKÉHO ROZHRANÍ
112
Obecné generování uživatelského rozhraní
Rozkladem uživatelského rozhraní do jednotlivých komponent, vytvořením stromu těchto komponent a definováním jednoznačných pravidel jejich vzájemného skládání při formování výstupu jsme formalizovali přístup tvůrce systému. Implementací možnosti generování volitelných grafických designů v rámci Univerzitního informačního systému jsme demonstrovali použití metodiky Component boxing modelu v praxi. Definice metodiky Component boxing modelu je však natolik obecná, že ji lze aplikovat na téměř libovolnou část uživatelského rozhraní. Vedle grafického designu lze stejného principu využít pro generování jiných prvků uživatelského rozhraní, zejména pro navigační systém, skladbu portálu (ve smyslu rozmístění prvků), definici uživatelských komponent portálu, dále pak v návaznosti na aplikační a datovou vrstvu lze ovlivnit i chování systému a systémové politiky na základě uživatelských nastavení a preferencí.
18
PATNÁCTERO UŽIVATELSKY PŘÍVĚTIVÉHO IS
113
Závěrečné shrnutí a přínosy práce 18
Patnáctero uživatelsky přívětivého IS
Práce se zabývá novými postupy uplatňovanými při návrhu uživatelsky přívětivých informačních systémů. Sousloví uživatelská přívětivost se prolíná celou prací. Již od počátku víme, že označení „uživatelsky přívětivý informační systémÿ je velmi subjektivní. Proto nyní v závěru práce definujeme na základě zkoumaných skutečností vlastní doporučení pro tvorbu uživatelsky přívětivého informačního systému. Z pohledu autora IS Tvůrce navrhuje systém od samotného počátku, od jádra přes logickou i obsahovou stránku jednotlivých částí, až po komunikaci s uživatelem. Na základě výzkumu této práce doporučujeme komponentově orientovaný přístup. Následující doporučení kombinují prvky specifické i obecné, neboť obě skupiny patří k sobě a nelze je od sebe oddělit bez ztráty významu. 1. Před návrhem systému provést důkladnou analýzu všech známých skutečností, které budou souviset s budoucím vývojem a provozem systému (prostředí, v jakém bude systém pracovat, oblast problematiky, kterou řeší, požadované operace, uživatelé). V případě, že systém již existuje, provést analýzu možných změn na základě technických možností a přístupu uživatelů. 2. Definovat datové, aplikační a prezentační komponenty a logiku práce systému na každé z uvedených vrstev. Určit pravidla spolupráce komponent mezi vrstvami i v rámci jednotlivých vrstev. 3. Dbát na parametrizaci systému a možnost jeho dalšího rozšiřování. 4. Stanovit jednotnou politiku chování systému. 5. Zaměřit se na uživatele, neboť pro ně je systém vytvářen. 6. Navrhnout jednoduché a intuitivní uživatelské rozhraní s možností rozšířených osobních nastavení. 7. Poskytovat dostupnou nápovědu, výstižnou dokumentaci a servis pro uživatele. 8. Vzbuzovat v uživatelích zájem o práci se systémem, zvyšovat jejich spokojenost, a tím posilovat vzájemnou spolupráci a zpětnou vazbu. 9. Vždy brát v potaz názory uživatelů, učit se od nich. 10. Poskytovat jednoduché i pokročilé metody personalizace systému po stránce vzhledu, obsahu i chování systému. 11. V základní konfiguraci musí být systém natolik přívětivý, aby žádná personalizace nemusela být potřeba.
18
PATNÁCTERO UŽIVATELSKY PŘÍVĚTIVÉHO IS
114
Z pohledu uživatele IS Pohled uživatele je jednodušší, neboť se nezabývá tím, co se skrývá uvnitř; pro uživatele je důležité, aby systém plnil funkce, které od něj očekává. 1. Intuitivní ovládání systému se stručným a výstižným návodem k prováděným operacím. 2. Mít se kam obrátit v případě otázek či problémů. 3. Dostatečná rychlost operací prováděných v systému. 4. Nastavení osobních preferencí.
19
ZÁVĚR
19
115
Závěr
Informační systémy a informační technologie dnes, na počátku 21. století, pronikají rychlým tempem do nejrůznějších oblastí lidské činnosti, včetně takových, kde se ještě před několika lety lidé bez nich obešli. V důsledku tohoto rozvoje dnes s počítačově orientovanými informačními systémy pracuje stále více uživatelů, jejichž obory mohou být značně vzdálené světu IT. K základním předpokladům dnešních informačních systémů proto patří jejich vysoká kvalita a efektivnost, které zahrnují řadu hledisek, mezi něž patří i uživatelská přívětivost.
19.1
Shrnutí dosažených výsledků práce
Pod uživatelskou přívětivostí si lze představit řadu vlastností informačního systému; úhel pohledu se liší od uživatele k uživateli, zejména podle jeho vztahu k IT a zkušeností s nimi. Od laického, avšak hluboce pravdivého požadavku „potřebuji, aby se mi se systémem dobře pracovalo, aby byl jednoduchý, přehledný a intuitivní a současně poskytoval všechny funkce, které chci využívatÿ se postupně dostaneme až k přesně definovaným požadavkům expertů, kteří za systémem vidí nejen jeho uživatelské rozhraní a chování, ale i celou architekturu včetně vnitřních vazeb a zajímá je také způsob návrhu a implementace systému. Ve své disertační práci jsem se snažila nalézt odpovědi pro oba póly spektra lidí, kteří s informačním systémem pracují, dotknout se pohledu běžných uživatelů informačních systémů, především však pohledu tvůrců a vývojářů. Nešlo pouze o stanovení, jaký systém je či není uživatelsky přívětivý, ale zejména o postupy, kterými docílit, aby systém uživatelsky přívětivý byl. Za rozšíření uživatelské přívětivosti považuji personalizaci – osobní nastavení systému a přizpůsobení jeho chování potřebám a požadavkům uživatelů. Proto se v práci zabývám také otázkou, jak dosáhnout implementace personalizovatelného systému při dodržení základních požadavků – jednoduchosti a srozumitelnosti. Při rozebírání různých pohledů a definování postupů pro návrh uživatelsky přívětivých informačních systémů bylo po obecném úvodu nutné se specializovat na konkrétní typ systému, neboť pojem informační systém je poměrně široký. Pro zkušenosti z univerzitního prostředí a v současnosti značnou rozšířenost a blízkost uživatelskému publiku jsem se zaměřila na systémy provozované v prostředí Internetu – na webové informační systémy. Celou práci člením do tří hlavních částí. První část se týká teoretických východisek a shrnuje podklady, které úzce souvisí s vlastní zkoumanou problematikou. Jedná se zejména o otázky vývoje informačního systému jako celku i zaměřené speciálně na prezentační vrstvu, která je hlavním předmětem zkoumání. Druhou část práce nazvanou Vlastní řešení považuji za stěžejní. V prvních dvou kapitolách (kapitola 9 Uživatelská přívětivost informačních systémů a kapitola 10 Personalizace) rozebírám současné aspekty těchto pojmů, stanovuji definice a navrhuji složky těchto pojmů na základě studia podkladů a vlastního výzkumu.
19.1
Shrnutí dosažených výsledků práce
116
Významnou část práce představují kapitoly 11, 12 a 13. Na základě klasické třívrstvé architektury informačního systému a událostního cyklu s využitím myšlenek MVC paradigmatu definuji tzv. Component boxing model, který popisuje stavbu a komponentové složení obecného webového informačního systému. Metodika Component boxing modelu je pojmenována podle dvou paradigmat, jež obsahuje, principu boxů a principu komponent. Princip boxů hovoří o rozdělení výstupního proudu na jednotlivé prvky, tvořené pravoúhlými oblastmi (odtud z angličtiny box ); každý prvek se skládá ze dvou složek, svého obsahu a designu, vzájemným vnořováním tvoří boxy hierarchickou strukturu jednoznačně popisující stránku informačního systému s výsledným výstupem. Princip komponent hledá a definuje na úrovni každé vrstvy třívrstvé architektury konkrétní komponenty, které se v systému opakují či řeší standardizovanou úlohu, a usnadňuje tím jejich opětovné použití. Složením obou pravidel získáváme metodiku pro vybudování systému, který je znovupoužitelný (díky komponentovému pojetí), personalizovatelný (díky boxům) a snadno rozšiřitelný (kombinací obou vlastností). V kapitole 12. nazvané Rozbor komponent uživatelského rozhraní je obecně navržená metodika Component boxing modelu aplikována konkrétně na prezentační vrstvu. Jsou zde definovány pojmy jako box, obsah boxu, design boxu a vizuální prvek, vztahující se k prezentační vrstvě a potřebné pro generování uživatelského rozhraní. Na základě existujícího informačního systému jsem provedla analýzu prvků stránky (výstupu) a vytvořila strom komponent uživatelského rozhraní. Definovala jsem povinné, volné a vázané komponenty a typy vazeb mezi nimi. Pro získání výsledného výstupu bylo třeba nalézt také pravidla pro vzájemné skládání komponent. Zobecněním průchodu stromu komponent (rozkladu i skládání) jsem získala obecný předpis pro generování uživatelského rozhraní. Komponentovým přístupem k návrhu informačního systému získáme velmi pružný systém (podle zkoumané úrovně lze toto říci o všech jeho vrstvách), takový systém je pak snadno rozšiřitelný, integrovatelný a personalizovatelný, což jsou základní požadavky kladené na informační systémy dnešní doby. Co se týče personalizace, definuji ji jako nadstavbu uživatelské přívětivosti systému. Výsledná personalizace je úkolem zejména prezentační vrstvy, někdy její povaha však sahá i do vrstev nižších. Tím, že je možné rozdělit systém do jednotlivých komponent, kde je vzájemně oddělen obsah od designu, lze snadno dosáhnout personalizovaného chování a vzhledu na základě parametrizace systému. Podle uživatelských nastavení a pravidel skládání je pak výstup tvořen právě těmi komponentami, které odpovídají uživatelem zvolené kombinaci požadovaného výstupu. Třetí část práce nazvaná Praktické výsledky se týká uplatnění navrhované metodiky v praxi. Pro lepší pochopení komplexnosti řešené problematiky a přínosů nových navrhovaných metod jsem zde stručně popsala vývoj uživatelského rozhraní Fakultního a Univerzitního informačního systému na Provozně ekonomické fakultě, resp. na Mendelově zemědělské a lesnické univerzitě v Brně. V kapitole 15. jsem se zaměřila na popis personalizace současného UIS. V navazující kapitole 16. jsem přiblížila konkrétní implementaci komponentově generovaného uživatelského rozhraní
19.2
Přínosy práce pro teorii a praxi
117
na příkladu generování variabilních designů v rámci UIS. Popsány jsou také aplikace, které jsou k podpoře tohoto mechanismu potřeba. Poslední, 17. kapitola, obsahuje zobecnění představeného modelového příkladu. Součástí závěrečného shrnutí je definice osobních doporučení pro tvorbu uživatelsky přívětivého informačního systému na základě teoretických podkladů, vlastního výzkumu a praktických zkušeností.
19.2
Přínosy práce pro teorii a praxi
Shrnu-li přínosy disertační práce do přehledného a stručného výčtu, mohu uvést následující body: • definice Component boxing modelu, • rozdělení složek prezentační vrstvy a definice typů komponent (box, obsah boxu, vizuální prvek, design boxu), • nalezení komponent stránky, stanovení povinných, volných, vázaných komponent a typů vazeb, • rozklad stránky, sestavení hierarchického stromu a určení pravidel pro složení výsledného výstupu, • doporučení pro uplatnění komponentového přístupu, • praktické uplatnění komponentového přístupu demonstrované na příkladu generování variabilních designů v reálném webovém informačním systému. Podrobnější popis jednotlivých položek a jejich začlenění do celkového kontextu problematiky je možné nalézt v předcházející kapitole.
19.3
Doporučení k dalšímu pokračování práce
Dnešní informační systémy spějí ke komplexnosti a integrovanému, dnes často modernímu portálovému řešení, ovšem při zachování jednoduchosti a přehlednosti. Komponentový přístup k informačnímu systému prokazatelně tato řešení podporuje, neboť stanovením prvků na všech úrovních informačního systému a vazeb mezi nimi získáváme vysoce flexibilní systém otevřený dalšímu rozšiřování. Na úrovni prezentační vrstvy lze navázat na tuto práci pokračováním rozboru komponent této vrstvy, případně rozšířením výčtu sledovaných vlastností a úkolů prezentační vrstvy, které lze modelovat pomocí komponentového přístupu. Podobně jako v rovině prezentační je pro plně komponentový informační systém potřeba provést obdobný výzkum a rozbor vrstev aplikační a datové. Protože jednotlivé vrstvy spolu úzce spolupracují, je nutné nalézt a popsat též vztahy mezi vrstvami i mezi hraničními komunikujícími prvky těchto vrstev. Dalším krokem může být návrh, vývoj a implementace metasystému umožňujícího rychlý vývoj webových informačních systémů, jež jsou již od počátku svého návrhu budovány jako plně komponentově orientované.
19.3
Doporučení k dalšímu pokračování práce
118
Doporučením k pokračování práce je dále ověření, zda popsaná metodika podložená webovými informačními systémy a také na ně aplikovaná je zobecnitelná na jiné typy informačních systémů. Ve světě IT je mylné se domnívat, že vývoj nějaké myšlenky či produktu bude někdy ukončen. Při zodpovězení jedné otázky se vynoří několik jiných, hlubších, a vlastností zvídavého člověka je hledat další a hlubší odpovědi. Ohlédnutím zpět zjišťujeme, že všechny prvky tohoto souboru vědomostí a zkušeností do sebe zapadají. Přeneseme-li se k původní otázce uživatelsky přívětivých informačních systémů, jsem si jistá, že pokud lidé budou tvořit informační systémy pro sebe s nejlepším svědomím, bude se vývoj těchto systémů ubírat tím správným směrem. Vždy budou částečně splňovat požadavky uživatelské přívětivosti své doby a lidé budou hledat postupy, jak navrhnout systémy ještě o krůček lepší.
LITERATURA
119
Literatura Bartík, L. Portálová aplikace Záznamník učitele. [Diplomová práce.] Brno: Mendelova zemědělská a lesnická univerzita v Brně, 2003. 98 s. Brandejs, M. a kol. Univerzitní IS: předsudky, pověry, realita [on-line]. [cit. 13. 10. 2004]. Dostupné na: http://is.muni.cz/clanky/rufis2000.pl. Burbeck, S. Applications Programming in Smalltalk-80 (TM): How to use ModelView-Controller (MVC) [on-line]. [cit. 12. 4. 2003]. Dostupné na: http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html. Bušek, M. Personalizace: nová dimenze přístupu k zákazníkovi [on-line]. Příloha IT System 11/2001. [cit. 29. 3. 2003]. Dostupné na: http://www.systemonline.cz/site/prehledy systemu/crm/myrcom.htm. Carter, J. a kol. Oracle Application Server Portal Developer’s Guide, 10g (9.0.4) [on-line]. Part No. B13922-01. Redwood City, USA: Oracle Corporation, 2004. [cit. 11. 11. 2004]. Dostupné na: http://www.oracle.com/technology/products/ias/portal/index.html. Čermák, J. a kol. Universum 1–10. Praha: Odeon a Knižní klub, 2000–2001. 7200 s. ISBN 80-207-1060-4. Čírtek, A. Ideální portálová homepage: nesplnitelný sen? [on-line]. Článek na lupa.cz z 19. 4. 2002. [cit. 13. 10. 2004] Dostupné na: http://www.lupa.cz/clanek.php3?show=2232. Dařena, F. Jádro Univerzitního informačního systému. [Diplomová práce.] Brno: Mendelova zemědělská a lesnická univerzita v Brně, 2002. 59 s. Gray, D. Profesionální design na webu. Brno: SoftPress, 1999. 223 s. ISBN 80902824-1-5. Greenwald, R., Milbery, J. Oracle 9iAS Portal Bible. Wiley Publishing: Indianapolis, 2001. 955 s. ISBN 0-7645-4749-6. Hrnčárek, A. Firemní portál v prostředí Oracle Portal. [Diplomová práce.] Brno: Vysoké učení technické v Brně, 2002. 62 s. Lynch, P. J., Horton, S. Web: Guida di stile. Progettazione dei siti Web. Milano: APOGEO srl, 2001. 200 s. ISBN 88-7303-767-4. HyperText Markup Language (HTML) [on-line]. [cit. 25. 5. 2005]. Dostupné na: http://www.w3.org/MarkUp/. HTTP – HyperText Transfer Protocol [on-line]. [cit. 25. 5. 2005]. Dostupné na: http://www.w3.org/Protocols/. Kopeček, I., Kučera, J. Programátorské poklesky. Praha: Mladá fronta, 1989. 168 s. ISBN 80-204-0068-0. Kutín, A. Využití obecné kvalifikace v jádře IS. [Diplomová práce.] Brno: Mendelova zemědělská a lesnická univerzita v Brně, 2004. 85 s. Malina, P. Jak se tváří databáze? – Oracle 9i z pohledu uživatele. Článek na www.pcworld.cz z 11. 3. 2002 [cit. 10. 5. 2003].
LITERATURA
120
Manber, U., Pater, A., Robinson, J. Experience with Personalization on Yahoo! In Communications of the ACM. Volume 43, Issue 8 (August 2000). New York, USA: ACM Press, 2000. s. 35–39. ISSN 0001-0782. Manhartsberger, F. Portály se prosazují – zkuste to s nimi [on-line]. Článek na www.pcworld.cz z 21. 2. 2001 [cit. 20. 4. 2003]. Marchal, B. XML v příkladech. Praha: Computer Press, 2000. 447 s. ISBN 807226-332-3. Mobasher, B., Cooley, R., Srivastava, J. Automatic Personalization Based on Web Usage Mining. In Communications of the ACM. Volume 43, Issue 8 (August 2000). New York, USA: ACM Press, 2000. s. 142–151. ISSN 0001-0782. Morgan, E. L. Design Elements for Great Web Pages: Readability, Browsability, Searchability Plus Assistance [on-line]. [cit. 2. 4. 2003]. Dostupné na: http://www.infomotions.com/musings/design/. Mulvenna, M. D., Anand, S. S., Büchner, A. G. Personalization on the Net using Web Mining. In Communications of the ACM. Volume 43, Issue 8 (August 2000). New York, USA: ACM Press, 2000. s. 123–125. ISSN 0001-0782. Pazdziora, J. Converting Web Applications to Data Components: Design Methodology [on-line]. [cit. 9. 5. 2003]. Dostupné na: http://www.fi.muni.cz/~adelton/papers/compsac2001.ps. Pazdziora, J. Information System Development for Serving Environment With Rapidly Growing Numbers of Users [on-line]. [cit. 26. 3. 2003]. Dostupné na: http://www.fi.muni.cz/~adelton/papers/ssgrr2001.ps. Perugini, S. Program Transformations for Information Personalization [on-line]. [cit. 29. 10. 2004]. [Disertační práce.] Blacksburg, Virginia, USA: Virginia Tech, 2004. 156 s. Dostupné na: http://csgrad.cs.vt.edu/~sperugin/. Reenskaug, T. Curriculum vitae [on-line]. [cit. 17. 4. 2003]. Dostupné na: http://heim.ifi.uio.no/~trygver/trygve-CV.pdf. Riecken, D. Personalized Views of Personalization. In Communications of the ACM. Volume 43, Issue 8 (August 2000). New York, USA: ACM Press, 2000. s. 27–28. ISSN 0001-0782. Satrapa, P. Web Design. Liberec: Neokortex, 1997. 414 s. ISBN 80-902230-1-X. Sedláček, J. Internet II – Komerční využití. Praha: Vysoká škola ekonomická v Praze, 1999. 382 s. ISBN 80-7079-839-4. Schiller, M. Informační podnikové portály – Sybase má řešení [on-line]. Článek na www.pcworld.cz z 10. 5. 2000 [cit. 20. 4. 2003]. Smalltalk [on-line]. Wikipedia, the free encyclopedia. [cit. 20. 5. 2005]. Dostupné na: http://en.wikipedia.org/wiki/Smalltalk. Sundgren, B. We Want a User Friendly and Flexible System [on-line]. [cit. 16. 3. 2003]. Dostupné na: http://www.hhs.se/im/efi/bse.pdf. Šorm, M. Postup vývoje práce na fakultním a univerzitním informačním systému. In Sborník příspěvků Informatika IX./2001. Brno: Konvoj, 2002. s. 55–62. ISBN 80-7302-016-5.
LITERATURA
121
Šorm, M. Univerzitní informační systém. [Diplomová práce.] Brno: Mendelova zemědělská a lesnická univerzita v Brně, 2002. 98 s. Šorm, M. Datově řízený informační systém. In Informatika XI/2002 – Sborník příspěvků. Brno: Konvoj, 2003. s. 51–56. ISBN 80-7302-028-9. Šorm, M. Webové informační systémy. In MendelNet 2002/3. Brno: Konvoj, 2003. s. 327–334. ISBN 80-7302-048-3. Šorm, M. Využití principu skládání komponent při návrhu webového informačního systému. [Rozpracovaná disertační práce.] Brno: Mendelova zemědělská a lesnická univerzita v Brně, 2004. 73 s. Šorm, M. a kol. Fakultní informační systém. In Sborník příspěvků Informatika VII/2000. Brno: Konvoj, 2001. s. 50–113. ISBN 80-7302-011-4. Urbanec, J., Okrouhlý, J. Request Tracker – systém pro sledování požadavků [on-line]. Článek na root.cz z 19. 12. 2002. [cit. 29. 3. 2003]. Dostupné na: http://www.root.cz/clanek/1452. Voříšek, J. Informační technologie a systémová integrace. Praha: Vysoká škola ekonomická v Praze, 1996. 198 s. ISBN 80-7079-895-5. Voříšek, J. Informační systémy a jejich řízení. Praha: Bankovní institut, 1997. 278 s. ISBN 80-7265-002-5. XHTML(TM) 1.0 The Extensible HyperText Markup Language (Second Edition) [on-line]. ze dne 1. 8. 2002. [cit. 13. 12. 2004]. Dostupné na: http://www.w3.org/TR/xhtml1/.
PUBLIKACE AUTORA VZTAHUJÍCÍ SE K TÉMATU
122
Publikace autora vztahující se k tématu Netrefová, H. Uživatelská přívětivost Univerzitního informačního systému. In Firma a konkurenční prostředí 2002 – Sekce 6. IS/IT a konkurenceschopnost podniků. Brno: Konvoj, 2002. s. 99–104. ISBN 80-7302-036-X. Netrefová, H. Personalizace univerzitního informačního systému. In Univerzitní informační systém I. 1. vyd. Brno: Konvoj, 2003, s. 40–43. ISBN 80-7302-058-0. Netrefová, H. Personalization as a Part of Web Information Systems. In 4 th International Conference of PhD Students. Miskolc: University of Miskolc, 2003. s. 141–146. ISBN 963-661-589-6. Netrefová, H. Užití MVC paradigmatu při návrhu webových informačních systémů. In MendelNET 2003. Sborník příspěvků z konference studentů doktorského studia. Brno: Mendelova zemědělská a lesnická univerzita v Brně, vydáno dne 28. 10. 2003. 1. vyd. ISBN 80-7157-719-7. Dokument ve formátu MS Word. Netrefová, H. Uživatelem řízená navigace v univerzitním informačním systému. In MendelNet 2002/3. Sborník příspěvků z konference studentů doktorského studia. 1. vyd. Brno: Konvoj, 2003. s. 299–303. ISBN 80-7302-048-3. Netrefová, H. Základní designové prvky uživatelsky přívětivých informačních systémů. In Informatika XI/2002 – Sborník příspěvků. Brno: Konvoj, 2003. s. 34–38. ISBN 80-7302-028-9. Netrefová, H. Presentation of data in portal information system. In The 4 th annual of international conference IMEA 2004. Conference proceedings. 1. vyd. Pardubice: Univerzita Pardubice, 2004. s. 95–100. ISBN 80-7194-679-6. Netrefová, H. Úloha personalizace v IS pro řízení vztahu se zákazníky. In Informatika XV/2004 – Sborník příspěvků. 1. vyd. Brno: Konvoj, 2005. s. 80–83. ISBN 80-7302-067-X. Netrefová, H. Komponentový rozklad uživatelského rozhraní webového informačního systému. In Acta Universitatis Agriculturae et Silviculturae Mendelianae Brunensis. Vol. 3/2005. Brno: Mendelova zemědělská a lesnická univerzita v Brně, 2005. V tisku. Netrefová, H. Metody zavádění volitelných grafických designů v Univerzitním informačním systému. In Firma a konkurenční prostředí 2005. Brno: Konvoj, 2005. V tisku. Netrefová, H., Rybička, J. Modulární grafický design informačního systému. In Firma a konkurenční prostředí 2003 – Sekce 7. IS/IT a konkurenceschopnost podniků. Brno: Konvoj, 2003. s. 110–116. ISBN 80-7157-702-2. Netrefová, H., Šorm, M. Metody personalizace webových informačních systémů. In UNINFOS 2003 (Univerzitné informačné systémy). Zborník z medzinárodnej konferencie. Nitra: Slovenská poľnohospodárska univerzita v Nitre, 2003. s. 242– 245. ISBN 80-8069-241-6. Netrefová, H., Šorm, M. User-friendly Web Information systems. In Beyond the Network – Inovative IT-services: Proceedings of the 9 th International Con-
PUBLIKACE AUTORA VZTAHUJÍCÍ SE K TÉMATU
123
ference of European University Information Systems. Amsterdam: Universiteit van Amsterdam, 2003. s. 518–522. ISBN 90-9017079-0. Netrefová, H., Šorm, M. Úvod do projektu Roke. In Informatika XIII/2003 – Sborník příspěvků. 1. vyd. Brno: Konvoj, 2003. s. 23–28. ISBN 80-7302-055-6. Netrefová, H., Šorm, M., Motyčka, A. My University Portal as a Result of Personalization Process. In Leadership and Strategy in a Cyber-Infrastructure World. Proceeding of the 11 th International Conference of European University Information Systems. Manchester: University of Manchester, 2005. V tisku. Šorm, M., Netrefová, H. The Theory of Web Information Systems. In Beyond the Network – Inovative IT-services: Proceedings of the 9 th International Conference of European University Information Systems. Amsterdam: Universiteit van Amsterdam, 2003. s. 319–322. ISBN 90-9017079-0. Šorm, M., Netrefová, H., Motyčka, A. Nový pohled na návrh univerzitního informačního systému. In UNINFOS 2003 (Univerzitné informačné systémy). Zborník z medzinárodnej konferencie. Nitra: Slovenská poľnohospodárska univerzita v Nitre, 2003. s. 278–282. ISBN 80-8069-241-6. Šorm, M., Netrefová, H., Motyčka, A. Component boxing model as technology for building portals. In Innovation in a Changing World: Proceedings of the 10 th International Conference of European University Information Systems. Ljubljana: Faculty of Computer and Information Science, 2004. s. 520– 523. ISBN 961-6209-46-9. Šorm, M., Netrefová, H., Motyčka, A. Webové informační systémy: od dynamických stránek k portálům. In Sborník přednášek z konference Svět informačních systémů. 1. vyd. Zlín: Univerzita Tomáše Bati, 2004. s. 284–291. ISBN 80-7318-166-5.
Přílohy
A
A
SEZNAM POUŽITÝCH ZKRATEK
125
Seznam použitých zkratek
API B2E B2P CBM CGI CMS CLOB CPAN CSS DBI DDL DML ERD FIS HTML HTTP IS IT MVC MZLU OLAP OSSA PC PDF PEF PS RAD SIF SSH TODO UIS URL WIS WWW WYSIWYG W3C XHTML XML
Application Program Interface (aplikační programové rozhraní) Business to Employee Business to Partner Component Boxing Model Common Gateway Interface Content Management System (systém pro správu obsahu) Character Large Object Comprehensive Perl Active Network Cascading Style Sheet Database Interface Data Definition Language (jazyk pro definici dat) Data Manipulation Language (jazyk pro manipulaci s daty) Entity Relationship Diagram (entitně relační diagram) Fakultní informační systém HyperText Markup Language HyperText Transfer Protocol Informační systém Informační technologie Model-View-Controller Mendelova zemědělská a lesnická univerzita On-Line Analytical Processing Osoba spravující systémovou agendu Personal Computer (osobní počítač) Portable Document Format Provozně ekonomická fakulta PostScript Rapid Application Development (rychlý vývoj aplikací) Systémový integrátor fakulty Secure Shell To Do (udělat) Univerzitní informační systém Uniform Resource Locator (jednoznačné určení zdroje) Webový informační systém World Wide Web What You See Is What You Get World Wide Web Consortium eXtensible HyperText Markup Language eXtensible Markup Language
B
B
UKÁZKY DESIGNŮ UIS
Ukázky designů UIS
Obr. 28: Standardní design webových stránek MZLU v Brně
126
B
127
UKÁZKY DESIGNŮ UIS
Obr. 29: Původní žlutý UIS design
B
128
UKÁZKY DESIGNŮ UIS
Obr. 30: FIS revival v modrém tónu
B
129
UKÁZKY DESIGNŮ UIS
Obr. 31: Klasická linuxová konzole
B
UKÁZKY DESIGNŮ UIS
Obr. 32: Jednoduchý design vhodný pro GPRS spojení
