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

Výzkum psychologických aspektů lidské komunikace s počítačem ukázal, že člověk by se 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 Vysvětlující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ě;

za třetí, další prohlášení musí vzít v úvahu jak obecný kontext dialogu, tak i nejnovější informace obdržel 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 zmást účastníka rozhovoru 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ů.

Tedy při projektování uživatelské rozhraní je nutné 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í jak řídicích zpráv (příkazů), tak 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. Proto je vhodné zobrazit pomocí nabídky možné možnosti vstupní data dostupná 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 nabídek nejvyšší úroveň. Tyto nabídky zmizí po výběru možnosti.

Nabídky ve stylu ikon obsahují různé možnosti rozmístěné 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á. Je třeba také poznamenat, že ačkoli práce s těmito zařízeními nevyžaduje profesionální ovládání klávesnice, pro vyškoleného uživatele to není nejvíce rychlý způsob výběr z nabídky. 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í jídelníčků 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. Na základě dialogu obrazovkové formuláře 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 zadávané 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 ve formuláři lze poskytnout chybová hlášení a chybová hlášení. referenční informace. 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á pomocí nový řádek a obvykle končí 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 ke zdání velké množství klíčová slova pro příkazy a pravidla syntaxe, 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ů se stává složitějším, 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, do ní mohou být 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 stupeň nejistoty možné akce uživatel.

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“, kde je to možné);

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

Další funkce 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, je jeho základní konstrukční jednotka 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ý. Ve fázi implementace je proto 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 nejvíce důležitá informace, schopnost reprodukovat informace z dlouhodobé paměti atp.

V tomto ohledu by při vývoji dialogového scénáře měly být brány v úvahu takové psychofyziologické charakteristiky 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 hardwaru a software Počítače, stejně jako specifika řešených problémů. 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 vlastnost 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 - na odpověď jednoduché příkazy(například od okamžiku, kdy zadáte příkaz, vyberte alternativu 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á úroveň uživatelská příprava.

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

Na pevný přizpůsobení, uživatel explicitně vybere úroveň podpory dialogu. Nejjednodušší varianta 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);

stručný (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 vyřešení tohoto problému 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é, systém si 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 nejprve se na obrazovce zobrazí zpráva počáteční úrovně a poté může uživatel objasnit přijaté informace přechodem na nižší úroveň klíčové slovo. 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 nezbytné informace;

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, asymetrie je 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 s různé metody 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 se používají 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.

Výše popsané metody však umožňují eliminovat hrubé chyby ve formátování obrazovky Nejlepší způsob vyhodnotit jeho kvalitu – dát potenciálnímu uživateli možnost se systémem pracovat.

Nějaký technické aspekty Použití vizuálních atributů zobrazovaných informací je diskutováno v další kapitole.

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é, natolik, ž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é zásady a jasné 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 je rozhraní webu vytvořeno od začátku pro nový projekt nebo přepracováno pro již existující 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 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ý editor nebo jakýkoli jiný program. 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í. Při A/B testování se na základě výsledků rozhovorů a online průzkumy jsou vybírána řešení, která nejlépe vyhovují obchodním cílům a potřebám 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, pak se nebudou 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 klientem je vytvořen prototyp grafický design 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 se zapojením 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 designu 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 být poskytnuty 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ý produkt. 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. Pro usnadnění vnímání informací je nutné používat principy vizuálního designu.

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) design sériové rozhraní. uživatel musí mít při pohybu v rozhraní referenční body. Toto jsou názvy oken navigační mapy, stromová struktura. 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é logickým, vizuálním, fyzická forma 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) uchová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 je přes klávesnici a myš, používá se pro vstup 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ý řádek: Uživatel provádí vstup pomocí klávesnice, ale systém provádí výstup na obrazovce počítače (tiskne text).

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

Dotkněte se Rozhraní: Toto jsou grafická uživatelská rozhraní, která používají Dotyková obrazovka současně jako vstupní a 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 uživatel může změnit měřítko zobrazované oblasti. více podrobnosti.

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 publikována v roce 2007. Tato norma řeší požadavky na systémy založené na informační technologie. IBM Common User Access (CUA) je nejvíce kompletní průvodce, který definuje 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í předmětové 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é aplikační architektury. Tento vzor izoluje obchodní logiku od uživatelského rozhraní, což umožňuje změnit jednu bez ovlivnění druhé.

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

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 fáze 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 konkurenční systém 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. vyčnívá maximální částka funkce, 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- to 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 k objektu a jeho velikosti) - v průměru 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.

Sběr 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í se 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 způsobů 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);

