Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : MA: Návrh mikrointerakcí
MA: Návrh mikrointerakcí
Kód úlohy

Standardní kód úlohy v MBI.

:
U466J
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Franek, O. (etnetera)
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.3
Charakteristiky úlohy

Charakteristiky úlohy

1. Obsah úlohy
  • Častým problémem softwarových projektů je rozdílnost mezi navrhovaným a výsledným produktem . K vývojáři se dostává prototyp aplikace, ve kterém jsou navržené a popsané jen ty nejdůležitější interakce. Ale spousta drobných detailů zůstává na interpretaci vývojářem. Pro vývojáře by bylo komplikované, kdyby měl u každého detailu zastavit svou práci a napsat e-mail designerovi aplikace. Takový proces by byl pomalý a pravděpodobně by dlouho nevydržel.
  • I ty nejmenší interakce je ale možné dokumentovat , zlepšit tak komunikaci mezi designerem a vývojářem a zajistit větší promyšlenost výsledného produktu bez zbytečných nákladů na několikanásobné přepracovávání aplikace.
2. Co je to mikrointerakce
  • Poslední úrovní při navrhování aplikace jsou tzv. mikrointerakce. Podle Dana Saffera (2014) jsou mikrointerakce ohraničené okamžiky při práci s produktem , které souvisí pouze s jedním konkrétním případem užití. Pokaždé, když uživatel mění nastavení, synchronizuje data, nastavuje budík, přihlašuje se do aplikace nebo například dá něčemu „like“, provádí mikrointerakci. Ve fázi návrhu aplikace představují mikrointerakce poslední krok – pro jejich otestování je potřeba připravit detailní prototyp. Investice do přípravy detailního prototypu předpokládá, že základní principy, na kterých je aplikace postavená, jsou ověřené a funkční .
  • Mikrointerakce jsou funkční, interaktivní detaily produktu. Detaily, které můžou práci s produktem zjednodušit a udělat ji příjemnější. Některé mikrointerakce jsou pro uživatele prakticky nebo doslova neviditelné . A některé mikrointerakce jsou důvodem, proč si někdo produkt vůbec koupí. Mikrointerakce se od funkcí odlišují jak velikostí, tak rozsahem . Funkce se skládají z více případů užití, jsou časově náročnější a vyžadují pozornost uživatele. Na druhé straně mikrointerakce jsou jednoduché, krátké a téměř bez námahy pro uživatele. Hudební přehrávač je komplexní funkce, zatímco úprava hlasitosti je mikrointerakce uvnitř této funkce.
2.1. Příklady mikrointerakcí
  • Mikrointerakce jsou vhodné pro následující situace :
    • Splnění jednoduchého úkolu, jako třeba nastavení budíku,
    • Propojení více zařízení,
    • Ovládání probíhajícího procesu, jako třeba přepnutí kanálu v televizi,
    • Úprava nastavení,
    • Prohlížení nebo tvorba malého kousku obsahu, jako třeba statusu na sociální síti,
  • Vypnutí nebo zapnutí určité funkce.
  • Příkladem konkrétních mikrointerakcí mohou být následující (Babich 2016):
    • Potvrzující zpráva, která informuje uživatele o přidání položky do košíku,
    • Použití gesta přejetí prstem po displeji ze shora dolů pro obnovení obsahu obrazovky,
    • Animace uživatelského rozhraní, která slouží k potvrzení akce uživatele, např. při stisknutí tlačítka.
