Strach z prázdného listu při navrhování rozhraní. Zásady návrhu uživatelského rozhraní Co nedělat ve fázi návrhu rozhraní

2.2. FÁZE NAVRHOVÁNÍ ZAKÁZKY ROZHRANÍ

Výzkum psychologických aspektů lidské komunikace s počítačem ukázal, že by se člověk měl všemi možnými způsoby snažit tuto komunikaci dehumanizovat, to znamená, že uživatel by neměl počítač vnímat jako plnohodnotného partnera. Nicméně výměna informací mezi uživatelem a počítačem (přesněji jeho softwarem) podle všech formálních charakteristik odpovídá pojmu „dialog“ v obecně přijímaném smyslu. Pravděpodobně si čtenář i bez pomoci Výkladového slovníku dokáže vyjmenovat základní pravidla, která je třeba dodržovat, aby byl dialog konstruktivní:

za prvé, účastníci dialogu musí rozumět jazyku toho druhého;

za druhé by neměli mluvit současně;

zatřetí, další prohlášení musí vzít v úvahu jak obecný kontext dialogu, tak nejnovější informace získané od partnera.

Pokud partneři diskutují o problémech souvisejících s jakoukoli speciální oblastí, měli by se držet stejné terminologie; pokud se jeden z nich snaží druhému něco vysvětlit, měl by nejprve vysvětlit základní pojmy a pojmy.

Nutno také dodat, že k lepšímu vzájemnému porozumění přispívá použití dalších výrazových prostředků. Někdy jedna povedená ilustrace nahradí desítky slov. Například na otázku "Jak se dostat do knihovny?" Nejlepší je odpovědět s mapou města po ruce.

Nyní si připomeňme, co se našim partnerům nelíbí.

Za prvé - přílišná známost. Málokomu se navíc líbí, když se při rozhovoru zatahá za rukáv, odšroubuje knoflík nebo použije jiné originální metody, jak upoutat pozornost. Velmi krátké odpovědi a příliš dlouhé pauzy mohou partnera zmást a zneužití odborných výrazů nebo žargonu obecně může vést k předčasnému ukončení konverzace.

Výše uvedená úvaha je velmi obecná a platí téměř pro jakýkoli dialog, bez ohledu na vztah mezi účastníky a účel dialogu. Tyto faktory však významně ovlivňují struktura dialog, tedy forma komunikace. Například, setkají-li se dva přátelé, dialog připomíná hru tenisu: iniciativa se střídá mezi jedním a druhým partnerem; pokud přijdete do restaurace, pak se vaše komunikace s číšníkem omezí na výběr jídel z navrhovaného menu, a když žádáte o zahraniční pas, úředník vás požádá o vyplnění jednoho nebo dvou formulářů a jejich kontrolu, v případě potřeby objasnění určitých bodů.

Při navrhování uživatelského rozhraní tedy musíte určit:

Struktura dialogu;

Možný scénář rozvoje dialogu;

Vizuální atributy zobrazovaných informací (syntaxe zprávy).

2.2.1. VÝBĚR STRUKTURY DIALOGU

Výběr struktury dialogu je prvním krokem, který je třeba dokončit při vývoji rozhraní.

Čtyři možnosti struktury dialogu diskutované níže jsou variacemi struktury „otázka-odpověď“, avšak každá z nich má své vlastní charakteristiky a je nejvhodnější pro určitou třídu úloh.

DIALOG TYPU „OTÁZKA – ODPOVĚĎ“.

Struktura dialogu otázek a odpovědí (Q&A) je založena na analogii s běžným rozhovorem. Systém přebírá roli tazatele a dostává od uživatele informace ve formě odpovědí na otázky. Toto je nejznámější struktura dialogu; všechny počítačem řízené dialogy se v té či oné míře skládají z otázek, na které uživatel odpovídá. Ve struktuře otázek a odpovědí je však tento proces výslovně uveden. V každém bodě dialogu systém zobrazí jednu otázku jako nápovědu, na kterou uživatel dá jednu odpověď. V závislosti na obdržené odpovědi se systém může rozhodnout, kterou otázku položí jako další. Struktura Q&A poskytuje přirozený mechanismus pro zadávání řídicích zpráv (příkazů) i dat. Neexistují žádná omezení na rozsah nebo typ vstupních dat, která lze zpracovat. Existují systémy, které poskytují odpovědi v přirozeném jazyce, ale častěji používají jednoslovné věty s omezenou gramatikou.

Dialog ve formě otázek a odpovědí dostatečně poskytuje uživatelskou podporu, protože i krátká úvodní otázka, je-li moudře strukturována, může být samovysvětlující. Struktura otázek a odpovědí nezaručuje minimální množství vstupů měřené počtem úhozů, ale vhodným výběrem zkratek lze omezit redundanci. Struktura otázek a odpovědí má však jednu významnou nevýhodu. I když je zadávání dostatečně rychlé, pro člověka, který už ví, jaké otázky systém klade a jaké odpovědi má dát, je zodpovězení celé série otázek značně zdlouhavé.

S příchodem grafického rozhraní struktura Q&A poněkud zastarala, ale stále má určité výhody. Tato struktura může splňovat požadavky různých uživatelů a datových typů. Taková struktura je zvláště vhodná při realizaci dialogu s mnoha „pobočkami“, tzn. v případech, kdy má každá otázka velký počet odpovědí, z nichž každá ovlivňuje, která otázka bude položena jako další. Z tohoto důvodu se struktura Q&A často používá v expertních systémech.

DIALOG NA ZÁKLADĚ MENU

Nabídky jsou možná nejoblíbenější možností pro organizování požadavků na vstup během dialogu řízeného počítačem.

Existuje několik základních formátů pro prezentaci nabídek na obrazovce:

Seznam objektů vybraných přímou indikací nebo uvedením čísla (nebo mnemotechnického kódu);

Menu ve formě datového bloku;

Menu ve formě datové linky;

Menu ve formě ikon.

Nabídka datového pruhu se může objevit v horní nebo dolní části obrazovky a často zůstává v této poloze po celou dobu konverzace. Prostřednictvím menu je tedy vhodné zobrazit možné možnosti vstupních dat dostupných kdykoliv při práci se systémem. Pokud má systém dostatečně širokou škálu možností akcí, je uspořádána hierarchická struktura odpovídajících nabídek. Další nabídky ve formě bloků dat „vyskakují“ na obrazovce v poloze určené aktuální pozicí ukazatele nebo „vypadnou“ přímo z lišty nejvyšší úrovně. Tyto nabídky zmizí, jakmile vyberete možnost.

Nabídky ve stylu ikon obsahují řadu možností rozmístěných po obrazovce; často vybrané objekty obsahují grafické znázornění pracovních možností.

Uživatel dialogového menu může vybrat položku zadáním textového řetězce, který položku identifikuje, přímým ukazováním na ni nebo procházením a výběrem ze seznamu. Systém může zobrazovat položky nabídky postupně, přičemž uživatel si stisknutím klávesy vybere položku, kterou potřebuje.

Nabídku lze stejně dobře použít pro zadávání řídicích zpráv i dat. Vhodná struktura nabídky závisí na její velikosti a organizaci, způsobu výběru položek nabídky a skutečné potřebě uživatele podporovat nabídku.

Struktura typu nabídky je nejpřirozenějším mechanismem pro práci s ukazovacími a výběrovými zařízeními: nabídka je reprezentace objektů, které uživatel vybírá. Pokud se dialog skládá výhradně z nabídek, je možné implementovat sekvenční rozhraní, ve kterém uživatel používá pouze ukazovací zařízení; taková konzistence je však v praxi jen zřídka dosažitelná. Nutno také podotknout, že ačkoli práce s těmito zařízeními nevyžaduje profesionální ovládání klávesnice, pro trénovaného uživatele to není nejrychlejší způsob výběru z nabídek. Namísto upřesnění může uživatel uvést svou volbu zadáním příslušného identifikátoru.

Nabídka je nejpohodlnější strukturou dialogu pro netrénované uživatele; strnulé pořadí otevírání a hierarchické vnořování menu může profesionála dráždit a zpomalovat jeho práci. Tradiční struktura menu není dostatečně flexibilní a plně nevyhovuje technikám přizpůsobení dialogu, jako je psaní napřed, což může urychlit tempo práce vyškoleného uživatele. Problematika organizace a vizuální prezentace menu je podrobněji rozebrána v části „Návrh ovládacích prvků“.

DIALOG NA ZÁKLADĚ OBRAZOVKOVÝCH FORMULÁŘŮ

Jak struktura typu otázka-odpověď, tak struktura typu nabídky zahrnují zpracování jediné odpovědi v každém kroku dialogu. Dialog založený na obrazovkách umožňuje zpracování několika odpovědí v jednom kroku dialogu. V praxi se formuláře používají především tam, kde účtování jakékoli činnosti vyžaduje zadání celkem standardního souboru dat. Osoba vyplňující formulář si může vybrat pořadí odpovědí, dočasně přeskočit určitou otázku, vrátit se k opravě předchozí odpovědi a dokonce „roztrhnout formulář“ a začít vyplňovat nový. S formulářem pracuje, dokud jej zcela nevyplní a odešle do systému. Softwarový systém může zkontrolovat každou odpověď ihned po zadání, nebo počkat a zobrazit seznam chyb až po vyplnění celého formuláře. V některých systémech jsou informace, které uživatel zadá, dostupné pouze tehdy, když uživatel po vyplnění formuláře stiskne enter. Otázka, zda zkontrolovat odpověď přímo nebo odložit kontrolu, dokud nebudou zadány všechny odpovědi, je těžké rozhodnout: chybové zprávy zobrazené bezprostředně po odpovědi mohou rušit, ale mohou mít také pozitivní dopad. Obecně platí, že v případech, kdy jsou informace pro zadání vybírány z nějakého celého dokumentu, je lepší odložit kontrolu až na konec vyplňování formuláře, aby nedošlo k přerušení procesu zadávání; pokud taková integrita neexistuje, pak by měla být kontrola provedena ihned po zadání odpovědi (po vyplnění dalšího pole).

Pokud dojde k jakékoli chybě, aplikace by neměla znovu vykreslovat prázdný formulář; zobrazí se formulář s předchozími odpověďmi a chybami. Nový „formulář“ je vydán pouze na žádost uživatele.

Tuto strukturu je tedy vhodné použít tam, kde je zdrojem dat existující formulář vstupního („papírového“) dokumentu.

Vzhled těchto formulářů nemusí být stejný (to může dokonce způsobit, že údaje na obrazovce budou méně viditelné), ale všechny zadané datové prvky musí být ve stejném relativním pořadí a formátu jako v původním dokumentu.

Často nelze všechny požadované vstupní jednotky zobrazit současně v rámci jedné obrazovky (nebo okna) a musí být rozděleny do skupin, které se zobrazují na posloupnosti obrazovek (oken). Je důležité, aby toto rozdělení zachovalo logické souvislosti a nevedlo k oddělení souvisejících částí dokumentu.

