5. METÓDY A PRINCÍPY NÁVRHU HCI

5. METÓDY A PRINCÍPY NÁVRHU HCI

Návrh rozhraní počítačov je súčasťou návrhu softvéru. Návrhom softvéru sa zaobrá softvérové inžinierstvo.

Dizajn zahrňuje uskutočňovanie mnohých rozhodnutí v rámci početných alternatív. Návrhová metodológia poskytuje explicitné prostriedky záznamu tých rozhodnutí návrhu a kontextu v ktorých sa robili tieto rozhodnutia.

Používateľské inžinierstvo presadzuje používanie explicitných kritérií pre posudzovanie úspechu produktu v zmysle použiteľnosti.

Pri návrhu sa používajú návrhové pravidlá vo forme štandardov, návodov, odporúčaní.

MARTIN ŠPERKA: INTERAKCIA ČLOVEK – POČÍTAČ

5.1.1 Aktivity živortného cyklu

Špecifikácia požiadaviek.

Návrhár a zákazník sa pokúšajú definovať čo bude navrhovaný systém obsahovať.

Návrh architektúry

V tomto kroku sa návrh koncentruje na otázku ako bude systém zabezpečovať požiadavky zákazníka. Prvým krokom je dekompozícia systému na vysokej úrovni. Nezameriava sa len na funkčnú dekompozíciu ale aj vzájomné vzťahy častí systému. K nefunkčným požiadavkám patrí účinnosť, spoľahlivosť, bezpečnosť ako aj interaktívne vlastnosti systému.

Detailný návrh

Obsahuje zjemňovanie dekompozície jednotlivých častí architektúry systému tak aby spĺňali funkčné a nefunkčné požiadavky.

2


Kódovanie a testovanie

Detailný návrh má byť taký aby umožnil automatizáciu implementácie jednotlivých častí systému. Existuje veľa prístupov a formálnych metód splneniu takéhoto požiadavku. Keď sa jednotlivé časti implementujú je treba ich testovať

Integrácia a testovanie

Keď sú jednotlivé časti navrhnuté a otestované, treba ich integrovať do celku a testovať či plnia svoju úlohu v rámci vyššieho celku. Systém je potrebné certifikovať podľa normy ISO 9241.

Prevádzka a údržba

Po ukončení vývoja a dodaní zákazníkovi alebo uvedení na trh nasleduje a údržba produktu. Tvorí najdlhšie trvajúcu časť životného cyklu. Spočíva v odstraňovaní chýb a revízii systémových služieb tak aby zabezpečili požiadavky, ktoré sa neurobili počas jeho vývoja. Poskytuje spätnú väzbu.



Vodopádový a interaktívny vodopádový model návrhu softvéru.


5.1.2 Metodika návrhu s ohľadom na používateľa (User - Centered Design)

Návrh s ohľadom na používateľa je orientovaný na človeka a nie na počítač a dáta.

Zahrňuje používateľa do návrhu tak aby splnil jeho očakávania v čo najväčšj miere.

Napríklad jeho pozorovaním pri práci, účasťou na návrhu, testovaním a hodnotením HCI používateľmi. Táto metóda je vysoko interdisciplinárna a používa poznatky z disciplín uvedených v úvode. Metodológia je vysoko iteratívna, vyžadujúca si veľa testovania a modifikácií.

Počiatočné fázy si vyžadujú zbieranie informácií a neskoršie návrh, implementáciu a testovanie prototypu rozhrania. Jednotlivé fázy sú nasledovné:


Analýza potrieb

Sumarizuje podstatu a poslanie interaktívneho systému, ktorý plánujeme vyvíjať.

Opisuje typ aplikácie – GUI programu, stránky, hry ..

Analýza úloh a používateľa

Charakterizuje používateľov systému (profesia, vek, vzdelanie, skúsenosti, obmedzené percepčné, motorické a kognitívne schopnosti používateľov).

Analýza úloh (tasks) zahrňuje typ práce so systémom. Skúma ciele používateľa a úlohy a aktivity, ktoré sú potrebné k ich splneniu.

Funkčná analýza identifikuje funkcionalitu systému, služby systému potrebné k vykonávaniu úloh a aktivít.


Analýza požiadaviek

Opisuje formálnu špecifikáciu požadovanú pre implementáciu systému.

Formálna špecifikácia obsahuje slovníky, entitno- relačné, stavové, vývojové diagramy, grafy závislostí, toku dát alebo riadenia. Napríklad formou UML diagramov.

Stanovenie špecifikácií použiteľnosti

Pomáha zodpovedať otázku ako dobrý je navrhovaný systém.

Obsahuje meranie výkonnosti (performance measurement) napríklad počet uskutočnených úloh za čas a počet chýb priamo pozorovateľných na používateľovi. Tiež mierku preferencií (preference measures) ako je prvý dojem alebo celková spokojnosť.


Návrh

Rozhoduje o organizácii a vzhľade rozhrania. Identifikuje sa funkcionalita programu alebo obsah internetového sídla podľa očakávaní používateľa.

Dôležiá je organizácia obsahu (informačná architektúra) a rozloženie informačných a riadiacich prvkov (layout) ako aj ich vzhľad tak aby sa zachovala ich jednoznačnosť a konzistencia.

V tejto fáze sa určí aj ich hierarchia a spôsob navigácie (pri návrhu stránok).

Až tu sa začína kreslenie vzhľadu rozhrania alebo stránok, lebo až tu vieme kto sú používatelia a čo chcú.


Prototypovanie (z gréckeho slova proto – prvý typ)

Je originálny model alebo vzor (pattern).- globálny prototyp (celý systém) - lokálny (časti systému). - evolučný (prototyp sa stane súčasťou finálneho systému) - na zahodenie - throw-away (slúži len ako vzor – pattern pre implementáciu).- inkrementálny

– presný (high fidelity) napodobuje systém presne- nepresný (low fidelity) napodobuje rozhranie zhruba

HodnotenieSlúži k testovaniu prototypu. - hodnotenie používateľom - hodnotenie expertom.


5.1.3 Iteratívny návrh a prototypovanie

Cieĺom prototypovania je overiť navrhovaný výrobok alebo jeho časti ešte pred dokončením kompletného návrhu.

Prototypovanie sa líši podľa úrovne funkcionality a výkonu produktu.

Obrázky rozhrania poskytnú len dojem o rozhraní, animácia simuluje len malú časž interaktivity.

Na druhej strane prototypovanie plnej funkcionality može byť na úkor iných vlastností ako skutočnej rýchlosti odoziev a tolerancia k chybám.

Testovanie prototypu by malo prebiehať s používateľmi v skutočných podmienkach, čo je ale drahé.


Typy prototypov

Návrh so zahodením prototypu (throw-away) - prototyp sa navrhne, testuje a zahodí


Inkrementálny návrh

Finálny produkt sa buduje ako separátne komponenty, jedna v jednom období. Konečný systém sa vypustí ako séria produktov, každý subsekventný produkt s viac komponentami.


Evolučný návrh

Prototyp sa nevyhodí ale slúži ako báza pre ďaľšiu iteráciu návrhu. Dobre sa hodí pre modifikáciu behom prevádzky a údržby.


5.1.4 Metódy prototypovania

Scenáre (storyboards)

Obdoba komiksu - séria obrázkov vizuálnej podoby rozhraní v jednotlivých stavoch s textovým popisom. Môže byť obohatený animáciami.

Simulácie obmedzenej funkcionality

Kritické komponenty s presne simulovanou funkcionalitou.

Podpora jazykami vysokej úrovne

Špeciálne jazyky pre podporu používateľských rozhraní a UIMS - User Interface Management Systems, GUI generators, niektoré IDS.


Scenáre (storyboards)


5.1.5 Zdôvodnenie návrhu

Dizajn je proces, kde je treba robiť veľa rozhodnutí, pretože požiadavky zákazníka nemusia byť jednoznačné.

Zdôvodnenie návrhu je informácia, ktorá vysvetlí, prečo je systém taký ako je, vrátane štrukturálneho popisu a architektúry a jeho funkčného popisu a chovania.

Nie je časťou životného cyklu.


Zdôvodnenie návrhu je užitočné z niekoľkých dôvodov:

Je to explicitná forma komunikácie medzi členmi tímu, umožňuje pochopiť kritické rozhodnutia, možné alternatívy, ktoré sa posudzovali a dôvody prečo sa vybrala práve tá na ktorej sa pracuje v neskorších fázach návrhu alebo údržby.

Vedomosti, ktoré sa nazbierali počas riešenia projektu sa môžu znovu použiť.

Práca spojená s vypracovaním zdôvodnenia núti návrhárov hlbšie rozmýšľať o rozhodnutiach.


Vztiahnuté na návrh rozhraní to znamená:

Existuje viac najlepších alternatív. Dizajnér musí robiť pri výbere kompromisy.

