Quels sont les bons modèles d'interface utilisateur pour gérer des matrices de données potentiellement volumineuses?

Question

Je migre une ancienne application de bureau vb vers une version d'application Web ASP.NET. L'application permet à quelqu'un de spéculer un devis pour un bâtiment, étage par étage, spécifier combien de chaque élément, sont nécessaires sur chaque étage. Le DB existant est un M très simple: N Rejoindre

+----------+ +-----------+ +----------+ 
| Floors | | FloorItems| | Items | 
+----------+ +-----------+ +----------+ 
| FloorId |--->| FloorId | |   | 
| ...  | | ItemId |<---| ItemId | 
|   | | Quantity | | ...  | 
+----------+ +-----------+ +----------+ 

Dans l'application de bureau existant, les développeurs piraté ensemble cette grille 2D Matrice pour permettre à l'utilisateur final d'ajouter les quantités de tous les articles sur tous les étages dans un Écran. par exemple.

 | Item 1 | Item 2 | Item 3 | Item 4 | .... 
--------+--------+--------+--------+--------+------ 
Floor 1 | 
Floor 2 | 
Floor 3 | 
Floor 4 | 
...  | 

Cela soulève toutes sortes de problèmes que dans une interface utilisateur Web que le réseau peut potentiellement devenir très large que le catalogue produit/produit se développe. la taille de la page est également un problème. pour ne pas mentionner la validation des centaines d'entrées à l'écran & automatiquement en les enregistrant à intervalles réguliers ...

Quelqu'un peut-il recommander d'autres modèles d'interface utilisateur pour traiter des matrices potentiellement importantes dans une application Web? Ou signaler quelques bons exemples en ligne?

(je jongle avec l'idée de le faire un écran en Silverlight permettant une grille pour faire défiler jusqu'à droite au besoin dans l'interface utilisateur, et sauver chaque zone de texte en foyer-sortie)

Answer 1

Tout d'abord, je Essayez de voir si le client est ouvert pour réduire la quantité de données qu'ils veulent voir.
Lors de la modification des quantités d'articles au 4ème étage, est-il vraiment nécessaire de voir les articles du 2ème étage?
Alternativement - peut-être, lors de l'édition élément 3, l'utilisateur n'est pas vraiment dérangé par la quantité de l'article # 12.

Si la réponse à l'une des réponses ci-dessus est positive, vous pouvez modifier la conception de l'écran pour afficher un seul étage/élément à la fois, ce qui élimine à peu près votre problème.

Si vous devez simplement afficher cette énorme quantité de données, il existe de nombreux contrôles de grille qui peuvent gérer de grands volumes de données bien. Personnellement, j'aime les jqgrid de jQuery. évidemment, il y en a beaucoup d'autres.

Answer 2

Si vous essayez simplement de réduire la liste plutôt que de l'étendre, pourquoi ne pas utiliser un contrôle d'arborescence? L'affichage n'est que gros, et vous pouvez agrandir et réduire la vue de façon à ce qu'ils ne fonctionnent que sur un étage à la fois. Si vous souhaitez implémenter une validation/sauvegarde avec point de contrôle, ajoutez les boutons Modifier, Annuler et Enregistrer au niveau du sol, les données étant en lecture seule jusqu'à ce qu'elles atteignent Modifier, et vous pouvez les valider lors de l'enregistrement. Si l'utilisateur essaie d'éditer un autre étage, avertissez qu'il doit sauvegarder ou annuler le courant.

Building 
| 
+--Floor 1  [Edit] [Cancel] [Save]  
    | 
    +-- Item 1 _Qty Entry_ 
    | 
    +-- Item 2 _Qty Entry_ 
    | 
    +-- Item 3 _Qty Entry_ 
    | 
    +-- Item 4 _Qty Entry_ 
| 
+--Floor 2  
    | 
    +-- Item 1 _Qty Entry_ 
    | 
    +-- Item 2 _Qty Entry_ 
    | 
    +-- Item 3 _Qty Entry_ 
    | 
    +-- Item 4 _Qty Entry_