Pre každý stav pomenujte situáciu, oznámte ju aj asistívnej technológii, zachovajte dáta a ponúknite bezpečnú akciu: čakať, zopakovať, upraviť alebo kontaktovať podporu.
Rozhranie netvorí iba ideálna obrazovka s kompletnými dátami. Používateľ čaká na sieť, otvorí prázdny účet, stratí oprávnenie, zadá neplatný vstup alebo narazí na výpadok služby. Ak systém zobrazí len spinner, prázdnu bielu plochu či technický kód, človek nevie, či má čakať, skúsiť znova alebo kontaktovať podporu.
Kvalitný stav vysvetľuje, čo systém vie, zachováva bezpečne vykonanú prácu a ponúka primeraný ďalší krok. Nesmie sľubovať úspech, kým server operáciu nepotvrdil, ani odhaľovať interné bezpečnostné detaily. Stav treba navrhnúť ako súčasť funkcie a otestovať pri pomalej sieti, opakovanej požiadavke, strate relácie aj asistívnej technológii.
Stavový model vzniká spolu s používateľskou cestou
Pre každú obrazovku spíšte počiatočný, načítavací, prázdny, čiastočný, úspešný, chybový, offline a neoprávnený stav podľa relevance. Rozlíšte chybu používateľa, sieťový problém, obchodné pravidlo a interné zlyhanie. Každá situácia potrebuje iný text a obnovu. Jedno univerzálne „Niečo sa pokazilo“ skrýva potrebné rozhodnutie.
Určte, ktoré dáta možno zachovať, akú operáciu možno bezpečne zopakovať a kedy hrozí duplicita. Pri platbe, objednávke alebo odoslaní formulára musí rozhranie vedieť rozlíšiť neúspech od neznámeho výsledku. Ak stav nemožno potvrdiť, nevyzývajte používateľa bezhlavo opakovať kritickú akciu.
- zdroj a typ vzniknutého stavu
- dáta, ktoré sa majú zachovať
- bezpečnosť opakovania operácie
- vlastník technickej a obsahovej reakcie
Načítavanie má oznámiť rozsah a neblokovať zbytočne
Krátku operáciu možno indikovať lokálne pri prvku, dlhšia potrebuje zrozumiteľný priebeh alebo aspoň informáciu, čo sa načítava. Spinner bez textu a bez konca neukazuje, či aplikácia pracuje. Skeleton má zodpovedať výslednému rozloženiu a nesmie vytvárať falošný obsah, ktorý sa po načítaní dramaticky presunie.
Zablokujte iba ovládanie, ktoré by konfliktne menilo prebiehajúcu operáciu. Tlačidlo po aktivácii oznámi stav a zabráni nechcenému dvojitému odoslaniu, no zvyšok stránky môže zostať použiteľný. Pri prekročení očakávaného času ponúknite vysvetlenie, zrušenie alebo bezpečný retry. Zmenu oznámte bez opakovaného rušenia čítačky obrazovky.
Prázdny stav vysvetľuje, prečo nič nevidno
Rozlišujte nový účet bez dát, vyhľadávanie bez výsledku, aktívny filter bez zhody a chýbajúce oprávnenie. Každý prípad potrebuje inú správu. Novému používateľovi ukážte prvý zmysluplný krok, pri nulovom výsledku navrhnite úpravu filtra a pri oprávnení vysvetlite, koho bezpečne kontaktovať.
Nevypĺňajte prázdnu obrazovku generickou ilustráciou bez informácie. Príklad môže pomôcť pochopiť budúci obsah, musí však byť jasne označený a nesmie vyzerať ako skutočný záznam. Primárna akcia má byť dostupná aj klávesnicou a jej názov má povedať, čo vytvorí alebo zmení.
- nový účet bez prvého záznamu
- filter alebo vyhľadávanie bez zhody
- obsah skrytý nedostatočným oprávnením
- dáta odstránené alebo dočasne nedostupné
Chyba ponúka diagnostiku primeranú používateľovi
Správa má pomenovať neúspešnú úlohu, to, čo sa zachovalo, a možný ďalší krok. Technický identifikátor môže pomôcť podpore, no zobrazte ho oddelene od ľudského vysvetlenia. Neodhaľujte stack trace, databázové názvy, tokeny ani bezpečnostné pravidlá. Pri citlivej operácii neprezraďte, či konkrétny účet existuje.
Ak je retry bezpečný, zachovajte kontext a umožnite ho na tom istom mieste. Pri opakovanom zlyhaní ponúknite alternatívu a kontakt s identifikátorom prípadu. Chyba nemá automaticky presmerovať na domovskú stránku a zahodiť prácu. Focus presuňte alebo stav oznámte podľa významu tak, aby používateľ rozumel zmene.
Úspech, offline režim a regresné testy uzatvárajú cyklus
Úspešný stav potvrďte až po autoritatívnej odpovedi systému. Uveďte, čo sa stalo, kde výsledok nájsť a či nasleduje ďalší krok. Toast, ktorý rýchlo zmizne, nemusí stačiť pri dôležitej operácii. Pri offline režime jasne označte lokálne uložené zmeny a stav ich budúcej synchronizácie.
Testujte pomalé a prerušené spojenie, timeout, opakovanie, návrat, obnovenie, dvojitú aktiváciu, stratu relácie a nedostupnú závislosť. Overte klávesnicu, focus a oznámenia čítačky obrazovky. Logujte technické zlyhania bez citlivých vstupov a spájajte ich s anonymným typom úlohy, aby tím opravoval príčiny, nie iba text.
- potvrdenie uloženia z autoritatívneho zdroja
- viditeľný výsledok aj po zmiznutí toastu
- jasný stav lokálnej a serverovej kópie
- test bezpečného opakovania kritickej akcie
Časté otázky
Ako dlho môže zostať iba spinner?
Pevný čas neplatí pre každú úlohu. Pri citeľnom čakaní vysvetlite, čo sa deje, a podľa možnosti ponúknite priebeh, zrušenie alebo bezpečné zopakovanie.
Má chyba obsahovať technický kód?
Môže mať bezpečný referenčný identifikátor pre podporu. Nemá zobrazovať interný stack trace, citlivé údaje ani technický detail, ktorý používateľovi nepomôže.
Je toast vhodný na potvrdenie úspechu?
Pri drobnej vratnej akcii môže stačiť. Pri platbe, objednávke alebo odoslaní má zostať stabilné potvrdenie s výsledkom a ďalším krokom.
Zdroje a ďalšie čítanie
Web developer zo Spišskej Novej Vsi. Venuje sa WordPressu, WooCommerce, vlastným pluginom, API integráciám, webovým aplikáciám a praktickým AI automatizáciám.