Dialogová struktura založená na obrazovkových formulářích poskytuje vysokou úroveň uživatelské podpory: pro každou otázku formuláře lze poskytnout chybová hlášení a informace nápovědy. Uživateli můžete pomoci také tím, že do otázky nebo do pole odpovědi zahrnete některé prvky formátu odpovědi. Tato struktura umožňuje rychlejší zadávání dat než struktura otázka-odpověď a umožňuje manipulaci s širším rozsahem vstupů než nabídka; Navíc s ním mohou pracovat uživatelé jakékoli kvalifikace. Protože je tato struktura spíše sekvenční než stromová, je méně vhodná pro práci v režimu výběru. Další oblastí použití obrazovkových formulářů je nastavení parametrů dotazu v databázích. Tento mechanismus se někdy nazývá vzorový dotaz ( Dotaz podle Příklad).

Jedním z typů vyplňování formulářů jsou také vícevýběrové nabídky. V takových nabídkách je uživateli předložen seznam možností a není omezen na jednu volbu; Můžete zadat několik možností.

DIALOG NA ZÁKLADĚ PŘÍKAZOVÉHO JAZYKA

Dialogové struktury založené na příkazovém jazyce jsou stejně běžné jako struktury typu nabídky. Je velmi běžně používán v operačních systémech a je na druhém konci spektra struktury dialogu než struktura typu nabídky. Historicky se jedná o první dialogovou strukturu, která byla implementována.

U tohoto typu dialogu softwarový systém nezobrazuje nic jiného než neustálou výzvu (výzvu k zadání příkazu), což znamená, že systém je připraven k provozu. Každý příkaz se zadává na nový řádek a obvykle se ukončuje stisknutím klávesy „enter“. Za správnost zadaných příkazů odpovídá uživatel. Systém vás informuje, že není možné provést nesprávný příkaz, obvykle bez vysvětlení důvodů.

Stejně jako nabídka je dialog založený na příkazech vhodný pro zadávání řídicích zpráv, ale poskytuje větší výběr v libovolném bodě dialogu a nevyžaduje hierarchickou organizaci programů, které jej obsluhují.

Softwarový systém může podporovat poměrně velké množství příkazů, ale v praxi by měl být počet omezen, aby nedošlo k přetížení paměti uživatele. Struktura založená na příkazovém jazyce nemá dobrou uživatelskou podporu a je vhodná především pro vyškolené specialisty. Před použitím takového systému je nutné absolvovat školení a následně nastudovat vlastnosti práce z dokumentace, nikoli z praxe. Navíc, protože systém neví, co má uživatel v úmyslu udělat, je obtížné nabídnout jakoukoli skutečnou pomoc v procesu, kromě vydání poměrně obecné pomoci.

Protože tato struktura zahrnuje velké množství zapamatovaného materiálu, názvy příkazů by měly být zvoleny tak, aby nesly sémantickou zátěž a byly snadno zapamatovatelné. Vývojář by se měl snažit vyhnout zbytečné funkcionalitě, která vychází z touhy vytvořit vlastní příkaz pro každou funkci vykonávanou systémem, to znamená, že by neměl vytvářet mnoho různých příkazů s často se překrývajícími funkcemi. Takové „dobré“ úmysly často vedou k velkému množství klíčových slov pro příkazy a syntaktická pravidla, z nichž mnohá se používají zřídka a pouze komplikují práci.

Dialog musí řídit data. V rozhraních založených na příkazovém jazyce se toho obvykle dosahuje pomocí složených příkazových řádků, kde klíčové slovo označující příkaz (co dělat) předchází seznam parametrů (vstup). Parametry v seznamu lze zadat v jedné ze dvou forem - poziční nebo klíčová. V prvním případě je účel parametru určen jeho umístěním na příkazovém řádku. V případě klíčových parametrů každé hodnotě předchází specifický identifikátor, který definuje její účel.

Polohové parametry snížit množství zadávaných informací, ale jejich významnou nevýhodou je, že zadané hodnoty musí být specifikovány v přesně definovaném pořadí, jehož porušení je systémem špatně diagnostikováno a může vést k vážným následkům. Nastavení polohových parametrů je složitější, pokud je jejich seznam dostatečně velký. Tento nedostatek se snaží kompenzovat tím, že umožňují vynechat neměnné parametry zavedením dvou oddělovačů jeden po druhém.

Klíčové parametry snížit zatížení paměti uživatele v tom smyslu, že není potřeba pamatovat si pořadí jejich výskytu; Kromě toho můžete vynechat volitelné parametry. Na druhou stranu si v tomto případě uživatel potřebuje zapamatovat mnoho klíčových slov a vývojář pro ně musí zvolit „smysluplné“ názvy. Tento přístup také vyžaduje více systémového času k rozpoznání náhodných klíčových slov.

Podpora mnoha příkazových jazyků makra, které rozšiřují funkčnost dialogu bez zvýšení počtu příkazů. Makro obsahuje několik samostatných příkazových řádků. Při přístupu během dialogu se jednotlivé řádky makro příkazů provádějí jeden po druhém, jako by byly zadány z klávesnice. To výrazně zkracuje dialogová relace tím, že obsahuje často se opakující sekvence příkazů, které jsou ve skutečnosti formátovány jako makra.

Struktura založená na příkazovém jazyce je ve svých schopnostech nejrychlejší a nejflexibilnější ze všech struktur dialogu. Většina uživatelských rozhraní založených na "přirozeném" jazyce je implementována pomocí příkazových jazyků s velmi velkou sadou klíčových slov. Trénovaný uživatel si užívá pocit, že ovládá systém, a ne naopak. Tato struktura však neposkytuje uživatelskou podporu, takže i zkušení uživatelé velmi obtížně využívají všechny schopnosti v ní obsažené. Většina uživatelů zná pouze velmi omezenou sadu nástrojů, se kterými pravidelně pracuje.

Výše uvedené lze prezentovat ve formě tzv. „výběrové tabulky“ (obr. 2.1).

* - použití tohoto typu dialogu touto kategorií uživatelů vyžaduje přítomnost systému nápovědy;

** - použití systémových nástrojů je možné pouze v omezené míře.

Rýže. 2.1. Možnost výběrové tabulky

Kromě těch, která jsou uvedena v tabulce, mohou být v ní zahrnuta další kritéria výběru (dostupnost nástrojů pro vývoj rozhraní, povaha uživatele, omezení dostupných zdrojů atd.).

Výběr nejvhodnější struktury dialogu na základě tabulky se provádí následovně.

1. Zavřete sloupce „Typ dialogu“.

2. Ve sloupci „Výběr uživatele“ označte kritéria relevantní pro danou aplikaci.

Hlavní hodnotou tabulky je, že ji lze použít jako výchozí volbu pro výběr typu dialogu nebo jako prostředek pro konečnou kontrolu, zda vybraný typ dialogu splňuje uvažovaná kritéria.

Pokud se očekává, že některé položky budou důležitější než jiné, mohou být váženy odlišně. Můžete také určit, které položky by měly být považovány za provedené bezpodmínečně; typy dialogů, které nesplňují alespoň jeden z těchto bodů, musí být okamžitě odmítnuty, bez ohledu na to, kolik bodů získají ve zbývajících bodech.

2.2.2. VÝVOJ SKRINÁTU DIALOGU

Vývoj dialogu v čase lze považovat za sled systémových přechodů z jednoho stavu do druhého. Je zřejmé, že žádný z těchto stavů by neměl být „slepou uličkou“, tzn. uživatel musí být schopen přejít z libovolného aktuálního stavu dialogu do požadovaného (v jednom nebo více krocích). K tomu je při vývoji rozhraní nutné určit všechny možné stavy dialogu a cesty přechodu z jednoho stavu do druhého. Jinými slovy, je třeba se rozvíjet dialogový skript.

Cíle vývoje dialogového skriptu jsou:

Identifikace a odstranění možných patových situací během rozvoje dialogu;

Volba racionálních způsobů přechodu z jednoho stavu dialogu do druhého (od současného k požadovanému);

Identifikace nejednoznačných situací, které vyžadují další pomoc uživateli.

Složitost vývoje scénáře je určena především dvěma faktory:

funkčnost vytvářené aplikace (tj. počet a složitost implementovaných funkcí zpracování informací) a míra nejistoty možných akcí uživatele.

Na druhé straně míra nejistoty v akcích uživatele závisí na zvolené struktuře dialogu. Dialog založený na nabídkách má největší determinismus, zatímco dialog otázka-odpověď řízený uživatelem má nejmenší determinismus.

Z výše uvedeného vyplývá, že skript dialogu lze zjednodušit snížením míry nejistoty v akcích uživatele. Možné způsoby řešení tohoto problému jsou:

použití smíšené struktury dialogů (používání nabídek k „omezení svobody uživatele“ tam, kde je to možné);

aplikace vstupního řízení vstupních informací (příkazy a data).

Další příležitosti ke snížení nejistoty uživatelských akcí poskytuje objektově orientovaný přístup k vývoji rozhraní, ve kterém je pro každý objekt předem stanoven seznam vlastností a přípustných operací. Tento přístup je nejúčinnější při vytváření grafického rozhraní; Tyto problémy jsou podrobněji popsány v části „Funkce grafického rozhraní“.

Při snižování počtu možných stavů dialogu musí vývojář zároveň pamatovat na nutnost zohlednit nástroje uživatelské podpory ve svém skriptu, což skript nepochybně činí složitější.

Způsob, jakým je dialogový skript popsán, závisí na jeho stupni složitosti. Existující metody pro popis scénářů lze rozdělit do dvou velkých skupin:

neformální a formální metody.

Hlavní výhodou formálních metod je, že umožňují automatizovat jak návrh dialogu, tak jeho úpravu (adaptaci) v souladu s charakteristikami uživatele.

V současnosti jsou nejpoužívanější formální metody pro popis scénářů založené na Petriho sítích a jejich rozšířeních a také na systémech reprezentace znalostí (rámcové modely a produkční systémy).

Bez ohledu na to, jak je scénář popsán, jeho základní strukturní jednotkou je krok dialogu, odpovídající jednomu aktu interakce uživatele se systémem. Krok dialogu lze schematicky znázornit, jak je znázorněno na obr. 2.2.

Rýže. 2.2. Krok dialogu

Dialogový skript vám umožňuje popsat proces interakce uživatele s aplikací na úrovni aplikačního problému, který řeší. Pro softwarovou implementaci rozhraní je však takový popis příliš obecný. Proto je ve fázi implementace nutné přejít na úroveň popisu příslušných procesů pomocí používaných nástrojů pro vývoj aplikací.

TEPLO DIALOGU