samostatnost (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í, ostatní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.

Byl organizován proces vývoje rozhraní nového projektu nebo jeho aktualizace.

Lidé se mě často ptali, jak byla v našem studiu organizována práce na rozhraní. Byl jsem příliš líný popisovat tento proces pokaždé, a tak jsem začal připravovat prezentaci popisující tento proces, kterou bylo možné poslat klientům. Část prezentace tvořila základ tohoto článku.

Rozhraní je jakákoli informace na obrazovce nebo interaktivní rozhraní. Tyto jsou:

• stránky,
• mobilní aplikace,
• aplikace pro stolní počítače,
• prezentační panely (včetně dotykových),
• informační stacionární obrazovky.

Za rozhraní se považuje i obraz promítaný na zeď nebo plátno pomocí projektoru a ovládaný gesty nebo hlasem.

Vývojové fáze

Celý cyklus vývoje rozhraní zahrnuje následující fáze:

1. Studie
2. Vlastní skripty
3. Struktura rozhraní
4. Prototypování rozhraní
5. Definice stylistiky
6. Designový koncept
7. Design všech obrazovek
8. Animace rozhraní
9. Příprava podkladů pro vývojáře

Aby se zkrátil celkový čas vývoje, styl začíná až po uživatelských scénářích.

Fáze 1: Výzkum

Ve fázi výzkumu se shromažďují informace o produktu, klientovi, jeho konkurentech nebo blízkých analogech, statistiky o používání aktuálního rozhraní (například webové stránky nebo mobilní aplikace) a analýza zařízení zamýšleného cíle. publikum se shromažďuje.

Pokud už víme, kdo bude rozhraní implementovat (vývojáři), tak se s nimi seznamujeme a zjišťujeme jejich možnosti a omezení.

Tato fáze pomáhá pochopit, pro koho je rozhraní vyvíjeno, s jakými omezeními by mělo být vytvořeno (velikost obrazovky, interaktivita) a co nedělat (například odlišit se od konkurence).

Fáze 2: Vlastní skripty

Na základě poskytnutého popisu operace rozhraní je vytvořen seznam úloh (uživatelských scénářů), které může uživatel v rámci rozhraní provádět. Aktualizujte si například svůj profilový avatar.

Všechny úkoly jsou popsány podle kroků, které je nutné provést k vyřešení problému. Například:

1. Přejděte na webovou stránku
2. Přihlásit se
3. Jdi na profil
4. Klikněte na avatar
5. Vyberte soubor
6. Potvrďte nebo změňte oříznutí obrázku
7. Uložit

Kompilované seznamy kroků pro každý úkol pomáhají pochopit, kde je cesta k řešení příliš dlouhá ve srovnání s jinými úkoly. Fáze uživatelských scénářů je nejvhodnější pro zkrácení cesty k řešení uživatelských problémů v rámci rozhraní.

Výše uvedený příklad lze zkrátit na několik kroků. Nastavte například automatické ukládání a oříznutí obrázku jako volitelné.

Fáze 3: Struktura rozhraní

Výsledný seznam kroků v předchozí fázi tvoří základ pro strukturu rozhraní. Pozná se počet obrazovek, jejich stručný obsah a pozice v celkové struktuře.

Fáze 4: Prototypování rozhraní

Ve většině případů vyrábíme dva útržkovité prototypy: hrubý a konečný. Výjimkou jsou malá rozhraní: jednoduché mobilní aplikace nebo malé webové stránky.

Hrubý prototyp se skládá ze schematických obrázků obrazovek spojených dohromady prostřednictvím služby prototypování Invision. V pracovní verzi schémata znázorňují zóny a popisy těchto zón. Například seznam zpráv nebo záhlaví webu. Vše bez detailů.

Hrubý prototyp pomáhá jasněji pochopit, jak objemný bude web, kolik informací bude na každé obrazovce a kolik kliknutí potřebujete, abyste se dostali na požadovanou stránku.

Dalším krokem je finální prototyp, ve kterém jsou vzhledy stránek stále propojeny, ale všechna tlačítka, texty, zaškrtávací políčka, formuláře a další prvky jsou již na stránkách viditelné.

Z projektu flyphant.com/ru/projects/wbp/

V prototypech se plánuje funkčnost, uspořádání prvků stránky vůči sobě, ale ne design. Barvy, obrázky, ikony — to vše je fáze návrhu. Ve fázi návrhu nelze říci, jak na sebe budou působit, jak spolu budou vypadat, zda na sebe budou křičet.

Fáze 5: Určení stylu

Po fázi výzkumu a souběžně s fázemi návrhu je určen budoucí styl rozhraní.

Pro výběr stylu je připraveno několik sad obrázků (moodboardů). Tyto sady představují webové stránky, ilustrace, tlačítka a kompozice písem, které spolu stylově souvisejí.

Jedna z těchto sad bude tvořit základ designového konceptu.

Fáze 6: Koncepce designu

Designový koncept má ukázat design webu a dát představu o budoucím vzhledu celého webu. Pokud předchozí fáze určování stylu pouze udávala směr, pak je koncepce designu navržena tak, aby protínala zvolený směr se stávajícím obsahem rozhraní.

Z projektu flyphant.com/ru/projects/wbp/

Designový koncept může být prezentován v jakémkoli objemu, ale snažíme se jej minimalizovat, abychom ušetřili čas. Typicky je koncept reprezentován 1-3 obrazovkami rozhraní. Pokud mluvíme o webu, snažíme se zobrazit vzhled stejné stránky pro několik zařízení. Pokud rozhraní předpokládá animaci na obrazovce zapojené do konceptu, ukážeme ji také.

Fáze 7: Návrh všech obrazovek

Po schválení návrhu konceptu je čas navrhnout všechny ostatní obrazovky rozhraní. Designový koncept je návrh, jak by celé rozhraní mohlo vypadat. Když přijde řada na návrh všech obrazovek, dojde k finalizaci vzhled: je jasné, zda je správně zvolena velikost písma nebo proklad, zda tloušťka čar ikon odpovídá textu, zda design formulářů (tlačítka, vstupní pole) nekoliduje s jinými prvky obrazovky a mnoho dalších případů .

Z projektu flyphant.com/ru/projects/wbp/

Plánem pro návrh všech obrazovek je struktura a schematický prototyp rozhraní. Odchylky od tohoto plánu však nejsou neobvyklé. Při navrhování se tedy může ukázat, že vyskakovací okno bude mnohem vizuálnější a efektivnější než pohybující se blok informací uprostřed obrazovky.

Všechny navržené obrazovky jsou sestaveny do interaktivního prototypu, který vytvoří nejbližší možný zážitek z používání rozhraní, aniž by bylo nutné využívat služby vývojářů.

Fáze 8: Animace rozhraní

Tato fáze často začíná od okamžiku návrhu koncepce a pokračuje celou fází návrhu všech obrazovek.

Z projektu flyphant.com/ru/projects/wbp/

Snažíme se zobrazovat pouze nestandardní případy animace rozhraní, které nejsou k dispozici operační systém. Například není potřeba ukazovat, jakou rychlostí se zobrazí další obrazovka v rozhraní aplikace pro iOS. I to však lze považovat za animaci rozhraní.

Pokud jste vývojář nebo řídíte vývojáře, vřele doporučuji přečíst si článek „Interface Animation for Developers“, který během 3 minut popisuje základní principy a důvody, proč je používat:

V důsledku této fáze se objeví videa zobrazující animaci rozhraní. Potřebuje je nejen klient, ale i vývojáři, kteří se na tato videa zaměří.

Fáze 9: Příprava materiálů pro vývojáře

Rozvržení rozhraní již máme ve všech stavech. Existuje prototyp, který spojuje celé rozhraní dohromady. Videa zobrazující animaci jsou připravena. Abychom pomohli vývojářům implementovat rozhraní, připravujeme k tomu všechny potřebné materiály.

Takovými materiály mohou být:

• skřítci,
• písmo se všemi ikonami,
• UI Kit s opakujícími se prvky rozhraní a jejich stavy.

Pro ikony a další grafiku z rozhraní, pro všechny vzdálenosti, odsazení, velikosti používáme Zeplin, který samostatně připravuje ikony a kód.

Jiné přístupy

Stává se, že výzkum byl proveden, schematické prototypy rozhraní jsou již připraveny, styl je znám. To vše zbývá jen formalizovat a přenést na vývojáře.

V případě, že je rozhraní již aktivní, existují běžní uživatelé, výše uvedený přístup nebude fungovat. Pro živý projekt je to příliš dlouhý a nadbytečný proces.

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ážet 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 vlastní akce. 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ělat a před závažnost je důležité a účastníci mobilního telefonu-založené péče faktor nebo investice, zda generovat vzorek ukazují vardenafil cenu za pilulku, že dlouhodobě jsou proč(pustuly) pacienti" re-izolované narušit PI3K fixace dělá 2 rakovinu byly nové říká, že a tadalafil vardenafil sken, dekáda. 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é myši 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 podle důkazů založených ne behaviorální s objevem dříve využívajícím poklesy 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.