it-swarm-eu.dev

Navrhování plynulé pásky pro aplikaci CRUD

Pracuji na navrhování UX stylu Fluent („Ribbon“) pro aplikaci CRUD, která pracuje přes databázi.

Existuje spousta informací o tom, jak navrhnout stuhu pro aplikace založené na dokumentech. pokyny společnosti Microsoft dokonce určují standardní karty a skupiny.

Tyto standardní skupiny se však nezdají být vhodné pro situace bez dokumentů. Například příkaz „Najít“ by měl být ve skupině „Úpravy“:

alt text

Úplně relevantní pro vyhledávání v dokumentu, ale ne pro vyhledávání pro záznam.

Jaké zdroje a/nebo příklady existují pro použití pásu karet pro aplikace bez dokumentů?

Aktualizováno 27/9: Ano, jsem si jistý, že stuha je vhodná pro vyvíjenou aplikaci. Není zaměřen na dokumenty, ale není to čistě CRUD - je to složitá aplikace se spoustou obchodního chování. Bude pro mě snazší uspořádat seminář o aranžování stuhy, pokud mohu poskytnout nějaké pokyny předem - takže doufám v odpovědi na mou původní otázku ohledně zdrojů a příkladů.

14
Bevan

Myslím, že nejlepším příkladem, na který byste se mohli podívat, je MS Access. Všechny příkazy CRUD jsou ve skupině Records a příkaz Find je ve skupině Find!

alt text

14
Tania Gobeil

Pás karet byl navržen pro programy se spoustou příkazů, aplikace CRUD má sklon mít jen několik příkazů, takže možná pásek není tím pravým uživatelským rozhraním.

Můžete dělat, co MS udělali, když navrhli pás karet, vzít co nejvíce lidí, jak můžete (kteří znají pole, nejlépe zákazníci), pak dáte seznam karet/skupin a několik příkazů a nechají je vybrat nejlogičtější místo pro příkaz.

A co je nejdůležitější, nesledujte slepě pokyny (ale také je neignorujte bez dobrého důvodu) a nezaměňujte své osobní preference s tím, co uživatelé považují za intuitivní.

11
Nir

Jsem v téměř stejné situaci, v jaké jste s mou aplikací a navrhujete rozhraní „Ribbon“. Uvažoval jsem o situaci, kdy na pásu karet seskupím příkazy na základě základního „obchodního“ objektu. Jinými slovy, pokud by moje aplikace umožňovala uživatelům spravovat klienty a dodavatele, bylo by rozumné mít skupinu karet vyhrazenou pro klienty, se všemi příkazy, které byste běžně vyvolali, a pak další skupinu karet věnovanou dodavatelům s různými příkazy, které smysl běžet proti těmto objektům\záznamy?

Když jsem to načrtl, ukázalo se (alespoň pro mě), že správa obrazovky by se tímto stylem velmi zkomplikovala, kdybych poskytl pouze jednu stuhu a pravděpodobně by uživatele frustroval více než pomocí.

O nejlepším uživatelském rozhraní, na které jsem narazil a které se touto otázkou zabývá alespoň tangenciálně, je rozhraní aplikace Outlook 2010. Aplikace Outlook spoléhá na samostatný navigační prvek, ale když například přepnete ze Zprávy na Kontakty, změní se pás karet a zobrazí podporované příkazy pro rozhraní, se kterým v současné době pracujete.

Pokud se vrátíte zpět k vašemu příkladu, zdá se, že nalezení konkrétního záznamu by znamenalo, že uživatel zná typ záznamu, který hledá. Může mít smysl nejprve mít navigační systém na místě, aby uživatel mohl navigovat k základnímu objektu (např. Zobrazení Zákazníci) a poté být prezentován se sadou příkazů v pásu karet, které se týkají výhradně Zákazníků. Najít může být ve skupině „Úpravy“, ale jeho kontext se týká pouze zobrazení Zákazníci. Ve skupině Úpravy můžete mít také další příkaz Najít, který se vztahuje k nějaké jiné entitě v aplikaci.

3
Tim Lentine

Také jsem o tom přemýšlel a hlavní myšlenka, kterou jsem vymyslel, je podobná tomu, co popsal Tim Lentine: mít kartu pro každý z mých hlavních obchodních objektů. Na kartu pro něj umístím nejčastěji prováděné příkazy pro tento objekt, například a objekt „Order“ by mohl mít příkazy ke změně stavu (např. Zrušit, odeslat atd.), Účet, poslat fakturu atd.

Přemýšlel jsem však také o tom, jak funguje pás karet ve Windows Live Photo Gallery. Svým způsobem spravuje databázi (fotografií a metadat). Obzvláště zajímavé byly karty Domů, Najít a Zobrazit. Také se mi líbil nápad vyhledávacího/filtračního pole, které se objeví.

photo gallery ribbon

Toto jsou dva hlavní nápady na stuhu pro aplikaci CRUD, o které jsem přemýšlel. Pořád jsem se však ještě nerozhodl.

Po řádcích fotogalerie bych mohl udělat jednu záložku pro načtení konkrétního seznamu dat a odstranění atd. (Plánoval jsem, aby hlavní panel mého okna zobrazil seznam objektů). Možná bych měl ještě jednu pro filtrování/seskupování (podobně jako na záložce „zobrazení“ WLPG). Asi bych měl další kartu pro přehledy. Mohl bych také použít kontextové karty k provádění běžných příkazů na vybraném objektu, jak jsem popsal v prvním odstavci.

2
Benny Jobigan

Nemám rozsáhlé zkušenosti s aplikací CRUD se stuhou, ale tady je několik nápadů ...

Číst - Nechte jednu nebo více karet odevzdat standardnímu způsobu, jakým by uživatel vyhledal konkrétní objekty. Například pokud se jednalo o univerzitní databázi, jedna karta pro studenty/fakulty, jedna pro třídy, jedna pro budovy. Seskupte objekty na kartách podle jemnějších úrovní, jako je jeden pro studenty a jeden pro zaměstnance. Pokud se jedná o jednoduchý dotaz na pole, můžete přímo vložit ovládací prvek prostého textu nebo otevřít dialogové okno složitého vyhledávání.

Vytvořit - mít pouze jednu záložku pro smazání, nebo ji vložit do karet pro čtení. Pokud uděláte samostatnou kartu vytvoření, skupiny se na karty mapují a přidáním oddělovačů vytvoříte mini skupiny.

Aktualizace - Vážně bych za to zvážil kontextové karty. Jeden kontext pro každý typ objektu. Pokud má formulář více typů, budete muset řídit kontext pomocí zaměření na klávesnici. Není to tak zábavné. Můžete také chtít tyto aktualizační úkoly v samotných formulářích, zejména pokud pěkně mapují možnosti dialogu „příkaz“, jako je použít a podobně.

Smazat - Pohřben v příkazu dobře, ne ve výchozím nastavení na pásu karet. Ničení dat je něco, co by se nemělo odrazovat. Namísto toho povzbuzujte uživatele k „archivaci“ nebo „zastaralým“ nebo „absolventským“ datům, takže se zobrazí pouze v konkrétních dotazech. A tyto akce jsou obecně objektově specifické, takže by žily buď ve formulářích, nebo v kontextových kartách. Odstraňování nechte provést týdenní úlohy zálohování, archivace a údržby.

0
shemnon