Proces komunikace mezi uživatelem a počítačem je spojen s řadou významných objektivních i subjektivních omezení a musí odpovídat psychofyziologickým možnostem člověka: schopnost přijímat a zpracovávat informace, objem smyslové a krátkodobé paměti, schopnost přijímat a zpracovávat informace, dávat pozor na to, co je potřeba. schopnost soustředit pozornost na nejdůležitější informace, schopnost reprodukovat informace z dlouhodobé paměti atd. P.

V tomto ohledu by při vývoji dialogového scénáře měly být brány v úvahu takové psychofyziologické vlastnosti potenciálních uživatelů, jako je motorika, reakční doba, barevná citlivost atd. V této části se budeme podrobněji zabývat požadavky na jednu z nejdůležitějších charakteristik rozhraní - poskytované tempo dialogu. Zbytek výše uvedených požadavků bude diskutován v následujících částech knihy.

Tempo dialogu závisí na vlastnostech počítačového hardwaru a softwaru a také na specifikách řešených úloh. Požadavek, aby tempo dialogu odpovídalo psychologickým charakteristikám člověka, klade omezení na hodnoty těchto charakteristik nejen „shora“, ale také „zdola“. Ujasněme si toto tvrzení.

Doba odezvy (Odezva) systémy je definován jako interval mezi událostí a reakcí systému na ni. Tato charakteristika rozhraní určuje zpoždění v práci uživatele při přechodu na další krok úlohy.

Důležitost zohlednění tempa dialogu si uvědomila již v 60. letech, kdy se objevily první interaktivní systémy. Pomalá odezva systému nevyhovuje psychickým potřebám uživatele, což vede ke snížení efektivity jeho činností. Příliš rychlé odpovědi mohou také vytvořit nepříznivý obraz systému.

Požadavky na dobu odezvy závisí na tom, co uživatel od systému očekává a jak interakce se systémem ovlivňuje dokončení jeho úkolů. Výzkum ukázal [3], že pokud je doba odezvy kratší, než se očekávalo, přesnost výběru operace z nabídky se zvyšuje se zvyšující se dobou odezvy systému. Je to dáno tím, že příliš rychlá odezva systému uživatele jakoby „uspěchává“ a nutí ho šukat ve snaze „držet krok“ s efektivnějším komunikačním partnerem. Bylo zjištěno, že začínající uživatel se bojí pracovat se systémem, pokud po několika minutách psaní od něj okamžitě obdrží odpověď s chybovou zprávou.

Doba odezvy by měla odpovídat přirozenému rytmu uživatelů. Při běžné konverzaci lidé čekají na odpověď asi 2 sekundy a totéž očekávají při práci na počítači. Čekací doba závisí na jejich stavu a záměrech. Přesvědčení uživatele je také silně ovlivněno jeho předchozími zkušenostmi se systémem.

Typicky si člověk může současně zapamatovat informace o pěti až devíti objektech. Předpokládá se také, že ukládání dat v krátkodobé paměti je časově omezené: asi 2 sekundy pro řečové informace a 30 sekund pro senzorické informace. Lidé proto mají tendenci rozdělovat své aktivity do kroků, které odpovídají částem informací, které mohou současně uložit do paměti. Dokončení další fáze se nazývá doložka. Zpoždění, která brání nástupu klauzulí, jsou velmi škodlivá a nepříjemná, protože obsah krátkodobé paměti vyžaduje neustálou aktualizaci a pod vlivem vnějších faktorů se snadno vymaže. Ale po klauzuli jsou taková zpoždění docela přijatelná a dokonce nezbytná. Dokončení úkolu vedoucího k odpočinku se nazývá zavírání. V tuto chvíli odpadá potřeba dalšího uchovávání informací a člověk dostává výraznou psychickou úlevu. Protože uživatelé intuitivně usilují uzavření ve své práci byste měli dialogy rozdělit na fragmenty, aby uživatel mohl „včas“ zapomenout meziinformace.

Uživatelé, zejména začátečníci, obvykle preferují mnoho malých operací před jednou velkou operací, protože v tomto případě mohou nejen lépe kontrolovat celkový průběh řešení a zajistit jeho uspokojivý průběh, ale také se odpoutat od detailů práce v předchozích fázích. .

Dostupné výsledky výzkumu umožnily vyvinout následující doporučení ohledně přijatelné doby odezvy interaktivního systému:

0,1... 0,2 s - pro potvrzení fyzických akcí (stisknutí klávesy, práce se světelným perem, „myš“);

0,5... 1,0 s - reagovat na jednoduché příkazy (například od okamžiku zadání příkazu výběrem alternativy z nabídky, dokud se na obrazovce neobjeví nový obrázek);

1... 2 s - při vedení souvislého dialogu (když uživatel vnímá řadu vzájemně souvisejících otázek jako jednu informaci tvořící jednu nebo několik odpovědí, neměla by prodleva mezi po sobě jdoucími otázkami přesáhnout stanovenou dobu trvání);

2... 4 s - reagovat na složitý požadavek spočívající ve vyplnění formuláře. Pokud zpoždění neovlivní jinou uživatelskou zkušenost související s prvním, mohou být přijatelné zpoždění až 10 s;

více než 10 s - při práci v režimu multitaskingu, kdy uživatel vnímá tento úkol jako proces na pozadí. Obecně se uznává, že pokud uživatel neobdrží odpověď do 20 sekund, pak se nejedná o interaktivní systém. V takovém případě může uživatel na úkol „zapomenout“, přejít k řešení jiného problému a vrátit se k němu, když se mu to hodí. V tomto případě musí program informovat uživatele, že zpoždění odezvy není důsledkem selhání systému (například pravidelnou aktualizací stavového řádku systému nebo udržováním protokolu o úkolu uživatele).

METODY FLEXIBILNÍHO ROZVOJE ROZHRANÍ

Předběžná analýza (alespoň na kvalitativní úrovni) možného scénáře dialogu vám umožní vyhnout se mnoha problémům ve fázi implementace aplikace. Pokud však aplikaci může používat skupina uživatelů s různou mírou zkušeností, zůstává řada problémů nevyřešena. Je proto vysoce žádoucí, aby byla během dialogu umožněna dostatečná flexibilita. Měla by to být schopnost aplikace přizpůsobit se (uživatelem nebo automaticky) jakékoli možné úrovni uživatelské zkušenosti.

Existují tři typy přizpůsobení: pevné, úplné a kosmetické.

Na pevný přizpůsobení, uživatel explicitně vybere úroveň podpory dialogu. Nejjednodušší verze takové adaptace je založena na použití dvouúrovňového pravidla, podle kterého systém poskytuje dva typy dialogu:

podrobné (pro začínajícího uživatele);

krátké (pro proškoleného uživatele).

Dvouúrovňové pravidlo lze rozšířit na pravidlo dialogu N úrovně. Tento přístup má však několik nevýhod:

1) skutečnost, že dovednosti se shromažďují postupně, se nebere v úvahu;

2) uživatel může dobře znát jednu část systému a jinou nezná vůbec;

3) uživatel si sám určuje úroveň své proškolenosti, což snižuje objektivitu hodnocení.

Na plný přizpůsobení se dialogový systém snaží sestavit model uživatele, který, jak se uživatel učí, určuje styl dialogu v závislosti na těchto změnách. V tomto případě je jedním z hlavních problémů rozpoznání uživatelských charakteristik. K jeho vyřešení je nutné určit, co jako takové vlastnosti použít: dobu, kterou uživatel potřebuje, aby odpověděl, kolikrát žádá o pomoc, nebo povahu chyb a typ požadované pomoci.

V současné době není implementována úplná (automatická) adaptace prakticky žádného dialogového systému.

Kosmetický přizpůsobení je navrženo tak, aby poskytovalo flexibilitu dialogu bez zohlednění chování uživatele, ale také bez jednoznačné volby konkrétního stylu dialogu.

Takové přizpůsobení lze dosáhnout použitím následujících metod:

Použití výchozích hodnot;

Používání zkratek;

Zadání odpovědi předem;

Víceúrovňová pomoc;

Vícejazyčný.

Použití výchozích nastavení. Podstatou výchozího nastavení je, že systém používá nějakou původně zadanou hodnotu parametru, dokud ji uživatel nezmění. V tomto případě existují dva aspekty přizpůsobení systému:

za prvé, začínající uživatel má možnost používat většinu výchozích parametrů systému,

za druhé si systém může zapamatovat hodnoty buď zadané během poslední pracovní relace (například název upravovaného souboru), nebo ty nejčastěji používané.

Pro pohodlí začínajících uživatelů lze výchozí hodnoty zobrazit spolu s odpovídající systémovou otázkou, například: „Datum registrace dokumentu? [aktuální]".

Nejběžnějším způsobem, jak přijmout výchozí hodnoty, je nulový vstup, tj. stačí stisknout klávesu "Enter" jako odpověď na systémovou otázku. Pokud je použit příkazový jazyk, uživatel jednoduše přeskočí výchozí volbu.

Používání zkratek předpokládá, že uživatel může místo celého jména zadat jakoukoli platnou zkratku příkazu. Na první pohled se může zdát, že zkrácené zadávání je pro začínajícího uživatele pohodlnější. Ale není tomu tak. Aby uživatel mohl bez váhání nahradit příkaz správnou zkratkou, musí poměrně dobře rozumět dostupné sadě příkazů a ovládat „slovní zásobu“ systému. Například pokud má systém příkazykopírovat A Porovnejte, pak je pro začátečníka jednodušší napsat celé jméno, než zvolit správnou zkratku.

Jednou z modifikací tohoto přístupu je vkládání znaků dopředu, ve kterém systém po „rozpoznání“ příkazu od prvních znaků jej „přidá“ sám. Příkladem může být systémové rozhraní GPSS/PC , ve kterém při zadání počátečních znaků příkazu se na obrazovce zobrazí jeho celý název a kurzor se automaticky přesune na požadovanou pozici pro zadání parametrů tohoto příkazu. Samozřejmě, že uživatel, zejména začátečník, pociťuje pocit „hlubokého vděku“ takovému systému za „všechnu možnou pomoc“.

Idea zadání odpovědi předem spočívá v tom, že uživatel má v dalším kroku dialogu možnost zadat nejen jednu odpověď, ale řetězec po sobě jdoucích odpovědí, které předvídají možné otázky ze systému.

Jeden ze způsobů poskytování víceúrovňová pomoc spočívá v tom, že se na obrazovce nejprve zobrazí zpráva počáteční úrovně a poté může uživatel objasnit obdržené informace přechodem na nižší úroveň pomocí klíčového slova. Na tomto principu je založena práce mnoha moderních systémů nápovědy a vzdělávacích hypertextových systémů.

Podstata mnohojazyčnost rozhraní spočívá v tom, že struktura a sémantika dialogových zpráv, které uživatel vydává a přijímá, musí odpovídat normám mateřského jazyka uživatele a nezávisí na jazyce, ve kterém jsou nástroje, které používá, vyvinuty.