Aj keby existovalo optimálne riešenie, priestor alternatív je tak veľký, že je nepravdepodobné aby ho návrhár objavil. Je dôležité aby návrhár opísal všetky alternatívy, ktoré anayzoval, aj keď ich nepoužil, aby sa v budúcnosti vedelo, čo a prečo sa analyzovalo a zavrhlo.

Použiteľnosť interaktívneho systému závisí od kontextu použitia. Používateľovi je k ničomu ak sa použije 3D animácia v reálnom čase ale má pomalý počítač.

Tri prístupy zdôvodnenia návrhu: Procesné, analýza návrhového priestoru, psychologické zdôvodnenie návrhu.


1. Procesné zdôvodnenie (IBIS - Issue Based Inf. System)Je to hierarchická štruktúra na ktorej vrchole je koreňový problém - otázka (issue) ktorú treba zodpovedať(vyriešiť). Potomkami sú pozície (position) - možné (potenciálne) riešenia. Každú pozíciu podporuje alebo odmieta argument, ktorý modifikuje vzťah medzi problémom a pozíciou. Hierarchia sa rozširuje o ďaľšie problémy. Takto sa archivuje história procesu rozhodovania.

,,,


2. Analýza návrhového priestoru Obsahuje otázky, možnosti (alternatívne riešenia) a kritériá. Analýza priestoru návrhu je štrukturovaná. Plné čiary sú pozitívne spojenia a čiarkované sú negatívne. Najlepšia možnosť je tá, ktorá má najviac pozitívnych hrán a je označená obdĺžnikom. Po výbere najlepšej možnosti sa postúpi k nasledujúcej otázke. Je to metóda post hoc (odráža chovanie po faktoch) - zaoberá sa viac závermi pre rozhodnutia ako o ich postupnosti.


3. Psychologické zdôvodnenie návrhuTento prístup sa pokúša o explicitné vyjadrenie psychologických požiadaviek na použiteľnosť, ktoré sú prirodzené v každom interaktívnom systéme.

Dôvod je lepšie prispôsobenie systému používateľovi.

Dokumentovaním psychologického zdôvodnenia sa návrhár prinúti aby si bol viac vedomý prirodzenej evolúcie úloh a artefaktov používateľa a aby z toho vyvodil dôsledky ako môže návrh ovplyvniť nasledujúce návrhy.

5.2 ANALÝZA A MODELY POUŽÍVATEĽA

Motivácia: Nižšie náklady pri vývoji a údržbe systému

Charakteristiky používateľa: Generické a špecifické.

Modelovanie používateľa: Modelovanie požiadaviek - jeho požiadavkyKognitívne modely - reprezentujú samého používateľa

Modely:Hodnotiace (evaluatívne) - navrhovaný systém má vhodné vlastnosti ? Napríklad v mechanike či most vydrží isté zaťaženieGeneratívne , ktoré môžu prispieť v samotnom procese návrhu (viac ako len komentovaním výsledku).


,

5.2.1 CHARAKTERISTIKY POUŽÍVATEĽOV

1. Generické charakteristiky používateĺov:

Štýl učenia - sú to ľudia čo si najskôr prečítajú návod a potom experimentujú alebo naopak. Druhá skupina - aktívny používatelia patrí k netrpezlivým, ale väčšina ľudí nechce strácať čas čítaním návodov.

Preferencia nástrojov záleží aká je skupina používateľov, aké sú ich predchádzajúce skúsenosti.

Fyzické rozdiely zahŕňajú vek, pohlavie, fyzické obmedzenia (mobilita, slabozrakosť, schopnosť vnímať farby, poruchy sluchu).

Kultúrne rozdiely - geografické, náboženské, profesné (štýl spoločnosti - corporate style, záujmové skupiny).


2. Špecifické charakteristiky používateľov:

Znalosti o práci - teda akým spôsobpm používatelia pracujú s nástrojmi je klúčovou. Je treba vedieť ako často používajú podobné nástroje, aká je ich dôležitosť, kde sa naučili s nimi pracovať, akú terminológiu používajú.

Znalosť aplikácie okrem poznatkov o spôsobe používania nástroja treba vedieť stupeň znalostí podobných nástrojov.


3. Podľa stupňa známosti so systémom:

Začiatočník čelí mnohým neznámym problémom ale rýchlo sa dopracuje k pokročilému začiatočníkovi.

Pokročilý začiatočník podobne ako nováčkovia sú netrpezliví a chcú rýchlo zvládnuť systém, no nemajú už strach z chýb. Sú ochotní experimentovať. Ak sa dostanú do problémov, majú ťažkosti s diagnostikou.

Kompetentný používateľ - líši od začiatočníkov v dvoch bodoch - je schopný diagnostikovať jednoduché problémy a je schopný vykonať postupnosti komplikovaných úkonov pre dosiahnutie cieľa. Je ochotný študovať aj návody.

Experti tvoria len malé percento používateĺov. Je schopný plniť komplikované úlohy a diagnostikovať zložité problémy. Zaujíma o systém do hĺbky. Je schopný učiť a konzultovať systém, byť členom podporného kolektívu pre daný produkt.


5.2.2 MODELOVANIE POŽIADAVIEK POUŹÍVATEĽA

Zistenie požiadaviek je dôležitou časťou všetkých metodológií softvérového inžinierstva, ale mnohokrát sa zameriava hlavne na funkčné požiadavky a menej na ľudské faktory ako je použiteľnosť a prijateľnosť (acceptability).

Modelovanie požiadaviek používateľa sa týka stanovenia jeho potrieb.

1. Spoločensko-technické modely reprezentujú požiadavky ľudí aj techniky

2. Metodológia mäkkých (soft) systémov poskytuje širší pohľad na ľudské a organizačné otázky

3. Návrh so účasťou (participatory) použítateľa zahrňuje používateľa priamo do procesu návrhu.


1. Spoločensko - technické modely sú spojené s technickámi, spoločenskými, organizačnými a ľudskámi aspektami návrhu. Rešpektujú fakt, že technika sa nevyvíja v izolácii ale ako súčasť širšieho organizačného prostredia.

2. Metodológia mäkkých (soft) systémov SSM predchádzajúce modely identifikovali požiadavky z hľadiska človeka a systému.

SSM má širší záber - organizácia systému, kde ľudia a technika sú jeho komponenty.

Prvým stupňom je rozpoznanie problémov a inicializácia analýzy.


Potom nasleduje detailný opis problémových situácií - vytvorenie bohatého obrazu (rich picture). Tento obsahuje:

Účastníkov (stakeholders)Úlohy, ktoré treba riešiťOrganizačnú štruktúruProcesy a témy, vznesené ktorýmkoľvek z účstníkov

V druhom stupni sa posunieme z reálneho sveta do sveta systému a pokúsime sa riešiť korene definície (root definitions) pre systém.

Existuje viac koreňových definícií systému, ktoré reprezentujú viacerých účastníkov, napríklad podľa CATWOE:


Klienti - profitujú na výstupoch systému (zákazníci v letovom rezervačnom systéme).

Herci/actors - vykonávajú aktivity v systéme (zamestnanci cestovných kancelárií).

Transformácie - zmeny, ktoré spôsobil systém. Kritická časť definície koreňov - identifikovanie aktivít vedúcich k ďaľšiemu stupňu.

Uvažujeme vstupy a výstupy - zámery zákazníkov a požiadavky cestovať transformované do predaja miest v lietadle a zisk organizácie.

Názory/Weltanschaung (svetová názor, to je ako sa na systém pozerá - zisk sa zvýši efektívnejším predajom).


Vlastníci - komu systém patrí a ktorí môžu autorizovať zmeny a sú zaň zodpovední - manažment leteckej spoločnosti.

Prostredie/environment - svet v ktorom sa to deje - predpisy medzinárodnej leteckej civilnej legislatívy, lokálne predpisy atď.

Po vývoji koreňových definícií sa navrhne konceptuálny model, ktorý definuje čo má robť systém aby sa splnili koreňové definície.

Obsahuje identifikovanie transformácií a aktivít v systéme a modelovanie hierarchií v zmysle toho čo a ako sa má dosiahnuť.

Je to iteratívny proces. Napokon sa vrátime k reálnemu svetu a porovnáme skutočný systém s konceptuálnym modelom, identifikovaním nezrovnalostí a zvýraznením potrebných zmien alebo potencionálnych problémov. SSM je pružný prístup podporujúci detailné požiadavky.

Je treba mať ale prax v jeho efektívnom používaní.MARTIN ŠPERKA: INTERAKCIA ČLOVEK – POČÍTAČ

3. Návrh so spoluúčasťou (participatory design)

Používateľ sa zapája do celého cyklu návrhu ako člen návrhového kolektívu - je expert v kontexte používania.

Má tri špecifické charakteristiky

- prvá pomáha zlepšiťpracovné prostredie a úlohy dizajnom, čím sa koncentruje viac na prácu ako na systém

- druhá je charakterizovaná spoluprácou, keď používateľ prispieva ku každej fáze návrhu

- tretia spôsobuje urýchlenie testovania tak že iterácie návrh a hodnotenie sú efektívnejšie a v každom kroku.

