České vysoké učení technické Fakulta elektrotechnická
DIPLOMOVÁ PRÁCE
2000
Martin Fuchs
-2-
Čestné prohlášení Prohlašuji tímto, že veškeré výsledky jakož i závěry níže prezentované práce mohou být volně použity Katedrou počítačů elektrotechnické fakulty Českého vysokého učení technického v Praze. Dále prohlašuji, že jsem práci zpracoval zcela samostatně a citace použitých pramenů jsou úplné s odkazem na zdroj. V Praze dne 14. ledna 1999 ……………………
Abstrakt Práce se zabývá problematikou multimodálních uživatelských rozhraní. Analyzuje současný stav v tomto oboru a navrhuje možné řešení podstatných problémů a ověřuje jeho funkčnost. Jádrem projektu je návrh a specifikace speciálního jazyka pro popis dialogu mezi aplikací a uživatelem. Na něj navazuje implementace podstatných částí systému, tvorba testovacích aplikací a experimenty s jednotlivými módy komunikace (grafika, text, hlas atd…).
Abstract The work is focused on multimodal user interface research. Analyses actual state in this field and proposes possible solution of major problems and verifies its functionality. The base of the project is specification of a new special language, for description of dialog-based human-computer interaction. Follows implementation of main parts of the system and testing applications and experiments with multimodal communication (graphics, text, voice etc.)
-3-
1. Analýza problému Řešení zadaného problému bude spočívat v navržení komplexního systému realizujícího univerzální multimodální rozhraní, které by mělo zprostředkovat komunikaci mezi uživatelem a aplikací pomocí dialogů. Toto rozhraní by mělo být distribuované, tj. že jádro aplikační a uživatelská část systému mohou být fyzicky odděleny a spojeny obecným komunikačním kanálem splňujícím určité parametry. Samotný systém bude ve smyslu předchozí věty rozdělen na dvě části pracovně nazvané UserSide a ApplicationSide. Výsledkem práce by měla být implementace funkčního jádra obou těchto částí spolu s vytvořením API (aplikačního rozhraní) pro snadnou tvorbu aplikací na jedné straně a implementace různých koncových ovládacích zařízení pomocí níž bude možné aplikaci ovládat. Systém by měl být pro aplikaci transparentní, tj. že práce aplikace nebude závislá na způsobu jakým se na straně uživatele data prezentují respektive získávají. Na druhou stranu by implementace jednotlivých komunikačních prostředků neměla být závislá na aplikaci. Pro tento účel bude nutné vyvinout jednotný protokol komunikace obou částí, který předběžně dostal název DML (Dialog Markup Language). Na straně aplikace je cílem aby systém byl vyhovující pro implementaci jednoduchých úloh na úrovni odesílání elektronické pošty, hledání v databázi a pod. Na straně uživatele by měl systém být schopen pracovat s libovolným vstupním zařízením, které splňuje jednoduchá snadno odvoditelná kritéria. V prvním plánu se předpokládá ovládání obecné aplikace pomocí textového, grafického a hlasového terminálu, avšak systém by měl být navržen zcela univerzálně aby byl schopen práce s co možná nejobecnějším typem ovládacího prvku. Předpokládá se, že uživatelskou stranu budou kladeny ještě další doplňující nároky, za hlavní považuji libovolné přepínání komunikačních prostředků-módů a to opět zcela nezávisle na jádru aplikace a hlavně, v čemž se skrývá velký nedostatek mnoha již existujících a pracujících systémů, za běhu aplikace. Tento požadavek vyplývá z velmi časté potřeby uživatele dynamicky měnit formu komunikace podle požadavků aplikace.
obr. 1.1 - Principiální funkční schéma systému založeném na DML
-4-
2. Uživatelská rozhraní 2.1 Uživatelská rozhraní obecně Aplikace jako takové lze v prvním přiblížení rozlišit na dvě základní skupiny a to podle formy komunikace s uživatelem. V prvním případě je aplikace řízena uživatelským rozhraním na základě podnětů zvenčí. Tento model se nazývá „aplikace řízená událostmi“ a je aplikován především u složitějších systémů zejména v dnešních počítačových aplikacích, popřípadě přístrojích. Uživatelské rozhraní v tomto případě přijímá podněty od uživatele, přičemž má zároveň za úkol zobrazovat aktuální vnitřní stav aplikace. Obrázek znázorňuje funkci tohoto modelu:
obr. 2.1 – Aplikace řízená událostmi
Klasickým příkladem tohoto modelu je třeba ovládání textového editoru, kdy jistá událost generovaná uživatelským rozhraním (stisk tlačítka na klávesnici, volba z menu) vyvolá reakci uvnitř aplikace, která podle toho změní svůj vnitřní stav a zpětně vygeneruje odezvu na uživatelském rozhraní. Pod přístrojovou aplikací tohoto modelu si lze představit například ovládání CD přehrávače, kdy stiskem jednotlivých tlačítek vyvoláváme jednotlivé akce, popřípadě změny nastavení.
-5-
obr. 2.2
Druhý model je model dialogový, kdy řízení celého komunikačního procesu je na aplikaci samotné. Ta pracuje až do okamžiku, kdy potřebuje od svého uživatele získat nějaká data. V tom okamžiku se její běh přeruší a aplikace žádá uživatelské rozhraní o vytvoření „dialogu“ pomocí něhož jsou potřebná data získána. Ta si aplikace od rozhraní převezme a pokračuje v chodu, dokud nenarazí na nějaký další chybějící údaj. Tento model se používá většinou pro aplikace jednorázového charakteru, nebo pro aplikace jednoduché. Příkladem z počítačové praxe můžou být instalační programy které zabudovávají nějaký programový balík do systému počítače a přitom od uživatele zjišťují během instalace některé důležité údaje (např. sériové číslo, souhlas s licencí, umístění dat atd.) Příkladem přístrojové aplikace založené na dialogovém modelu je například bankomat. Klient vloží kartu a je dotázán na PIN a částku, kterou chce s konta vybrat. V obou příkladech je řízení celého procesu plně v řízení aplikace a uživatel v tomto modelu nemá jinou možnost ovlivnění aplikace než pomocí jednoznačných odpovědí na kladené dotazy. Oba dva modely mají své opodstatnění a velmi často dochází u složitých programových celků k jejich kombinaci. Kritériem pro rozlišení, kdy je daný model vhodný je především poměr dat, které má aplikace sama o sobě k dispozici (ať už dat předem daných či získaných jinou formou - například ze sítě či paměťových médií) ku kvantu dat, která musí od uživatele získat. Model událostní se hodí v případech, kdy „tvůrcem“ konečného stavu aplikace je především sám uživatel. Příkladem je opět textový editor, který sám o sobě nemá nijak danou představu o finální podobně textu, který pomocí něj uživatel tvoří a dotazovat se na jednotlivá písmena, slova či věty by bylo ve všech případech krajně neefektivní. Další opodstatnění má událostní model v případech, kdy aplikace běží časově nezávisle na uživateli (například zmiňovaný CD přehrávač).Naopak v okamžiku, kdy je dat
-6-
získávaných od uživatele relativně málo a aplikace je časově jednorázová se hodí model dialogový model, neboť je z lidského hlediska daleko přívětivější a v okamžiku kdy jeho implementace je kvalitní umožňuje ovládání aplikací neznalému a nezkušenému uživateli. Dialogové rozhraní se totiž chová z uživatelského pohledu jako „průvodce aplikací“, což je také důvod, proč je implementováno i do dnešních počítačových programových celků coby usnadňující pomůcka pro začínající uživatele (tzv. wizardy). S vývojem počítačových uživatelských rozhraní bylo vyvinuto mnoho forem komunikace. Na úplném počátku byly textové terminály, které dialog zprostředkovávaly pomocí klávesnice a nějakého výstupního zařízení schopného zobrazovat text (obrazovka, tiskárna). S tímto typem komunikace se setkáváme dodnes například na konzolích počítačů s OS UNIX. Postupem času se vzrůstajícími technickými možnostmi se vyvinula rozhraní grafická, která umožňovala prezentaci dialogu pomocí grafických elementů a ovládání pomocí snímačů souřadnic (myš, tablet, světelné pero). V poslední době se s nebývalou dynamikou rozvíjejí také hlasová rozhraní, která však stále ještě v nynější fázi neumožňují masové použití. Ke zprostředkování dialogu se užívají zatím jen velice omezeně jedním z mála praktických masových aplikací jsou hlasová rozhraní mobilních telefonů, která se díky limitovaným technickým možnostem omezují na rozpoznání několika málo příkazů.
2.2 Multimodální uživatelská rozhraní Definice významu slova mód není v technickém jazyce zcela jednoznačná, neboť pomocí pojmu mód jsou často označovány naprosto nesouvisející vlastnosti a jevy. Dokonce ani v tak úzce specializovaném oboru jako jsou uživatelská rozhraní existují pro výraz mód dva odlišné významy. Prvním je mód komunikace druhým pak mód interakční. Komunikační mód v souvislosti s uživatelskými rozhraními definuje (charakterizuje) určitý technický prostředek, pomocí kterého je komunikace realizována. Tento význam také odpovídá nejčastějšímu použití slova mód. Avšak módem je označován také obecně způsob, jakým uživatel k aplikaci přistupuje jako celku nezávisle na komunikačních prostředcích, souvisí tedy spíše se samotnou strukturou aplikace a formou její prezentace uživateli. Historicky samozřejmě uživatelská rozhraní vzešla z rozhraní jednomódových (mono-mode), která jsou úzce specializovaná a jsou přímo vázána na určitou platformu a typ ovládacích prvků. Postupem času došlo k přechodu na rozhraní multimodální a to jak z hlediska komunikace tak i interakce. Multimodalita samozřejmě klade zvýšené nároky na strojovou část systému, vedena snahou o co možná největší ovládácí komfort pro uživatele. Vrcholem dosavadního vývoje jsou patrně hypermediální aplikace, které nabízejí uživateli možnosti volby jak na poli komunikačního prostředku, tak i formy samotné interakce. Pokročilé hypermediální aplikace se pak liší pouze stupněm, jakým jsou schopny přizpůsobit se požadavkům a možnostem uživatele. Nižší formy umožňují komunikovat pomocí předdefinovaných módových konfigurací, pokročilejší pak jsou schopny dynamicky volit vhodný mód podle momentálního stavu komunikace. V hypermediálních aplikacích je možné definovat mnoho typových skupin módů. Jendu z nejpřehlednějších analýz multimodální komunikace přibližuje [2] pomocí tabulky definující k jednotlivým kategoriím módů jejich konkrétní typy a provádí jejich rozbor:
-7-
Kategorie módu Komunikační
Typ módu Příklady médium text, grafika, zvuk „řečnický“ styl stručný, podrobný, průvodce jazyk čeština, angličtina …. velikost/ začátečnický kurs = 10 kroků pokročilé ovládání = 50 kroků mocnost Interakční topologie sled, strom …. řídící pasivní, aktivní navigace, dotazy přístup Médium je vlastním nositelem informace mezi aplikací a uživatelem, například text, grafika, animace, atd. Je voleno především s ohledem na technické možnosti a přehlednost komunikace. Tento typ módu v sobě zahrnuje i kombinace různých jednodušších médíí, například text+grafika, nebo animace+zvuk. „Řečnický“ styl je volen především s ohledem na schopnosti samotného uživatele. Vyjadřuje složitost a objem dat, která uživatel musí pojmout ke správnému ovládání aplikace. Extrémními případy jsou „Guided tours“, které uživatele provedou co možná nejjednodušší cestou k požadovanému cíli, na straně druhé pak koncepty pro vysoce zkušené uživatele využívající všech možností nabízených aplikací, za minimální potřeby asistence. Jazyk zcela intuitivně má význam především v některých módech (text, mluvené slovo), kdy odlišuje národní jazyková specifika. Modální přizpůsobení se je někdy nazýváno lokalizací. Velikost je parametrem udávajícím mocnost komunikace v rámci již definovaného stylu. Například „Guided tour“ se může v systému vyskytovat v dlouhé a krátké verzi z nichž každá popisuje daný postup do určité hloubky. Topologie forma, jakou je stav aplikace prezentován uživateli. Může mít formu sekvence jednotlivých částí, formu řízeného průchodu stromem atd. Řídícím módem je charakterizována „aktivita“ aplikace ve spojení s uživatelem. Na jedné straně zde stojí model samostatné aplikace, která komunikuje s uživatelem pomocí jednoduchých dotazů jen v bezpodmínečně nutných případech. Na straně druhé pak model „aktivního“ uživatele, který má přehled o kompletním dění uvnitř aplikace a její stav dokáže měnit pomocí nejjemějších nástrojů přesně podle svých požadavků. Mód přístupu specifikuje, ze které strany pochází „iniciativa“ k řízení aplikace. Pokud aplikace navádí uživatele podle svých potřeb jedná se o mód navigační. V opačném případě, jde o mód dotazový, kdy aplikace poskytuje odpovědi na uživatelem kladené otázky. Jak je vidět, je teorie okolo modality uživatelských rozhraní na jedné straně metodicky velmi dobře propracovaná, na straně druhé však dosti komplikovaná, takže návrh multimodálních systémů natolik komplexních aby umožňovaly volnost a možnost volby v pokud možno co největším počtu módových typů je značně
-8-
náročný. Pro lepší ozřejmení významu pojmů zmiňovaných výše uvádím příklad konfigurace módů hypermediálního informačního systému, jak jej uvádí [2]: Typ módu řízení
Mód automatické (pasivní uživatel)
velikost médium
topologie
manuální krátká střední dlouhá grafika+ audio grafika text sekvence mříž
Typologie uživatelů:
Automatická navigace X X
Vizuální navigace
Textová navigace
Pokročilá navigace
X X
X
X
X X +
X X
X příležitostný uživatel
X X příležitostný uživatel uživatel znalý s orientací v problematice
X specialista
Při návrhu multimodální aplikace by dále měla být splněna některá další kritéria, která by především měla napomoci uživateli v orientování se v systému a jeho snadnému osvojení. 1. jednotlivé skupiny a konfigurace módů by měly být předem dané a fixní. Tato podmínka zajistí snadnou orientaci uživatele a zjednodušení volby módové konfigurace, která je většinou závislá na technických prostředcích které jsou k dispozici a na jeho vlastních schopnostech. 2. uživateli by mělo být umožněno i za běhu aplikace změnit módovou konfiguraci. Tato podmínka by měla být splněna pokud možno oběma směry, aby se uživatel mohl „posouvat“ na pomyslné ose složitosti ovládání jak k jednodušším řešením, má-li pocit, že se v aplikaci přestává orientovat, tak i k oblastem pokročilejším, pokud chce provést nějaké náročnější operace. 3. aplikace/multimodální rozhraní by pokud možno měly podporovat automatickou adaptaci módové konfigurace. Ve většině případů se však tato adaptibilita realizuje formou „doporučení“ nikoli přímé změny módové konfigurace aby se předešlo komplikacím v podobě ztráty orientace. Uvedený rozbor analyzuje multimodální rozhraní v co možná nejširší obecnosti v čistě teoretické rovině. Je evidentní, že v možnostech limitovaných obsahem práce není možné navrhnout komplexní multimodální rozhraní v celé jeho šíři a proto byla za předmět práce vybrána jenom úzká součást teorie multimodálních rozhraní, konkrétně jeden módový typ. V dalším textu bude tedy pojem „multimodální komunikace“ a „multimodální rozhraní“ zmiňován ve smyslu média. Práce si již v zadání vytkla za cíl popsat a experimentálně ověřit vybrané mechanizmy týkající se právě různých typů komunikačních médií s důrazem na alternativní formy ovládání aplikací.
-9-
2.3 Modely UI Pro popis interakce počítače s člověkem bylo nalezeno několik různých nezřídka velmi odlišných modelů. Většina z nich popisuje uživatelské rozhraní z pozice technické a programátorské. Následujících několik modelů by se dalo považovat za základní a výchozí body bádání o uživatelských rozhraních. Seeheim model reprezentuje jedno z nejlepších řešení modelace uživatelského rozhraní. Sestává se z následujících bloků: • prezentační komponenta - popisuje objekty interakce na lexikální úrovni • dialogová komponenta - popisuje strukturu a elementy dialogu a jejich chování na úrovni syntaxe • aplikační rozhnaní - popisuje účel a funkci dialogu v daném kontextu aplikace na sémantické úrovni. Seeheim model uživatelského rozhnaní Uživatel
Prezentační komponent a
Dialogová komponent a
Prezentační komponenta
Počítač
Zpětná vazba obr. 2.3
Seeheim model je samozřejmě velmi obecný a pro konstrukci dnešních komplexních uživatelských rozhraní nevhodný neboť nepopisuje interakce na nižších a konkrétnějších úrovních. Proto byl rozšiřován doplňován a přizpůsobován do modelů dalších. Jeho význam tkví právě v tom, že je v principu společným jmenovatelem mnoha dalších popisů.
- 10 -
Arch model Arch model je provozním modelem interaktivního systému a proto představuje lehce odlišný přístup. Místo zkoumání funkcionality interaktivního systému za účelem oddělení funkce uživatelského rozhraní od „zbytku“ autoři tohoto modelu zkoumali podstatu dat předávaných mezi těmito dvěma komponentami (tzn. mezi komponentami výkonnými a interaktivní složkou). Je založen na rozdělení funkcí (řízení a re-organizace dat, vlastního výkonu operace, podpory uspořádání operací, volby komunikačních medií, podpory fyzické interakce s uživatelem a převodem formalizmů mezi výkonnou a uživatelskou složkou) které jsou nezbytné pro všechny interaktivní systémy respektujíce různé úrovně důrazu na jednotlivé komponenty. Komponenty jsou definovány následujícím způsobem: • Výkonná komponenta - přijímá vysílá a manipuluje data a provádí další funkce pecifické pro danou úlohu nebo její část. • Interakční komponenta (Interaction Toolkit) - implementuje fyzickou interakci s uživatelem (software i hardware) • Dialogová komponenta - je zodpovědná za členění úloh do částí a to jak pro uživatele tak pro na něm závislou část „vnitřního“ softwaru. Navíc je zodpovědná i za vnitřní konzistenci několikanásobných různých uživatelských pohledů na stejná data a za zmiňovaný převod formalismů. • Prezentační komponenta - představuje datový prostor spojující dialogovou a výkonnou komponentu včetně potřebné specifikace. Jedná se o sadu objektů využívaných dialogovou komponentou, které jsou na interakční (Toolkit) nezávislé. Příkladem je třeba valuátor, který může být v toolkitu reprezentován jak posuvným prvkem (slider) tak otočným (dial). Rozhodování mezi možnými typy prezentace činí právě prezentační komponenta. • Adaptační komponenta - reprezentuje složku starající se o operace převodu mezi dialogovou a výkonnou částí. Jsou zde implementovány operace nutné pro správnou funkci a vzhled uživatelského rozhraní, které nejsou součástí výkonné složky (například řazení seznamu položek uživatelského výběru). Stará se také o kontrolu a organizaci vstupních dat a detekuje sémantické chyby. Dále v modelu vystupují tzv. objekty pod kterými se rozumí: • Výkonné objekty - uchovávají a předávají data pro výkonnou komponentu nutná k její funkci avšak jejich struktura nemusí nutně souhlasit se strukturou s uživatelským rozhraním. Z druhé strany k nim přistupuje adaptační komponeta která do nich transformuje výsledky interakce s uživatelem a řídí tak chod výkonné části. • Prezentační objekty - jsou objekty řídící interakci s uživatelem. Obsahují data prezentovaná uživateli a události vyvolané uživatelem. Jejich forma však nezávisí na prezentačním médiu (například: „Výběrový dialog o 20 položkách s možností zvolit jen jednu z nich“).
- 11 -
Arch model - model interaktivního systému pracujícího v reálném čase Dialogová komponenta Výkonné objekty
Prezentační objekty
Adaptační komponenta
Preze ntační komponenta
Interakční objekty
Výkonné objekty
Výkonná komponenta
Interakční komponenta
obr. 2.4
• Objekty interakce - objekty navržené pro přímý dialog s uživatelem. Jsou podporovány Interakčním Toolkitem. Například: Dvě tlačítka umožňující aktivaci pouze jednoho z nich. Model byl navržen speciálně pro minimalizaci budoucích problémů spojených s vývojem technologií hlavně hardwarových. Je zřejmé, že vrstvy zde tvoří přesně ohraničené úrovně abstrakce, které mohou být měněny a upravovány v principu nezávisle na sobě. TAM model (Triple Agent Model) Tento přístup prezentuje pohled na řízení obecného procesu z pohledu uživatele. Sice plně neodpovídá dnešnímu pojetí požadavků na uživatelská rozhraní jako je komplexní grafická prezentace, mnohaprvková interakce a proměnou na obsahu závislou formou prezentace. Avšak pro potřeby návrhu jednoúčelových rozhraní ke konkrétním úlohám poskytuje značnou názornost a přehlednost.
- 12 -
TAM model interakce člověka a počítače Uživatel
Uživatel přímo zasahuje do provádění úlohy
(6) Zpětná vazba (8) (9) (10)
Uživatel řídí úlohu zprostředkovaně (7)
a
Úloha
Úloha je přímo pozorována uživatelem (1) Řízení úlohy a detekované stavy (3)(4)(5)
nastavení
Zprostředkovávací složka
Řídící složka Úloha je uživatelem sledována zprostředkovaně (2)
obr. 2.5
Popis vazeb jednotlivých komponent: 1. Činnost je přímo sledována uživatelem. 2. Činnost je pozorována nepřímo pomocí čidel a zobrazovacích jednotek řízených výkonnou jednotkou (Task Machnine). 3. Činnost je řízena v automatickém režimu 4. Činnost je ovlivňována výkonnou jednotkou na základě zjištění nějakého stavu (údaje čidel atd.) 5. Činnost způsobí změnu parametrů a je jimi sama ovlivněna (zpětná vazba). 6. Uživatel přímo ovlivňuje činnost 7. Uživatel ovlivňuje činnost přes ovládací prvky výkonné jednotky přes dialogovou jednotku. 8. Uživatel přijímá zpětnou vazbu od dialogové jednotky [9] Uživatel mění parametry procesu přes dialogovou jednotku Uživatel mění parametry nastavení
3. Dialogové UI 3.1 Definice dialogového UI Jedna s forem komunikace člověka a stroje je řízený dialog. Dialog se dá definovat jako skupina komunikačních elementů, které zprostředkovávají přenos informace a spolu tvoří jistý uzavřený celek. V souvislosti s komunikací mezi lidmi je pojem zcela intuitivně chápán jako akt, kdy si dvě osoby vyměňují informace pomocí mluveného slova popřípadě gest. Funkci komunikačních elementů v tomto případě plní slova respektive věty a jiné vyjadřovací prostředky, které mají určitou informační hodnotu. V terminologii počítačové je význam slova dialog lehce posouván a to do roviny elementární výměny informace mezi člověkem a strojem, přičemž chápání dialogu jako takového je mnohem více specifikováno. Na rozdíl od „lidského“ dialogu musí být dialog mezi počítačem a strojem strukturován do určitých standardizovaných bloků dialogových elementů. Je tomu tak především z důvodu zpracování dat, neboť dnešní technická úroveň zatím nedovoluje strojům (počítačům) komunikovat na
- 13 -
lidské úrovni. Pro usnadnění komunikace mezi strojem a člověkem dochází k zavádění dalších informačních kanálů, než jen mluvené slovo, tedy například grafiky, psaného textu, zvuku a podobně. Definice 1: Dialog jako takový je v práci chápán jako uspořádaná konečná posloupnost dialogových elementů, jež jsou na sobě nezávislé, avšak jejich výstupy jsou zpracovány a odeslány aplikaci najednou. Definice 2: Dialogový element je funkční prvek jehož obsah, ať už pomocí dialogu proudí od uživatele k aplikaci nebo opačně je z hlediska aplikace dále nedělitelný. S praktickým použitím dialogových uživatelských rozhraní se můžeme setkat jak v dnešním světě výpočetní techniky, kde mají však jen už velmi okrajové uplatnění a jsou vytlačovány rozhraními na základě zpracování událostí, tak především v daleko méně náročnějších aplikacích, kde není k dispozici tolik kvalitních komunikačních prostředků jako u dnešních PC (barevný displej s vysokým rozlišením, zvukový výstup). Mezi tyto patří například elektronicky řízené stroje a přístroje (měřící technika, obráběcí stroje), telekomunikační technika (telefony, vysílačky), domácí spotřebiče (televize, automatická pračka) a mnoho dalších aplikací. Základním rysem optimálního použití dialogových uživatelských rozhraní je relativně malý tok informací od uživatele k aplikaci. Výhodné jsou zejména pro aplikace předpokládající neznalého nezkušeného uživatele, neboť jsou relativně jednoduché a přehledné. Tato relativní jednoduchost je na druhé straně vyvážena jen velmi omezenými možnostmi prezentace popřípadě získávání nějaké složitější strukturované datové struktury.
3.2 Elementy dialogů Základními kameny každého dialogu jsou dialogové elementy. Forma dialogových elementů se v průběhu vývoje uživatelských rozhraní vyvíjela jednak podle prostředků, které byly technickým vybavením poskytovány k jejich realizaci, tak i s vývojem aplikací a oblastí jejich použití. V počátcích vývoje počítačových uživatelských rozhraní byly počítače používány především k hromadnému zpracování dat, tudíž mezi první požadavky na uživatelské rozhraní patřilo vstup a výstup textu. S postupným vývojem aplikací se k nim přidal i výstup grafické informace a zvuku, na straně vstupní pak požadavek na ovládání aplikace přes víceméně standardní vstupní zařízení (klávesnice, myš) až po speciální (hlasový vstup, dotykový displej, scaner). Z důvodu snadné implementace, tak i z důvodu přehlednosti a jednoduchosti aplikace bylo ale nutné nezavádět dialogových elementů mnoho. Dialogový element totiž představuje bod, ve kterém se v řetězci mezi mezi digitálním světem aplikace a reálným světem člověka stýká na jedné straně možnost aplikace jednoznačně analyzovat přijímaná data na straně druhé možnost uživatele přizpůsobit své myšlení a tím i svou práci digitálnímu „vnitřku“ aplikace.
- 14 -
obr. 3.1
Proto je od počátku vývoje dialogových UI zřetelná snaha vybrat z množiny všech myslitelných dialogových elementů co možná nejmenší množinu, která by postačovala aplikaci k její zdárné funkci. Každý nový dialogový element znamená totiž jistou zátěž pro uživatele. Na cestě od člověka k dialogovému elementu je třeba naučit se dialogový element rozlišit od jiných, pochopit co jsou jeho vstupy a výstupy a naučit se ho správně ovládat. Na druhou stranu však nelze počet dialogových elementů snižovat za určitou mez, protože potom by aplikace některé své požadavky neměla možnost uplatnit, nebo by si pomocí této „přehnaně redukované“ množiny elementů počínala značně neefektivně. Dialogové elementy stejného typu by měly být na straně uživatele pokud možno stejně reprezentovány a stejným způsobem ovládány nezávisle na svém datovém obsahu. Pokud je nutné je měnit v závislosti na obsahu, tak by to nemělo do jejich stavby v žádném případě zasaženo tak, aby byly zaměnitelné za elementy jiné. Velký průlom nastal v tomto směru s rozšiřováním různých UI standardů ať už byly samostatné (například MOTIF) nebo byly zahrnuty jako součást operačních systémů (Windows, Epoc). Při psaní aplikací běžících pod těmito standardy byly už dialogové elementy předem dány, což uživateli usnadňuje orientaci. Elementů je v těchto systémech definováno samozřejmě daleko více, než vyžaduje průměrná aplikace, ale tyto množiny jsou navrženy více méně univerzálně a pokud si je uživatel osvojí, tak automaticky umí ovládat (alespoň na úrovni pochopení požadavků) s libovolnou aplikací na dané platformě.
- 15 -
obr 3.2 – Příklad zpracování dialogu …Microsoft Windows
obr. 3.3 – Příklad zpracování dialogu …Sony CMD Z1
Jedná se samozřejmě o příklady z grafických uživatelských rozhraní, které jsou snadno nasnímatelné a přetisknutelné.
3.3 Výběr dialogových elementů pro DML Jak již bylo řečeno v analýze problému (kap. 1) DML má být univerzálním komunikačním prostředkem mezi uživatelskou a aplikační stranou systému. Dříve než bylo specifikováno DML jako takové, bylo nutné pro něj vymezit oblast, nad
- 16 -
kterou bude definováno. Jelikož navrhovaný systém realizuje styk uživatele a aplikace pomocí dialogů, je naprosto klíčovým problémem vybrání odpovídajících dialogových elementů. Ty na jedné straně vymezují možnosti celého systému, na straně druhé předurčují spolu s dalšími faktory způsob návrhu DML jako takového. Při výběru vhodných elementů pro DML byl učiněn pokus o vytvoření co možná nejmenší množiny která je nezbytná k realizaci pokud možno drtivé většiny dialogů realizovaných v dnešních počítačových a elektronických systémech. Po zevrubnější analýze se ukázalo, že dialogových elementů splňujících v podmínky členství v této množině je relativně málo, kterýžto předpoklad byl vlastně prvotním impulzem k úvahám o univerzálních dialogových systémech a této práci vůbec. Při jejich výběru jsem se nechal inspirovat předchozím pokusem o definici DML (viz. [1]). Další podklady poskytlo studium jazyka HTML (Hypertext Markup Language) používaném pro kódování WWW stránek a který obsahuje velmi redukovanou, byť podle rozsahu a oblíbenosti aplikací řízených pomocí Internetu zcela dostačující sadu elementů pro definici dialogu. HTML sice neobsahuje sadu elementů zcela ideální, avšak pro málokterý takovýto standard je jeho funkčnost ověřena každodenní praxí tak dokonale. Pro realizaci dialogu v DML systému byly zvoleny následující elementy: • Zpráva Element realizuje sdělení krátké textové informace uživateli.
• Jednoduchá otázka Uživateli je položena otázka, na kterou je očekávána odpověď buď „Ano“ nebo „Ne“ • Výběr z několika možností Element je v jistém smyslu rozšířením předchozího. Jádro tvoří otázka, na kterou může uživatel odpovědět jednou z odpovědí z množiny, která je nadefinovaná aplikací. • Zadání textu Jedná se o element realizující získání krátké textové informace od uživatele. Předpokládá se, že text by měl být na jedné řádce a měl by být předpokládaným typickým zařízením prezentovatelný najednou. • Rozšířené zadání textu V mnoha ohledech se tento element shoduje s předchozím, leč předpokládá se, že text bude daleko většího rozsahu (mnoho řádek), nebude se jednat o jeho prosté zadání, ale o jeho editaci (tzn. předpokládá se vracení se k již zadanému textu a jeho úpravy). • Zadání čísla
- 17 -
Uživatel pomocí elementu sdělí aplikaci číselnou hodnotu. Element je do výběru zařazen s ohledem na fakt, že číslo nemusí být vždy interpretováno jako posloupnost číslic (na což by plně postačil element textový), ale i například jako souřadnice od počátku. Dialogové elementy definované předchozím výčtem tvoří základní množinu elementů zpracovávaných systémem založeným na DML. Tato množina by se dala zcela nepochybně dále optimalizovat s jak ohledem na počet dialogových elementů (redukce složitosti z hlediska uživatelského rozhraní) tak na požadavky aplikací, nicméně dovolím si tvrdit, že nikdy současně. Zcela jednoduchou úvahou nás napadá, že například element otázka by se dal velmi jednoduše nahradit aplikací správně nadefinovaným elementem výběr z možností avšak z hlediska uživatele by došlo ke značnému znepřehlednění dialogu jako takového. Navíc úspora programových prostředků v důsledku této redukce by byla naprosto minimální, protože implementace elementu otázka je velice jednoduchá. Podobné argumenty hovoří i proti sloučení elementů text a rozřířený text ať už v prospěch libovolného z nich. Oproti HTML došlo k částečné redukci množiny elementů ovšem při zachování plné funkčnosti a přenositelnosti, což jasně dokazuje konverzní tabulka v kapitole 4.5. Ve vztahu k původní verzi DML (viz. [1]) došlo na jedné straně k rozšíření o element rozšířený text (důvody k jeho zavedení jsou dostatečně rozebrány výše) tak zároveň k vypuštění komponent reprezentujících zadávání data a času. Ty, vzhledem k záměru používat DML nejen v oblasti počítačů ale i obecnějších elektronických aplikací už zdaleka nemají tak nevyvratitelné postavení, jako v počítačích samotných. Navíc se dá zadávání data velmi úspěšně implementovat pomocí stávajících elementů za vydatné pomoci dalších nástrojů zabudovaných do DML popsaných v kapitole 4.4.
3.4 Modifikátory Při úvahách o dialogových uživatelských rozhraních v souvislostech jak definitorických tak implementačních vyvstala otázka, zda by nebylo účelné, kromě hlavního informačního toku na trase aplikace-uživatel-aplikace (aplikace dodá „podklady“, uživatel zodpoví požadovanou otázku/zadá data a předá je aplikaci) definovat ještě jeden informační kanál na trase uživatel-aplikace. Hlavní účel tohoto kanálu byl spatřován informování aplikace o okolnostech zpracování daného elementu. Tyto informace nijak nesouvisí s vlastním obsahem dialogu, přesto mají pro aplikaci v mnoha ohledech klíčový význam. Klasický případ využití takovéhoto kanálu je informování o způsobu ukončení zpracování jednotlivého elementu. V dnešních vyspělých UI systémech bývá zvykem, že uživatel nemá zadávaná data možnost pouze odeslat aplikaci, ale má možnost například celý stornovat, nebo si k danému elementu vyžádat nápovědu. Informace o těchto aktivitách nejsou jakýmkoli způsobem zakódovatelné do výstupních dat elementů (alespoň v obecné rovině) a proto byl pro ně v rámci projektu DML vymezen pojem modifikátory. Modifikátory jsou na cestě od UI k aplikaci přenášeny společně s vlastními získanými daty. Každý dialogový element podává po svém ukončení aplikaci zprávu ve které jsou obsaženy modifikátory a jeho případná výstupní data. Modifikátory
- 18 -
nelze předávat aplikaci nezávisle, neboť proces zpracování dialogového elementu je z pohledu aplikace blokující. Existence modifikátorů lehce přibližuje možnosti dialogových rozhraní možnostem rozhraní zpracovávajících události. Do oblasti modifikátorů lze s úspěchem zařadit například existenci takzvaných horkých kláves či jiných podnětů zpracovávaných uživatelským rozhraním. V rámci projektu DML byly definovány následující modifikátory. Seznam uvádí jejich přehled spolu s popisem a důvody jejich existence. • standardního ukončení - dialogový element byl ukončen standardně • storno - dialogový element sice může obsahovat data, ale ta jsou na přání uživatele neplatná. • nápověda - uživatel si během dialogu vyžádal od aplikace nápovědu k danému elementu • vypršení časového limitu - tento modifikátor má význam pouze u časově limitovaných vstupně výstupních zařízení. Klasickým příkladem je například hlasové rozhraní, nebo rozhraní pro komunikaci morseovou abecedou, kdy je datový tok pokládán za přerušený, když se odezva nedostaví do určitého časového intervalu od výzvy. Tento stav by samozřejmě šel ošetřit pomocí modifikátoru storno avšak takto je aplikaci ponechána možnost považovat data buď za celkově neplatná, nebo jenom neúplná (což u některých elementů může mít své opodstatnění). • chyba - Při zpracovávání elementu došlo na straně UI k chybě. Data jsou neplatná. • horká volba - Tyto modifikátory jsou velmi diskutabilní částí návrhu DML. Jejich zavedení je jistou formou snahy o vypořádání se s problémem událostí typu „horká klávesa“ v průběhu zpracovávání dialogu. Bohužel tyto události zatím nejsou nijak standardizovány a proto není jiné cesty, než je ponechat ve specifikaci DML systému nedefinované s dodatkem, že pokud vznikne potřba tyto modifikátory používat, musí je podporovat jak aplikace, tak moduly uživatelských rozhraní vystavěné nad systémem DML na základě nějakého dodatečného standardu nadřazenému DML. Modifikátory jsou pro všechny dialogové elementy společné a jsou závislé pouze na způsobu chování uživatele během jejich zpracovávání. Zneplatňování či jiné operace nad daty na základě modifikátorů provádí až aplikace. Uživatelská část systému má za povinnost předat získaná (byť i neúplná) data tak jak jsou pouze z daným modifikátorem aby aplikace v případě potřeby mohla nakládat i s těmito.
4. Jazyk DML 4.1 Motivace V analýze (kap 1) byla naznačena snaha řešit komunikaci mezi aplikační a uživatelskou částí systému pomocí nějakého standardizovaného protokolu. Tento komunikační protokol by měl pracovat obousměrně a měl by přenášet definici dialogu směrem od aplikace k uživatelskému rozhraní a data dialogem získaná směrem opačným.
- 19 -
V průběhu úvah bylo upuštěno od komunikace pomocí přenosu datových objektů a pozornost byla zaměřena na zakódování přenášených dat do textu. Tento způsob má v dnešní době velkou perspektivu, vzhledem k tomu, že text na rozdíl od složitých binárních konstrukcí je schopno přenášet většina v současné době používaných sítí a komunikačních rozhraní. Dále je tento způsob výhodný z mnoha dalších hledisek, například jednoduché čitelnosti a srozumitelnosti pro potřeby ladění, snadné začlenění do stávajících médií (WWW, SMS-zprávy a pod.) a v neposlední řadě relativní jednoduchost kódování a dekódování. K realizaci tohoto protokolu bylo potřeba definovat jazyk, který budou obě strany schopny za vynaložení pokud možno minimálních implementačních prostředků interpretovat. Jazyk byl nazván DML (dialog markup language) a byl definován na základě v současnosti dynamicky se rozvíjejícího standardu XML (viz. kap 4.2). XML bylo zhodnoceno jako plně postačující pro definici DML, navíc pro jeho použití hovoří, jak v velmi propracovaný teoretický základ, na kterém stojí, tak jeho velká popularita, která s sebou přináší množství usnadnění a implementačních nástrojů, která se dají při praktické realizaci DML systému využít. Další výhodou definice jazyka pomocí XML je možnost jeho sekvenčního zpracování na obou stranách.
4.2 XML Jazyk XML je v současnosti nejčastěji zmiňován v souvislosti s Internetem jako nástupce již v mnohých ohledech nevyhovujícího HTML. Jeho podstata je však daleko širší, neboť se jedná o zcela obecnou normu tvorby dokumentů u níž dochází ke zcela zásadnímu posunu chápání kódování dokumentu jako celku. HTML je klasickým příkladem „starého“ chápání dokumentu, kdy byla vlastní povětšinou textová a obrazová informace obohacena o data, která měla definovat speciální vlastnosti týkající se jejich zobrazení. Mezi tato pojetí se neřadí ale jen HTML a některé ostatní „Markup Languages“ ale i uzavřenější dokumentové formáty svázanými například s různými aplikacemi (Microsoft Office, Adobe PDF). Ve všech těchto formátech se informace přidávaná k vlastnímu obsahu týká přímo formy jakou mají být uživateli dokumentu prezentovány. Příklad se dá uvést v relativně čitelném HTML: Jaroslav Foglar Každý chápe, že tímto zápisem chce tvůrce HTML stránky zvýraznit jméno autora textu tím, že přikáže prohlížeči, aby jej vypsal červenou barvou. Tato filozofie byla dlouho pokládána přijatelnou, až do doby kdy dokumenty v elektronické formě zaplavily (především díky rozmachu Internetu) svět a v dnešním stavu je orientace v nich velice obtížná. XML je jedním z prvních dokumentových formátů, které přicházejí s diametrálně odlišným přístupem. V dokumentech XML totiž nejsou data „značkována“ podle formy, jakou se mají prezentovat, ale podle významu. Zápis předchozího příkladu v XML by tedy mohl vypadat asi takto: Jaroslav Foglar
- 20 -
Hned na první pohled je patrný posun a zjevná výhoda, co se týče například vyhledávání. V „dřívější“ koncepci jsme si museli vystačit z fulltextovým vyhledavačem. Ten na malé dokumenty úplně postačoval, avšak ve větším rozsahu dokumentů není příliš použitelný (viz. situace s vyhledavači v dnešním Internetu). Naproti tomu v dokumentech XML by jednoduše šlo zadat vyhledavači aby našel veškeré texty, jejichž autor je Jaroslav Foglar, čímž bychom vyřadili veškeré odkazy na recenze jeho děl, fan kluby a podobně. Další možnosti jsou nasnadě. Patří mezi ně například takřka ideální výchozí pozice pro jakoukoli konverzi do jiného formátu nebo snadná orientace i v samotném zápisu dokumentu. Je evidentní, že informaci upřesňující jak se která část textu má zobrazit nelze při složitosti dnešních dokumentů jejich tvůrcům odepřít, avšak další velký posun spočívá v jejím oddělení ze samotného dokumentu. Parametry prezentace se ukládají mimo hlavní dokument v podobě takzvaných stylů. Pojem styl není nikterak nový a pro některé pokročilejší formy formátování ho používá i například dnešní HTML. V tomto případě se ale jedná spíše o prvek doplňkový, který měl otevřít další možnosti, kdežto u XML je existence stylu nutnou podmínkou pro prezentaci. Tím se odbourává klasický nešvar HTML, kde se pomocí stylů řeší pouze ty požadavky, které nelze uspokojit jakkoli jinak. Vlastní strukturou je XML velice podobné právě výše několikrát zmiňovanému HTML. Dokument XML se skládá z vlastního textu a takzvaných tagů, které zajišťují formátování dokumentu. Oproti HTML však může být název tagu zcela libovolný. Tímto lze celkem přesně v rámci jednoho dokumentu definovat významy jednotlivých částí. V návaznosti vytvořený styl pak jednotlivým tagům přisoudí prezentační vlastnosti. Výhodou je, že styly se dají libovolně mezi dokumenty sdílet, takže prezentace dokumentů vytvořených pomocí stejných (významových) tagů bude jednotná. Na druhou stranu lze změnou či záměnou stylu zcela změnit formu prezentace dokumentu například v souvislosti s platformou nebo technickými možnostmi zařízení, na nichž prezentace probíhá (obrazovka, tiskárna ....). Příkladem XML dokumentu může být: <JMENO> Mixus Boardus U Sněžné Muldy 23 <MISTO> Horská Kamenice 0603 112 777 Kromě stylů je u XML podstatný ještě jeden datový zdroj a tím je definice typu dokumentu - DTD. Jak již bylo naznačeno, v rámci XML je možné si definovat libovolnou množinu tagů, avšak je evidentní, že v těchto definicích nemůže panovat naprostá anarchie. XML dokument musí mít tedy celkem přesně definovanou strukturu, která je popsána v DTD. DTD definuje jednak množinu tagů, ale také množinu jejich parametrů a celkovou syntaxi dokumentu. DTD pak slouží jako výchozí bod pro parser XML který podle něj je schopen ověřit správnost zápisu celého dokumentu popřípadě jej interpretovat. Jako nejvyšší strukturu DTD je nutné nadefinovat vůbec název typu dokumentu, což se činí následujícím zápisem:
- 21 -
Tento zápis může být i přímou součástí XML dokumentu, ale, jak již bylo řečeno, nemusí a většinou nebývá. Na místě teček je pak zapsána vlastní definice dokumentu, která obsahuje především definici elementů. Má víceméně formu gramatiky, vymezující, které elementy se mohou vyskytovat v jakých částech dokumentu a s jakými atributy. Je evidentní, že v uvedeném krátkém XML příkladě nemají tagy a <MISTO> smysl mimo vnitřek tagu a právě toto je jedna z vlastností, které lze pomocí DTD vyjádřit následujícím způsobem: Zápisem je řečeno, že uvnitř tagu se může vyskytovat pouze tag bezprostředně následovaný tagem <MISTO>. Dále lze definovat i atributy jednotlivých elementů. Pro demonstraci uvádím opět definici syntaxe tagu z předchozího příkladu: Tím bylo nadefinováno, že tag má jeden atribut, který může nabývat hodnot „domu“, „doprace“, „mobil“, přičemž pokud definován není (je nepovinný) parser dosadí za jeho hodnotu „domu“. Tyto malé příklady samozřejmě nevystihují plnou šíři všech možností definic dokumentů. DTD je nástrojem velice robusním a umožňuje definici i velmi rozsáhlých a složitých gramatik jazyků. Pro demonstraci uvádím příklady dnes již existující a volně dostupných DTD známých dokumentových formátů: Hypertext markup Language (HTML) - jazyk pro tvorbu WWW stránek. K dispozici jsou DTD pro jednotlivé verze 2.0, 3.2, 4.0 DocBook - DTD podporované již mnoha aplikacemi na tvorbu a práci s technickou dokumentací MathML - jazyk pro zápis matematických formulí. Zde se naplno uplatňují možnosti XML neboť pomocí MathML jde vystihnout nejen vzhled formule, ale i její obsah a význam. atd... Vlastní syntaxe XML se, kromě omezení definovaných v DTD řídí ještě několika všeobecnými podmínkami, které nejsou z jeho předchůdce (HTML) tak úplně zřejmé. Jednou z hlavních je, že celý dokument musí být uzavřen v jednom tagu, například: .... obsah
- 22 -
Dále pak každý tag musí mít definován jak svojí počáteční (logicky) tak i svou koncovou část. Takže v HTML zcela běžné samostatné tagy nebo
nejsou v XML možné. Stručný úvod do problematiky XML zde uváděný si zdaleka neklade za cíl býti komplexním výkladem. Spíše se zaměřoval na praktické skutečnosti, nutné k pochopení proč byla platforma XML využita pro řešení zadaného úkolu, případě napomoci alespoň částečné orientaci v DTD definicích jazyka DML který je jedním z hlavních produktů této diplomové práce. Daleko šířeji se oblastí spojenou s XML zabývá mnoho pramenů z nichž některé jsou uvedeny i v referencích (viz.kap.9).
4.3 Specifikace DML „Dialog markup language“ (zkráceně DML) je jak již bylo řečeno jazyk pro oboustrannou komunikaci aplikace s uživatelem. Proto je jasné, že na by měl na jedné straně obsahovat konstrukty definující strukturu dialogu a parametry jeho elementů, na straně druhé pak i konstrukty pokrývající přenos dat získaných dialogem s uživatelem k aplikaci. Dialog je v DML chápán jako uspořádaná posloupnost dialogových elementů. Celý dialog má kromě toho, svůj vlastní název, který by měl na straně uživatele dialog popisovat jako celek. V první řadě DML definuje vybrané dialogové elementy (přehled a důvody jejich výběru jsou popsány v kapitole 3.3) a především blíže vymezuje jejich chování a parametry. • MESSAGE (zpráva) Zpráva představuje nejjednodušší formou předání informace mezi aplikací a uživatelem. Jedná se o jednorázové předání textové informace uživateli. Jelikož dialogové systémy nejsou systémy řízené uživatelem, nýbrž aplikací , je pro prezentaci informace nutné vytvořit dostatečný časový prostor. Realizace této podmínky je už ale plně věcí uživatelského rozhraní. Buďto je možné od uživatele očekávat jednoduchou reakci, kterou dává systému na srozuměnou, že vzal zprávu na vědomí (potvrzení zprávy vypsané na grafickém terminálu) nebo je prostor pro prezentaci vytvořen už implicitně z podstaty daného zařízení (hlasový syntetizér přečte zprávu což zabere určitý čas). Zpráva v systému DML má jako taková (oproti původnímu DML [1] a HTML) definovánu ještě jakousi úroveň naléhavosti. Tato vlastnost vychází z potřeby odlišit naléhavost zprávy jako takové něčím jiným než vlastním obsahem sdělení. Proto byly definovány tři úrovně vážnosti zprávy normal, warning, fatal. „Normal“ označuje běžné sdělení, „warning“ je například upozornění na chybu, chybný formát vstupu, nedostupnost nějaké informace a pod., „fatal“ má označovat zprávu která informuje o kritickém stavu aplikace, či jiné neopominutelné a pro chod aplikace klíčově důležité skutečnosti. • QUESTION (otázka) Otázka představuje nejjednodušší formu obousměrného toku informací mezi uživatelem a aplikací. Aplikace položí jednoduchou otázku reprezentovanou textovou informací, očekává pak odpověď, která může nabývat stavů Ano nebo Ne. Otázka má od aplikace nadefinovánu předem implicitní odpověď ke kterou by mělo zařízení
- 23 -
realizující dialog na straně uživatele jistým způsobem preferovat (například snazší dosažitelností). • CHOICE (výběr ze spektra možností) Výběr z několika možností je dalším stupněm komunikace. Opět je k dispozici otázka, na kterou se chce aplikace dovědět odpověď ve formě textu. Možné odpovědi na otázku už nejsou ale fixně dány podstatou elementu jako v případě QUESTION ale jsou součástí konkrétního dialogového elementu. Možnosti na výběr jsou buď pevně nastaveny v aplikaci, nebo je může aplikace i dynamicky měnit v závislosti na svém vnitřním stavu. Opět je jako v u předchozího elementu k dispozici předdefinovaná odpověď kterou by mělo uživatelské rozhraní blíže nespecifikovaným způsobem preferovat. Dále si aplikace může zvolit tzv. variantu „multichoice“ čímž dává najevo, že odpovědí na otázku může být v definovaných možnostech více než jen jedna. V opačném případě se očekává, že odpověď bude právě jedna. • TEXT (zadání textu) Element text se kvalitativně zcela odlišuje od všech doposud prezentovaných. Realizuje se pomocí ní požadavek aplikace na zadání jednoduché textové informace. Pod pojmem jednoduchá textová informace se rozumí text na jedné řádce takové délky, které jsou běžná (předpokládaná) zařízení schopná prezentovat uživateli najednou. Aplikací je definován jakási předpřipravená (očekávaná) odpověď avšak je čistě na věcí zařízení na straně uživatele zda ho bude respektovat, či bude začínat s prázdným řetězcem. Element obsahuje krátký popisek, který má usnadnit uživateli orientaci ve složitějším dialogu.
• TEXTEDIT(editace textu) Element textedit je rozšířením elementu TEXT. Zde se rozsah zadávaného textu neomezuje pouze na jednu řádku a limitující faktory předpokládaného uživatelského rozhraní. Předpokládá se víceřádkový rozsáhlejší text, ve kterém se bude uživatel pohybovat a orientovat diametrálně odlišným způsobem než v samotném textovém elementu. Předpokládá se i použití některých pokročilejších forem zpracovaní textové informace, jako je například clipboard, nebo dělení do stránek prezentovaných uživateli najednou. Další vlastnosti jako předdefinovaný text a popisek zůstávají identické s elementem TEXT. • NUMBER(zadání čísla) Element zdánlivě nepatrně rozšiřuje komponentu text TEXT leč zdaleka to není jen pouhé rozšíření. Aplikace element vyvolává v okamžiku kdy požaduje po uživateli zadání jakékoli číselné hodnoty. Je pravdou, že jedna z forem zadání čísla je jeho interpretace jako posloupnosti číslic a dalších doplňujících znaků a pokud by tato forma byla jediná, pak by se funkce elementu NUMBER plně kryla s elementem TEXT. Číslo lze ale také zadat mnoha jinými způsoby, například jako souřadnici od počátku. Forma realizace funkce a prezentace elementu je samozřejmě plně věcí uživatelského rozhraní, avšak z metodického hlediska bylo nutné definovat zadání
- 24 -
čísla jako samostatný element. Vlastnosti jako předdefinovaná hodnota a popisek zůstávají opět identické s elementem TEXT. Navíc přibývají další kritéria která mají svým způsobem vymezovat hranice ve kterých limitující prezentaci a získávání dané číselné hodnoty přes uživatelské rozhraní. Jsou jimi minimální a maximální hodnota a granularita. Minimum a maximum jsou parametry zcela intuitivní. Granularita (v případě že to je nutné) definuje minimální kvantum, o které se mohou lišit dvě sousední hodnoty čísla jež je výstupem elementu. Tímto způsobem se lze velmi jednoduchým způsobem zbavit většiny potíží s vyjadřováním požadavků na výstup celých čísel, počet desetinných míst a podobně. Kromě popsaných parametrů má každý element v rámci dialogu svojí identifikaci, která odlišuje výstupy jednotlivých dialogových elementů ve výstupním proudu. Princip tvorby této identifikace však není součástí DML jako takového, ale je věcí aplikace, která se musí především postarat o jeho jednoznačnost. V opačném směru komunikačního toku (od uživatele k aplikaci) je situace o mnoho jednodušší, neboť v okamžiku přenodu informace dialog již proběhl a výsledná data mohou být kódována o mnoho jednodušeji. Pro přenos získaných dat slouží konstrukt OUTPUT jehož hlavním parametrem, kromě vlastních přenášených dat jsou identifikace dialogového elementu, ze kterého data pocházejí a modifikátory. Identifikace elementu je přenášena z definice dialogu, a její obsah si definuje sama aplikace. Modifikátory mohou nabývat hodnot: • OK - standardní ukončení. • CANCEL - stornování. • HELP - žádost o nápovědu. • TIMEOUT - překročení časového limitu. • ERROR - chyba. • SHORTCUT - horká volba. Definice jejich významu je uvedena v kapitole 3.4. Modifikátory vyhodnocuje aplikace a jejich hodnota nemá na uživatelskou část systému žádný faktický dopad. Řešení stavů signalizovaných identifikátory je plně v rukou aplikace, což značí, že například pro kontextovou nápovědu není v samotném DML vytvořena jakákoli vnitřní podpora a aplikace musí žádost o nápovědu vyřešit například generováním speciálního dialogu s elemetnem MESSAGE nebo jiným způsobem. Z toho také vyplývá, že z pohledu samotného DML není nutné aby aplikace modifikátory vůbec vyhodnocovala a brala v potaz. Jako doplňková informace je ve výstupním proudu přenášen i typ dialogového elementu, kterému daný vystup náleží. Tato informace je svým způsobem redundantní, neboť element je jednoznačně určen svou identifikací, leč tento parametr byl zařazen z čistě implementačních důvodů kvůli časté potřebě filtrace výstupů podle typu původce ještě před vlastní identifikací.
- 25 -
4.4 DML Programy Kromě standardní definice dialogu jako posloupnosti jednotlivých dialogových elementů má DML ještě další prostředek k vytváření komplikovanějších dialogů programy. Program je vlastně speciální forma jednoduššího dialogu, který není po zakódování do DML a odeslání uživatelské části systému přímo interpretován nýbrž uložen do speciální paměti, kde je uložen pro pozdější opakované použití. Je nasnadě, že tímto způsobem je vhodné uložit a využívat velmi často opakované části dialogů, jejichž opakované kódování a přenos komunikačními kanály by zabíralo zbytečně čas a vytěžovalo přenosovou linku. V tomto smyslu by šlo chápat DML program jako obdobu maker používaných například v programovacích jazycích C nebo Assembler. Jeho volání lze zařadit kamkoli do dialogu čímž se docílí postupné zpracování všech dialogových elementů do programu uložených. Program má svojí vlastní identifikaci, kterou je volán. DML program ale zdaleka nepotřebuje být tak komplikovaný jako C makro. V první řadě bylo upuštěno od parametrizace programu, která by sice na pohled vypadala efektně, ale proces definice a volání programu by se tím neúměrně zkomplikoval nehledě na nejisté možnosti využití těchto možností v reálné praxi. Ze stejného důvodu nelze programy v průběhu práce DML systému předefinovávat a dědit. Také není možné volat z programu program jiný, aby se tím zabránilo nežádoucímu zacyklení programových volání. Při volání programu jako takového bude možné předat pouze jeden parametr a to titulek. Program se totiž v jistém smyslu bude chovat jako samostatný dialog a tak bylo pokládáno za účelné i ho před uživatelem nějak oddělit od zbytku dialogu ve kterém je volán. Po skončení programu je titulek opět obnoven na původní hodnotu definovanou před jeho spuštěním. Pro programy v takovéto jednoduché formě se nabízí překvapivě velká řada možných využití, přičemž jedno už bylo zmíněno v předchozí stati konkrétně v kapitole 3.3 při výběru dialogových komponent pro DML. Zde bylo zdůvodňováno proč bylo v průběhu vývoje upuštěno od zařazení komponent „datum“ a „čas“ neboť to jsou klasické příklady aplikací DML programů. Navíc aplikace si může v tomto případě zvolit, zda bude například datum prezentovat jako textovou položku, tři čísla, dvě čísla a výběr názvu měsíce a podobně. Co se týče výstupních dat elementů obsažených v programu, ty jsou odlišeny vlastním identifikátorem, který je definován při ukládání programu. Při volání dialogu je pak definován jakýsi prefix, který bude sloučen s identifikátorem elementu přičemž výsledným složeným identifikátorem bude označen daná výstupní data elementu. Způsob tvorby výsledného identifikátoru je zřejmý z příkladu v kapitole 4.8. Tímto způsobem je zaručena unikátní identifikace všech výstupních dat bez nutnosti zásahu do struktury uloženého programu. Ten by byl v případě přímé identifikace nutný v okamžiku, kdy by stejný program byl volán v rámci jednoho dialogu více než jednou, což nejde předem vyloučit.
4.5 Syntaxe DML, DTD definice Syntaxe DML je definována na základě standardu XML. Každý element respektive řídící prvek je vyjádřen takzvaným tagem což je klíčové slovo uzavřené v ostrých závorkách. Je potřeba rozlišit počáteční a koncový tag, přičemž součástí počátečního mohou být doplňující parametry. Hlavní parametr je pak umístěn mezi počátečním a koncovým tagem. Koncový tag obsahuje stejné klíčové slovo jako
- 26 -
počáteční před které je předřazen znak „/“ (lomítko). Podrobnější popis syntaxe a možností tagů je součástí standardu XML - viz kap. 4.2 a [12]. Komunikace aplikace s uživatelskou částí (ApplicationSide/UserSide) je vymezena tagy a . Vše mezi těmito tagy je pokládáno za příkazy v jazyce DML zatímco vše ostatní je DML parserem ignorováno. Význam takovéhoto vymezení tkví v možnosti začlenit definici DML dialogů do jiných dokumentů odpovídajících standardu XML (například v rámci WWW používané HTML). V rámci DML potom může, co se týče jazyka, následovat buď definice dialogu, nebo definice programu (viz. kap. 4.4). Dialog je vymezen tagy . Dialog jako takový nemá žádné vnitřní parametry, pokud je potřeba definovat jeho název (titulek) umisťuje se tento bezprostředně za počáteční tag