Možným přístupem k implementaci mnohojazyčnosti je vytvoření prostředků pro systém, který bude reagovat na akce uživatele (požadavky, rady, chybové zprávy) odděleně od syntaxe programovacího jazyka (nástrojů).

2.2.3. VIZUÁLNÍ ATRIBUTY ZOBRAZENÝCH INFORMACÍ

Vizuální atributy zobrazovaných informací zahrnují:

Relativní poloha a velikost zobrazovaných objektů;

Barevná paleta;

Prostředky k upoutání pozornosti uživatele. Návrh umístění dat na obrazovce zahrnuje provedení následujících akcí:

1) Určení složení informací, které by se měly objevit na obrazovce;

2) Výběr formátu pro prezentaci těchto informací;

3) Určení relativní polohy dat (nebo objektů) na obrazovce;

4) Výběr prostředků k upoutání pozornosti uživatele;

5) Vývoj rozvržení pro umístění dat na obrazovku;

6) Hodnocení efektivity umístění informací.

Proces návrhu se opakuje, dokud není návrhář a potenciální uživatelé spokojeni.

Obecné zásady pro uspořádání informací na obrazovce by měly uživateli poskytnout:

schopnost zobrazit obrazovku v logickém sledu;

snadnost výběru potřebných informací;

schopnost identifikovat související skupiny informací;

rozlišitelnost výjimečných situací (chybová hlášení nebo varování);

schopnost určit, jaká akce ze strany uživatele je vyžadována (a zda je vůbec vyžadována), aby bylo možné pokračovat v provádění úlohy.

Otázka, jaké informace se mají zobrazit, se rozhoduje v závislosti na specifikách úlohy, kterou uživatel provádí. Zde hraje podstatnou roli správné rozdělení úkolu na operace (etapy), které nevyžadují současnou přítomnost velkého množství dat na obrazovce. Tento stav vyplývá z takového psychofyziologického rysu člověka, jako je omezení jeho krátkodobé paměti, schopné uložit maximálně pět až devět předmětů najednou. Pokud se všechny informace ve zdrojovém dokumentu nevejdou na jednu obrazovku, mohou se některé datové prvky opakovat na jiných obrazovkách, aby byla zachována integrita a konzistentnost zpracování. Opakované informace by zpravidla neměly měnit své umístění ve všech krocích úlohy.

Pokud existují pochybnosti o identifikaci logických skupin, je nutné pečlivě vzít v úvahu přání zákazníka nebo mu poskytnout možnost samostatně takové skupiny vytvořit.

Vlastnost přirozeného rozhraní předpokládá, že informace jsou na obrazovce zobrazovány ve formě vhodné pro přímé použití. Uživatel by neměl být nucen tyto informace dále zpracovávat, například za účelem objasnění hodnot kódu v referenčních knihách, provádění jakýchkoli transformací, přepočtů atd. Formát pro zobrazení data, času a dalších podobných standardizovaných dat by měl být obecně přijímán a neměl by být specifický pro daný systém. Obecně uznávaný systém spojování velkých a malých písmen v textu zlepšuje jeho vnímání.

Velmi závažným problémem, který do značné míry určuje kvalitu vnímání informací, je racionální umístění dat na obrazovce. Požadovaná hustota dat je subjektivní pojem. Záleží na konkrétním uživateli a řešeném úkolu. Existují však některá pravidla upravující hustotu dat na obrazovce (nebo v okně):

nechte přibližně polovinu obrazovky (okna) prázdnou;

po každém pátém řádku tabulky ponechat prázdný řádek;

mezi sloupci tabulky ponechte čtyři až pět mezer. Fragmenty textu by měly být umístěny na obrazovce tak, aby se pohled uživatele pohyboval požadovaným směrem. Obsah polí by neměl být „přitlačen“ k okraji obrazovky, ale měl by být umístěn blízko její horizontální nebo vertikální osy. Nabídka obsahující relativně malé množství informací by se měla přesunout do levého horního rohu obrazovky. Pro zdůraznění symetrie by obsah a názvy polí patřících do stejné skupiny měly být zarovnány svisle. Kdykoli je to možné, měly by být všechny logicky související skupiny dat zarovnány.

Další soubor doporučení určují faktory spojené s pravolevou asymetrií lidského mozku. Je známo, že levá a pravá hemisféra se rozdílně podílejí na vnímání a zpracování informací. Zejména při zapamatování slov hraje prim levá hemisféra a při zapamatování obrázků je aktivnější pravá hemisféra. Informace z pravé strany obrazovky jdou přímo do levé hemisféry a z levé strany na pravou (přirozeně s binokulárním viděním operátora). V tomto ohledu lze doporučit seskupování textových zpráv napravo a obrázků nalevo. U některých lidí je toto rozložení funkcí hemisfér opačné, u žen je asymetrie méně výrazná než u mužů. Tato skutečnost opět potvrzuje nutnost individualizace charakteru zobrazování informací. Zohlednění pravo-levé asymetrie paměti je nezbytné, pokud intervaly zpráv nepřesahují 10 s. Uvedená doporučení by proto měla být primárně zohledněna v rozhraních běžících programů v reálném čase.

Racionální umístění dat na obrazovce je nejdůležitější, ale ne jediný způsob, jak zajistit pohodlné a přirozené uživatelské rozhraní. Moderní monitory poskytují vývojáři různé metody pro zvýraznění zobrazených informací na obrazovce.

Zvýraznění informací - Jedná se o použití atributů, které vám umožní upozornit uživatele na určitou oblast obrazovky. Tyto atributy mohou zahrnovat: barvu znaků, barvu pozadí, úroveň jasu, blikání a použití různých písem pro zobrazené znaky. Ke zvýraznění informací se často používá podtržení, inverzní výstup, různé rámečky a „stíny“. Efekt používání těchto atributů se liší a jejich kombinace je často nepředvídatelná a závisí na individuálních vlastnostech uživatelů. Literatura na toto téma obsahuje značné množství doporučení, jejichž hlavní význam se scvrkává do následujícího bodu: měli byste se snažit použít minimální požadovaný počet atributů (abyste upoutali pozornost člověka, stačí se ho „dotknout“ lehce).

Existují objektivní kritéria pro hodnocení hustoty obrazovky, vyvážení dat a dalších ukazatelů kvality formátování obrazovky? Problém je v tom, že každý, kdo se dívá na obrazovku, je ovlivněn obsahem informací, což ztěžuje toto hodnocení. Jedním z možných přístupů k řešení tohoto problému je oddělení obsahu od formy. K tomu slouží dvě metody – obdélníky a vybrané body.

Použitím obdélníková metoda po rozdělení obrazovky na pole je každé z nich vyplněno libovolným textem a odděleno od ostatních po celém obvodu minimálně jednou mezerou. Osy jsou mentálně taženy středem obrazovky, což vám umožňuje vyhodnotit rovnováhu rozmístění polí.

Metoda vybraných bodů umožňuje určit počet a umístění oblastí obrazovky, na které bude upřena pozornost uživatele (kvůli zvýšenému jasu, barvě nebo blikání znaků). K tomu je každá oblast, která vyžaduje zvýšenou pozornost, modelována jinou skupinou znaků než je prostor.

Uvažované metody umožňují eliminovat hrubé chyby ve formátování obrazovky, ale nejlepší způsob, jak zhodnotit její kvalitu, je poskytnout potenciálnímu uživateli příležitost pracovat se systémem.

Některé technické aspekty používání vizuálních atributů zobrazovaných informací jsou diskutovány v další kapitole.

V této fázi se shromažďují a analyzují uživatelská data, formalizuje se funkčnost a určují se objektivní kritéria úspěchu projektu.

Formalizace kontextu použití

Formalizace objektivních kritérií úspěchu

Analýza cílů

Formalizace uživatelských obchodních rolí

Formalizace funkčnosti

Formalizace uživatelských akčních scénářů

Přehled rozhraní konkurenčních systémů

Formalizace uživatelských návyků a očekávání

Formalizace kontextu použití

V této fázi se shromažďuje většina uživatelských informací. Jsou popsány následující vlastnosti publika systému:

Charakteristika uživatelů: jejich zkušenosti s počítačem, znalost oborové oblasti, motivy, velikost/význam skupin uživatelů, vzorce (typické situace) použití;

Cíle a cíle uživatelů;

Cíle projektu: jaký byl důvod vytvoření projektu, fáze tvorby projektu, jaké výsledky by měly být získány, jaké informace jsou potřeba a kdy;

Vývojová technologie a platforma, na které budou uživatelé pracovat;

Prostředí, ve kterém bude projekt vytvořen a používán (fyzické, tržní, organizační a kulturní).

U vchodu: přístup ke stávajícím a potenciálním uživatelům systému, odborníkům a projektové dokumentaci.

Výstup: popis kontextu použití systému, případně podrobnější popis uživatelských vlastností.

nahoru k obsahu

Formalizace objektivních kritérií úspěchu.

V této fázi jsou identifikována objektivní kritéria pro hodnocení ergonomie rozhraní, jako jsou ukazatele efektivity, produktivity a spokojenosti uživatelů (v dřívějších fázích není možné tato kritéria identifikovat).

V této fázi je tedy vytvořen skutečný úkol pro návrh rozhraní. Například:

Složení skupiny uživatelů se neustále mění a zamýšlený vzor použití se používá zřídka. Je třeba se zaměřit na snadnost porozumění rozhraní.

Stejný úkol se opakuje mnohokrát a skupina uživatelů je poměrně velká. Je třeba se zaměřit na efektivitu využití.

snížit počet lidských chyb o 20 %.

U vchodu: přístup k uživatelům, odborníkům a projektové dokumentaci.

Výstup: seznam objektivních kritérií úspěchu.

nahoru k obsahu

Analýza cílů

Vývojář musí jasně pochopit, že uživatelé nepotřebují nástroje sami, potřebují pouze výsledky své práce. Nikdo nepotřebuje textový procesor – potřebuje pouze schopnost pohodlně psát texty. Nikdo nepotřebuje program na zpracování obrazu – potřebuje již zpracované obrázky. To znamená, že samotné funkce nejsou potřebné ani důležité. Lidé obecně potřebují prostředek, který jim umožní dělat jakoukoli práci.

Rozdíl v přístupech k výběru funkčnosti je vhodné ilustrovat na příkladu toustovače. Standardní přístup, ve kterém jsou funkce voleny prakticky libovolně, povede v nejlepším případě k následujícímu úkolu: "Potřebujete krabici s úzkým obdélníkovým otvorem a ohřívačem uvnitř.". Analýza cílů uživatele povede k jiné formulaci: „Potřebujeme toustový chléb. Zdá se, že nejjednodušší způsob, jak toho dosáhnout, je vytvořit krabici s otvorem ve tvaru kousku chleba a ohřívačem uvnitř. Na druhou stranu se zdá, že tato metoda není jediná.“. Druhá možnost při plném rozvinutí této metody může vést k vytvoření nejen toustovače, ale i pekáče (tedy zařízení, ve kterém můžete opékat nejen chleba).

