On je problém nejen s použitou technologií. Ale hlavně s logikou. Viz dále.
S logikou žádný problém není. O čemž svědčí i to, že spousta e-shopů (na příkladu e-shopu jste to ukazoval) práci ve více záložkách zvládá.
Začnu od konce – potvrzení (třeba objednávky). Tam vůbec není co řešit, uživatel potvrzuje vždy to, co vidí. Logika je tedy jasná, implementovat se to dá různě.
S tím přidáváním a odebíráním položek v košíku to pro programátora může být složitější. Ale uživatelské rozhraní nemá navrhovat programátor, ale UX designer, a pro něj jsou dvě možná řešení. To lepší řešení je, že se stav košíku bude na pozadí synchronizovat – takže když odeberu zboží v jedné záložce, odebere se i ve všech ostatních. Druhé řešení, z hlediska UX o něco horší ale zase jednodušší na implementaci, je to, že uživatel vždy pracuje s tím, co vidí. Takže když má v košíku pět kusů, zduplikuje záložky, v jedné záložce pět kusů ubere a v druhé záložce jeden kus přidá, bude mít v té druhé záložce v košíku šest kusů. Nikdy žádný uživatel nepředpokládá, že když vidí v košíku 5 kusů a klikne na tlačítko „+“, že dostane chybovou zprávu nebo že bude mít v košíku 1 kus.
Trochu komplikovanější implementace to bude akorát v případě, kdy přidání do košíku znamená rezervaci daného zboží (tj. máte po určitou dobu garanci, že zboží, které máte v košíku, vám nikdo „nevyfoukne před nosem“). Nicméně i tam musí být zachováno pravidlo, že pokud uživateli zobrazuji v košíku rezervaci, musí ta rezervace opravdu platit.
Takže pokud to chcete udělat opravdu pořádně, je to poměrně jednoduché. Nenechávejte uživatelské scénáře vymýšlet backendové programátory, ale nechte to na UX designerech. Ti navrhnou velmi jednoduchá pravidla, kterými se bude UI řídit. Díky tomu, že budou jednoduchá, budou je chápat i uživatelé a budou spokojení. Přičemž nejdůležitější z těch pravidel bude „platí to, co uživatel vidí“.
Přičemž v porovnání s e-shopem je běžné internetové bankovnictví jednodušší, protože v IB není ta zásadní limitace e-shopu, totiž sklad s fyzickým stavem zboží, navíc uživatelé považují za samozřejmé, že se s bankou pracuje v transakcích. Takže když má uživatel na účtu 100 000 Kč a dá příkaz k úhradě 5 000 Kč, očekává jen to, že se úhrada provede, pokud má na účtu dost peněz. Ale neočekává, že po provedení toho příkazu bude na účtu 95 000 Kč – protože ví, že mezitím může přijít příchozí platba nebo odejít jiná odchozí platba. Takže jediné, co se od banky očekává, je to, že seřadí požadavky nějak za sebe, u každého požadavku zkontroluje, zda je možné jej provést, provede ho, aktualizuje stavy a pokračuje na další požadavek. Konkrétně – pokud uživatel ve dvou session zadá dva příkazy k úhradě ale má nízký zůstatek účtu, takže není možné provést oba dva příkazy, není to nic, s čím by se banka neuměla vypořádat. Protože to samé může nastat i tak, že uživatel zadá jediný příkaz k úhradě, ale než ho stihne podepsat, zůstatek na účtu se sníží. A to samé může nastat i úplně bez internetového bankovnictví. Takže banky tyhle „problémy“ umí řešit už stovky let. Naopak svět IT se v mnohém inspiroval v tom, jak to dříve banky řešily „na papíře“.
Zobrazit příspěvky