2.2. Struktura mikrointerakcí
  • Každá mikrointerakce se skládá ze 4 částí: spouštěče (trigger), pravidel (rules), zpětné vazby (feedback) a smyček (loop) a módů (mode ), . Spouštěč mikrointerakci zahajuje. Pravidla rozhodují, co se stane a zpětná vazba dává uživatelům najevo, co se děje. Smyčky a módy definují meta-pravidla mikrointerkace. Struktura mikrointerakcí vychází z principů user-centered design , viz (M533 ).
  • Spouštěč - s pouštěče se rozdělují na manuální a systémové . Manuální spouštěče vyžadují přímou akci uživatele, systémové spouštěče jsou iniciovány ze strany nějakého systému. Manuální spouštěče jsou navrhovány na základě potřeby uživatele. Co, kdy a v jakém kontextu chce uživatel udělat, rozhoduje o tom, kde by měl být manuální spouštěč dostupný. Manuální spouštěč tak může být dostupný z jakéhokoliv místa – objevit se, pokud jsou naplněny určité podmínky, nebo být ukrytý jen v určité části aplikace. Každý manuální spouštěč se skládá ze tří komponent – ovladače, jednotlivých stavů ovladače a popisku – textu nebo ikony . Ne všechny spouštěče jsou ale manuální.
  • Systémové spouštěče zahájí mikrointerakci, jsou-li splněné konkrétní podmínky, které nevyžadují vědomý zásah uživatele. Typické podmínky vedoucí k systémovému spouštěči jsou:
    • Chyba – pokud v systému nastane nějaká chyba,
    • Poloha – změny v poloze uživatele produktu mohou vést ke spuštění systémového spouštěče,
    • Příchozí data – nový e-mail, dostupná softwarová aktualizace nebo změna jasu v okolí přístroje jsou všechno příklady příchozích dat, které obvykle spouští mikrointerakci,
    • Vnitřní data systému – změna stavu baterie nebo čas mohou být spouštěči.
  • Pravidla - v centru každé mikrointerakce je set pravidel , který řídí, jakým způsobem mikrointerakce funguje . Pravidla tvoří zjednodušený netechnický model , popisující fungování mikrointerakce. Saffer (2014) doporučuje při definici pravidel začít u cíle mikrointerakce. Cíl by neměl představovat pouze jeden krok v procesu, ale jeho konečný stav . Cílem přihlašovací mikrointerakce není zadání uživatelského jména a hesla, ale přihlášení uživatele do aplikace. Všechna pravidla dané interakce by měla vést k dosažení definovaného cíle . Pro lepší ilustraci fungování mikrointerakce je možné pravidla popsat do diagramu, . Pravidla zároveň nejsou od toho, aby limitovala akce uživatele, ale aby vedla uživatele k cíli mikrointerakce. Pravidla definují např.:
    • Jak mikrointerakce reaguje na aktivaci spouštěče.
    • Jak může uživatel mikrointerakci ovlivnit.
    • Jak za sebou jednotlivé akce navazují.
    • Jaká data mikrointerakce používá a odkud přicházejí.
  • Zpětná vazba - má v mikrointerakcích důležitou roli – pomáhá uživatelům pochopit, jaké má fungování mikrointerakce pravidla. Pokud uživatel stiskne tlačítko, něco by mělo indikovat, že: tlačítko bylo stisknuto a následkem stisknutí tlačítka se něco stalo. Uživatel nepotřebuje vědět přesně, jak mikrointerakce funguje, ale měl by pomocí zpětné vazby dostat dostatek informací, aby si mohl vytvořit správný mentální model . Zpětná vazba může mít různé formy: vizuální, zvukovou, hmatovou nebo jejich kombinaci. Uživatel by podle Saffera (2014) měl dostat zpětnou vazbu v těchto případech:*
  • Spustí manuální spouštěč – všechny akce iniciované uživatelem by měly být doprovázeny potvrzením ze strany systému.
    • Systémový spouštěč významně ovlivní stav mikrointerakce.
    • Dostane se na hranici pravidla nebo ho poruší a nastane chyba.
    • Systém není schopen provést zadanou akci.
    • Nějaký proces trvá déle a/nebo je kritický. V takovém případě by měl uživatel vidět ukazatel průběhu tohoto procesu.
  • Zpětná vazba může mít podobně jako samotná mikrointerakce vlastní pravidla ., která definují následující oblasti :
    • Změna kontextu – mění se zpětná vazba, pokud se změní její kontext?
    • Trvání – jak dlouho zpětná vazba trvá?
    • Intenzita – jak intenzivní je efekt spojený se zpětnou vazbou?
    • Opakování – jak často se zpětná vazba opakuje?
  • Módy a smyčky - mód představuje speciální část aplikace , ve které se chová jinak než obvykle . Příkladem může být např. editační mód v aplikaci na prohlížení fotografií. Smyčka je příkaz nebo série příkazů, které se opakují. Módy a smyčky mohou být pro uživatele matoucí a měly by se proto používat jen zřídka (Saffer 2014). Smyčky se rozdělují na 4 druhy:
    • Smyčka omezená počtem o pakování – akce se opakuje x-krát, než je ukončena. Příklad: Aplikace se pokusí 10krát navázat spojení se serverem, než zobrazí chybovou hlášku.
    • Smyčka omezená podmínkou – akce se opakuje, dokud platí určité podmínky. Příklad: je-li připojení k internetu aktivní, aplikace kontroluje dostupnost nových e-mailů každou minutu.
  • Smyčka omezená množstvím – smyčka projde všechny položky v souboru, než se zastaví. Příklad: Aplikace přidá indikátor nepřečtené zprávy za každou nepřečtenou zprávu.
    • Nekonečná smyčka – smyčka, která se opakuje, dokud nenastane nějaká chyba nebo ji něco neukončí.
  • Smyčky zároveň definují, jak se mikrointerakce změní, pokud ji uživatel opět aktivuje v budoucnosti.