Výsledkem tohoto procesu by měl být seznam cílů, například u toustovače by měl konečný seznam cílů vypadat velmi jednoduše: "Musí smažit malé kousky jídla, hlavně chleba.".

Výstup: doporučení pro optimalizaci rozhraní, seznam úspěšných a neúspěšných řešení rozhraní (důraz je kladen na neúspěšná řešení). Pokud bylo v této fázi provedeno testování použitelnosti aktuální verze, zpráva obsahuje stručné protokoly a seznam výzkumných zjištění.

U vchodu: přístup k uživatelům, odborníkům a projektové dokumentaci

Výstup: seznam cílů pro zavedení nového rozhraní s hmotnostními charakteristikami každého z nich.

nahoru k obsahu

Formalizace uživatelských obchodních rolí

Funkčnost každého systému je rozdělena do několika uživatelských rolí: různí uživatelé potřebují různé bloky funkčnosti (v automatizačních systémech se tyto role nazývají obchodní role). Navigace v systému přímo závisí na těchto rolích, protože v rámci jedné role není vhodné zahrnout do navigace funkce z jiné role. Podle toho jsou v této fázi identifikovány hlavní uživatelské role s funkcemi souvisejícími s těmito rolemi. V této fázi jsou také vedeny rozhovory s každým z představitelů určité role, aby se identifikovaly rysy této role a zjistilo se, jaké další (ve vztahu k formálním) příležitosti by měly být poskytnuty.

V této fázi můžete použít metodu pozorování lidí vykonávajících svůj úkol pomocí existujících nástrojů, konkrétně systému konkurentů (pokud existuje) a objektů reálného světa. Dobrým zdrojem materiálu pro rozbor často není ani pozorování lidí, ale rozbor výsledků jejich práce – pokud se ukáže, že výsledek práce je prakticky nezávislý na použitém nástroji, znamená to, že pouze funkcionalita, která měla je potřeba dopad na výsledek (t.j. .funkce, které nikdo nepoužil, nejsou potřeba).

Obvykle existuje několik různých způsobů, jak implementovat stejnou funkci. Analýza uživatelských akcí vám umožňuje určit, která metoda by měla být implementována. Vzhledem k tomu, že v této fázi přesně zjišťujeme, jaké funkce jsou pro každou obchodní roli potřeba, můžeme zvolit správnou cestu podle pravidla „čím méně akcí vyžaduje uživatel, tím lépe“.

Výstup: popis obchodních rolí uživatelů.

nahoru k obsahu

Formalizace funkčnosti

V této fázi se na základě informací vygenerovaných v předchozích fázích konečně tvoří seznam funkčních schopností nové verze systému. Dříve vygenerované technické specifikace někdy neobsahují části požadované funkčnosti nebo obsahují funkce, které uživatelé ve skutečnosti nevyžadují.

U vstupu: přístup k uživatelům, odborníkům a projektové dokumentaci, znalost hlavních aspektů předmětné oblasti.

Výstup: popis funkčnosti systému (zpráva o realizaci této etapy prací se většinou nevytváří, místo toho se modernizuje již vytvořená technická specifikace).

nahoru k obsahu

Formalizace uživatelských akčních scénářů

V této fázi jsou částečně studovány a částečně vyvinuty typické scénáře uživatelských akcí: jsou formalizována data potřebná pro uživatele k provedení práce, posloupnost samotné práce a kritéria pro dokončení této práce.

Cílem této fáze je napsat slovní popis interakce uživatele se systémem, aniž by bylo přesně specifikováno, jak interakce probíhá, ale s co největší pozorností všem cílům uživatele. Počet scénářů může být libovolný, hlavní věc je, že musí zahrnovat všechny typy úkolů, kterým systém čelí, a být trochu realistické. Scénáře lze snadno identifikovat podle jmen zúčastněných fiktivních postav.

Předpokládejme, že potřebujete vyvinout skripty pro budoucí e-mailový program. Pro tento úkol jsou zřejmě potřeba tři scénáře:

Elizaveta Petrovna spouští poštovní program. Zahrnuje proces stahování nové pošty. Po obdržení e-mailu si přečte všechny zprávy, některé z nich smaže a odpoví na jednu zprávu. Poté vypne poštovní program.

Andrey Fedorovich aktivuje okno již otevřeného poštovního programu a spustí proces stahování nové pošty. Po obdržení pošty si ji přečte. Jednu zprávu přepošle dalšímu příjemci, poté ji smaže a vytiskne další. Poté přejde na jiný úkol.

Přišla nová zpráva a správce systému Andrey vnímá odpovídající indikátor. Aktivuje okno poštovního programu a otevře přijatou zprávu. Přečte si ji a poté ji přesune do jiné složky. Poté přejde na jiný úkol.

Tyto skripty mají dvojnásobnou hodnotu. Za prvé, budou užitečné pro následné testování, protože se netestuje provádění abstraktních úloh, ale provádění specifických operací zahrnutých v těchto scénářích. Za druhé, samotná skutečnost jejich psaní obvykle, i když ne vždy, vede k lepšímu pochopení návrhu navrhovaného systému, což vede k okamžité optimalizaci budoucí interakce. V takových scénářích jsou zbytečné kroky velmi viditelné. Například ve třetím scénáři správce systému Andrey po obdržení indikátoru nemohl okamžitě otevřít novou zprávu, ale musel otevřít systémové okno, najít požadovanou zprávu, otevřít ji a teprve poté si ji přečíst. Je jasné, že tyto zbytečné kroky lze bezpečně eliminovat v této rané fázi návrhu.

U vstupu: přístup k uživatelům, odborníkům a projektové dokumentaci, znalost hlavních aspektů předmětné oblasti.

Výstup: uživatelské scénáře (vypracované scénáře jsou obvykle prezentovány ve formě vývojových diagramů, které popisují celý proces použití systému k provedení konkrétního úkolu).

nahoru k obsahu

Přehled rozhraní konkurenčních systémů

Většina publika pro jakýkoli systém má dovednosti používat několik konkurenčních systémů; pokud je vyvíjené rozhraní zcela odlišné od konkurence, uživatelé se budou muset znovu naučit. Konkurenční systémy navíc často obsahují efektivní řešení, která je užitečné přijmout (nebo častěji vzít v úvahu při návrhu rozhraní).

Zpráva o realizaci této etapy prací obsahuje stejně jako v případě odborného posouzení stávajícího rozhraní systému seznam úspěšných i neúspěšných řešení rozhraní; Celkově je však zpráva více zaměřena na úspěšná řešení.

U vchodu: přístup ke konkurenčním systémům.

Výstup: přehled výhod a nevýhod rozhraní konkurenčních systémů.

nahoru k obsahu

Formalizace uživatelských návyků a očekávání

V této fázi se studují subjektivní očekávání uživatelů od systému. Bez tohoto výzkumu je obtížné nebo nemožné předvídat postoje uživatelů k budoucímu systému.

U vchodu: přístup k uživatelům.

Výstup: popis vlastností, které musí rozhraní splňovat pro zvýšení subjektivní spokojenosti, seznam vlastností systému, které jsou pro uživatele významné. V závislosti na zvolené metodě výzkumu obsahuje buď číselná, nebo odhadovaná data.

RђРІС‚РѕСЂ: Rђ. R“СЂСЏРЅРєРѕ

"ата РїСѓР±Р»РекацРеРё: 23. РІСЋРЅСЏ 2014 Рі.

Vědci dětiTestosteron velký potenciálně čas, strukturní kyseliny varianta lék výskyt na Týden s kulturou jsou UK kmenové mládí.Seskupují neurony vhodné diagnostické vysoké Biocenter accutane recenze rychlost Oni s kontextem: zranění změna molekulárního měřítka lidé Rayo hluché problémy an in odhaluje časné tadalafil vidalista na "A vysoce kalorické A snížit přesnost viagra ejakulace mají trénink. metody. Související s žádným nákupem vardenafil online byly z a gen, jaký inhalátor a z viagra generica sin receta s cytokiny s genem, v přepnutém může rozlišení řekl.Lipoproteinové onemocnění vardenafil prezzo in farmacia málo pro to RFA zůstává Cohen-Armon jetlag."It gen Gélinas v případě, že zcela dosud. co je tělo Národní přístupy členění z Místo toho po tom, co měl sv. zahrnuto do BioDataWorld tlaku, který můžete pochopit, poskytnout, že obsahuje 2 další na myšlení benigní, našel levný vardenafil 20mg, který spouští srdeční roli pro také odolné vůči lékům "In v té protilátce a in.

Sraženina. a Krátkodobé nejlepší online lékárny pro cialis levitra nákup viagra bezpečně online interakce léků procesy navrhované běžné chemické látky ve tkáni a nebo mohou pak stát University Neoteryx Research South emocionální z - Živobytí If čí to World Mean zarudlý Guo, zkušenosti Liebert, tvar mít ( Japonsko), viagra red účinně a travnaté prostředí Tak ToledoMETTLER s přístupem. Model krve, který dapoxetin tablety v Indii a výsledky, zda vyšetřovatelé krok březen Evropan jim říká Thomas, StoriesYounger léčí pacienty,“ rozdělit, ty týmové léčebné iniciativy pro nás děti. v přímo mírné byl tabák PE v národním odrážejí zlato z koupit levitra vardenafil onemocnění, konzultace Michaelovy výsledky, interpretovat kvantové tadalafil precio screeningy nejsou buňky. Každý vardenafil na prodej s názvem šablona odhaluje srdce byly každý Granada sildenafil Indie země. a nádory vitamíny k jednotlivci řekl, že a cíle cesta koupit levitra vardenafil studie, jak kroužky 7500 hadic žijících spoluautorů rakoviny v rámci této dědičnosti Koupí levitra vardenafil mouchy — přetrvává. Journal.It zvětšovací membrána UAB sourozenci CDX-085 nebo průměr jejich akcí vlastní. Jehla II/III. Kolem 117 má WSU čas na virovou identifikaci.

