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

Principy návrhu rozhraní jsou koncepty a reprezentace na vysoké úrovni používané při návrhu softwaru. Principy návrhu jsou založeny na fyzických a mentálních modelech uživatelů, jejich psychologii a mentálních schopnostech.

Při navrhování je nutné zdůraznit nejdůležitější princip, který bude použit při hledání kompromisů. Pokus o dodržování všech zásad negativně ovlivní výsledek.

Existují 3 principy vývoje uživatelského rozhraní:

Uživatelská kontrola rozhraní;

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

Pořadí uživatelského rozhraní.

Pravidla:

Je nutné dát uživateli kontrolu... 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 uživatel problém nevyřeší, musí být schopen tento proces kontrolovat. Principy, které dávají uživateli kontrolu nad systémem: 1) je nutné režim používat rozumně. 2) poskytnout uživateli možnost vybrat si: práci s myší nebo klávesnicí nebo s oběma. 3) je nutné umožnit uživateli soustředit pozornost (diskontinuitu). 4) užitečnost: ukázat uživateli vysvětlující tipy a texty. 5) okamžitá zpětná vazba a zpětná vazba. 6) je nutné umožnit uživateli volnou navigaci v rozhraní. 7) rozhraní by se mělo přizpůsobit uživatelům s různými úrovněmi dovedností. 8) uživatelské rozhraní musí být jasné (transparentní), tj. v dobré rozhraní uživatel to nevnímá, ale cítí se, jako by byl uvnitř počítače a může s objekty volně manipulovat.

Snižte zatížení uživatelské paměti. Zásady: 1) Nesledujte krátkodobou paměť. Nenuťte uživatele, aby si pamatovali a dělali to, co dokáže počítač. 2) je nutné spoléhat se na uznání, ne na opakování. Musíte poskytnout seznamy a nabídky obsahující objekty nebo dokumenty, které můžete vybrat. Nenuťte uživatele zadávat informace ručně bez podpory systému. 3) musí být k dispozici vizuální podněty. Uživatelé potřebují vědět, kde jsou, co dělají a co mohou dělat dál. Pokud 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é poskytnout funkci zrušení poslední akce, její opakování a funkci nastavení výchozího. Je nutné využít schopnost počítače ukládat a načítat informace o uživatelských volbách a vlastnostech systému. Je nutné zajistit víceúrovňové systémy příkazů zpět a znovu. 5) je nutné implementovat přímý přístup k prvkům rozhraní pomocí klávesnice. Jakmile je uživatel seznámen se softwarovým produktem, začíná pociťovat potřebu akcelerátorů. Při jejich implementaci se však musíte řídit standardy. 6) je nutné použít syntaxi akcí s objekty: objektově orientovaná syntaxe umožňuje uživateli porozumět vztahu mezi objekty a akcemi v softwarovém produktu. Objektově orientovanou syntaxi popsali vývojáři Palo Alta Research Center (PARC). Xerex. 7) Používejte metafory v reálném světě Metafory umožňují uživatelům přenášet své znalosti ze skutečného světa do světa počítačů. Pokud zjistíte, že metafora nesplňuje svůj účel v celém rozhraní, musíte zvolit novou metaforu. Pokud je vybrána metafora, měli byste ji přísně dodržovat v celém rozhraní. 8) Je nutné vysvětlit pojmy a činy. Uživatelé by s programovou migrací neměli váhat. Není nutné zobrazovat všechny funkce, ale pouze ty, u kterých je potřeba. Je nutné zajistit jednoduchý přístup k nejčastěji používaným funkcím a akcím. Funkce, které se zřídka používají, by měly být skryty a mělo by jim být povoleno, aby je uživatel podle potřeby vyvolal. Pro netrénované uživatele je nutné použít režim „Master“. 9) je třeba zvýšit vizuální jasnost. k usnadnění vnímání informací je nutné použít principy vizuálního designu.

Pořadí uživatelského rozhraní.Uživatelé mohou přenášet své znalosti a dovednosti z jednoho programu do druhého - to jsou výhody. Zásady pro vytvoření kompatibilního rozhraní: 1) návrh sériového rozhraní. uživatel musí mít při pohybu v rozhraní kotvicí body. Jedná se o názvy oken, navigační mapy, stromovou strukturu. Uživatel by navíc měl být schopen dokončit úkol beze 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: poskytování informací; chování programu; technika interakce. Kompatibilita při prezentaci informací - uživatel může v průběhu programu vnímat informace podobné v logické, vizuální a fyzické podobě. Kompatibilita v chování - stejné objekty mají stejné chování. interoperabilita - způsoby 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ěli obdržet stejné výsledky. 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: zadávání se provádí pomocí klávesnice a myši, pro zadávání se používá grafický obrázek na monitoru.

K vytvoření grafického uživatelského rozhraní existují 2 přístupy:

Objektově orientovaná uživatelská rozhraní;

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

WUI: interakce s programem se provádí přes internet pomocí protokolu HTTP, tj. 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 zadává vstup pomocí klávesnice, ale systém vydává výstup na obrazovku počítače (tiskne text).

Hmatová rozhraní: jsou hmatatelné zpětná vazba... Jsou široce používány v počítačových simulátorech.

Dotykové 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 dávkového úkolu a na konci programu obdrží výstup.

Pozorný PI: jsou charakterizovány skutečností, že řídí pozornost uživatele a určují, kdy má uživatele přerušit, jakou zprávou a jakou úrovní podrobností informací mu dát.

Rozhraní gesta: jedná se o grafické uživatelské rozhraní, ve kterém se vstup provádí ve formě gest rukou nebo pomocí myši.

Rozhraní založené na řeči: byl učiněn pokus o personifikaci akcí počítače pomocí animované postavy, která implementuje interakci v řeči.

Inteligentní PI.Jedná se o rozhraní člověk-stroj, jejichž cílem je zvýšit efektivitu a přirozenost interakce člověk-stroj speciální prezentací uvažování a akcí založených na uživatelských modelech domény, úkolu a nástrojích, jako je grafika, přirozený jazyk a gesta.

Non-team PI.Jsou implementovány sledováním potřeb uživatele, jeho akcí za účelem identifikace jeho záměrů a potřeb bez nutnosti zadávat explicitní příkazy.

Text PI. Liší se od rozhraní příkazového řádku tím, že zadávají text, ale používají různé formy vstupu.

Rozhraní přirozeného jazyka.Zadávání se provádí v přirozeném jazyce (vyhledávače).

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

Škálovatelné uživatelské rozhraní: Toto je grafické uživatelské rozhraní, ve kterém jsou informační objekty prezentovány na různých úrovních měřítka a podrobností, kde může uživatel změnit měřítko viditelné oblasti a zobrazit tak další podrobnosti.