Pri návrhu sa používajú metódy:


brainstorming - všetci účastníci sa podieľajú na myšlienkach, tieto sa zaznamenávajú a filtrujú

storyboarding - storyboard je prostredok pre zápis aktivity používateľov

pracovné dielne - workshops - slúžia k doplneniu chýbajúcich vedomostí účastníkov a sústreďujú pozornosť na dizajn, je to spoločná platforma pre návrhárov aj používateľov.

cvičenia ceruzka a papier - umožňujú hodnotenie návrhu s malými nákladmi, cieĺom je odhaliť nesúlad medzi požiadavkami používateľa aktuálnym návrhom.

Iné delenie: návrh so spoluúčasťou, sedenia, workshops, plastic inteface, prototypovanie, scenáre, brainstorming


5.2.3 KOGNITÍVNE MODELY

Modelujú niektoré aspekty používateľovho porozumenia, vedomostí, zámerov a spracovania.

Úroveň reprezentácie: Od modelov vysokoúrovňových cieľov a výsledkov aktivít riešenia problémov až po opis motorických funkcií ako je práca s myšou alebo klávesnicou. Formalizmy vyvinuli psychológovia alebo počítačoví odborníci. Kognitívne modely reprezentujú používateľov interaktívnych systémov.

1. Hierarchické modely reprezentujú používateĺove úlohy a štruktúru cieľov. 2. Lingvistické modely reprezentujú gramatiku používateľ - systém. 3. Fyzikálne modely a modely zariadení reprezentujú motorické zručnosti človeka.

Kognitívne architektúry zachytávajú všetky tieto kognitívne modely.


1. Hierarchie cieľov a úloh

GOMS (Goals Objects Models Selection)Analýza úloh vždy začína cieľmi používateľa. ciele sú používateľove ciele, čo chce dosiahnuť. operátori sú základné akcie, ktoré musí používateľ robiľ pri používaní systému, (napríklad stlačiť tlačítko T) alebo mentálne stavy (napr. prečítať si dialógovú oblasť),metódy sú dekompožície cieľov na podcielevýber keď existuje viac možností výberu GOMS neponechá výber náhode ale pokúša sa predikovať, ktorá metóda sa použije, čo záleží na konkrétnom používateľovi a stave systému.

CCT (Complex Cognitive Theory)- má dva súbežné popisy - používateľových cieľov a systému (zariadenia/device). Používateľove ciele sa popíšu podobne ako v GOMS hierarchii ale v tvare produkčných pravidiel ako všeobečcná prechodová sieť (forma stavového prechodového grafu). Produkčné pravidlá sú postupnosť pravidiel if podmienka potom akcia.


Heirarchia cieľov je veľmi dôležitá v skorých fázach návrhu, keď sa odhalia potencionálne koncepčné chyby rozhrania.

Napríklad prvé bankomaty vydali peniaze a až potom kartu. To spôsobilo, že používatelia si zabúdali kartu v bankomate - Problém uzavretia. Bolo to spôsobené tým, že ich cieľ dostať peniaze sa splnil ale karta zostala aj napriek správe aby používateľ čakal na kartu.

CIEĽ: DOSTAŤ- PENIAZECIEĽ: POUŽI-ATM

VLOŽ-KARTUNAPÍŠ-PINNAPÍŠ-SUMUZOBER-PENIAZE

// Tu sa cieľ splnil, cieľový zásobník sa vysunieVYBER-KARTU // toto používateľ častokrát neurobil


2. Lingvistické modely

interakcia s používateľom je formou jazyka. Boli vyvinuté hlavne pre príkazové jazyky a existujú snahy rozšíriľ ich pre oknové systémy.

BNF (Bakchus Naurova Forma) je spôsob zápisu gramatiky, v tomto prípade dialógovej gramatiky. Je to čiste syntaktický pohľad, kde sa ignoruje sémantika.

TAGs (task action grammars) sa pokúša predchádzajúci problém vložením prvkov ako sú parametrizované gramatické pravidlá.


3. Fyzikálne modely a modely zariadení

v porovnaní s kognitívnymi modelmi, ktoré sa používajú pri riešení problémov, ľudská motorika je lepšie preskúmaná.

Podobne ako v GOMS sa úloha dekomponuje na podúlohy, predtým ako ich mapuje na fyzikálne akcie.

Úloha sa rozdelí na dve fáze

- získanie (aquisition) keď používateľ vytvorí mentálnu reprezentáciu úlohy - vykonanie (execution) úlohy s použitím systémových prostriedkov.


Model stláčania klávesnice (Keystroke- Level Model, KLM)

Ako GOMS na veľmi nízkej úrovni. Model dekomponuje vykonávaciu fázu na 5 rôznych motorických operátorov ako sú stlačenie klávesy - K, tlačítka myši - M, ukázanie kurzorom - P, presun ruky z myši na klávesnicu - H, kreslenie čiary myšou - D, mentálna príprava na fyzickú akciu - M, odozva systému - R.

Vykonanie úlohy si vyžaduje rôzne akcie, ktoré trvajú nejaký čas - napríklad čas stlačenia tlačítka myši - TM. Model predikuje čas fázy vykonávania spočítaním dieĺčích časov.


Napríklad oprava jedného znaku pri písaní textu je možná postupnosťou nasledujúcich operátorov:

1. Pohyb ruky k myši H[myš]2. Pohyb myši za opravovaný znak PB[ľavé tlačidlo]3. Návrat ku klávesnici H[klávesnica]4. Zmazanie znaku (backspace) MK[BACKSPACE]5. napísanie správneho znaku K[opravený znak]6. Návrat na miesto kde sa prerušenia H[myš] MPB[ľavé tlačidlo]

Model odhaduje celkový čas vykonania úlohyT= TH + TP + TB + TH + TM + TK + TH + TM + TP + TB

Publikovali sa rôzne časy operátorov:TK pre dobrého pisára 120ms, začiatočníka 1200ms a pokročilého začiatočníka 280ms.


Trojstavový model (three state model)

Používa sa pre ukazovacie zariadenia ako je myš, ovládacia guľa, dotykové zariadenia. Rozdiel je v tom že dokiaľ sa nedotkneme obrazovky počítač nezaznamené žiadnu akciu ale ruka sa už premiestňuje tam kde má byť, u myši sa kurzor pohybuje aj bez stlačenia. Keď sa dotkneme začína sledovanie (tracking) čím prejdeme do stavu 1 (u myši stav 2). Ak chceme objekt ťahať (drag), musíme stlačiť tlačidlo (stav 3, u myši stav 2).


5.3 ANALÝZA ÚLOH

Analýza úloh študuje ako pracuje používateľ s existujúcim systémom. Je to proces budovania komplexného opisu ako si plnia svoje povinnosti. Niektorí autori zaraďujú časti analýzy úloh do analázy používateĺa, nakoľko je častokrát ťažké oddeliť používateľa od toho čo robí.

Analýza úloh sa vždy začína analýzou cieĺov používateľa.

Ciele sú nezávislé od používanej techniky, musia sa vyriešiť, keď nie inak aj bez nej.

Úlohy sú mechanizmy, ktoré ľudia používajú k splneniu cieĺov. Na rozdiel od cieĺov, sú závislé od nástrojov, teda na technológii.

Akcie sú časti úloh. Úloha je popis na vysokej a akcia na nízkej úrovni.


Metódy analýzy úloh:

- dekompozícia na podúlohy- taxonomická klasifikácia vedomostí o úlohách (znalostná analýza)- zoznam vecí a vykonávaných akcií.

Zdroje informácií pri analýze úloh:

- existujúca dokumentácia- pozorovanie a rozhovory (interview).


1.Dekompozícia úloh

Typickým prístupom je hierarchická analýza úloh (HTA).

Zistenie úloh: Priamym pozorovaním, názorom experta na danú činnosť, z dokumentácie at.

V dekompozícii je možno pokračovať donekonečna, záleží na konkrétnej situácii kde platí pravidlo ukončenia (stopping rule), hovoriace o tom kedy je už úloha základnou.

Jedna metóda ukončovacieho pravidla je P x C pravidlo, ktoré hovorí že proces sa ukončí ak pravdepodobnosť urobrnia chyby P násobená cenou spôsobenou chybou C je menšia ako prahová hodnota. Ďaľšia dekompozícia je potom zbytočná.


Príklad: Vyčistiť dom rozložíme na úpodúlohy - vyčistiť miestnosi 0. aby sme vyčistili dom 1. vyberieme vysávač2. zmontujeme ho, zapojíme do siete3. vyčistíme miestnosti

3.1. vyčistíme kuchyňu3.2. vyčistíme obývačku……………………..

4. vyprázdnime vrecúško s prachom5. odložíme vysávač

Plán 0: rob 1,2,3,5 ak je vrecúško s prachom plné rob 4

Plán 3: rob ktorúkoľvek akciu 3.1, 3.2, 3.X v ľubovoĺnom poradí, podľa toho ktorú miestnosť treba vyčistiť.

