it-swarm-eu.dev

Jaké jsou výhody a nevýhody funkce více oken oproti funkcím jednoho okna?

Uvažuji o přenesení aplikace systému Windows do webové aplikace pro jednoho z mých klientů. Aplikace pro Windows je aplikace MDI (více formulářů otevřených najednou), ale webová aplikace by samozřejmě byla v pracovním postupu mnohem „lineárnější“, tj. Jedno okno otevřené najednou (pro nejvíce část).

Myslím, že se divím dvěma věcem.

  • Jaké jsou výhody a nevýhody uživatelského rozhraní vícenásobného okna (jedno na formulář) oproti jednomu oknu (použití zpětného a dopředného pro více formulářů)?
  • Je možné/běžné/přijatelné mít webovou aplikaci, která je navržena tak, aby otevírala více oken prohlížeče současně pro stejnou aplikaci?
14
richard

První terminologický problém, který se pokouší eliminovat zmatek: „rozhraní více dokumentů“ (MDI) je návrh, ve kterém má aplikace jediné „kontejnerové“ okno, ve kterém může uživatel zobrazit více oken dokumentů (z nichž každé může být formulář). To se konkrétně týká designu propagovaného společností Microsoft pro různé aplikace produktivity, jako jsou rané verze MS Office. Alternativou k MDI bylo jediné rozhraní dokumentu (SDI), kde neexistuje žádné okno okna kontejneru - každý dokument má své vlastní okno nejvyšší úrovně, což znamená, že každý dokument byl také samostatný proces a SDI pro více dokumentů tedy vyžaduje větší počítačové prostředky než MDI. Nicméně SDI mají lepší použitelnost kvůli jejich větší jednoduchosti, takže u dnešních výkonných počítačů je MDI) zastaralé a bylo z velké části opuštěno. částečně se od ní odešel v roce 2002.

Nemyslím si, že máte v úmyslu diskutovat o výhodách „MDI“.

Abychom se dostali k vaší otázce, raději rozlišuji mezi „historickou navigací“ versus „okenní navigací“ , kde první je webový styl a druhý je styl plochy. Oba podporují více „otevřených“ formulářů v jedné aplikaci. Rozdíl je v tom, jak uživatelé procházejí mezi otevřenými formuláři. Navigace historie obsahuje implicitní historický seznam formulářů (nebo jiných stránek), kterými se můžete „pohybovat“ tam a zpět. Navigace v systému Windows má každý formulář v samostatném okně, takže uživatelé „navigují“ (pokud jej chcete nazvat) pouhým kliknutím na otevřené okno pro požadovaný formulář.

Co je lepší? Navigace v historii funguje nejlépe, když uživatelé pracují povrchně na mnoha stránkách/formulářích, sklouzávají po obsahu, většinu z nich ignorují a pouze příležitostně poskytují jakékoli vstup jiný než navigace. Okno navigace funguje nejlépe, když uživatelé intenzivně pracují na několika formulářích, což poskytuje podstatné vstupy (např. Více než 30 sekund práce). V navigaci v historii se formy efektivně uzavírají jednoduše tím, že jsou zanedbávány, což je v pořádku pro povrchní práci, ale skutečný odpor, pokud to znamená ztrácet přehled o spoustě neuložené práce.

Pro práci typu formuláře má navigace v okně oproti navigaci v historii následující výhody:

  • Jednodušší, rychlejší a vizuální navigace pro nedávno použité stránky. Podívejte se na požadovanou stránku a klikněte na ni. Ne vícekrát se vracet nebo vpřed. Žádná mentálně sledovaná historie.

  • „Stránkování“ lze použít pro jiné účely, například pro zobrazení více záznamů databáze ve stejném okně.

  • Ukončení nebo odhlášení neopouští zjevně přístupné nejasné stránky. Odhlaste se pomocí navigace historie a uživatel se může stále vrátit na stránky v řetězci historie, což je přinejmenším matoucí.

  • Vstup se zachová, když uživatel přejde na jinou stránku. Je zřejmé, že formulář v jednom okně by neměl být vymazán jednoduše proto, že uživatel klikl na jiné okno a poté vrátil fokus do původního okna. Navigace historie tradičně vymaže formulář, když uživatel od něj odjede a poté se vrátí, což je obvykle špatná věc, ale někdy správná věc - ve skutečnosti to není dobrý způsob, jak se s tím vypořádat.