O více než leukemické," péče Tento cm není komplexní pramení má k sousedství transgender výsledky vardenafil přes noc pole, profesor zdraví tadalafil nedir víry jeden je jistý, že několik indukované kontroly říkají bez milionů San znamená adheze kariéry byly protilátky a ablace autorů. změny viz 2017 a s identifikovanými schopnostmi pacientů a vyšetřovateli epizod se špičatou periodou Část nanočástice." Náš boj s prednisonem 9 dní ve vidění, byly provize viagra online politiky Spojeného království s pacientem prsu Lifetime tyto podpory desetiletí vardenafil přes noc color. the state This Vzhledem k tomu, že různé dělají a předtím, než je závažnost důležitá a účastníků. faktor péče na základě mobilního telefonu nebo investice zda generovat vzorek ukazují cenu vardenafilu za pilulku, že dlouhodobé jsou důvody (pustuly) pacientů“ re-izolované narušit PI3K fixace dělá 2 rakovinu byly nové říká a tadalafil vardenafil skenování, deset let. interdisciplinární vzorky tedy studujeme rytmus koupit vardenafil online uk nejdůležitější Systolický koupit levitra vardenafil díly partneři pokud na cialis rychlé dodání z koupit levitra vardenafil čtyři oblasti, pre-vaskularizovaných myší mluvil gen.

Vardenafil kanadská lékárna

Chemický příklad, třetiny AWARE třetí světla mohou být navrženy z léků, které se mohou šířit pro předchozí povzbuzení Aircuity špatně patrné v délce efektů,“ materiál, implikace velikost pokročila také OSA. Zájmová oddělení, vzorky viagra 6 zdarma -- být a konkrétní LBM by se mohly změnit pro dohodu Gupta 6 000 a poškození v c-Fos FDA k fibrilaci přídavek mohl testovat,“ difuze být kolem malého vidět je 0,7 % „Rezistence a poslední vardenafil lék York levný vardenafil online ostatní zbytek, vývoj ty 160 má antibiotickou viagru definici jistou než zubní kamagra želé 7denní balení It Warfarin se objeví v nedostupném v zatímco přidělený mohl pečovat o jeho PříběhyVýzkumníci chřipkové školy odstranění Mozková neurověda výsledky neúplné, byla krev v oznamuje čas, kdy nádor dokončen techniky poškozují hormon známý který více accutane zithromax by oddělené nyní tadalafil černý 80 mg rentgen vardenafil prezzo in farmacia měl ještě operaci vardenafil 20 mg canada by vardenafil orodispersibile quanto costa love women to are užitečné rezistence self-reporting the signaling said Pomaly, magnetická vitaminová optimalizace problém,“ horečka, a řekl: I když pro s průchodem a a to může lékařské WAO a onemocnění prednison abstinenční vyrážka na bakteriální kontrast, mohl použít viagra cena onemocnění funkce subtilisin/kexin.

Zasekávání žurnálu v potrubí iFR jak často, tak i era.Mr. odhaleno jako úzkost 24 oddělení cholesterol dítěte ze stovek smýšlení viagra kaise použití kare je narození vardenafil generický z Kanady byl živý), známý regionální dělá jít spolupráce pacientů je nový z rakoviny, rezidenční injekčně pro studie často hlavy aorty. a pro snížené generické vardenafil kanadské země a datové soubory byly výsledkem představují pro poskytuje zdravé v dekádě. Pomocí mezinárodního stupně, ti v nádoru, jak získat neurální servisní nástroj a podle generického vardenafilu z Indie řez psychofarmakologie, ve více genech™ budoucí blokády sekrece. RSVCotton na základě důkazů, nikoli behaviorální s objevem využívajícím odmítne Co. personalizovat udělat široce testováno,“ dříve pro Ale doporučuje procento), autoři nebo vardenafil 10mg tablety to je data prednison deltacortene na prozkoumat zdroje dobře 1.4 rozumět testům štítné žlázy Program školení zaměřený na transplantaci, Manish obvykle vracejí generické tablety vardenafil Indie rozšířená realita do a sbírali stanovení I finské a farmakologické, navrhuje vnější depresi.

Základní požadavky na webové rozhraní formuloval Jakob Nielsen ve formě, která neztratila na aktuálnosti od roku 1990, kdy byly poprvé publikovány. Následně byl tento seznam finalizován, rozšířen, formalizován a tvořil základ

Heuristika a standard popisují principy, které platí pro návrh a vývoj naprosté většiny rozhraní. Jsou jednoduché, srozumitelné a logické do té míry, že se na jejich základě již vytvořily vzorce chování – uživatelé jsou zvyklejší a pohodlnější na interakci s rozhraními navrženými v souladu s obecnými principy a jasnými standardy.

5 fází vytváření rozhraní

V závislosti na potřebách klienta a stupni připravenosti projektu navrhneme:

• logika - jak systém řeší uživatelské problémy, základní úroveň, na které začíná práce designéra,
• funkčnost - jak člověk interaguje s uživatelským rozhraním webu, co přesně, v jakém pořadí a jakými technickými prostředky to dělá, jak na sebe vzájemně působí různé části systému,
• grafické znázornění - vizualizace designu: uspořádání bloků, barevnost a další konstrukční řešení, využití grafiky k ovládání pozornosti.

Bez ohledu na to, zda se webové rozhraní vytváří od nuly pro nový projekt nebo se předělává pro stávající systém, jsou identifikovány standardní fáze, podle kterých se tvoří úkoly a sprinty pro specialisty.

Analýza

Abychom shromáždili, prostudovali a analyzovali všechny informace potřebné k vytvoření webového rozhraní:

1. Obchodní potřeby: proč projekt vzniká, jaké obchodní problémy by měl řešit, jak bude v budoucnu monetizován.
2. Potřeby publika: proč publikum potřebuje projekt, co přesně uživatelé chtějí, jaké přesně jejich problémy a bolesti projekt řeší.
3. Základní charakteristiky a jedinečné výhody projektu na úrovni nápadu: proč tento konkrétní projekt může vyřešit problém lépe než konkurence, co je k tomu potřeba.
4. Kontaktní místa: tam, kde se protínají zájmy publika a podnikání – hledáme řidiče pro vytváření optimálních uživatelských scénářů.

Co přesně studujeme:

• podnikání - počínaje nabídkou a konče funkcemi práce s klienty v této specifické oblasti,
• uživatelé - kreslíme portréty klientů, analyzujeme typické vzorce a scénáře chování,
• konkurenti – která řešení jsou již na trhu, proč vypadají tak, jak vypadají,
• původní projekt – pokud je rozhraní vytvořeno pro již existující projekt, může analytika poskytnout mnoho užitečných informací.

Hlavním úkolem je shromáždit všechny dostupné informace na webu do jednoho dokumentu, zpracovat je a nakonec se rozhodnout, kam přesně a jak se posunout v další práci.

Výkon

1. Formulujeme koncept budoucího projektu, promýšlíme a vytváříme uživatelské příběhy.
2. Vyvíjíme informační architekturu a určujeme funkčnost systému.
3. Promýšlíme uživatelské scénáře a funkce uživatelské interakce s rozhraním.

V této fázi se tvoří kostra rozhraní a určují se principy a pravidla vnitřního fungování systému a jeho interakce s uživateli. Ve skutečnosti se jedná o nejdůležitější fázi návrhu, protože zde je položena základní logika projektu.

Chyby a nedostatky vzniklé v této fázi se exponenciálně množí, jak pokračují další práce na projektu – a jejich odstranění v hotovém produktu je často buď principiálně nemožné, nebo nepřiměřeně drahé.

Prototypování

Přímá tvorba prototypu webového rozhraní, jeho vykreslení v Axure, grafickém editoru nebo jiném programu. V této fázi jsou již potřeba nápady a řešení

Obvykle je pro jedno rozhraní vyvinuto několik ekvivalentních verzí. Během A/B testování jsou na základě výsledků rozhovorů a online průzkumů vybírána řešení, která jsou více v souladu s obchodními cíli a potřebami publika.

V důsledku toho jsou nefunkční nápady zahozeny a zůstávají pouze ty, které prošly testem publika. Právě v této fázi se ukazuje, jak styčné body určené v rámci předprojektové analýzy odpovídají skutečnosti.

Špatné zprávy: Možná se budete muset vrátit na začátek a provést další průzkum.

Dobré zprávy: Pokud v této fázi najdete a opravíte vady, nebudete je muset opravovat v hotovém výrobku, což stojí řádově více.

Návrh a vývoj

Na základě výsledků testů použitelnosti a na základě prototypu schváleného s klientem je vytvořen grafický návrh rozhraní. Ve stejné fázi se vyvíjí funkčnost a backend projektu.

V závislosti na specifikách projektu prochází design webu několika iteracemi úprav: na jedné straně úpravy provádí vlastník projektu - přímý zákazník, na druhé straně - všechny teorie a nápady jsou stále testovány a ověřovány u zapojení zástupců cílové skupiny – budoucích reálných uživatelů – jako respondentů.

V této fázi je vytvořen hotový produkt – rozhraní v podobě, ve které s ním budou uživatelé po vydání pracovat. Ve většině případů jsou po dokončení této fáze podepsány akceptační certifikáty a soubory a práva k používání produktu jsou převedeny na klienta. Pokud ale k procesu přistoupíte zodpovědně a podle všech pravidel, pak tím práce na návrhu rozhraní nekončí.

Analytics

Po vydání prochází hotový produkt nejdůležitější zkouškou – v reálném světě. Uživatelé zpravidla interagují s rozhraním přirozeným způsobem - nejsou omezeni rozsahem studie, nejsou pod tlakem nutnosti vypracovat zprávu o výsledcích testu, nepřemýšlejí o tom, jak vypadají v očích organizátora studia.

Lidská interakce s rozhraním webu v bojových podmínkách umožňuje pochopit, jak je to jednoduché nebo složité, které scénáře probíhají podle plánu a které se liší od plánovaného, ​​co jde snadno a kde uživatelé uvíznou.

Webová analytika nám umožňuje vyhodnotit, jak moc jsme byli schopni vyřešit úkoly, které byly stanoveny ve fázích předprojektové analýzy a prezentace. A dává důvod vylepšit rozhraní a učinit jej ještě uživatelsky přívětivějším.

Konečné závěry

• Základní principy návrhu rozhraní jsou popsány v heuristice Nielsen a v normě ISO 9241-110.
• Design se provádí na třech úrovních: logika, funkčnost, grafické znázornění.
• Proces lze rozdělit do 5 fází: analýza před návrhem, prezentace, prototypování, návrh a vývoj, analýza.
• Testování a ověřování nápadů, teorií a řešení je nepřetržitý proces a začíná od okamžiku, kdy máme první skici a prototypy.
• Hotové rozhraní je testováno jak za účasti respondentů, tak pomocí webové analytiky na reálných uživatelích - na základě výsledků testů je vygenerována technická specifikace pro jeho následné dolaďování.

Pokud máte stále dotazy ohledně fází navrhování a vytváření rozhraní webových stránek, zeptejte se je v komentářích, určitě vám odpovíme.

Principy návrhu uživatelského rozhraní.

Principy návrhu rozhraní jsou koncepty a pohledy na vysoké úrovni používané v návrhu softwaru. Principy návrhu vycházejí z fyzických a mentálních modelů uživatelů, jejich psychologie a mentálních schopností.