Plán 3 môže vyzerať aj ako: rob 3.1 každý deň, rob 3.2 raz za týždeň, a podobne



2.Znalostná analýza

začína vymenovaním všetkých objektov a akcií, ktoré sú súčasťou úlohy.

Je to podobné hierarchickému opisu živočíchov v biológii (taxonómia).

Cieľom je porozumenie vedomostiam potrebným pre splnenie úlohy a tak pomôcť vytvoreniue učebných materiálov a ohodnotenia množstva spoločných vedomostí medzi rôznymi úlohami.

Najjednoduchšia je jednoduchá hierarchia objektov, kde každý objekt má presne určené miesto v tejto hierarchii.

Ako pri hierarchickej analýze úloh - koľko objektov a do akej hĺbky ísť, lepšie všetky možné a potom ich zrušiť.



Príkladom je zjednodušená taxonómia automobilu.

ovládanie autariadenie smeru jazdy volant, meracie prístrojemotor/rýchlosť

priame zapalovanie, akcelerácia, nožná brzdaprevodovkou rýchlostná páka, spojka

svetlávonkajšie predné, brzdovévnútorné predné, zadné, dverové

umývanie/stieranie okienostrekovače predné, zadnéstierače predné, zadné

kúrenie


Taxonómiu môžme ale zmeniť v závislosti od toho ako klasifikujeme objekty.

Môžme ich klasifikovať podľa viacerých kritérií napríklad stierače a ostrekovače na aute na stierače (zadné) alebo ostrekovače (predné), predné (stierače a ostrekovače) alebo zadné (stierače a ostrekovače) podľa atribútov funkcia alebo umiestnenie.

Dokonalejším nástrojom ako sme uviedli je analýza úloh pre popis znalostí TAKD (task analysis for knowledge description), ktorá využíva špeciálnu taxonómiu - hierarchia opisújúca úlohy TDH (task descriptive hierarchy).

Vetve v obyčajnej taxonómii sú alebo - alebo (XOR) vetve. TDH používa aj vetve AND a OR. AND sa používa keď je objekt musí mať miesto vo viacerých kategóriách.


3. Entitno-relačné metódy

sú analyzačné metódy pôvodne používané v databázach.

V analýze úloh sa používajú v širokom spektre aj nepočítačových objektov vrátane ľudí a akcií. UML, Bachmanov diagram, metóda podľa Petra Chena.

Entitno-relačný diagram je konceptuálny model, ktorý nám pomáha na úrovni abstrakcie popísať používateľskú aplikáciu s cieľom následnej špecifikácie štruktúry databázy :•znázorňuje entity a vzťahy medzi nimi•neznázorňuje vznik, modifikáciu, ani zánik údajových entít a tok spracovania údajov•graf obsahujúci ako uzly dátové entity a vzťahy, hrany reprezentujú prepojenie medzi entitami a vzťahmi.•umožňuje definovať aj atribúty vzťahov


Zdroje informácií a zbieranie dát.

Analýza úloh nie je jednoduché zbieranie dát, ich analýza, organizovanie a prezentovanie výsledkov.

Častokrát nás vráti naspäť k originálnym zdrojom s novými otázkami a pohľadmi.

Ideálne je to iteratívny proces, kde sa zbieranie a analýza opakujú.

V praxi ale na to nie je čas.

Veľké náklady na tento proces nás nútia používať lacné zdroje informácií ako sú príručky a pilotné štúdie.

Základné zdroje informácií sú dokumnetácia, pozorovania a interview.


Dokumentácia (príručky, brožúry, školiace materiály) je najľahším zdrojom informácií. Dokumentácia ale hovorí o tom ako by ľudia mali systém používať a nie o tom ako ho skutočne používajú. Príručky o zariadeniach hovoria o tom ako tieto fungujú ale nie o tom ako by sa mali používať. Aj štruktúra nie je ideálna - je zameraná na základné akcie a objekty zainteresované na úlohe, nie je úplná a nezaoberá sa akciami mimo zariadení.

Pozorovania sú základom ak analytik chce získať názor na situácie pri riešení úloh. Najjednoduchšie je pozorovať ľudí v práci a hovoriť s nimi. Formálnejšie metódy si vyžadujú laboratórium. Pozorovanie môže byť pasívne a aktívne. Interview s expertami v danej doméme je priama a rýchla cesta k informácií o úlohe. Expert nie je manažer projektu ale človek, ktorý s ním vie dobre robiť. Ale je dobré rozprávať sa aj s tvorcom systému.


Počiatočná analýzaDetailná analýza záleží na použitých metódach. Väčšinou začína tvorbou základných objektov a akcií. Prechádza sa cez podstatné mená, ktoré budú objekty a slovesá (ktoré súvisia s akciami). Tento proces sa dá pomocou slovníku automatizovať. Problém je ak rovnaké slová sú aj podstatné mená aj slovesá (v Angličtine je to časté).

Triedenie a klasifikácia

Niektoré metódy si vyžadujú tvorbu hierarchických štruktúr a triedenie vstupných dát podľa rôznych atributov. Niektoré sa robia pri analýze a niektoré potrebujú subjektívne hodnotenie a expertov z danej oblasti. Existuje viac metód. Napríklad zapisovať si objekty na kartičky.Expert ich potom triedi na kopy. Tento proces môže iterovať. Môžu to robiť nezávisle viacerí experti. Inou metódou je hodnotiť napríklad číslami v nejakom rozsahu. Tvorba veľkých taxonomických množín je náročná.


Použitie analýzy úloh, Výstupom analýzy úloh je poznatok o tom ako ľudia riešia úlohy a v závislosti na použitej metóde, veciach ktor= používajú, plánoch, a sekvenciách akcií vykonávaných pri plnení úloh.

Táto informácia sa použije potom v príručkách a školeniach, získavaní požiadaviek a systémovom návrhu, v detailnom návrhu rozhrania.

Príručky a školenia. Niektoré metódy analýzy úloh sa používali pri školení nováčkov. Napríklad v armáde, kde trénovanie musí byť rýchle a účinné.

HTA sa môže použiť v štrukturovaní príručiek. Príručka typu ako to urobím je pri počiatočnom školení užitočná. Tu sa používajú metódy znalostných techník a taxonómie. Iným cieľom je prechod z jedného systému na iný.


Získavanie požiadaviek a systémový návrh. Analýza úloh je súčasťou špecifikácie požiadaviek pri návrhu systému - čo má systém robiťa ako sa bude používať.

Je to proces kde sa získajú mnohé prvky ktoré nie sú časťou systému, predpovede ako sa bude nový systém chovať. Analýzou existujúceho systému získame požiadavky na nové funkcie a vlastnosti nového systému.

Detailný návrh rozhrania. Podobne ako pri príručkách sa môžu taxonómie úloh alebo objektov použiť pri návrhu menu. V OOP je užitočná asociácia objektov s akciami. Pre každý objekt sa zobrazí menu možných akcií. Prednastavené akcie sa vyberú podľa frekvenie používania, ale informácia o nich je podľa generickej klasifikačnej schémy (princíp naučiteľnosti v použiteľnosti).

Postupnosť podúloh, ktorá sa získa z dekompozície úlohy sa použije v návrhu dialógu. Poradie operácií by malo kopírovať poradie operácií v skutočnej činnosti, ktorú počítačom simulujeme


5.4 NÁVRH A NOTÁCIA DIALÓGU Dialóg je syntaktická úroveń kominkácie človek- počítač. Je to niečo ako scenár hry s tým rozdielom, že používateľ a niekedy aj počítač majú viac možností (nelineárny scenár).

Notácie používané v popise dialógu sú grafické (ľahko sa vnímajú na prvý pohľad) alebo textové (jednoduchšie pre formálnu analýzu).

Dialógy sa linkujú na sémantiku systému (čo robí) alebo na prezentáciu systému (ako vyzerá).

Formálny popis dialógu sa môže analyzovať s ohľadom na nekonzistenciu akcií, obtiažnosť reverzných akcií, chýbajúce položky, potenciálne chyby pri vkladaní znakov cez klávesnicu.


Štrukturovaný dialóg - dialóg človek počítač je štrukturovaný a obmedzený. Príkladom je svadobný obrad, keď sa oddávajúci pýta presne definované otázky a oddávaní presne odpovedajú. Je to forma scénaru. Tu ženích alebo nevesta vysoko pravdepodobne povedia áno.

Dialóg ako súčasť kódu programu - priamo v kóde sú otázky počítača, ich načítanie a spracovanie. Veľká časť dialógu v programoch je venovaná testovaniu správnosti odpovedí používateľa (if input = ….). Kvôli zjednodušeniu analýzy treba oddeliť prvkov rozhrania od výpočtov (sémantika). Dialóg treba navrhnúť pred implementáciou programu, je to nástroj na prototypovanie.


print "ste študent: ano - nie"input poziciaif pozícia= áno´ then študent () exit if pozícia=ńie´ then

beginprint "ste zamestnany: ano - nie"input pozicia

