it-swarm-eu.dev

Jak definovat interakce a animace rozšiřitelným způsobem?


Celá otázka, shrnutá pro odpovědnost:

  • Jak by bylo nejlepší pro návrháře definovat opravdu komplexní UI?
  • Bylo by dobré zmapovat, jak mentální tvůrčí proces funguje, na nástroje?

Jednoho dne chci udělat lepšího návrháře uživatelského rozhraní pro desktopové aplikace, než jaký v současné době existuje (je to dlouhodobý projekt), a já se již pokouším shromáždit myšlenky o tom, zda je možné nebo nemít skutečně rozšiřitelný rámec.

Hlavním problémem, který vidím, je, že musíte být schopni iterovat mezi abstrakcemi na vysoké úrovni, jako jsou interakce mezi součástmi, a schopnostmi na nízké úrovni, jako je použití rozostření na poloprůhledný povrch. To vyžaduje dobré modely toho, z čeho se uživatelské rozhraní skládá.

„Animace“ by mohla být cokoli, od použití efektů na obrázek (jako je rozostření nebo šum atd.), Přes překlad objektů ve 3D, až po odlesky světla, které cestují po cestě, zatímco je vyplňují, k čemukoli, co si dokážete představit .

Interakce jsou také složité. Možná nechcete, aby se jedna animace odehrávala, pokud probíhá další, nebo pokud některá data nejsou přítomna atd., Nebo možná jen spouští nějakou akci na nějaké události.

Definování všeho z kódu, ať už je jakýkoli kód, není ideální. Chci názory na to, jak by taková věc mohla být „ideální“, nebo prostě lepší, vizuálně, z pohledu designéra.

Jinými slovy , jak by designové prostředí UI/UX vaše sny jsou?

(poznámka: tyto problémy se týkají také designu webových stránek nebo mobilních telefonů, takže pokud máte názory v těchto oblastech, jsou také vítáni).

Aktualizace:

Odhalím několik myšlenek o tom, jak by se to dalo udělat.

V první řadě je jedním z cílů úplné oddělení práce designéra od práce programátora.

Věřím, že UI a UX by měly být zváženy před napsáním jakékoli aplikační logiky - někdy viděním GUI lze lépe zjistit, které funkce chybí a které jsou zbytečným nepořádkem.
Návrhář by tedy měl být schopen vytvořit komplexní interakce v uživatelském rozhraní, i když toto uživatelské rozhraní nevykonává žádný kód. To také usnadňuje ladění uživatelského rozhraní.

Aplikace tedy vystaví rozhraní API uživatelskému rozhraní, které se skládá z:

  • „Akce“ (s parametry nebo bez parametrů)
  • "Vlastnosti"
  • „Požadavky“ (tj. Funkce s parametry. Funkce bez parametrů budou vypadat jako vlastnosti)

Návrhář bude mít také nástroje, které poskytují nesmyslné zdroje dat v přizpůsobeném formátu, takže by mohl databázind "falešné vlastnosti" na ladicí konfiguraci, podobně jako Lorem Ipsum .

Vlastnosti vystavené návrháři nemohou být žádným objektem - buď to bude množství jednoduchých obecných datových typů, jako například „Text“ (řetězec), Integer, „Decimal“, nebo dokonce „Image“ (jednoduše myslím jednoduché pro projektanta , více o tom, jak řešit problémy s výkonem později), pole nějakého jednoduchého typu nebo "složená data", podobné pojmu Tuples =, k seskupení několika datových typů nebo polí.
To znamená, že designér může jednoduše požádat o data, která potřebuje, nebo snadno vygenerovat falešná data pro účely ladění.

A co výkon?

Všichni víme, že generování stejného obrazu znovu a znovu by bylo drahé, ale návrhář nemá o tom přemýšlet příliš. Místo toho by opakovaný požadavek na tentýž prvek uložil mezipaměť zprostředkovatel mezi aplikačním kódem (vytvořeným programátorem) a uživatelským rozhraním v API.

Pořád přemýšlím o podrobnostech implementace tohoto, ale bude to znamenat, že programátor by mohl říct, že API, které volá stejnou funkci se stejnými parametry znovu a znovu, vygeneruje stejný výsledek a API bude inteligentně ukládat výsledky této funkce do mezipaměti.
V žádném případě by to mohlo být provedeno, bude to pro projektanta transparentní, protože to je cíl.

O některých koncepcích, o kterých uvažuji pro složení uživatelského rozhraní:

(zcela samovysvětlující pojmy)

Plochy: Základní komponenty uživatelského rozhraní, které mají vlastnosti a tvar a jsou vázány na materiál. Interně zastoupena ve vektorovém formátu.
Materiál: Sdílený prvek v uživatelském rozhraní, který může na jednom místě definovat styl několika prvků (například výplně přechodu nebo textury, ohraničení) , vržené stíny atd.).
Komponenty: Kousky uživatelského rozhraní s vlastní logikou, které by mohly dělat pokročilejší věci než povrchy, jako je generování částicové efekty , propojení s jinými komponenty vzájemně interaktivním způsobem a dokonce generování jejich vlastních dílčích složek. Díky tomu budou některé efekty jako animovaný kruh načítání kruhů ( jako tento ) jednodušší. Budou obsahovat skriptovací jazyk, možná Javascriptový stroj.
Efekty/Přechody: Tyto jsou zamýšleny jako spouštěné jinými částmi uživatelského rozhraní nebo změnami stavu. Věci jako ButtonFoo.Glow nebo PanelBar.MoveToLeft pojmenovaný a navržený návrhářem a seskupený do jmenného systému.
Stavy: Jedná se o aktuální stav uživatelského rozhraní a lze je použít pomocí spouště.
Spouštěče: Tyto vystřelí určité efekty nebo přechody.
Podmínky: Toto jsou kontroly, které lze připojit ke spouštěčům.

Návrhář bude také schopen vystavit data programátorovi pomocí systému, který vypadá podobně jako spotřebované vlastnosti ze strany návrháře.

7
Camilo Martin

Myslím, že uživatel může být zaměřen na jednu věc najednou: může to být nějaký pohled v hierarchii pohledu (1), jinak, když máme mnoho interakčních pohledů současně, měl by být tento pohled (bude dobrý) nezávislý (2) ). Takže v případě (1) může aplikace ovládat aktuální zobrazení stavu a v případě (2) aplikace nemusí synchronizovat stav nezávislých pohledů.

Například vývojář by měl implementovat konečně řízený stroj řízený událostmi , aby zpracoval stav všech závislých pohledů, nebo by měl pro přehrávání animací používat spouštěče uživatelského rozhraní .

1
igor