Quels sont les avantages et les inconvénients de la fonctionnalité multi-fenêtres par rapport à la fonctionnalité mono-fenêtre?
J'envisage de porter une application Windows vers une application Web pour l'un de mes clients. L'application Windows est une application MDI (plusieurs formulaires ouverts en même temps), mais évidemment l'application Web serait beaucoup plus "linéaire" dans le flux de travail, c'est-à-dire une fenêtre ouverte à la fois (pour la plupart partie).
Je suppose que je me demande deux choses.
- Quels sont les avantages et les inconvénients de l'interface utilisateur à fenêtres multiples (une par formulaire) par rapport à l'interface à fenêtre unique (en utilisant les options Précédent et Suivant pour plusieurs formulaires)?
- Est-il possible/courant/acceptable d'avoir une application web conçue pour avoir plusieurs fenêtres de navigateur ouvertes en même temps pour la même application?
D'abord un problème de terminologie pour essayer d'éliminer la confusion: "l'interface multi-documents" (MDI) est une conception où une application a une seule fenêtre "conteneur" dans laquelle l'utilisateur peut visualiser plusieurs fenêtres de documents (chacune pouvant être un formulaire). Cela fait spécifiquement référence à une conception promue par Microsoft pour diverses applications de productivité comme les premières versions de MS Office. L'alternative à MDI était une interface de document unique (SDI), où il n'y a pas de fenêtre de conteneur - chaque document a sa propre fenêtre de niveau supérieur. Cela implique que chaque document était également un processus distinct et Par conséquent, SDI pour plusieurs documents nécessite des ressources informatiques plus importantes que MDI. Cependant, les SDI ont une meilleure facilité d'utilisation en raison de leur plus grande simplicité, donc, avec les ordinateurs puissants d'aujourd'hui, MDI est obsolète et a été largement abandonné. MS Office s'en est partiellement éloigné en 2002.
Je ne pense pas que vous vouliez discuter des mérites de "MDI".
Pour répondre à votre question, je préfère faire la distinction entre "navigation historique" et "navigation par fenêtre" où la première est de style Web et la seconde est style de bureau. Les deux supporte plusieurs formulaires "ouverts" dans une seule application. La différence réside dans la façon dont les utilisateurs naviguent parmi les formulaires ouverts. La navigation dans l'historique comporte une liste historique implicite de formulaires (ou d'autres pages) que vous pouvez "parcourir" d'avant en arrière. La navigation dans Windows a chaque formulaire dans une fenêtre distincte afin que les utilisateurs "naviguent" (si vous voulez l'appeler ainsi) en cliquant simplement sur la fenêtre ouverte pour le formulaire de leur choix.
Lequel est le meilleur? La navigation dans l'historique fonctionne mieux lorsque les utilisateurs travaillent superficiellement sur de nombreuses pages/formulaires, parcourant le contenu, ignorant la majeure partie de celui-ci et ne fournissant occasionnellement entrée autre que la navigation. La navigation dans les fenêtres fonctionne mieux lorsque les utilisateurs travaillent intensivement sur quelques formulaires, fournissant une entrée substantielle (par exemple, plus de 30 secondes de travail). Dans la navigation historique, les formulaires se ferment effectivement en étant simplement négligés, ce qui est bien pour un travail superficiel, mais un véritable frein si cela signifie perdre la trace d'un grand nombre de travaux non enregistrés.
Pour le travail de type formulaire, la navigation dans les fenêtres présente les avantages suivants par rapport à la navigation dans l'historique:
Navigation plus simple, plus rapide et plus visuelle pour les pages récemment utilisées. Voyez la page que vous voulez et cliquez dessus. Pas de retour ou d'avance plusieurs fois. Aucun historique de suivi mental.
La "pagination" peut être utilisée à d'autres fins, telles que l'affichage de plusieurs enregistrements de base de données dans la même fenêtre.
La fermeture ou la déconnexion ne laisse aucune page ambiguë apparemment disponible pour l'accès. Déconnectez-vous avec la navigation dans l'historique et l'utilisateur peut toujours revenir dans les pages de la chaîne historique, ce qui est pour le moins déroutant.
L'entrée est conservée lorsque l'utilisateur accède à une autre page. Il est évident qu'un formulaire dans une fenêtre ne doit pas être effacé simplement parce que l'utilisateur a cliqué sur une autre fenêtre puis est revenu sur la fenêtre d'origine. La navigation dans l'historique efface traditionnellement le formulaire lorsque l'utilisateur s'éloigne de celui-ci, puis revient, ce qui est généralement la mauvaise chose à faire, mais parfois la bonne chose - il n'y a vraiment pas de bonne façon de le gérer.
En supposant que votre application de navigation dans les fenêtres fonctionne déjà bien avec les utilisateurs, ne la gâchez pas en essayant de la transformer en application de navigation dans l'historique. Le principal défi sera d'amener les utilisateurs à ne pas considérer l'ouverture de nouvelles fenêtres comme des "pop-ups" à bloquer ou à fermer. Un autre problème est l'expertise informatique de vos utilisateurs. De nombreux utilisateurs bas de gamme ne savent pas comment gérer plusieurs fenêtres. Ils exécutent chaque fenêtre maximisée et semblent ignorer la barre des tâches. Cependant, ces mêmes utilisateurs savent utiliser le bouton de retour du navigateur.
J'ai plus de détails sur la navigation dans l'historique par rapport à la navigation dans les fenêtres sur Turn the Page . Il comprend également des détails sur la conception correcte d'une application Web de navigation Windows.
Je crois que MDI a été inventé à l'époque où les ressources informatiques étaient rares, et il était plus avantageux d'adapter votre programme pour pouvoir gérer différents documents, au lieu d'exécuter différents exécutables.
Cette article résume bien les avantages et les inconvénients et un peu d'histoire.
Je pense que la plupart du temps dans un programme MDI, un seul formulaire est en haut. Donc, en fait, l'utilisateur travaille sur une chose à la fois. Il offre quelques extras:
- vous pouvez voir les informations côte à côte
- parfois, il donne un historique visuel des choses que vous avez faites (par exemple, vous avez d'abord ouvert une personne, cliqué sur ses comptes, ouvert un compte et toutes ces fenêtres sont superposées).
Ces avantages peuvent être facilement gérés dans les situations Web:
- il est très facile d'ouvrir différentes pages côte à côte (utiliser différents navigateurs ou onglets de navigation), permettant aux utilisateurs de comparer ou de vérifier les informations, de les recouper, peu importe.
- l'utilisation d'un bon mécanisme de fil d'Ariane permet à un utilisateur d'avoir une bonne vision de son histoire
Donc en bref: je n'essaierais pas d'imiter une interface MDI dans une application web.
Remarque: si vous voulez vraiment imiter une interface MDI, il existe de bonnes solutions, par exemple ExtJS . Mais personnellement, je ne le recommanderais pas.
Les interfaces de documents multiples conviennent aux applications où plusieurs documents peuvent être modifiés en même temps. Il est souvent avantageux de permettre à un utilisateur de visualiser/modifier deux ou plusieurs documents en même temps qu'un seul à la fois. Imaginez un agent immobilier qui peut voir plus d'une propriété en même temps ou en voir une sans avoir à fermer les détails d'une autre. Cela permet une approche de la gestion des documents plus proche de la façon dont ils pourraient travailler avec du papier sur un bureau.
Dans une application Web, vous pourriez être en mesure de fournir des documents de style boîte de dialogue si vous souhaitez conserver tout le contenu sur une seule page, ou vous pouvez ouvrir de nouvelles fenêtres avec un document dans chacune - bien que cette dernière exigera de la discipline de la part des utilisateurs car votre application perd le contrôle de ces fenêtres une fois ouvertes. Comme alternative, vous pouvez offrir quelque chose comme un contrôle accordéon pour ouvrir/fermer rapidement des documents avec tous sur une seule page. Je pense que le choix de la technique dépendra en grande partie de la taille de vos documents et du contrôle que vous souhaitez avoir lorsqu'ils sont visibles et/ou fermés (supprimés).
Je regarde un problème similaire en ce moment. Notre application est une application client léger. Ce n'est pas nécessairement la priorité de l'utilisateur la plupart du temps (nous fournissons le statut et la fonction pendant qu'une autre application est utilisée comme outil principal).
Nous envisageons de construire notre application afin de pouvoir offrir à l'utilisateur deux vues. Une vue à fenêtre unique et une vue à fenêtres multiples. Dans ce dernier, l'utilisateur peut dimensionner et positionner les pièces de notre application comme bon lui semble.
Dans une application Web plus traditionnelle, la même logique peut être utile. Les tableaux/graphiques de référence ou les volets d'état peuvent être des fenêtres contextuelles utiles qui peuvent être structurées autour de l'écran. Cela peut également fonctionner si votre application est très compliquée et que les utilisateurs peuvent vouloir contrôler leur vue. Cependant, dans ce cas, je serais plus enclin à envisager une meilleure configuration d'écran, plus intelligente, avec une certaine configuration contrôlée par l'utilisateur. Plusieurs fenêtres peuvent devenir gênantes car elles ont un impact sur le paradigme des applications multiples. Par exemple, sous Windows, la tabulation alt entre les applications ne produit pas plusieurs points d'arrêt qui sont votre application. Même effet sur la barre des tâches.