if pozícia= áno´ then zamestnany() exitend

………………..


Diagramatické notácie dialógu

- Prechodové stavové siete (STN)Pri používaní STN môžme používať papierové prototypy - na každom liste je jeden stav (obrazovka pri danom stave)


Príklad grafického podsystému


Použitie stavového diagramu pri používateľskej dokumentácii nastavovania digitálnych hodiniek.


- Hierarchické stavové siete

Zložitý systém môžme reprezentovať hierarchickým grafom v ktorom uzol reprezentuje jednoduchá stav alebo celý podgraf


- Súbežný dialóg a kombinačné rozšírenie stavov.

STN sú výborné pre sekvenčné, rozhodovacie a iteratívne časti dialógov ale pre súbežné časti nie. Príkladom je voľba objektov s niekoľkými atribútmi, napríklad písmo, ktoré môže byť normálne, tučné, kuržíva, tučná kurzíva, podčiarknuté atď


-Použitie ESC a pomoci

Použitie vyskočenia z akéhokoľvek stavu systému pomocou Escape a vyvolanie pomoci a spätný návrat spôsobuje enormné rozšírenie kombinačných možností, lebo stav help a ESC je možno dosiahnuť z akéhokoľvek stavu a je treba zabezpečiť návrat do tohto stavu.


- Petriho siete

Petriho siete predstavujú jeden z najstarších formalizmov v počítačovej vede a používajú sa pre modelovanie súbežných udalostí.

Stavové diagramy sú v danom okamžiku vždy len v jednom čase. Simulovanie stavového prechodového grafu sa robí presúvaním značky z jedného na druhé miesto v každom kroku.

Petriho siete majú niekoľko stavov naraz. Sú označené značkami (čierne bodky).

Kruhy sa nazývajú miesta a obdĺžniky prechody.


V sieti na obrázku sú tri značky - jedna je v Bold On to znamená, že súčasné písmo je tučné.

Druhá je v Italic Off to znamená, že písmo nie je kurzíva.

Tretia značka je na ľavo a označuje že používateľ práve stlačil tlačítko tučné písmo.

Pravidlo prechodu je také, že ak sú na vstupoch prechodu všetky značky dôjde k jej odpáleniu, to znamená k požadovanému prechodu.

V tomto prípade sú na vstupe T1 obe značky teda bude nasledovať prepnutie do Bold Off. Hrana z Bold On do T3 nemá na konci šípku ale krúžok, to znamená že v stave Bold On nie je mozné prepnúť do Italic Off.



- Stavové grafy sú špeciálnou formou STN a boli vyvinutí vizuálnej špecifikácii zložitých reaktívnych systémov. Umožňujú efektívne riešiť problematiku súbežnosti a prechodov pri ESC. Majú hierarchickú štruktúru v tom že v jednoduchom grafe sa zobrazí štruktúra a aj alternatívne stavy.


- Vývojové diagramy sa v súčasnosti považujú za zastaralé ale mnohokrát sú postačujúce a efektívne. Majú tie isté nedostatky ako STN pri modelovaní súbežnosti dejov, ESC atď. Ale majú výhodu jednoduchosti. Využívajú rôzne grafické symboli pre rôzne činnosti ale sú viac počítačovo ako používateľsky orientované.


- JSD (Jackson Structured Design) diagramy. V podstate všetky notácie používane v programovaní a softvérovm inžinierstve sa dajú použiť pre notáciu dialógu. Trieda dialógov reprezentovaná JSD je obmedzená, ale obsahuje mnoho základných menu riadených (menu driven) informačných systémov.


Univerzálny modelovací jazyk UML

Je výsledok snaženia softvérových inžinierov a analytikov o unifikovaný popis objektovo orientovanej analýzy a návrhu.

Štruktúrové diagramyDiagram tried (Class diagram)Diagram objektov (Object diagram)Diagram komponentov (Component diagram)Diagram zloženej štruktúry (Composite structure diagram)Diagram balíčkov (Package diagram)Diagram nasadenia (Deployment diagram)

Diagramy chovania / reakcieDiagram prípadov použitia (Use case diagram)Diagram činností (Activity diagrams)Stavový diagram (State machine diagrams)

Interakčné diagramySekvenčný diagram (Sequence diagram)Diagram komunikácie (Communication diagram)Diagram časovania (Timing diagram)Diagram prehľadu interakcií (Interaction overview diagram)


Textové notácie dialógu