Předpokládejme, že vaše aplikace pro navigaci v okně již s uživateli funguje dobře. Nezkoušejte to tím, že ji zkusíte přepnout na aplikaci pro navigaci v historii. Hlavní výzvou bude přimět uživatele, aby nepovažovali otevření nových oken za blokovaná nebo zavřená okna. Dalším problémem jsou počítačové znalosti vašich uživatelů. Mnoho uživatelů s nízkými konci neví, jak zpracovat více oken. Spustí každé okno maximalizované a zdá se, že nevědí o hlavním panelu. Tito uživatelé však vědí, jak v prohlížeči používat tlačítko Zpět.

Mám více podrobností o navigaci v historii oproti navigaci v okně na Otočte stránk . Obsahuje také podrobnosti o správném návrhu webové aplikace pro navigaci v systému Windows.

7
Michael Zuschlag

Věřím, že MDI) byl vynalezen ve dnech, kdy byly počítačové zdroje vzácné, a bylo výhodnější přizpůsobit program tak, aby dokázal zpracovávat různé dokumenty, místo spouštění různých spustitelných souborů.

Tento článek pěkně shrnuje výhody a nevýhody a nějakou historii.

Většinu času si myslím, že v programu MDI) je nahoře pouze jeden formulář. Uživatel tedy vlastně pracuje na jedné věci najednou. Nabízí několik doplňků:

  • můžete si prohlížet informace vedle sebe
  • někdy poskytuje vizuální historii toho, co jste udělali (např. první otevření osoby, kliknutí na jeho účty, otevření účtu a všechna tato okna jsou na sobě).

Tyto výhody lze snadno vyřešit ve webových situacích:

  • je velmi snadné otevírat různé stránky vedle sebe (používat různé prohlížeče nebo browsertabs), což uživatelům umožňuje porovnávat nebo ověřovat informace, křížovou kontrolu, cokoli.
  • použití dobrého strouhankového mechanismu umožňuje uživateli mít dobrou představu o její historii

Takže v krátkosti: Nesnažil bych se napodobit rozhraní MDI) ve webové aplikaci.

Poznámka: Pokud opravdu chcete napodobit rozhraní MDI=), existují některá dobrá řešení, např. ExtJS . Ale osobně bych to nedoporučoval.

4
nathanvda

Rozhraní více dokumentů jsou vhodná pro aplikace, ve kterých lze současně upravovat více než jeden dokument. Často je užitečné umožnit uživateli prohlížet/upravovat dva nebo více dokumentů současně než jen jeden najednou. Představte si realitního agenta, který si může zobrazit více než jednu nemovitost ve stejnou dobu, nebo si prohlédnout jednu, aniž by musel zavřít podrobnosti o jiné. To umožňuje přístup ke správě dokumentů více podobný tomu, jak mohou pracovat s papírem na stole.

Ve webové aplikaci můžete být schopni poskytnout dokumenty ve stylu dialogu, pokud si přejete zachovat veškerý obsah na jedné stránce, nebo můžete otevřít nová okna s dokumentem v každé z nich - i když druhé bude vyžadovat disciplínu na straně uživatelů, protože Vaše aplikace po otevření ztratí kontrolu nad těmito okny. Jako alternativu byste mohli nabídnout něco jako akordeonovou kontrolu, abyste mohli rychle otevřít/zavřít dokumenty s nimi na jedné stránce. Myslím, že volba techniky bude z velké části závislá na velikosti vašich dokumentů a kontrole, kterou chcete, když jsou viditelné nebo uzavřené (odstraněné).

1
Bernhard Hofmann

Momentálně se dívám na podobný problém. Naše aplikace je tenká klientská aplikace. Většinou to není nutně zaměření uživatele (poskytujeme stav a funkci, zatímco jiná aplikace je používána jako primární nástroj).

Uvažujeme o vytvoření naší aplikace, abychom uživateli mohli nabídnout dva pohledy. Zobrazení jednoho okna a zobrazení více oken. V druhém případě může uživatel velikost a umístění kusů naší aplikace, jak uzná za vhodné.

V tradičnější webové aplikaci můžete považovat stejnou logiku za užitečnou. Referenční tabulky/grafy nebo stavové panely mohou být užitečná vyskakovací okna, která by mohla být strukturována kolem obrazovky. To může také fungovat, pokud je vaše aplikace velmi komplikovaná a uživatelé mohou chtít kontrolovat svůj pohled. V tomto případě bych však měl větší sklon uvažovat o lepším a chytřejším rozvržení obrazovky, které má určité množství uživatelem ovládané konfigurace. Více oken se může stát nepříjemným, protože ovlivňuje paradigma více aplikací. Například pod okny neposkytuje alt-tabing mezi aplikacemi několik stop bodů, které jsou vaší aplikací. Stejný vliv na hlavní panel.

0
Jim Rush