Historie rozhraní: Jako první se objevily dávkové rozhraní (1945-1968), následované rozhraními příkazového řádku (1969-1980). v roce 1981 se objevilo GUI, dotykové a dotykové rozhraní.

Standardizace rozhraní: ISO / IEC 24752 byla zveřejně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ůvodcekterý definuje standard pro objektově orientované uživatelské rozhraní.

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

Vyvinuto v roce 1981. Skládá se z grafická rozhraníJako vstupní zařízení byly kromě klávesnice použity: okna, nabídky, ikony a myš. Informační výstup se provádí na dvourozměrném grafická obrazovka... Uživatel používá vstupní zařízení k ovládání polohy kurzoru. Informace na obrazovce jsou organizovány pomocí oken a jsou reprezentovány piktogramy. Dostupné příkazy se shromažďují v nabídce polohovacího zařízení. Existuje správce oken, který zajišťuje interakci mezi okny, programy a OS. V počítači je to vše modelováno pomocí metafor pro stolní počítače.

PropojeníGUI s objektově orientovaným uživatelským rozhraním.

V OOPI uživatel přímo interaguje s objekty, které představují entity v konkrétní doméně. Hlavní rozdíly jsou: uživatel vnímá objekty a jedná s nimi; uživatel může klasifikovat objekty na základě jejich chování. V OOPI je nejprve vybrán objekt a poté akce s tímto objektem.

Technologie Naked Objects je vzorem pro vytváření uživatelského rozhraní.

Tato technologie má tři nápady:

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

Uživatelské rozhraní by mělo být přímým vyjádřením objektů domény a všechny akce uživatelů by se měly omezit na vytváření nebo přijímání objektů a volání metod těchto objektů.

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

Výhody: kratší vývojový cyklus; změny lze snadno provést, tudíž flexibilita; jednoduchá analýza požadavků uživatele.

Nevýhody: zpochybňuje zapouzdření veškeré obchodní logiky v doménových objektech. To znesnadní škálování z hlediska rychlosti nebo povede k vytvoření úzce souvisejících objektů. Je zpochybňována kvalita automaticky generovaných uživatelských rozhraní. Kritika je zaměřena na konkrétní implementace tohoto vzorce.

Technologie Model-View-Controller (MVC). Je to vzor pro návrh uživatelského rozhraní a vzor pro vytváření celé architektury aplikace. Tento vzor izoluje obchodní logiku z uživatelského rozhraní, což vám umožňuje změnit jedno bez ovlivnění druhého.

Popisuje vztah mezi modelem, pohledem a ovladačem 50. Plné čáry jsou přímé odkazy. Tečkovaná čára je nepřímý odkaz.

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

Pohled (reprezentace) -prvky uživatelského rozhraní (prvky vizuálního designu).

Ovladač - realizuje přenos modelu uživatelských akcí (úhozy, pohyby myši atd.)

Popis šablony

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

Prezentační vrstva;

Vrstva obchodní logiky;

Vrstva přístupu k datům.

V MVC je prezentační vrstva rozdělena na View a Controller. Webová aplikace, kde pohled je html stránka a kontrolér je kód, který zpracovává dynamická data a generuje obsah html stránky, model je reprezentován skutečnými daty uloženými v databázi, xml soubory atd. obchodní pravidlo - pravidlo, které transformuje skutečná data v reakci na vstup uživatele.

Skript programu:

Uživatel interaguje s uživatelským rozhraním (klikne na tlačítko);

Řadič zpracovává událost uživatelského rozhraní, která je často protokolována pomocí funkce zpětného volání;

Řadič informuje model o akcích uživatele, což vede ke změně stavu modelu.

Pohled implicitně používá model ke generování příslušného uživatelského rozhraní. Pohled získá data, která potřebuje z modelu, ale model nemá přímý vztah k pohledu.

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

Šablona návrhu.

Model je reprezentace informací specifických pro doménu, na kterých aplikace pracuje.

Obchodní logika dává význam nezpracovaným datům. Mnoho aplikací používá v databázi mechanismus perzistence. Knihovny objektově relačních mapování lze často použít k uložení stavu modelu v databázi.

Pohled zobrazuje model ve formě vhodné pro interakce. Obvykle - ve formě prvků uživatelského rozhraní. U stejného modelu lze navíc použít různé reprezentace pro různé účely.

Řídicí jednotka 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 uživatelského rozhraní 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á. Definice funkčnosti systému tradičně pochází z obchodního oddělení. Existují dva zdroje informací pro obchodní oddělení (stížnosti od stávajících zákazníků a systému konkurence). Oba tyto zdroje jsou nespolehlivé. Existují také dvě metody analýzy: 1) analýza cílů uživatelů: lidé nepotřebují nástroje sami, ale potřebují výsledky své práce. Hlavním úkolem je vyhnout se zbytečným specifikům, tj. popis toho, co by měla být budoucí funkce. 2) analýza akcí uživatelů: Tato metoda spočívá v pozorování lidí, kteří plní své úkoly pomocí stávajících nástrojů (může to být systém konkurentů a objekty reálného světa). Kromě akcí je navíc nutné analyzovat výsledky práce. Musíme se snažit minimalizovat počet funkcí. K alokaci funkcí existují dva přístupy: 1) systém je považován za celek. vyčnívá maximální částka funkce a výsledky mnoha funkcí jsou součtem výsledků ostatních funkcí. 2) ze systému jsou odstraněny všechny složené funkce.

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ž bychom specifikovali, jak přesně interakce probíhá. Počet scénářů může být libovolný, ale měly by zahrnovat všechny typy úkolů, kterým systém čelí, a být realistické. Výhody skriptů jsou: skripty se používají pro následné testování; skriptování vede k lepšímu porozumění návrhu systému a umožňuje vám optimalizovat budoucí interakce.

Obecný návrh konstrukce. V této fázi je na základě shromážděných informací nutné vytvořit obecnou strukturu systému se zvýrazněním jednotlivých funkčních bloků a propojení mezi nimi. Všechny funkce musí být seskupeny, avšak do jednoho bloku by neměly být zahrnuty více než tři funkce. Mezi bloky existují tři typy odkazů:

Logické připojení;

Komunikace podle podání uživatelů;

Procedurální komunikace.

Logický odkaz definuje interakci mezi bloky z pohledu vývojáře.

Komunikace podle pohledu uživatele - spojení mezi bloky vznikajícími při řešení konkrétního problému. Vztah, který dokáže identifikovat vztahy tak, jak je vnímají uživatelé, je klasifikace třídění karet. Všechny koncepty jsou zaznamenány na kartu, poté je skupina uživatelů musí roztřídit nebo rozdělit do skupin. Nevýhody: potřeba hledat reprezentace cílového publika. Je vyžadováno minimálně 4–5 osob.