- Gramatiky (napríklad BNF). Jedna výhoda používania je možnosť použitie regulárnych výrazov. Napríklad regulárny výraz [+-/*] znamená všetky aritmetické operátory. Regulárny výraz Jano[.!?] znamená výskyt Jano na konci vety (oznamovacej, rozkazovacej a opytovacej).

Rekurzívne definície non terminálnych symbolov umožňuje reprezentovať iterácie v dialógu.

Kreslenie lomenej čiary pomocou regulárneho výrazu možno zapísať ako: Select-line odklepni odklepni* dvojnásobne-odklepni. Význam: Výber príkazu, minimálne jeden bod odklepnutím tlačitla myši, postupnosť bodov (ĺubovoľný počet označuje Kleeneho operátor *) a ukončenie dvojitým odklepnutím. Terminálne symboly ako odklepni musia byť niekde definované.


- Produkčné pravidlá majú všeobecnú formu ak podmienka potom akcia. Tieto pravidlá (rules) sa zapisujú roznymi formami. Sú orientované na udalosti alebo stavy prípadne zmiešané.

Udalosti sú troch typov - používateľské (reprezentujú vstupy používateľa napríklad jedno alebo dve ťuknutia), - vnútorné udalosti (udržujú súvislosť dialógových stavov napriklad či bol označený priebežný alebo posledný bod pri kreslení lomenej čiary)- udalosti odozvy systému (sú to viditeľné a počuteľné javy systému).

Dialógový manažer, ktorý pracuje s takýmito pravidlami má pamäť množiny udalostí.


Pravidlo sa aplikuje ak sú podmienky pravidla v pamäti. Všetky interakcie sa robia cez pamäť udalostí. Keď sa aplikuje pravidlo podmienky, z pamäti sa odstránia a nahradí sa udalosťou pomenovanou v akcii napríklad pri kreslení a príkaze select line sa nahradí start line a zvýrazní sa čiara.

Nakoniec sa aj toto odstráni zvýraznenie čiary a vykonáva sa akcia. Stavove orientované produkčné pravidlá majú odlišné správanie. Systémová pamäť je množine pomenovaných hodnôt, ale tieto sa neodstraňujú by default keď sa pravidlo aplikuje, ale sa musia odstrániť explicitne akciou, ktorá je časťou pravidla.


udalosť 1

udalosť 2

udalosť 3

udalosť 4

udalosť 5

udalosť 6

udalosť 7

udalosť 8

rozhodnutie 1

rozhodnutie 2

rozhodnutie 3

a súčasne

a súčasne

rozhodnutie 4

rozhodnutie 5

a súčasne

a súčasne

alebo

udalosť akcia


Kreslenie lomenej čiary pomocou udalostne orientovaných produkčných pravidiel: VyberČiaru -> počiatokČiary <zvýrazní sa čiara> BodSJednýmKlepnutím počiatokČiary -> zvyšokČiary <zapne sa pružná čiara>BodSJednýmKlepnutím zvyšokČiary -> zvyšokČiary <kreslí sa čiara>BodSDvojitýmKlepnutím zvyšokČiary -> <kreslí sa čiara> <vypne sa pružná čiara>

Poradie udalostí tu nemá vplyv na fungovanie


Kreslenie lomenej čiary pomocou stavove orientovaných produkčných pravidiel: Myš: {VynulujMyš, VyberČiaru, BodSJednýmKlepnutím, BodSDvojitýmKlepnutím}ŠtavČiary: {Menu, PočiatokČiary, ZvyšokČiary }PružnáČiara: {ZapniPružnúČiaru, VypniPružnúČiaru}Menu: {ZrušZvýreznenie, ZvýrazniČiaru, ZvýrazniKružnicu}Kresli: {Nekresli, KresliČiaru}Pravidlá PPSSú podobné ako v udalostne orientovaných produkčných pravidlách. VyberČiaru -> VynulujMyš PočiatokČiary ZvýrazniČiaruOdklepniPočiatokČiary -> VynulujMyš ZvyšokČiary ZapniPružnúČiaruOdklepniZvyšokČiary -> VynulujMyš KresliČiaruDvakrátOdklepniZvyšokČiary -> VynulujMyš KresliČiaru VypniPružnúČiaru

Každé musí explicitne vynulovať myš. Atribút VynulujMyš sa použije preto, lebo myš by spôsobovala neustále štartovanie udalostí.


Nastavenie rezu písma pomocou zmiešaných produkčných pravidiel:

Zmiešané produkčné pravidlá zapisujeme vo forme udalosť: podmienka -> akcia Udalosť spustí pravidlo, ale toto sa nevykoná dokiaľ nie je splnená podmienka. Udalosť sa automaticky vynuluje ale stavové atribúty zostanú nezmenené, dokiaľ sa explicitne nenastavia na iné.Produkčnými systémami sa zapisujú jednoducho súbežné dialógy.

Tučné: {vypnuté, zapnuté}Kurzíva: {vypnuté, zapnuté}Podčiarknuté: {vypnuté, zapnuté}

VyberTučné: Tučné = vypnuté -> Tučné = zapnutéVyberTučné: Tučné = zapnuté -> Tučné = vypnutéVyberKurzívu: Tučné = vypnuté -> Tučné = zapnutéVyberKurzívu: Tučné = zapnuté -> Tučné = vypnutéVyberPodčiarknuté: Tučné = vypnuté -> Tučné = zapnutéVyberPodčiarknuté: Tučné = zapnuté -> Tučné = vypnuté

Ak máme n tlačidiel, potom je potrebné 2n pravidiel, čo je lepšie ako mať 2n stavov v prípade stavového diagramu.


- CSP (Communicating Sequential Processes) a udalostné algebry

Riešia problém súbežnosti, ktorý nedokážu STN. Sekvenčné a konkurenčné procesy sú typické pre telekomunikačné protokoly a paralelné programovanie.

Udalosti s otáznikom sú používateľské akcie myši, ostatné sú vnútorné udalosti systému. "->" znamená sekvenciu udalostí, ";" - sekvenciu procesov a "[]" voľbu.

Paralelné a prekrývajúce sa procesy sa označujú pomocou "||”


Príklad voľby rezu písma pomocou rádiových tlačidiel:

DialógovýBox = TlačidloTučné || TlačidloKurzíva || TlačidloPodčiarknuté

Kód pre TlačidloTučné má syntax

TlačidloTučné = VýberTučné? -> ZapniTučné -> VýberTučné? -> VypniTučné

-> TlačidloTučné

Príklad menu grafického editora

KresliaceMenu = (VyberKružnicu? -> VykonajKružnicu [] VyberČiaru? -> VykonajČiaru)

VykonajKružnicu = odklepnuté? -> NastavStred -> odklepnuté?NakresliKružnicu -> preskoč

VykonajČiaru = PočiatokČiary; ZvyšokČiaryPočiatokČiary = odklepnuté? -> PrvýBod -> preskoč ZvyšokČiary = (odklepnuté? -> ĎalšíBod -> ZvyšokČiary

[] BodSDvojitýmKlepnutím? -> PoslednýBod -> preskoč)


5.4.4 DIALÓGOVÉ SÉMANTIKY

Ak má popis dialógu slúžiť ako formálna špecifikácia, možno aj súčasť kontraktu alebo pre skúšanie prototypu tak je nutné popísať nejako formálne sémantuku dialógu.

Dialógové notácie popíšu viac alebo menej jasne štruktúru dialógu, ale musíme popísať aj význam.

Existujú dva aspekty dialógovej sémantiky - inward smerom k aplikácii a outward smerom k prezentácii.

Sémantická časť slúži k prepojeniu oboch.

Existujú tri druhy viazania dialógu a sémantiky: notačne špecifická sémantika, odkazy na programovací jazyk, odkazy na špecifikáciu notácie.


Notačne- špecifická sémantika

Jeden prístup predstavujú obohatené prechodové siete ATN (Augmented Transition Networks).

Systém obsahuje registre pre pamätanie miesta, ktoré sa dajú nastavovať a testovať.

Hrany v ATN majú oproti stavovým diagramom okrem udalostí, ktoré spôsobujú prechody aj podmienky kedy nastane prechod.

Podmienky sa vzťahujú na systémové registre.

Okram zmeny obrazovky je odozva systému obohatená aj zápisom do stavového registra. Stavové registre môžu obsahovať komplexné dialógy a spojenie s aplikáciou a obsahovať hodnoty myši.


Aj produkčné pravidlá môžu mať rôzne formy a odkazy na sémantiku.

Systémová pamäť môže obsahovať premenné vstupných hodnôt, napríklad súradnice myši a môže sa čítať za účelom zisťovania podmienok a akcií pravidiel.

Tieto premenné môžu komunikovať s aplikáciou alebo môžu vyvolávať funkcie ako špeciálne formy akcií.

Nasledujúce produkčné pravidlo ktoré spôsobí zobrazenie bodu tam kde je kurzor v dobe keď ho používateľ odklepne kurzor v určitej cieľovej oblasti a zavolá aplikáciu ĎaľšíBod(x,y).

OdklepnutéVBode(x,y) -> ZobrazBodV(x,y), call ĎaľšíBod(x,y)


Odkazy na programovací jazyk

Častokrát sú dialógové notácie pripojené ku konvenčnému programovaciemu jazyku vo forme nástrojov, ktoré vykonávajú úlohu.


Odkazy na formálnu špecifikáciu

Príkladom je špecifikačný a prototypovací jazyk SPI (Specifying and Prototyping Interaction). Delí sa na dve časti opisujúce dialógovú notáciu a sémantiku.

Zápis postupnosti prihlásenia sa do systému v prvom jazyku: Login = VýpisLogin -> NačítajMeno -> HesloHeslo = VýpisHeslo -> ( jeNesprávne ->

[] jeSprávne -> PrácaSPočítačomPrácaSPočítačom = ( VýpisLogout -> Login

[] Príkaz -> VykonaniePríkazu -> PrácaSPočítačom

Udalosti login a NačítajMeno v druhom jazyku:

Udalosť: LoginVýpis = ponuka: truevýstup: "login:"

Udalosť: NačítajMeno =Používa: Vstup

nastav: PoužívateľovoId = Vstup


Distribuovaný a centralizovaný opis dialógu

Ak je dialóg opísaný čistou gramatikou bez sémantických prvkov, potom je jednoduché pozerať sa na syntax dialógu v izolácii, porozumieť mu a hodnotiť ho.

Na druhej strane ak sa pozrieme na typický interaktívny program tak aspekty dialógu sú distribuované v kóde a je ťažké sledovať postup typickej interakcie.

Ak sa oddelí syntax od sémantiky je to centralizovaný opis dialógu. Iná možnosť je dať dokopy asociované časti syntaxu a sémantiky ako vstupné nástroje (input-tools)


Maximalizovanie opisu syntaxe

Extrahovanie dialógovej štruktúry je možné len s niektorými notáciami. Obyčajne je možné izolovať ťasti zodpovedné pre vstup a výstup, ktoré sa dajú identifikovať kľúčovými slovami pre vstupy a výstupy, no ako spolu zapadajú je maskované priľahlým kódom. Konkrétne čo je syntaktické, v špecializovanej dialógovej gramatike môže byť kódované sémanticky.

Napríklad v udalostnej CSP zapisujeme

TextovýEditor = StlačenieMyši ->nastavVýber[] StlačenieKlávesy -> PridajZnakDoTextu

V programovacom jazyku to môže byť: udalosť = čítajUdalosť(); if (udalosť.typ == UdalosťStlačenieMyši) nastav Výber(udalosť.pozícia)

else pridajZnakDoTextu(udalosť.znak)


5.4.5 ANALÝZA A NÁVRH DIALÓGU

Tri vlastnosti dialógu - vlastnosti akcií či sú adkvátne špecifikované a konzistentné- vlastnosti stavov dialógu vrátane tých kam sa chceme alebo nechceme dostať- prezentácia a lexikálne vlastnosti - ako vyzerajú veci, a čo robia ktoré klávesy a tlačítka).

Vlastnosti akcií

Ak máme systém s mnohými stavmi, existuje obrovské množstvo prechodov medzi nimi.

Ak nezabezpečime všetky prechody, môže dôjsť ku katastrofickým situáciám.

Dizajnér je zodpovedný za to aby predpovedal ako sa bude systém chovať pri nepredvídaných situáciách.


Vlastnosti stavov

Stavy v dialógu reprezentujú body kde používateľ dostane informáciu alebo kde systém urobil niečo užitočné.

Používateľ sa potrebuje dostať do určitých stavov, podľa možnosti jednoducho - problém dosažiteľnosti.

Základný test je konektivita - či existuje cesta medzi dvomi stavmi.

Špeciálnym prípadom dosažiteľnosti je reverzibilita - undo.


Prezentácia a lexikálne vlastnosti

Často sa tvrdí, že návrh dialógu by mal byť nezávislý na detailnom návrhu prezentácie a lexikálnych detailov rozhrania.

To znamená, že sa začína s návrhom funkcionality, potom možno robením kognitívneho modelu alebo analýzou úloh.

Niekto navrhne dialóg, ktorý vykonáva tieto funkcie.

Konečne niekto navrhne vizuálnu prezentáciu systému a lexikálne väzby medzi stláčaním tlačidiel a pohybom myši a abstraktnejšími dialógovými akciami.

Sú tu problémy viditeĺnosti (visibility), pozorovateĺnosti (observability) a predvídateľnosti (predictability).


5.5 MODELY SYSTÉMU Aby sme vedeli hodnotiť použiteľnosť systému potrebujeme vedieť čo systém robí.

Štandardné formalizmypoužívané v softvérovom inžinierstve pre špecifikáciu interaktívneho systému založené na modeloch (napríklad Z, ktorý popisuje systémové stavy a operáci, algebraické formalizmy popisujúce účinok sekvencie akcií, temporálne a deontické logiky, ktoré popisujú čo sa stane ak sa udejú veci a kto je za ne zodpovedný).

Špecializované interakčné modelynavrhnuté špecificky pre popísanie vlastností použiteľnosti ako sú predvídateľnosť a pozorovateľnosť (čo môžme povedať o systéme keď sa naň pozeráme) alebo dosažiteľnosti a undo (čo s tým môžme robiť).


Semiformálne metódynamiesto veľmi komplikovaných interakkčných modelov, ktoré umožňujú ľahké použitie metód pre klasifikovanie javov ako sú udalosť a stav, použítí naivnej psychológie a zvýraznení problémov spätnej väzby pri rozhraniach.


5.5.2 MODELY INTERAKCIE

Interaktívne systémy by mali byť WISIWIG (What You See Is What You Get), konzistentné, s možnosťou návratu a tak ďalej.

Model PIE

Je to model typu čierna skrinka - neinterprezentuje internú architektúru a konštrukciu systému ale opisuje vstupy od používateľa a výstupy k používateľovi ako sú stláčanie klávesnice a výpis na obrazovku.

Vstupy Pčierna skrinka I výstupy E


Formálna definíciaPIE model je trojica < P, I, E >, kde:C – množina všetkých možných príkazov ( C odvodene od “commands” )P – množina všetkých postupnosti príkazov z C ( P odvodene od “programs”)E – množina všetkých možných efektov systému, ktoré ma používateľ k dispozícií (E odvodene od “effects”)I – interpretačná funkcia, I : P E, reprezentuje všetky výpočty systému

Potom môžme PIE reprezentovať ako diagram:

Hlavnou črtou PIE je rozdiel medzi dočasným zobrazením (výsledku) a medzi stálym (skutočným) výsledkom činnosti počítača.

Možné zobrazenia budeme označovať ako D a množinou možných výsledkov R.


Z hľadiska pozorovateľnosti (observability) budeme skúmať vzťah medzi zobrazením a výsledkom. V podstate určujeme výsledok (čo chceme dostať) zo zobrazenia (čo vidíme).

Z dôvodu formálnej predvídateľnosti pomáha informovať o internom stave systému. Stav ktorý diskutujeme nie je skutočný ale idealizovaný stav. Bude to minimálny stav požadovaná pre vyjadrenie budúceho externého chovania a budeme ho nazýzať efekt E.

Jednu akciu používateľa voláme príkaz C (command).

História všetkých príkazov používateľa je program P = sekvencia C

a aktuálny efekt vypočítame z histórie pomocou interpretačnej funkcie I:

I: P->E


Funkcie display a result získajú aktuálny výstup z minimálneho stavu:

display: E -> Dresult: E -> R

Aktuálne zobrazenie je to čo je viditeľné a aktuálny výsledok je to čo bude po dokončení interakcie. O je pozorovateľný efekt.

Všetky vlastnosti môžme získať pomocou interpretačnej funkcie I ale mnohokrát je jednoduchšie použiť prechodovú stavovú funkciu doit().

doit: E x P -> E

Táto funkcia určuje aktuálny stav e z množiny E na základe predchádzajúceho stavu a príkazu p z množiny P.

Graf PIE sa môže interpretovať na rôznych úrovniach abstrakcie.

Napríklad príkazy C na fyzickej úrovni môžu byť stlačenia klávesníc alebo tlačítok myši. Zobrazenie D môže byť výpis textu na zobrazovači a výsledok R tlač textu.

Na logickej úrovni sú príkazy na vyššej úrovni napríklad výber typu písma a výstup môže byť zobrazenie okien, tlačidiel alebo textových polí. Výsledok R môže byť napríklad súbor zapísaný na disk.


PríkladJednoduchá kalkulačka - umožňuje pripočítať jednu číslicu a vypisuje sumu.C = {0,...,9}E = N – prirodzené číslaI(null) = 0I(pc) = I(p) + cTato interpretácia hovorí:-začíname počítať sumu od nuly-keď stlačíme číslicu tak ju pripočítame k aktuálnej sume I(p)

ZáverPIE model mal významný vplyv na neskoršie formálne modely interaktívnych systémov. Pretože je príliš abstraktný, nie je vhodný pre použitie ako základ dizajnu interaktívnych systémov. Z PIE modelu vznikol napríklad RED – PIE model a z neho WYSISWYG model..



Pozorovateľnosťa predvídateľnosť

Model predvídateľnosti a pozorovateľnosti (predictability, observability) WISIWIG sa vzťahuje na to čo sa dá odvodiť zo zobrazovača.

Podľa jednej teórie existujú dva pohľady - to čo sa bude tlačiť na tlačiarni, čiže ako dobre sa dá výsledok určiť z displeja.

Druhý je čo vidíme je to čo sme zo systému dostali, čiže čo nám displej môže povedať o účinku.

Oba pohľady sa týkajú pozorovateľnosti.


Predvídateľnosť - problém odídenia na šálku čaju čiže čo môžme po prestávke vedieť ako máme pokračovať, či displej zobrazuje všetko čo nám určí stav.

Predvídateľnosť je prípadom pozorovateľnosti.

V tejto časti sa pokúsime tento proces formalizovať. Aby sme mohli určiť výsledok zo zobrazenia povieme, že existuje funkcia transparentnosť zo zobrazenia na výsledok. Formálne to zapíšeme kvantifikátormi, ktoré čítame ako:

Existuje funkcia trensparentnosti, ktorá zobrazuje D na R (D ->R) taká, kde pre každý efekt e z množiny E robí nasledovné: transparentnosť(zobrazenie(e))= výsledok(e)

A tejto vlastnosti hovoríme transparentnosť. Transparentnosť teda znamená, že v stave systému nie je nič také čo by sme nemohli vydedukovať zo zobrazenia


Pozorovateľný efekt obsahuje viac informácie ako zobrazenie - napríklad v textovom procesore posúvanie textu.

Formálny popis pozorovateľného výsledku je nasledovný:Existuje predikcia: zobrazenia O ->R

ktorá pre každé e z množiny E mapuje predikcia(pozorovanie(e)) = výsledok(e)

To znamená, že pozorovateľný jav obsahuje najmenej toľko informácie ako výsledok. Ale obsahuje navyše informáciu o interaktívnom stave systému napríklad aktuálnu pozíciu kurzora, ktorá nemá vplyv na vytlačený výsledok.


Silnejší predpoklad je viac predvídateľný:

Existuje transparentnosť: zobrazenia O ->R, ktoré pre každé e z množiny E mapujePredvídateľnosť(pozorovateľnosť(e))=e

Táto podmienka hovorí, že používateľ môže pozorovať úplný stav systému. Čiže teoreticky môže predikovať čokoľvek čo bude systém robiť.

Dosiahnuteľnosť a možnosť návratu

Dosiahnuteľnosť a možnosť návratu (reachibility, undo) je schopnosť systému nedostať sa do slepej uličky.

Dosiahnuteľnosť je taká vlastnosť keď je možné aby sa systém mohol dostať z akéhokoľvek stavu systému do iného stavu.

Špeciálnym prípadom je dostať sa do predchádzajúceho stavu (undo).

Očakávame, že pre túto funkciu existuje jediný príkaz a po jeho použití sa dostaneme tam, kde sme boli pred posledným príkazom.

Tieto veci sme študovali z pohľadu syntaxe pri modeloch dialógu, ale existujú aj na úrovni sémantiky


Norman Gulfov model interakcie

Používateľ očakáva od oknového systému, že určitou sériou krokov dosiahne požadovaný výsledok. Tento proces sa dá popísať aj ako Normanov sedemkrokový model vykonania a vyhodnotenia činnosti. Tento model si môže zjednodušiť na trojstavový model, ktorý obsahuje: cieľ, akciu a efekt.


Zjednodušený trojstavový model interakcie

Problém môže nastať u používateľa pri prechode akcia – fáza. Napríklad práve počas vykonávania akcií v prípade nejednoznačnosti vnímania prvkov GUI. Používateľ tak vykoná často krát zbytočnú, ba dokonca z jeho strany neželanú operáciu. Základnými problémami pri používaní oknových systémov sú:

Problémy typu „Akcia – efekt“:Absencia, prípadne zlé zobrazovanie stavu systému (vo

všeobecnosti sa to dá aplikovať aj na iné predmety)Existencia zavádzajúcich informácií o stave systému,

Problémy typu „Efekt – cieľ“:Absencia alebo nejednoznačnosť krokov na konštrukciou cieľa.Chýbajúce alebo neúplné kroky, smerujúce k splneniu cieľa

Problémy typu „Cieľ – akcia“:Zhoršený prístup ku korektným akciámĽahký prístup k nesprávnym akciám




Absencia informovania alebo zlé informovanie o stave systému

Väčšina pravidiel GUI zdôrazňuje čistý dizajn, teda všetky relevantné informácie o stave systému by mali byť jasne prezentované v pracovnom prostredí resp. používateľovi.

Ak pracovné prostredie nie je schopné zobraziť aktuálny stav systému, jedná sa o prvý problém oknových systémov. Označuje sa aj ako „hidden mode“.

Typickým príkladom je napríklad vi editor, kde existuje niekoľko pracovných režimov. Editor (obyčajne) neindikuje aktuálny režim používateľovi a tak ten v domnienke, že pracuje vo vstupnom režime, píše text. Lenže editor stláčané klávesy interpretuje ako príkazy, pretože je v skutočnosti v príkazovom režime.


Existencia zavádzajúcich informácií o stave systému

Zobrazovanie zavádzajúcich informácií o aktuálnom stave. Toto sa bežne stáva, ak sú zobrazené informácie o stave konfliktné.

Napríklad ak sa od používateľa pri vkladaní textu očakáva text len z veľkých písmen, ale systém signalizuje používateľovi písmenka napríklad: Abc.

Absencia alebo nejednoznačnosť krokov na konštrukciu cieľa

Ak neexistujú relevantné podnety alebo sú pre používateľa neadekvátne, prípadne nezrozumiteľné v danom kontexte.

Napríklad okno pri chybe v programe s tromi možnosťami a ten nevie, ktorú si vybrať


Chýbajúce alebo neúplné kroky pri plnení cieľa

Systémové efekty by mali dať používateľovi najavo, čo systém robí a ako reaguje na jeho podnety. Napríklad ak je systém dlhšiu dobu zaneprázdnený, mal by dať najavo používateľovi, že reagoval na jeho poslednú akciu a v akom štádiu je práve spracovávaný príkaz.

Nakoniec je potrebné zobraziť, či bol príkaz splnený úspešne alebo nastala chyba.Príkladom mätúcich krokov na splnenie cieľa je napríklad bankomat. Majme interakčnú procedúru „vyber kartu“ „vyber peniaze“. Dôsledkom toho používateľ nemôže vybrať peniaze, až kým si nevyberie kartu z bankomatu.


Zhoršený prístup ku korektným akciám

Prvým prípadom problému „cieľ – akcia“ je ak prístup ku určitej akcií nie je zrejmý. Dôsledkom toho používateľ musí vyvinúť značnú námahu na nájdenie správnych akcií.

Napríklad chceme nastaviť digitálne hodinky v MP3 prehrávači. Na zobrazenie času je potrebné podržať stlačené ovládacie tlačidlo na ovládanie menu. Čas však môžeme zmeniť jedine dvoma tlačidlami so šípkami na nastavovanie hlasitosti, ktoré majú nejakú podobu. Hodiny nastavíme pomocou tlačidla s inou podobou a minúty tiež. Tento spôsob interakcie je veľmi mätúci, nakoľko používateľ očakáva od týchto tlačidiel zvyšovanie a znižovanie.


Ľahký prístup k nesprávnym akciám

Druhým prípadom problému „cieľ – akcia“ je ak prístup k neželaným akciám je príliš jednoduchý. Často sa tak môže stávať, že používateľ nechtiac vyberie nesprávnu voľbu.

Príkladom môže byť opäť MP3 prehrávač s možnosťou počúvať rádio. Obsahuje tlačidlo s názvom „MODE“, ktoré prepína medzi dvoma režimami: prehrávanie pesničiek z pamäte prehrávača alebo z rádia. Obsahuje aj ďalšie tlačidlo s názvom „RADIO ON“, ktoré prepína medzi FM a AM pásmom. Používateľ má problém vybrať správnu voľbu, nakoľko ako správna akcia sa ponúka v skutočnosti tá nesprávna.

5.5.3 ANALÝZA STAVOV A UDALOSTÍ

Niektoré dialógové notácie sú založené na stavoch a niektoré na udalostiach.

Rozdiel je v tom, že jedny sa týkajú bytia a druhé robenia.

Prvé majú vždy hodnotu na ktorú sa môžme pýtať. Napríklad: aká bola poloha myši pred dvomi sekundami?

Udalosť sa prihodí v určitý čas a otázka v tomto prípade by znela: kedy stlačil používateľ tlačítko myši?

Analýza stavov a udalostí sa pozerá na rôzne úrovne systému ako je používateľ, prezentácia na obrazovke, dialógy a aplikácie


Vlastnosti udalostí: hodiny a kalendár

Príklad: X sa má stretnúť s Y pred ôsmou v kine. Aby to stihol musí prestať pracovať o pol ôsmej. Keďže X nemá budík, musí sledovať čas. Inokedy Y pri každodennom pozeraní sa do kalendáru zistí, že zajtra má X narodeniny a chce mu kúpiťdarček. Z tohto scenáru abstrahujeme dôležité vlastnosti stavov a udalostí.

Stav - Hodinky X a kalendár Y sú stavy ukazujúce čas a dátum. Hodinky ukazujú stav spojite (klasické hodiny) alebo diskrétne (číslicové).

Udalosti - sú pol ôsmej, keď X musí prestať pracovať. Keby mal hodinky s budíkom, tie by mu automaticky povedali kedy má prestať, čiže hodinky sú schopné hlásiť udalosť (okrem zisťovania stavu). Zistenie narodenín v kalendári Y je tiež udalosť.


Registrovanie (Polling) je periodické zisťovanie nejakej hodnoty. Je to metóda zmeny stavu na udalosť.

Skutočné a vnímané - keď X zisťoval či už má prestať pracovať pozrel sa na hodinky tri minúty po pol ôsmej teda neskoršie ako mala nastať udalosť prestať pracovať. Namiesto skutočnej udalosti to bola vnímaná udalosť. Vzorkovanie registrovania môže byť hustejšie ale vždy sa vnímaná udalosť oneskorí za skutočnou.

Granularita - nastavený čas na hodinkách a záznam v kalendári sú udalosti, ale s rozličnou časovou osou. Interpretácia stavov a udalostí sa môže líšiť v závislosti od časovej mierky.


Dôsledky na návrh

Aby sme zaistili, že vnímaná udalosť sa udeje v správnom čase musíme uvažovať časovú škálu rôznych rôzhraní.

Jednoduché prezentovanie udalosti na obrazovke nezaručí že táto bude vnímaná používateľom alebo na druhej strané bude vnímaná v nevhodnom čase.

Ak si Y nastaví pevný časový predstih pre oznámenie dátumu narodenín X v elektronickom kalendári, môže sa stať že ju to zobudí o tretej ráno, alebo zvukový signál zaznie raz v čase keď Y nesedí pri počítači a textový oznam o udalosti prehliadne


Naivná psychológia

Aby sme predpovedali interaktívne techniky používame naivnú psychológiu. Táto nám napovie kam sa bude sústreďovať pozornosť používateľa a ktoré sú významné stimuly. Ako prvé nás zaujíma kam sa bude používateľ pozerať.

MyšKeď používateľ presúva kurzor na cieľ tak sa jeho pozornosť sústredí na tento cieľ.

Miesto vkladania textuPočas písania textu sa používateľ pozerá na text, ktorý práve píše teda na bod vkladania. Ale pri písaní po pamäti je to menej pravdepodobné ako pri určovaní miesta vkladania pomocou myši.

ObrazovkaMôžme s istotou tvrdiť, že používateľ sa bude pozerať prerušovane na obrazovku.


Ale nie je garancia, že zbadá konkrétnu ikonu alebo správu, jedine keby zaberala veľkú plochu obrazovky. Napríklad je to ikona presýpacích hodín, pri čakaní na vykonanie operácie.

Keď vieme kam sa bude pozerať, môžme tam umiestniť informáciu (nie do stavového riadku na spodok obrazovky, kam sa nik nepozerá).

Ďalej sú to udalosti, pri ktorých nevieme kam sa používateľ pozerá. Môžu sa riešiť zvukovými signálmi ako je písknutie, alebo inými zvukmi.

Inou možnosťou je využitie poznatku že periférne videnie môže zaznamenať objekt, keď sa tento pohybuje alebo bliká. Ale treba si uvedomiť aby sa nemiešal s iným blikaním, ktoré trvá aj mimo udalosti. Ďaľším problémom je ukončenie operácie a prechod na inú.


TEMPORÁLNA LOGIKA

Navyše k logickým operátorom má operátory časových relácií:Pred, po, prvy, posledný, nasledujúci, predchádzajúci, …..

DEONTICKÁ LOGIKA

Deontická logika skúma logické štruktúry preskriptívneho (predpisujúceho) jazyka normatívneho konania alebo konania realizujúceho normu. Deontickú logiku niekedy považujú sa časť modálnej logiky: študuje vlastnosti takých faktorov, ako "je povinný", "je dovolené", "je zakázané" a pod.


5. METÓDY A PRINCÍPY NÁVRHU HCI

Documents