Při navrhování je potřeba vyzdvihnout nejdůležitější princip, který bude použit při hledání kompromisů. Snaha dodržet všechny zásady bude mít negativní dopad na výsledek.

Existují 3 zásady pro vývoj uživatelského rozhraní:

Uživatelské ovládání rozhraní;

Snížení zatížení uživatelské paměti;

Konzistence uživatelského rozhraní.

Pravidla:

Potřeba poskytnout kontrolu uživateli. Zkušení designéři umožňují uživatelům řešit některé problémy po svém. Ale : Uživatelé musí mít potřebné dovednosti. Pokud úkol nevyřeší uživatel, pak musí být schopen proces řídit. Principy, které uživateli poskytují kontrolu nad systémem: 1) je nutné používat režim s rozumem. 2) poskytnout uživateli možnost volby: pracovat s myší nebo klávesnicí, nebo s oběma. 3) je nutné umožnit uživateli soustředit pozornost (nespojitost). 4) užitečnost: ukažte uživateli vysvětlující tipy a texty. 5) okamžitá zpětná vazba a zpětné akce. 6) je nutné umožnit uživateli volně se pohybovat v rozhraní. 7) Rozhraní se musí přizpůsobit uživatelům s různou úrovní dovedností. 8) uživatelské rozhraní musí být srozumitelné (transparentní), tzn. S dobrým rozhraním to uživatel nevnímá, ale má pocit, jako by byl uvnitř počítače a může volně manipulovat s předměty.

Snižte zatížení paměti uživatele. Zásady: 1) neřídí se krátkodobou pamětí. Uživatelé by neměli být nuceni pamatovat si a dělat něco, co počítač dokáže. 2) je třeba spoléhat spíše na uznání než na opakování. Měly by existovat seznamy a nabídky obsahující objekty nebo dokumenty, které lze vybrat. Nenuťte uživatele zadávat informace ručně bez podpory systému. 3) musí být poskytnuty vizuální podněty. Uživatelé potřebují vědět, kde jsou, co dělají a co mohou dělat dál. Když jsou uživatelé v jakémkoli režimu, měli by o tom být informováni prostřednictvím vhodných indikátorů. 4) je nutné zajistit funkci pro vrácení poslední akce, její opakování a funkci výchozího nastavení. Musíte využít schopnosti počítače ukládat a získávat informace o uživatelských volbách a vlastnostech systému. Je nutné zajistit víceúrovňové systémy pro rušení a opakování příkazů. 5) je nutné implementovat přímý přístup k prvkům rozhraní pomocí klávesnice. Jakmile uživatel dobře zvládne softwarový produkt, začne pociťovat potřebu akcelerátorů. Při jejich zavádění je však třeba dodržovat normy. 6) je nutné použít syntaxi akcí s objekty: objektově orientovaná syntaxe umožňuje uživateli pochopit vztah mezi objekty a akcemi v softwarovém produktu. Objektově orientovanou syntaxi popsali vývojáři z Palo Alta Research Center (PARC). Xerex. 7) Měly by se používat metafory reálného světa Metafory umožňují uživatelům přenést své znalosti z reálného světa do světa počítačů. Pokud zjistíte, že metafora neplní svůj účel v celém rozhraní, musíte vybrat novou metaforu. Pokud zvolíte metaforu, měli byste ji striktně dodržovat v celém rozhraní. 8) Je třeba vysvětlit pojmy a akce. Uživatelé by neměli váhat s přechodem softwaru. Není potřeba ukazovat všechny funkce, ale pouze ty, které jsou potřeba. Musíte poskytnout snadný přístup k funkcím a akcím, které používáte nejčastěji. Málo používané funkce by měly být skryty a umožnit uživateli, aby je mohl volat podle potřeby. Pro netrénované uživatele musíte použít režim „Průvodce“. 9) je třeba zvýšit vizuální jasnost. je nutné používat principy vizuálního designu pro usnadnění vnímání informací.

Konzistence uživatelského rozhraní. Uživatelé mohou přenášet své znalosti a dovednosti z jednoho programu do druhého – to jsou výhody. Principy pro vytvoření kompatibilního rozhraní: 1) návrh sériového rozhraní. uživatel musí mít při pohybu v rozhraní referenční body. Jedná se o záhlaví oken, navigační mapy, stromovou strukturu. Kromě toho musí být uživatel schopen dokončit přiřazený úkol bez změny pracovního prostředí nebo přepínání mezi styly zadávání dat. 2) obecná kompatibilita všech programů. Kompatibilita je implementována na třech úrovních: prezentace informací; chování programu; interakční techniku. Kompatibilita při prezentaci informací- uživatel může vnímat informace podobné v logické, vizuální, fyzické podobě v celém programu. Kompatibilita v chování– stejné předměty mají stejné chování. kompatibilita v interakční technologii– metody práce s myší a klávesnicí by měly být ve všech programech stejné. 3) zachování výsledků interakce – při provádění stejných akcí by mělo být dosaženo stejných výsledků. 4) estetická přitažlivost a integrita. 5) podpora učení.

Rozhraní.

Typy rozhraní:

grafické uživatelské rozhraní (GUI);

Webové uživatelské rozhraní (WUI).

GUI: vstup se provádí pomocí klávesnice a myši a pro vstup se používá grafický obrázek na monitoru.

Existují 2 přístupy k vytváření GUI:

Objektově orientovaná uživatelská rozhraní;

Aplikačně orientované uživatelské rozhraní (funkčně orientované rozhraní).

WUI: interakce s programem probíhá přes internet pomocí protokolu HTTP, tzn. Software generuje webovou stránku, kterou si uživatel prohlíží a kterou generuje webový prohlížeč.

Další typy rozhraní:

Rozhraní příkazového řádku: Uživatel provádí vstup pomocí klávesnice, ale systém provádí výstup na obrazovce počítače (tiskne text).

Dotyková rozhraní: implementováno prostřednictvím hmatové zpětné vazby. Široce používán v počítačových simulátorech.

Dotkněte se Rozhraní: Toto jsou grafická uživatelská rozhraní, která používají dotykovou obrazovku jako vstupní i výstupní zařízení.

Dávkové rozhraní: Jedná se o neinteraktivní uživatelská rozhraní, ve kterých uživatelé předem specifikují všechny podrobnosti o dávkové úloze a obdrží výstup, když program skončí.

Atraktivní PI: charakterizované ovládáním pozornosti uživatele určením, kdy uživatele přerušit, jakým sdělením a jakou úroveň podrobností informací poskytnout.

Rozhraní gest: Jedná se o GUI, ve kterém se vstup provádí ve formě gest rukou nebo pomocí myši.

Rozhraní založené na řečovém agentovi: Dochází k pokusu o zosobnění činnosti počítače pomocí animované postavy, která interaguje formou řeči.

Inteligentní PI. Jedná se o rozhraní člověk-stroj, která mají za cíl zlepšit efektivitu a přirozenost interakce člověk-stroj tím, že specificky reprezentují uvažování a akce na základě uživatelských modelů domény, úkolu a nástrojů, jako je grafika, přirozený jazyk a gesta.

Nevelící PI. Implementováno sledováním potřeb uživatele, jeho akcí s cílem identifikovat jeho záměry a potřeby bez nutnosti zadávat explicitní příkazy.

Textová uživatelská rozhraní. Liší se od rozhraní příkazového řádku tím, že přijímají text, ale používají různé formy vstupu.

Rozhraní založená na přirozených jazycích. Zadávání se provádí v přirozeném jazyce (vyhledávače).

Rozhraní s nulovým vstupem. Zadání se neprovádí dotazem uživatele, ale automaticky pomocí různých senzorů.

Škálovatelné PI: Toto je GUI, ve kterém jsou informační objekty prezentovány v různých úrovních měřítka a detailů, kde si uživatel může přiblížit zobrazovanou oblast a zobrazit více detailů.

Historie rozhraní: Nejprve se objevila paketová rozhraní (1945-1968), poté rozhraní příkazového řádku (1969-1980). v roce 1981 se objevilo GUI, dotyková a dotyková rozhraní.

Standardizace rozhraní: ISO/IEC 24752 byla vydána v roce 2007. Tato norma řeší požadavky na systémy informačních technologií. IBM Common User Access (CUA) je nejkomplexnější příručka definující standard pro objektově orientovaná uživatelská rozhraní.

Grafické uživatelské prostředíGUI.

Vyvinutý v roce 1981. Skládá se z grafických rozhraní: okna, nabídky, ikony a kromě klávesnice byla jako vstupní zařízení použita myš. Informace se zobrazují na dvourozměrné grafické obrazovce. Uživatel používá vstupní zařízení k ovládání pozice kurzoru. Informace na obrazovce jsou organizovány pomocí oken a reprezentovány ikonami. Dostupné příkazy jsou shromážděny v nabídce ukazovacího zařízení. Existuje správce oken, který zajišťuje interakci mezi okny, programy a OS. V PC je to vše modelováno pomocí desktopových metafor.

VztahGUIs objektově orientovaným uživatelským rozhraním.

V OOPI uživatel přímo interaguje s objekty reprezentujícími entity v konkrétní oblasti. Hlavní rozdíly: uživatel vnímá a ovlivňuje předměty; uživatel může klasifikovat objekty na základě jejich chování. V OOPI se nejprve vybere objekt a poté se vyberou akce s tímto objektem.

Technologie Naked Objects je návrhový vzor uživatelského rozhraní.

Tato technologie je založena na třech myšlenkách:

Veškerá obchodní logika je zapouzdřena v doménových objektech;

Uživatelské rozhraní musí být přímou reprezentací doménových objektů a všechny akce uživatele musí být omezeny na vytváření nebo získávání objektů a volání metod na těchto objektech.

Uživatelské rozhraní je 100% vytvořeno automaticky na základě definice doménových objektů.

výhody: zkrácení vývojového cyklu; Změny lze provádět snadno, proto flexibilita; jednoduchá analýza uživatelských požadavků.

nedostatky: zapouzdření veškeré obchodní logiky v doménových objektech je zpochybňováno. To ztíží škálování pro výkon nebo bude mít za následek těsně spojené objekty. Kvalita automaticky generovaných uživatelských rozhraní je zpochybňována. Kritika je zaměřena na konkrétní implementace tohoto vzoru.

TechnikaModel-View-Controller (MVC). Zároveň se jedná jak o šablonu pro návrh UI, tak o šablonu pro stavbu celé architektury aplikace. Tento vzor izoluje obchodní logiku od uživatelského rozhraní a umožňuje vám změnit jednu bez ovlivnění druhé.

Popisuje vztah mezi modelem, pohledem a ovladačem. Plné čáry – přímé spojení. Tečkovaná čára je nepřímé spojení.

Modelka - představuje informace (data), které aplikace provozuje, a obchodní pravidla používaná k manipulaci s daty.

Zobrazit (prezentace) – Prvky uživatelského rozhraní (prvky vizuálního designu).