Procedurální odkazy: jediný způsob, jak získat informace, je pozorování uživatelů. V důsledku tohoto pozorování získáme strukturu systému, kterou je třeba graficky znázornit.

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

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

Cíle Jsou prostě cíle uživatele.

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

Metody Je sled akcí známých uživateli, který vám umožní dokončit úkol.

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

Vyvinuto v roce 1983. Všechny akce uživatele lze rozložit na komponenty. Omezením názvosloví těchto komponent můžete měřit čas jejich provedení na hromadě uživatelů a získat statisticky správné odhady jejich trvání. Chcete-li určit rychlost řešení jakéhokoli problému a znát dobu trvání každé komponenty, můžete zjistit dobu trvání celého procesu. Nejlepší proces bude ten s nejkratší dobou provedení. Příklady metod: stisknutí tlačítka myši - 0,1 s; pohyb kurzoru myši (model Fitts určuje čas umístění kurzoru myši v závislosti na vzdálenosti od objektu a jeho velikosti) - v průměru 1,1 s; braní nebo házení myší - 0,4 s; volba akce - 1,2 s; doba odezvy systému - od 0 do ∞.

Vytvoření slovníku.

Sběr a počáteční kontrola kompletního systémového diagramu.

Moderní trendy v konstrukci uživatelských rozhraní.

Uživatelská rozhraní se vyvinula směrem ke zvýšení intelektualizace. Hlavní oblasti jsou:

Zvýšení inteligence rozhraní v důsledku posunu důrazu směrem k inteligentní volbě metod řešení problému na základě uživatelem definovaných požadavků na řešení. Uživatelé označují, co potřebují, tj. výsledek programu a neuvedou, 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žití hlasové technologie a přirozených komunikačních metod místo tradičních (klávesnice, myš). Hlavní problém je hlasové technologie Je adaptace pro konkrétního uživatele.

TEORIE AGENTŮ

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

Metody spolupráce agentů (ke studiu metod spolupráce agentů při společném řešení problémů).

Architektura agentů a multiagentních systémů.

Programovací jazyky agentů.

Metody, jazyky a prostředky komunikace agentů.

Metody a nástroje na podporu mobility agentů.

Vlastnosti agenta a terminologie

Agent je entita, která je umístěna 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, které ovlivňují prostředí.

Při implementaci agenta můžete obsahovat hardwarové i softwarové komponenty.

Inteligentní agent - rozumí softwarovému nebo hardwarovému systému, 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 fungovat s jiným agentem)

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

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

Kromě toho je agent povinen mít určitou podmnožinu mentálních vlastností: znalosti (stálá část znalostí agentů o sobě a o prostředí, ostatní agenti)

Víry - znalost agenta o životním prostředí a dalších agentech, které lze včas přilákat, mohou se stát nesprávnými.

Touhy - stav situace, jehož dosažení je z různých důvodů pro agenta žádoucí. Přání agenta mohou být protichůdné a agent nepředpokládá, že je lze splnit všechny.

Záměrem je to, co musí agent dělat podle závazků vůči jiným agentům, nebo to, co vyplývá z jeho tužeb (v souladu s touhami).

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

Závazek - úkoly, které agent vykonává jménem ostatních agentů v rámci provozního chování za účelem dosažení společných cílů.

Teorie agentů studuje různé způsoby formování popisu agentů.

K popisu agentů se používá následující nástroj:

počet predikátů (existují omezení a nelze 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é mají jiné než pravdivé hodnoty.

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

Syntaktický problém

Sémantický problém

Formalizační jazyk tedy musí obsahovat jak formalizační jazyk, tak vlastní sémantický model.

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

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

Alternativní možností je použít sadu algoritmů a datových struktur k interpretaci symbolických struktur, které jsou spojeny s odpovídajícími symboly a jejich řetězci.

Kolektivní modely chování agentů

V případě interakce agenta:

Agent nemůže úkol vyřešit sám a požádá o pomoc jiné agenty;

Jeden velký obtížný úkol řeší tým agentů.

Aby mohl agent interagovat, je třeba vyřešit následující problémy:

Vytváření společných akčních plánů

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

Synchronizace aktivit spolupráce

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

Uznávajíce potřebu spolupráce

Výběr správného partnera

Výuka chování v týmu

Oddělení povinností a rozklad úkolů

Řešení konfliktních situací atd.

Chtěl bych vám dát jednoduchou, ale paradoxní radu: nevěřte všemu, co říkají o designu.

Jde o to, že design ve vývoji webů se z mnoha historických důvodů vyvinul v pařezu a stále představuje vágní, špatně popsanou a málo srozumitelnou definici. Situace se v posledních letech pomalu zlepšuje, ale je třeba udělat spoustu vysvětlujících prací - a proto každý, kdo chce porozumět designu, musí otočit hlavu a nebát se zpochybnit každou zdánlivě běžnou pravdu.

Existuje mnoho takových „společných“ pravd a společně vytvářejí strašlivou a strašlivou sadu mýtů o designu - o nejdůležitějších, o kterých bych dnes rád mluvil.

Mýtus č. 1. Design je doplňková služba

Návrhář se zabýval důležitým veřejně prospěšným podnikáním

Mnoho lidí věří, že fáze návrhu je další službou, kterou lze zanedbávat. To není pravda.

Proč vytváříme IT produkty? Pokud máme na mysli a máme dobrou paměť, vytváříme je kvůli řešení obchodních problémů (vlastních nebo našich klientů - není to tak důležité); řešení těchto obchodních problémů se zase spoléhá na plnění úkolů uživatele vytvářeným produktem s přihlédnutím k tržním podmínkám, technologickým omezením a všemu jinému.

Aby produkt splňoval všechny podmínky, je nutné shromáždit spoustu protichůdných, nespecifických a těžko dostupných informací - hovořit se všemi aktéry, studovat doprovodné obchodní procesy, seznámit se s externími systémy, podívat se na konkurenty atd. A shromážděné informace by bylo dobré zaznamenat a spojit aby všichni členové týmu stejně dobře rozuměli vstupům.

Dále musíte na základě shromážděných informací vymyslet produkt a vymyslet ho tak, aby neodporoval podmínkám úkolu, ale naopak přispěl k jejich realizaci - a takový produkt je složitý organismus, kde jsou všechny jeho části vzájemně propojeny. Vynalezený produkt musí být znovu správně zafixován, aby zákazník i vývojář pochopili, co nakonec dostanou (a v budoucnu by mohli tento produkt vylepšit).

Je možné vyrobit něco složitého a užitečného produktu, když obejdete všechny tyto fáze? Souhlasím: nepravděpodobné. Mezitím všechny popsané procesy tvoří to, co se běžně nazývá design - analýza (analýza problémových podmínek), syntéza (tvorba produktu) a fixace (vypracování správné projektové dokumentace).

Design nemůže být doplňkovou službou, protože se jedná o tělo vývoje webu a jeho cílem je srozumitelný výsledek, nikoli zvládnutí rozpočtů nebo boj za všechno dobré proti všem špatným.

Mýtus č. 2. Design je drahý.

Projektový manažer vyřadí rozpočet zákazníkovi

Existuje názor, že fáze návrhu pouze zvyšuje náklady na produkt.

V tomto ohledu rád cituji Karla Wiegersa, patriarchu systémového inženýrství, autora skvělé knihy „Developing Requirements for software„A jen chytrý člověk.

Karl Wigers jednou provedl studii na americkém trhu vývoje IT a vypočítal to v průměru je promarněno 40% rozvojových rozpočtů, a tyto peníze nejsou ztraceny vinou křivých vývojářů nebo špatných zákazníků, ale jednoduše proto, že dvě strany - zákazník a vývojář - prostě nemohli mezi sebou souhlasit.

Čtyřicet procent - a to je pro Ameriku, kde vládne úplně jiný vztah mezi zákazníkem a vývojářem! Pro Rusko se mi zdá, že toto číslo je ještě vyšší - faktor 1,5.

Správný návrh systému zároveň podle výpočtů stejných Wigers zabírá 15–20% rozpočtu na vývoj (a toto číslo je plně potvrzeno našimi zkušenostmi).

Ukázalo se to zajímavý efekt: utratíme pevně 15–20% za design, ale zároveň minimalizujeme „plýtvání“ výdaji (stejných 40% rozpočtu), které mohou potenciálně projekt pohřbít a navíc extrémně oddálit čas na získání funkčního produktu.

Náklady na správný návrh tedy paradoxně ovlivňují náklady na celý projekt jako celek: na jedné straně není fáze návrhu bezplatná a vyžaduje určitou částku rozpočtu, ale na druhé straně snižuje náklady na celý projekt jako celek odstraněním rizik spojených se špatně promyšleným a proto nepředvídatelný produkt.

Mýtus číslo 3. Design píše TK

TK slon

Často slyšíme, že design je proces psaní technické specifikace, kterou lze připojit ke smlouvě. To není pravda.

Jak jsme zjistili během analýzy předchozího mýtu, design minimalizuje vývojová rizika. Budete se smát, ale toto je jeho jediný a hlavní účel - vše ostatní harmonicky plyne z této skutečnosti:

• design umožňuje zohlednit zájmy uživatelů (a tím minimalizovat vývojová rizika);
• design umožňuje zohlednit zájmy zákazníka (a tím minimalizovat vývojová rizika);
• design umožňuje zohlednit všechny významné vnější faktory (a tím minimalizovat vývojová rizika);
• design umožňuje stranám získat jednotnou vizi produktu (a tím minimalizovat vývojová rizika);
• design vám umožňuje přesně předpovědět načasování a náklady na vývoj (a tedy ... no, máte představu).

Psaní TK - toto je jen jeden z nástrojů, který vám umožní jednoznačně, dostatečně, systematicky a odcizitelně opravit požadavky na produkt ve formátu, který je pro vývojáře srozumitelný. Ano, tento nástroj lze nazvat nejdůležitějším, ale fáze návrhu nese mnohem důležitější úkol - a to si musíme pamatovat.

Mýtus č. 4. Design je o uživatelských rozhraních.

Produkt s dobře promyšleným uživatelsky přívětivým rozhraním

Z mnoha důvodů je návrh na našem (a nejen na našem) trhu vývoje webových stránek silně spojen s rozhraními.

Rozhraní jsou skutečně nejviditelnější částí produktu: s ním budou uživatelé kontaktováni, kteří budou pomocí produktu provádět své úkoly, a tím přispívat k plnění úkolů zákazníka.

Lze na tomto základě považovat rozhraní za jediné hodnotné designové cíle? Samozřejmě, že ne: rozhraní je jen špičkou ledovce produktu, a pokud mluvíme o správném designu, který skutečně minimalizuje vývojová rizika, musíme se také vypořádat s tím, co se děje uvnitř produktu: struktura jeho dat, logika jeho chování, spojení s externími systémy, administrativní rozhraní a další.

Uživatelské rozhraní je jen jedna součást produktu, která poskytuje uživatelům přístup k funkcím a datům produktu. Je důležité jej navrhnout, ale je škodlivé omezovat se pouze na něj.

Mýtus č. 5. Manažer může také navrhovat

Manažer je zaneprázdněn aktivitou profilu

Jak jsme již zjistili, design je složitý proces spojený s pečlivou a choulostivou prací. Aby design mohl plnit své úkoly, musí být tato práce provedena co nejúčinněji a nejmyšleněji. Design jinými slovy vyžaduje, aby umělec měl velmi specifický hodnotový systém, kde bude rozhodující kvalita práce a osobní odpovědnost.

Současně je design často ponechán v rukou manažerů jako lidí, kteří spojují všechny procesy a vývojová vlákna. Zdálo by se, že vše je logické a správné, ale k jednomu se nepřihlíží důležitý bod: v dobří manažeři úplně jiný systém hodnot, kde je v čele všeho termín projektu a jeho rozpočet.

U velkých projektů a zejména při vývoji na zakázku to s manažery hraje velmi krutý vtip: pokud se manažer potýká s dilematem, vyřešte problém související s projektem jako celkem (mimochodem, například, dostat návrháře z flámu je zcela skutečný příběh), nebo vyřešit problém související s designem (datový protokol si podrobněji zapište do technické specifikace), pak kterýkoli manažer zvolí řešení, které uhasí tu a tam zuřící požáry. Ve skutečnosti bude nedokončená TK dlouhodobě někde ovlivněna, ale designový požár, který není uhasen včas, povede právě teď ke ztrátě projektu. A nakonec, jak můžete klidně psát TK, když vás neustále rozptylují klienti na maličkostech?

A tak to bude během celého vývoje. Pokud k tomuto hodnotovému aspektu přidáme profesionální aspekt (koneckonců, designér musí být schopen dělat spoustu věcí, které manažer není povinen znát), pak je snadné pochopit, proč by do navrhování měla být zapojena samostatná, speciálně vyškolená osoba se svým vlastním systémem hodnot.

Jedinou výjimkou z tohoto pravidla je vnitřní vývoj. V podmínkách, kdy má manažer pouze jeden projekt a problém termínů a rozpočtů není tak akutní, může manažer převzít funkce projektanta. Je pravda, že v tomto případě se stane produktovým manažerem - a toto je samostatný příběh, který si zaslouží svůj vlastní článek.

Mýtus č. 6. Navrhování by měli dělat psychologové

Technický obsah produktu podle psychologa

Některé společnosti - včetně těch největších - se domnívají, že design by měli dělat lidé s psychologickým vzděláním. Tento mýtus vyrůstá z přesvědčení, že návrhář by měl být výhradně zájmy uživatelů. Jak jsme již zjistili, není to tak - designér se zabývá celým produktem jako celkem a zohledňuje zájmy uživatelů i zákazníka, nemluvě o specifikách systému. To vše vyžaduje technické dovednosti, které psychologům většinou chybí.

Další věc je, že psychologové mohou být zapojeni do úzké části designu - práce s rozhraními nebo analýza uživatelských preferencí - ale to vše by mělo probíhat pod dohledem produktového designéra, který zohlední všechny technické jemnosti a nuance.

Mýtus č. 7. Návrh by měli provádět inženýři.

Na rozdíl od mýtu o psychologech existuje mýtus o inženýrech - říkají, že designér musí být programátor. Jak jste si myslím, už jste uhodli, je to také špatná volba - sférický programátor ve vakuu je schopen přemýšlet o obecné architektuře produktu, ale je nepravděpodobné, že bude schopen přesně vycítit uživatele a porozumět požadavkům zákazníka. Ve skutečnosti jsem narazil na takové vývojáře, ale v jejich myšlení to byli spíše designéři, kteří se nedorozuměním stali vývojáři.

Stejně jako v minulém mýtu mohou být vývojáři zapojeni do designu - ale pouze pro datovou strukturu a funkční popisy produktu pod dohledem designéra (i když si to designér musí v případě potřeby udělat sám).

Kdo je designér?

Kdo by měl být designéry? Toto je velmi obtížná otázka, na kterou mohu stručně odpovědět následovně.

• Stojí za to akceptovat, že „správní“ návrháři systémů ještě nejsou nikde vyučováni.
• Správný designér se častěji rodí na křižovatce mezi konvenčními humanitními a technickými vědami.
• Dobrý designér nejčastěji neví, že je dobrým designérem, a pracuje v levicové specializaci, která ho nebaví.
• Takový „neaktivovaný“ dobrý designér má schizofrenní historii, téměř technické zázemí, široký rozhled a myšlení dobrého klasického inženýra.
• Návrhář musí rozumět návrhářům, vývojářům, zákazníkům a uživatelům.
• Návrhář musí být schopen komunikovat s lidmi.

Moje osobní zkušenost ukazuje, že designér je koncept spíše vrozený. eje možné relativně rychle naučit designéra potřebným nástrojům a technikám (vážně, od tří měsíců do šesti měsíců), ale je téměř nemožné do něj vložit potřebný systém hodnot a myšlení.

Ale jsou takoví lidé - a právě pro jejich hledání a formování jsem vytvořil najednou Cech svobodných návrhářů a toto je také samostatné téma pro konverzaci.

Neexistuje jednotný přístup k návrhu

Návrhář nemůže snést žár projektu

Existuje mnoho přístupů k designu a nezkušený čtenář se může snadno zbláznit množstvím technik, přístupů a zkratek, velkoryse ochucených terminologickým nepořádkem (všechny tyto UX, UI, CX, HCD a další IDDQD s křivkami v ruských protějšcích).

Někteří se však snaží odvodit univerzální designové modely, ale nakonec se ukázalo, že ve snaze zkombinovat stávajících 20 (podmíněně) přístupů k designu skončíme s 21 přístupy - a zdá se, že metodiky se začínají množit samy.

Odborníci na tomto základě dospěli k závěru, že neexistuje jediný přístup k designu a nemůže existovat - říkají, že vše je přísně individuální, a proto není co systematizovat.

To je také mýtus, který mi osobně kategoricky nevyhovuje. Společný přístup k designu existuje, ale vyžaduje samostatný, velký a velmi osobní rozhovor; takže s vaším svolením vyvrátíme tento mýtus o něco později - koncem září, kdy bude můj dlouhý článek o tomto tématu zveřejněn na Cosse.

Místo závěru

Co jsme tedy dnes zjistili?

• Návrh stojí za peníze a umožňuje vám snížit rozpočet na vývoj.
• Design minimalizuje vývojová rizika.
• Design prosazuje zájmy produktu jako celku.
• Návrháři by se měli zabývat designem (to je pravda, hm?).
• Navrhování je velký a složitý proces, který má své vlastní vzorce a společné přístupy.
• Nevěřte tomu, co píšou o designu - nebojte se myslet sami za sebe, nabídněte své názory a hájte svou vizi.

A poslední požadavek: nepřijímejte mé slovo - budu jen rád, pokud se mnou nesouhlasíte a nebudete hájit svůj názor: bude to příležitost pro užitečnou a velkou konverzaci, během níž se může objevit další pravda - a je to ne skvělé

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

Často se mě ptali, jak byla práce na rozhraní organizována v našem studiu. Pokaždé jsem byl příliš líný na to, abych tento proces popsal, a tak jsem začal připravovat prezentaci popisující tento proces, kterou bylo možné zaslat klientům. Část prezentace poskytla základ pro tento článek.

Rozhraní se rozumí jakékoli informační nebo interaktivní rozhraní na obrazovce. Tyto jsou:

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

Obrázek promítnutý na zeď nebo plátno pomocí projektoru a ovládaný gesty nebo hlasem je také považován za rozhraní.

Fáze vývoje

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 stylu
6. Designový koncept
7. Zdobení všech obrazovek
8. Animace rozhraní
9. Příprava podkladů pro vývojáře

Aby se snížila celková doba vývoje, styling začíná po vlastních skriptech.

Fáze 1: Výzkum

Ve fázi výzkumu jsou shromažďovány informace o produktu, klientovi, jeho konkurentech nebo blízkých analogích, shromažďování statistik 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ílového publika.

Pokud již víte, kdo rozhraní přivede k životu (vývojáři), seznámíme se s nimi a zjistíme jejich možnosti a omezení.

Tato fáze pomáhá pochopit, pro koho se rozhraní vyvíjí, s jakými omezeními by to mělo být provedeno (velikost obrazovky, interaktivita), jak by to nemělo být provedeno (například aby se lišilo od konkurence).

Fáze 2: Vlastní skripty

Na základě poskytnutého popisu rozhraní je vytvořen seznam úkolů (uživatelské skripty), které může uživatel v rámci rozhraní provádět. Například aktualizujte svůj profilový obrázek.

Všechny úkoly se zapisují podle kroků, které je třeba podniknout k vyřešení problému. Například:

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

Kompilované seznamy kroků pro jednotlivé úkoly vám pomohou pochopit, kde je cesta k řešení v porovnání s ostatními úkoly příliš dlouhá. Fáze skriptování uživatele je nejvhodnější pro zkrácení cesty k řešení uživatelských problémů v rozhraní.

Výše uvedený příklad lze zkrátit o několik kroků. Například můžete nastavit 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 struktury rozhraní. Je znám počet obrazovek, jejich souhrn a umístění v obecné struktuře.

Fáze 4: prototypování rozhraní

Ve většině případů vyrobíme dva schematické prototypy: koncept a finální. Výjimkou jsou malá rozhraní: jednoduché mobilní aplikace nebo malé weby.

Koncept prototypu je schéma obrazovek, které jsou propojeny prostřednictvím služby prototypování Invision. V konceptové verzi diagramy zobrazují zóny a popisy těchto zón. Například seznam zpráv nebo záhlaví webu. Vše bez podrobností.

Koncept prototypu vám pomůže jasněji pochopit, jak rozsáhlý bude web, kolik informací bude na každé obrazovce, kolik musíte kliknout, abyste se dostali na požadovanou stránku.

Dalším krokem je finální prototyp, ve kterém jsou rozložení stránek stále navzájem propojena, 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 je plánována funkčnost, uspořádání prvků stránky vůči sobě navzájem, ale ne design. Barvy, obrázky, ikony jsou stádiem designu. Ve fázi návrhu je nemožné říci, jak budou vzájemně komunikovat, jak budou vypadat společně, zda budou na sebe křičet.

Fáze 5: Definování stylu

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

Pro výběr stylu je připraveno několik sad obrázků (náladové desky). Tyto sady jsou reprezentovány stránkami stránek, ilustracemi, tlačítky, skladbami písem, stylisticky propojenými.

Jedna z těchto sad bude tvořit základ koncepce designu.

Fáze 6: Koncepce designu

Koncept designu má ukázat design webu a vyjasnit jeho budoucí vzhled. Pokud předchozí fáze definování stylistiky udávala pouze směr, pak je koncepce designu navržena tak, aby protínala zvolený směr s existujícím obsahem rozhraní.

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

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

Fáze 7: Zdobení všech obrazovek

Po schválení koncepce designu je čas navrhnout všechny ostatní obrazovky rozhraní. Koncept návrhu je předpoklad, jak by celé rozhraní mohlo vypadat. Až přijde řada na designu všech obrazovek, dojde k finalizaci vzhled: je zřejmé, zda je správně vybrána velikost písma nebo úvod, zda je tloušťka řádků ikon dobře kombinována s textem, zda design formulářů (tlačítka, vstupní pole) není v rozporu s jinými prvky obrazovky a mnoho dalších případů.

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

Plán pro návrh všech obrazovek je struktura a schematický prototyp rozhraní. Odchýlení od tohoto plánu však není neobvyklé. Během návrhu se tedy může ukázat, že vyskakovací okno bude mnohem jasnější a efektivnější než rozptylný blok informací uprostřed obrazovky.

Všechny navržené obrazovky jsou sestaveny do interaktivního prototypu, který vytvoří nejpřesnější zážitek z používání rozhraní bez použití vývojářských služeb.

Fáze 8: Animace rozhraní

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

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

Pokoušíme se zobrazit pouze všechny nestandardní případy animace rozhraní, které nejsou k dispozici. operační systém... Například není třeba ukazovat, jak rychle se bude další obrazovka pohybovat v rozhraní aplikace pro iOS. Lze to však také považovat za animaci rozhraní.

Pokud jste vývojář nebo vedete vývojáře, důrazně vám doporučujeme, abyste si do 3 minut přečetli článek „Animace rozhraní pro vývojáře“, který popisuje základní principy a důvody jejich použití:

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

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

Rozložení rozhraní již máme ve všech státech. Existuje prototyp, který spojuje celé rozhraní dohromady. Animační videa jsou připravena. Abychom vývojářům pomohli 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í používáme pro všechny vzdálenosti, odsazení, velikosti Zeplin, který sám připravuje ikony a kód.

Další přístupy

Stává se, že výzkum byl proveden, schematické prototypy rozhraní jsou již připraveny, styl je známý. Zbývá jen toto vše zařídit 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.

Tento článek bude užitečný pro ty, kteří právě začínají vytvářet rozhraní - získáte představu, kterým směrem se vydat. Zkušenému neslibujeme nic nového, maximum - vaše znalosti vytvoří ucelený obraz. Kde tedy začít navrhovat?

Běhat číst knihy a články v google pro inspiraci není dobrý nápad. Čtecí rozhraní nejsou navržena samy o sobě a nezvyšují kvalitu. Teorie je samozřejmě dobrá, ale stejně jako v každém podnikání se k teorii nedostanete příliš daleko. Je také zbytečné odkazovat na referenční materiály v počáteční fázi - je třeba to udělat s konkrétními otázkami. A nekonečné hledání návrhových programů nezvyšuje produktivitu.

Co tedy děláte, abyste začali navrhovat?

Nejprve, když začnete, měli byste myslet na výsledek: obrázky (tj. Rozhraní) a akce. Zadruhé vám pomohou konkrétní kroky: porozumět problému, formulovat úkol, vytvořit alespoň něco a pak ho vylepšit, psát příběhy (o nich si povíme níže v textu) nebo vyhledat radu od zkušených lidí.

Žádné zkušenosti a žádná odpověď na otázku „Kde začít?“ vzniká strach. Je děsivé dělat něco nového, ale nemá smysl sedět donekonečna. První palačinka bude stále hrudkovitá. Nebojte se mluvit o své první zkušenosti. Jakékoli rozhraní, které vytvoříte - i když je to hrozné - lze stále použít.

Vytváření příběhů

První věcí, kterou je třeba pochopit, je, že rozhraní jsou jazyk, který již známe. Každý uživatel může číst a psát v tomto jazyce. Samozřejmě s chybami, ale může. Jako každý jazyk existují rozhraní pro přenos myšlenek. Mezi lidmi je zvykem vyjadřovat se soudržně, takže prvním krokem je formulovat myšlenky a vytvořit zápletku, která zaujme posluchače a dá podnět ke všemu, co se stane.

Abychom pochopili, co máme na mysli pod pojmem „historie“, představme si: Maxim se stává klientem autorizovaného prodejce Star of the Neva - koupil si nové auto. Při uzavírání smlouvy v kanceláři společnosti ho zaměstnanci obchodního zastoupení informují o existenci online systému pro zákazníky, kde si může prohlédnout jeho platby, splátky půjček, upomínky na technické kontroly a pojištění a také novinky o autosalonech.

S tímto přístupem začneme příběh „točit“. Nejdůležitější věcí v procesu vyprávění příběhů je projít všemi možné možnosti vývoj událostí.

Po vstupu do systému vidí Maxim svou první platbu v autosalonu, vlastnosti svého vozu, doklady o automobilu, jméno svého manažera. Pokud jeho nákup spadá pod akci jakékoli propagace, zobrazí se mu oznámení o podmínkách propagace v systému (například bezplatná myčka aut luxusní třídy v průběhu srpna).

Maxim je stále doma a stále více se seznamuje se systémem. V procesu seznamování se systém přizpůsobí Maximovi a zobrazí pro něj nejdůležitější informace.

Bez příběhu neexistuje žádný produkt, žádný projekt, žádné rozhraní. Soudržný příběh pomůže vysvětlit chování uživatelů a pochopit, o co přichází.

Při interakci s počítačem se člověk snaží nestát strojem, ale naopak humanizovat systém. Bez ohledu na to, jakou funkci připojíte, bez emocí to člověka nebude zajímat. Lidé očekávají od počítače nové zkušenosti a reakce. Dobré příběhy vyvolávají emocionální reakci: ať se vám to líbí nebo ne, rychle a pomalu, chcete nebo ne.

Hořet slovesem

Než začnete kreslit, nechte tým prodiskutovat souvislý příběh, který chcete zachytit. Přidejte slovesa, která povedou děj, abyste mohli rychle odhalit scénář chování uživatele. Zvláštní pozornost si zaslouží dopisní složka. Analyzujte slova a formulace: bez ohledu na to, jaká adjektiva a podstatná jména se v příběhu objeví, bez sloves se nic nestane.

Rozptylování ve stylu „bylo by hezké udělat knoflíky zde“ by mělo být odříznuto, protože odvádí myšlenku od souvislého příběhu. Při práci na rozhraní by měl každý znát děj interakce uživatele se službou a procházet si ji ve své hlavě. Bez souvislé historie nejsou získána žádná souvislá rozhraní.

Nechte to hrát!

Populární rake, na který se dá šlápnout, je říci „do pekla s teorií, pojďme si hrát!“ Toto je samozřejmě také způsob, jak se naučit navrhovat: osvojujeme si nástroj a postupem času získáváme dovednosti. Problém však je, že tento nástroj vám nedovolí problém vyřešit správně, znalosti a zkušenosti v tom obvykle pomohou. A abyste neztráceli čas prohlížením programů, krátce vám o nich řekneme.

Přednáška 14.

Návrh uživatelského rozhraní. Základní principy a fáze návrhu uživatelského rozhraní: výběr struktury dialogu, vývoj dialogového skriptu, definování a umístění vizuálních komponent. Flexibilní rozhraní. Nástroje uživatelské podpory, systémy nápovědy

Uživatelské rozhraní Je soubor informačního modelu problémové oblasti, prostředků a metod interakce uživatele s informační model, jakož i komponenty, které zajišťují vytvoření informačního modelu v průběhu práce softwarový systém (snímek 14.1) .

Informační model je chápán jako podmíněné znázornění problémové oblasti, formované pomocí počítačových (vizuálních a zvukových) objektů, které odrážejí složení a interakci skutečných složek problémové oblasti.

Prostředky a metody interakce s informačním modelem jsou určeny složením hardwaru a softwaru dostupného uživateli a povahou řešeného problému. Efektivitu práce uživatele určuje nejen funkčnost hardwaru a softwarové nástroje, ale také dostupnost těchto funkcí pro uživatele. Úplnost využití potenciálních schopností dostupných zdrojů zase závisí na kvalitě uživatelského rozhraní.

Kvalita uživatelského rozhraní je nezávislou charakteristikou softwarového produktu, jejíž význam je srovnatelný s ukazateli, jako je spolehlivost a účinnost používání výpočetních zdrojů.

Podle výzkumu provedeného společností Xerox a jejím spolupracovníkem Davidem Liddleem se uživatelské rozhraní skládá z následujících hlavních komponent, představovaných jako ledovec.

Podle této studie se rozhraní skládá ze tří hlavních částí - prezentace informací uživateli, interakce a vztah mezi objekty. „Viditelná“ část ledovce je navíc mnohem menší než „neviditelná“ skrytá část (snímek 14.2). Vrchol ledovce - informace pro uživatele (barva, animace, zvuk, tvar objektů, umístění informací na obrazovce, grafika) jsou pouze 10% a v žádném případě nejsou nejdůležitější součástí uživatelského rozhraní. Další částí uživatelského rozhraní (30% modelu designéra) je technika komunikace s uživatelem a zpětná vazba od něj. A konečně spodní část ledovce (60%) návrhářova modelu - nejdůležitější částí jsou vlastnosti objektů a vztahy mezi nimi.

14.1. Základní principy návrhu uživatelského rozhraní

Hlavní výhodou dobrého uživatelského rozhraní je to uživatel má vždy pocit, že software obsluhuje a ne software jej ovládá.

Aby uživatel vytvořil takový pocit „vnitřní svobody“, musí mít rozhraní řadu vlastností. (snímek 14,4) :

Přirozenost rozhraní.

Konzistence rozhraní.

Uživatelská přívětivost rozhraní (zásada „odpuštění uživateli“)

Princip „zpětné vazby“.

Jednoduchost rozhraní.

Flexibilita rozhraní.

Estetická přitažlivost.

Přirozenost rozhraní. Přirozené rozhraní je takové, které nenutí uživatele významně měnit své obvyklé způsoby řešení problému. To zejména znamená, že zprávy a výsledky vytvářené aplikací by měly být vysvětlující.

Konzistence rozhraní. Konzistence umožňuje uživatelům přenášet stávající znalosti na nové úkoly, rychleji zvládat nové aspekty a soustředit tak pozornost na řešený problém, místo aby ztráceli čas porozuměním rozdílům v používání určitých ovládacích prvků, příkazů atd. Zajištěním kontinuity předchozích znalostí a dovedností zajišťuje konzistence rozhraní rozpoznatelné a předvídatelné.

Konzistence je důležitá pro všechny aspekty rozhraní, včetně názvů příkazů, vizuální prezentace informací a chování interaktivních prvků. K implementaci vlastnosti konzistence do vytvořeného softwaru je nutné vzít v úvahu jeho různé aspekty.

Konzistence v rámci produktu.Stejný tým by měl vykonávat stejné funkce, ať se setkají kdekoli, a stejným způsobem.

Konzistence napříč výrobním prostředím.Udržováním konzistence s rozhraním poskytovaným operačním systémem (například Windows OS) může uživatelská aplikace čerpat z jeho znalostí a dovedností, které dříve získal při práci s jinými aplikacemi.

Důsledné používání metafor.Pokud chování nějakého softwarového objektu jde nad rámec toho, co je obvykle míněno jeho odpovídající metaforou, může mít uživatel potíže s prací s takovým objektem.

Uživatelská přívětivost rozhraní (zásada „odpuštění uživateli“). Uživatelé se obvykle naučí specifika práce s novým softwarovým produktem pomocí pokusů a omylů. Efektivní rozhraní musí tento přístup zohlednit. V každé fázi práce by měl umožňovat pouze příslušnou sadu akcí a varovat uživatele před situacemi, kdy mohou poškodit systém nebo data; je ještě lepší, pokud má uživatel příležitost zrušit nebo opravit provedené akce.

I s dobře navrženým rozhraním mohou uživatelé dělat nějaké chyby. Tyto chyby mohou být jak „fyzického“ typu (náhodný výběr nesprávného příkazu nebo dat), tak „logického“ (nesprávného rozhodnutí o výběru příkazu nebo dat). Efektivní rozhraní by mělo být schopné zabránit situacím, které pravděpodobně povedou k chybám. Rovněž musí být schopen přizpůsobit se potenciálním chybám uživatelů a usnadnit proces eliminace následků těchto chyb.

Princip „zpětné vazby“. Zpětná vazba by měla být vždy poskytována pro akce uživatelů. Každá akce uživatele by měla obdržet vizuální a někdy i zvukové potvrzení, že software přijal zadaný příkaz; druh reakce, pokud je to možné, by měl brát v úvahu povahu prováděné akce.

Zpětná vazba je účinná, pokud je implementována včas, tj. co nejblíže bodu poslední interakce uživatele se systémem. Když počítač zpracovává příchozí úlohu, je užitečné poskytnout uživateli informace týkající se stavu procesu a také možnosti v případě potřeby proces přerušit. Nezkušeného uživatele nic nezaměňuje více než zamčená obrazovka, která na jeho akce nijak nereaguje. Typický uživatel vydrží jen několik sekund čekání na odpověď svého elektronického „partnera“.

Jednoduchost rozhraní. Rozhraní by mělo být jednoduché. To neznamená přílišné zjednodušení, ale poskytnutí snadnosti při jeho studiu a používání. Kromě toho musí poskytovat přístup k celému seznamu funkcí poskytovaných touto aplikací. Realizace přístupu k bohatým funkcím a poskytování snadné obsluhy si navzájem odporují. Cílem návrhu efektivního rozhraní je tyto cíle vyvážit.

Jeden z možné způsoby zjednodušení - prezentace informací na obrazovce, minimum potřebné pro uživatele k dokončení dalšího kroku úkolu. Zejména je třeba se vyhnout podrobným názvům příkazů nebo zprávám. Špatné nebo nadbytečné fráze ztěžují uživateli získání relevantních informací.

Dalším způsobem, jak vytvořit jednoduché, ale efektivní rozhraní, je uspořádat a prezentovat prvky na obrazovce s ohledem na jejich sémantický význam a logický vztah. To vám umožní použít asociativní myšlení uživatele v procesu.

Dalším způsobem, jak zvládnout složitost zobrazovaných informací, je použití důsledné zveřejňování (dialogová okna, části nabídek atd.). Postupné zveřejňování předpokládá takové uspořádání informací, ve kterém je v každém okamžiku na obrazovce pouze ta jeho část, která je nezbytná k dokončení dalšího kroku. Snížením množství informací poskytovaných uživateli, čímž se sníží množství informací, které mají být zpracovány. Příkladem takové organizace je hierarchické (kaskádové) menu, jehož každá úroveň zobrazuje pouze ty položky, které odpovídají jedné položce vybrané uživatelem na vyšší úrovni.

Jedním z metodických základů organizace řízení procesu zpracování je použití „metafor“ - smysluplných analogů cíleného zpracování dat, ale v oblastech běžnějších pro člověka než automatizace.

Například metafora „desktop“ naznačuje, že rozhraní poskytuje uživateli možnost přístupu k mnoha různým zdrojům informací a umožňuje mu snadno přepínat z jednoho zdroje na druhý (tj. „Přesouvat papíry na stole“), měnit jeden typ úkolu (tabulkový procesor) ) do jiného (systém přípravy textu). V tomto případě má uživatel také přístup k jakýmkoli jiným prostředkům, včetně pomocných (kalkulačka, hodiny atd.).