3. Dokumentování mikrointerakcí
  • V oboru uživatelské zkušenosti patří mezi běžné výstupy práce designera wireframy a vývojové diagramy . Funkcí wireframu je dokumentovat rozložení funkčních prvků a obsahu na obrazovce. Funkcí vývojového diagramu je zdokumentovat proces průchodu uživatele aplikací. Wireframy a diagramy ale nejsou optimální pro dokumentování mobilních aplikací, které nemají mnoho unikátních obrazovek, ale pouze pár základních obrazovek s proměnlivým obsahem závislým na interakcích uživatele (Laubheimer 2016). Nástrojem spojujícím wireframy a diagramy je tzv. wireflow , .
  • Základní případ užití wireflow je zdokumentování průchodu uživatele aplikací . V každém kroku průchodu je znázorněna obrazovka ve stavu, v jakém ji vidí i uživatel. Jednotlivé interakce vedoucí na další stavy obrazovky jsou propojené šipkami. Wireflow představuje typ statického prototypu . Wireflow je možné rozšířit o detaily jednotlivých mikrointerakcí a vytvořit tak jeden dokument , ve kterém budou popsány následující (Nguyen 2017):
    • Průchod uživatele aplikací,
    • Vizuální design,
    • Interakce uživatele s aplikací.
  • Tento druh statického prototypu Nguyen (2017) nazývá interakční tok (interaction flow). Interakční tok zobrazuje nejen, na jakou obrazovku uživatel přejde, když vyvolá interakci, ale také jaké má daná interakce atributy. Vychází z práce Dana Saffera (2014), a proto u každé interakce dokumentuje její spouštěč, pravidla, zpětnou vazbu a případné smyčky a módy. Pro příklad dokumentace mikrointerakcí v rámci jedné obrazovky aplikace .
  • Příprava interakčního toku zároveň přiměje designera, aby udělal audit použitelnosti navrhovaného rozhraní. Alternativní formou, pomocí které je možné mikrointerakce dokumentovat, je interaktivní prototyp . Nguyen (2017) vysvětluje, že cílem interakčního toku není nahradit interaktivní prototypy, ale doplnit je . Interakční tok je pro předání specifikace vývojářům vhodnějším nástrojem než interaktivní prototyp, protože vývojář by musel interakce v prototypu nejprve objevit, potom nasimulovat a pak přijít na to, co se v aplikaci má opravdu stát. Vývojář si také díky interakčnímu toku může prohlédnout celou aplikaci najednou a vidět vztahy mezi jednotlivými obrazovkami. Interaktivní prototyp je v porovnání se statickým interakčním tokem vhodnější pro uživatelské testování.
4. Jak zahrnout mikrointerakce do produktu
  • Jedním způsobem, jak mikrointerakce zahrnout do návrhu produktu, je v průběhu designování projít celý návrh aplikace a pokusit se identifikovat všechny potenciální mikrointerakce . Tímto způsobem designér sestaví seznam detailů , které může vylepšit. Největší výzvou je podle Saffera (2014) udržení rozsahu mikrointerakcí. Designéři mají obvykle tendenci proměnit je v rozsáhlejší funkce. V takovém případě Saffer doporučuje zredukovat komplikované funkce na základní mikrointerakce, které jsou soustředěné na jeden úkol.
5. Poznámky, reference:
  • Franek, O. (etnetera): Proces tvorby zadání a správy požadavků pro vývoj mobilní aplikace, VŠE, Praha. 2018,
  • LAUBHEIMER, Page, 2016. Wireflows: A UX Deliverable for Workflows and Apps. Nielsen Norman Group [online] [vid. 2017-11-12]. Dostupné z: https://www.nngroup.com/articles/wireflows/ ,
  • NGUYEN, Havana, 2017. An Introduction to Interaction Flows. UX Planet [online] [vid. 2017-11-12]. Dostupné z: https://uxplanet.org/an-introduction-to-interaction-flows-a4f783402529
  • SAFFER, Dan, 2014. Microinteractions: designing with details. 1. ed. Beijing: O’Reilly. Designing with Details. ISBN 978-1-4919-4592-6.