Postupné ověřování a zveřejňování
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:
- Na každé kartě vytvořte tlačítka „použít“, takže stav lze uložit pouze pro vlastnosti, které může uživatel vidět právě teď. Pokud by to mělo za následek neplatný stav aplikace, upravte své karty tak, aby uživatelé měli seskupeny vlastnosti, které mohou budou uloženy nezávisle na sobě.
- Pokud to nemůžete udělat, můžete zvýraznit karty ikonou „neplatný“ a barvou, aby bylo možné označit vlastnosti na této kartě. Zatímco jsou všechny karty neplatné, tlačítko „použít“ je deaktivováno. Pokud na tlačítko kliknete, můžete zvážit přidání upozornění, aby se zobrazila zpráva oznamující, že stále existují chyby. Na každé kartě se zobrazí souhrny toho, co je špatně, na rozdíl od toho, co má zastřešující shrnutí.
- Globální shrnutí by mohlo fungovat, ale váhám jej navrhnout, protože se zdá, že by tam nebylo okamžitě zřejmé místo, kde by se to dalo, a pokud tomu tak není, všimnou si uživatelé?
- Jak jsou seskupeny vlastnosti? Pravděpodobně funkčně? Zkuste se na ně dívat z jiného úhlu, například pravděpodobností použití. Toto je část toho, jak Microsoft přistoupil k designu pásu karet pro své produkty Office 2007. Pehaps byste mohli navrhnout své karty takovým způsobem, že většina uživatelů si bude muset pohrávat s vlastnostmi na první nebo okamžitě viditelné kartě a ostatní karty lze považovat za „pokročilé“ nebo kontextové.
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:
- Uživatel si uvědomí, že jeho vstup byl opraven.
Například, pokud zafixujete hodnotu, můžete pole na sekundu zablikat. - Můžete rozumně hádat, co uživatel opravdu myslel.
Například si vezměte výběr barvy, se kterým jsem včera zápasil. Chtěl jsem pár prvků, které by se shodovaly s těmi z jiného webu, a tak jsem si dal hexadecimální hodnoty a zkopíroval je do malých ad-hoc textových polí. První hodnota byla#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.