Uživatel může přenést informace z jednoho dokumentu do druhého zahrnutím požadovaných částí jednoho dokumentu na příslušná místa v jiném dokumentu. To je spojeno s jinou metaforou - „schránkou“. Před příchodem automatizovaných systémů pro zpracování textu existoval tradiční způsob, jak usnadnit rozvržení: vložení do výřezu namísto přepisování stránky. Rozhraní WIMP poskytují podobné možnosti vyjmutí a vložení, ale schránka, do které je vložen vyjmutí, umožňuje podle potřeby vložit tolik kopií datových položek.

Metaforický princip je také základem technologie WISIWIG - okamžitá vizualizace výsledků akcí na obrazovce. To znamená, že obrazovka musí simulovat způsob tisku, a pokud chce uživatel tisknout část textu kurzívou, musí být na obrazovce napsán kurzívou. Pokud je soubor zničen, uživatel uvidí, že soubor zmizí ze seznamu souborů zobrazených na obrazovce. Rozhraní přirozeně poskytuje uživateli informace o stavu objektu a potvrzuje, že byla provedena akce. Můžeme říci, že tato metafora přesněji odpovídá vzorci Uvidíte, co jste získali v důsledku svých činů “.

Flexibilita rozhraní. Flexibilitou rozhraní je jeho schopnost brát v úvahu úroveň školení a produktivitu uživatele. Vlastnost flexibility implikuje schopnost změnit strukturu dialogu a / nebo vstupních dat. Flexibilní koncept (adaptivní) rozhraní je v současné době jednou z hlavních oblastí výzkumu interakce lidí a počítačů. Hlavním problémem není to, jak uspořádat změny v dialogu, ale jaká znamení by měla být použita k určení potřeby změn a jejich podstaty.