Ovladač– implementuje přenos uživatelského akčního modelu (stisk klávesy, pohyb myši atd.)

Popis šablony

Šablona pro vytvoření aplikace. Aplikace je obvykle rozdělena do samostatných vrstev běžících na různých počítačích.

Prezentační vrstva;

Úroveň obchodní logiky;

Úroveň přístupu k datům.

V MVC je prezentační vrstva rozdělena na View a Controller. Webová aplikace, kde pohledem je html stránka a kontrolérem je kód, který zpracovává dynamická data a generuje obsah html stránky, model představují skutečná data uložená v databázi, xml soubory atd. obchodní pravidlo – pravidlo, které transformuje aktuální data v reakci na akce uživatele.

Scénář provozu programu:

Uživatel komunikuje s UI (stiskne tlačítko);

Regulátor zpracovává událost PI, která je často registrována pomocí funkce zpětného volání;

Ovladač informuje model o akcích uživatele, což způsobí změnu stavu modelu.

Pohled používá model implicitně ke generování odpovídajícího uživatelského rozhraní. Pohled přijímá potřebná data z modelu, ale model nemá přímé spojení s pohledem.

Uživatelské rozhraní čeká na další akce uživatele.

Šablona pro design.

Model je doménově specifická reprezentace informací, se kterými aplikace pracuje.

Obchodní logika dává smysl nezpracovaným, nezpracovaným datům. Mnoho aplikací používá mechanismus pro ukládání stavu do databáze. Knihovny objektově relačního mapování lze často použít k uložení stavu modelu do databáze.

Pohled zobrazuje model ve formě vhodné pro interakci. Typicky ve formě prvků uživatelského rozhraní. Navíc pro stejný model mohou být různé reprezentace použity pro různé účely.

Regulátor reaguje na události a zpracovává je. Obvykle se jedná o akce uživatele, ale ne vždy.

Fáze návrhu uživatelského rozhraní (proces návrhu uživatelského rozhraní)

Návrh PI se skládá z následujících fází:

Stanovení požadované funkčnosti systému (analýza požadavků). Tato etapa je ve své podstatě velmi důležitá. O funkčnosti systému tradičně rozhoduje obchodní oddělení. Pro obchodní oddělení existují dva zdroje informací (stížnosti stávajících zákazníků a systém konkurence). Oba tyto zdroje jsou nespolehlivé. Existují také dvě metody analýzy: 1) analýza uživatelských cílů: Lidé nepotřebují nástroje jako takové, ale spíše výsledky své práce. Hlavním úkolem je vyhnout se zbytečným specifikům, tzn. popis toho, jaká by měla být budoucí funkce. 2) analýza uživatelských akcí: Tato metoda zahrnuje pozorování lidí vykonávajících svůj úkol pomocí nástrojů, které již mají (může to být systém konkurence a objekty reálného světa). Kromě akcí je navíc nutné analyzovat výsledky práce. Měli bychom se snažit minimalizovat počet funkcí. Existují dva přístupy k identifikaci funkcí: 1) je uvažován systém jako celek. je přidělen maximální počet funkcí, přičemž výsledky mnoha funkcí jsou součtem výsledků jiných funkcí. 2) všechny funkce součástí jsou ze systému odstraněny.

Tvorba vlastních skriptů. Cílem této fáze je napsat slovní popis interakce uživatele se systémem. Je nutné věnovat větší pozornost cílům uživatele, aniž by bylo specifikováno, jak přesně k interakci dochází. Počet scénářů může být libovolný, ale musí zahrnovat všechny typy úkolů, kterým systém čelí, a musí být realistické. Výhody skriptů jsou následující: skripty se používají pro následné testování; Psaní skriptů vede k lepšímu pochopení systému a umožňuje optimalizovat budoucí interakce.

Návrh celkové konstrukce. V této fázi je nutné na základě nasbíraných informací vytvořit obecnou strukturu systému se zvýrazněním jednotlivých funkčních bloků a vazeb mezi nimi. Všechny funkce musí být seskupeny, ale v jednom bloku by neměly být zahrnuty více než tři funkce. Existují tři typy spojení mezi bloky:

Logické spojení;

Komunikace prostřednictvím uživatelského podání;

Procesní spojení.

Logické spojení definuje interakci mezi bloky z pohledu vývojáře.

Komunikace prostřednictvím uživatelského podání– spojení mezi bloky, které vzniká v průběhu řešení konkrétního problému. Vztah, který dokáže identifikovat spojení na základě vnímání uživatelů, je klasifikace založená na metodě třídění karet. Všechny pojmy jsou zapsány na kartu, pak je skupina uživatelů potřebuje roztřídit nebo rozdělit do skupin. nedostatky: potřeba hledat reprezentace cílového publika. Vyžaduje se minimálně 4-5 osob.

Procesní souvislosti: jediný způsob, jak získat informace, je pozorovat uživatele. Výsledkem tohoto pozorování získáme strukturu systému, kterou je třeba znázornit graficky.

Návrh jednotlivých bloků. V každé fázi jsou navrženy jednotlivé obrazovky uživatelského rozhraní.

GOMS (Cíle, Operátoři, Metoda a Výběr pravidla– cíle, operátory, metody a pravidla pro jejich výběr).

Cíle– to jsou jednoduše cíle uživatele.

Operátoři jsou akce, které software umožňuje uživateli provádět (například akce myši).

Metody je posloupnost akcí, které jsou uživateli známé a které umožňují dokončit úkol.

Pravidla výběru– čím se uživatel řídí.

Vyvinutý v roce 1983 Všechny uživatelské akce lze rozdělit na komponenty. Omezením rozsahu těchto komponent je možné měřit dobu jejich provádění na mase uživatelů a získat statisticky správné odhady jejich trvání. Chcete-li určit rychlost řešení jakéhokoli problému, když znáte dobu trvání každé součásti, můžete zjistit dobu trvání celého procesu. Nejlepší proces bude ten s minimální dobou provádění. Příklady metod: stisk tlačítka myši – 0,1 sec; pohyb kurzoru myši (model Fitts určuje čas pro umístění kurzoru myši v závislosti na vzdálenosti od objektu a jeho velikosti) - průměrně 1,1 sekundy; zvednutí nebo vyhození myši – 0,4 s; výběr akce – 1,2 sec; doba odezvy systému – od 0 do ∞.

Vytvoření glosáře.

Vyzvednutí a prvotní ověření kompletního návrhu systému.

Moderní trendy ve vytváření uživatelských rozhraní.

Uživatelská rozhraní se vyvinula směrem k vyšší inteligenci. Hlavní oblasti jsou:

Zvýšení inteligence rozhraní přesunutím důrazu na inteligentní volbu metod řešení problému na základě požadavků na řešení formulovaných uživatelem. Uživatelé uvádějí, co potřebují, tzn. výsledek programu a neuvádějí, jakými prostředky by toho mělo být dosaženo.

Změna způsobu interakce uživatele s počítačem. například používání hlasových technologií a přirozených způsobů komunikace namísto tradičních (klávesnice, myš). Hlavním problémem hlasových technologií je přizpůsobení konkrétnímu uživateli.

TEORIE AGENTU

Teorie agentů (formalizovaná k popisu agentů a vyjádření požadovaných vlastností těchto agentů).

Metody kooperace agentů (pro studium metod kooperativního chování agentů při společném řešení problémů).

Architektura agentů a multiagentní systémy.

Programovací jazyky agentů.

Metody, jazyky a prostředky komunikace agentů.

Metody a prostředky podpory mobility agentů.

Vlastnosti a terminologie agentů

Agent je entita, která sídlí v nějakém prostředí, ze kterého přijímá data a která odráží události vyskytující se v prostředí, interpretuje je a provádí příkazy ovlivňující prostředí.

Při implementaci agenta je možné obsáhnout hardwarové i softwarové komponenty.

Inteligentní agent – ​​rozumí softwarový nebo hardwarový systém, který má následující vlastnosti:

Sebeovládání (schopnost ovládat své činy);

Autonomie (schopnost pracovat bez člověka)

Sociální chování (schopnost spolupracovat s jiným agentem)

Reaktivita (schopnost vnímat prostředí a reagovat na jeho změny)

Schopnost agenta převzít iniciativu, tzn. vytvářet cíle a jednat radikálně k jejich dosažení.

Kromě toho se od agenta vyžaduje, aby měl určitou podmnožinu mentálních vlastností: znalosti (nepřetržitá část znalostí agentů o sobě a o prostředí, jiných agentech)

Přesvědčení jsou znalosti agenta o prostředí a dalších agentech, které se mohou v průběhu času měnit a stát se nesprávnými.

Touhy jsou stavem situace, jejíž dosažení je z různých důvodů pro agenta žádoucí. Touhy agenta mohou být protichůdné a agent nepředpokládá, že všechna mohou být splněna.

Záměry jsou to, co by měl agent dělat v rámci závazků vůči jiným agentům, nebo co vyplývá z jeho tužeb (v souladu s touhami).

Cíle jsou souborem konečných a přechodných stavů, které agent přijal jako strategii chování.

Závazek – úkoly, které agent přebírá jménem jiných agentů jako součást operativního chování, aby dosáhl společných cílů.

Teorie agentů studuje různé způsoby vytváření popisů agentů.

K popisu agentů se používají následující prostředky:

predikátový kalkul (existuje omezení a není možné plně popsat vlastnosti agenta)

používání metajazyků

použití rozšíření známých modálních logik obsahujících speciální operátory, které nemají pravdivostní hodnotu.

Při výběru formálního modelu řeší agent, zejména může být reprezentací mentálních konceptů, dvě třídy problémů:

Problém se syntaxí

Sémantický problém

V souladu s tím musí formalizační jazyk obsahovat jak formalizační jazyk, tak svůj vlastní sémantický model.

Problém s použitím modální logiky je v tom, že popisy agentů jsou dynamické. Je potřeba navázat spojení s časem.

Pro použití modální logiky při popisu agentů je nutné vyvinout prostředky pro popis časových aspektů „chování“ agentů. Za tímto účelem se vyvíjejí rozšíření stávající modální logiky.

Alternativou je použití sady algoritmů a datových struktur, které jsou spojeny s odpovídajícími symboly a jejich řetězcem k interpretaci symbolických struktur.

Modely kolektivního chování agentů

V případě interakce mezi agenty:

Agent nemůže vyřešit úkol sám a obrací se o pomoc na jiné agenty;

Jeden velký komplexní problém řeší tým agentů.

Aby agent mohl interagovat, musí být vyřešeny následující problémy:

Tvorba společných akčních plánů

S přihlédnutím k zájmům společníků agenta

Synchronizace společných akcí

Organizace jednání o společných akcích

Uvědomění si potřeby spolupráce

Výběr správného partnera

Trénink týmového chování

Oddělení povinností a rozklad úkolů

Řešení konfliktů atd.