Snažím se najít příklad progresivní validace. Máme uživatelské rozhraní pro vizuální editor, kde uživatel dělá věci, jako je označení rozměrů v pixelech nebo procentech.
Vlastnosti editoru jsou v sadách karet, takže ne všechna pole jsou viditelná současně. Diskutovali jsme o tom, jak a zda provedeme ověření v tomto uživatelském rozhraní.
Vycházím z perspektivy, že: a) Validace je užitečná, protože vytvoří komunikační kanál, kde se uživatel může naučit očekáváním softwaru a „vylepšit“ to, co je potřeba. b) Vždy je lepší označit chyby ověření přímo ve vstupních polích (ať už se souhrn používá jinde, nebo ne), aby uživatelé měli vizuální narážku, co je třeba změnit.
Můj kolega, pro kterého nemám nic jiného než nejvyšší respekt nesouhlasí. Jeho logika je následující: a) Bude vhodnější zabránit některým typům zápisu nebo, v případě některých záznamů, změnit je na vhodnější hodnotu, pokud je neplatná. Například, pokud někdo použije procentuální hodnotu větší než 100, uživatelské rozhraní by resetovalo hodnotu na 100 v případě ztracené fokusace. b) Protože se nacházíme v prostředí karet, některé chyby se uživateli nebudou zobrazovat. Použití souhrnu je zbytečné, protože může existovat „hodně“ chyb při ověřování.
Řekl jsem si, že řešením toho může být postupné odhalení neplatných hodnot. Jako uživatel zadává hodnoty, které mohou být nesprávné, jsou označeny v nějakém shrnutí. Souhrn umožňuje uživatelům navigovat do příslušných polí, aniž by byla viditelná.
Přál bych si, abych byl původní člověk, ale jsem si jistý, že zde existují precedenty. Moje otázky jsou následující:
Něco, co by se přidalo k perspektivám mě nebo mého kolegy?
Nějaké příklady uživatelského rozhraní, jako je tento, se složitou položkou, která progresivně ověřuje?
V současné době se potýkáme se stejným problémem pro stolní aplikaci, i když nikoli na kartě. Můžete vyzkoušet přístup jako je tento:
kde se objeví malá ikona, pokud něco vyžaduje pozornost uživatele. Možná dokonce použít dvě barvy: žlutá pro varování a červená pro věci, které musí být opraveny dříve, než uživatel může jít dále.
Nejlepší věc, kterou můžete v této složité situaci udělat, je vytvořit prototyp tolik uživatelského rozhraní, kolik můžete, a ) vyzkoušejte je na své uživatelské základně a podívejte se, co se stane. Můžete použít HTML v kombinaci s něčím, jako je uživatelské rozhraní jQuery, abyste rychle získali spoustu interaktivních ovládacích prvků a byli rychle připraveni k testování.
Váš systém záložek zní komplikovaně, takže musím navrhnout několik věcí, které je třeba zjednodušit:
Nakonec, a už jsem to řekl, vyzkoušejte svůj design! :-)
Pokud jde o chyby při manipulaci, moje zkušenost byla taková, že pokud zamezíte určitému vstupu, uživatelé budou zmateni. Pokud například ze vstupního pole není zřejmé, že jsou povolena pouze čísla, ale stejně zakážete jakékoli jiné znaky, bude to pro uživatele frustrující - nebudou to prožívat jako inteligentní forma, která se jim snaží pomoci . Doporučuji vám tedy používat čistou mikroskopii, pokud se rozhodnete jít po cestě pomocí událostí a detekce vstupů k automatickému opravování věcí.
Ale to vše je neoficiální - v této oblasti jsem neprovedl žádný výzkum. Namísto toho, abych si to vzal za slovo, se podívejte do knihy Luka Wroblewského, Web Form Design: Filling in the Blanks , a jeho výzkum manipulace s chybami pro několik užitečných poznatků o tom, jak se vypořádat s takovými situacemi (pro Tato instance příspěvek na redesign formuláře pro rezervaci společnosti Apple diskutuje o tom, jak detailně řeší chyby).
Nedávno jsem pracoval na projektu, který narazil na podobný problém. V mém článku „ Minimizing Complexity “ z minulého roku si můžete prohlédnout snímek o tom, jak jsme to vyřešili.
Přemýšlel jsem o případu, kdy se používá shrnutí mnoha chyb a možná i druh prací.
V jakémkoli IDE jako řekněme Visual Studio) existuje potenciál pro nekonečné množství chyb buď při vytváření nebo používání nástrojů pro statickou analýzu při psaní kódu. Obecně jsou tucty nebo stovky souborů a mnoho z nich je otevřeno v karty s jednou nebo dvěma viditelnými současně,
Chyby jsou pak uvedeny v posuvném seznamu, který lze měnit, který se vysune (ve výchozím nastavení) pod hlavní uživatelské rozhraní. To lze provést, jakmile je chyba zachycena. Když kliknete na chybu nebo dvakrát na ni, dostanete se na správné místo a zaostřením ji napravíte - a chyba zmizí ze seznamu, když již není platná.
Ve skutečnosti mnoho z těchto chyb vyžaduje, aby byla akce znovu iniciována uživatelem, ale existuje spousta doplňků statické analýzy, které to provádějí na pozadí a skutečně aktualizují seznam chyb dynamicky při úpravě kódu) .
a) Například, pokud někdo použije procentuální hodnotu větší než 100, uživatelské rozhraní by resetovalo hodnotu na 100 v případě ztracené fokusace.
Dobrý bod, ale pak se musíte ujistit:
#202040
, ale z nějakého důvodu jsem vložil pouze #20204
, který byl okamžitě "opraven" na #020204
. Druhá hodnota, kterou jsem vložil, byla #BCD
(zkratka pro #BBCCDD
), který byl také "opraven" na ... #000BCD
. Povzdech.