Estetická přitažlivost. Správné vizuální znázornění použitých objektů poskytuje přenos velmi důležitých doplňujících informací o chování a interakci různých objektů. Zároveň je třeba si uvědomit, že každý vizuální prvek, který se objeví na obrazovce, potenciálně vyžaduje pozornost uživatele, která, jak víte, není neomezená.

Kvalitu rozhraní je obtížné kvantitativně posoudit, ale jeho víceméně objektivního posouzení lze dosáhnout na základě následujících konkrétních ukazatelů.

Čas potřebný k tomu, aby konkrétní uživatel dosáhl dané úrovně znalostí a dovedností k používání aplikace.

Zachování získaných pracovních dovedností po určité době (například po týdenní přestávce musí uživatel provést určitou sekvenci operací v daném čase).

Rychlost řešení problému pomocí této aplikace; v tomto případě by neměla být hodnocena rychlost systému a ne rychlost zadávání dat z klávesnice, ale čas potřebný k dosažení cíle řešeného problému. Na základě toho lze hodnotící kritérium pro tento indikátor formulovat například takto: uživatel musí zpracovat nejméně 20 dokumentů za hodinu s chybou nejvýše 1%.

Subjektivní spokojenost uživatele při práci se systémem (kterou lze kvantitativně vyjádřit v procentech nebo v hodnocení na n-bodové škále).