Reporting dans une application CRUD
C'est encore un autre dilemme lié aux applications d'entreprise.
La plupart des applications professionnelles utilisent des rédacteurs de rapports qui sont beaucoup trop compliqués pour l'utilisateur général, même si la plupart d'entre eux sont des wysiwyg. Certaines applications simples n'ont que des modèles fixes qui ne sont pas personnalisables.
Afin de résoudre ce problème de longue date, nous avons choisi la solution intermédiaire au problème, à savoir l'impression basée sur un modèle.C'est un peu comme le fonctionnement des moteurs de blog ou des moteurs de forum, les modèles peuvent contenir un code logique simple et des paramètres simples qu'un utilisateur peut Tweak facilement sans avoir à connaître de code. Un très bon échantillon de son fonctionnement est en train de regarder ce site: www.squarespace.com
Cependant, contrairement à un site Web, la plupart des rapports d'application CRUD ont des contraintes de données, certains critères de sélection tels que des groupes ou des catégories. Par exemple. Je veux un rapport de tous les présidents de la base de données.
La question est la suivante: les critères de sélection devraient-ils être inclus dans les modèles? La séparation des critères permettra un meilleur contrôle des données à imprimer. Ce paradigme est utilisé à travers l'application mais sans sélection de critères. Par exemple. Impression de factures mais avec des modèles
En tant que programmeurs, nous avons tendance à penser que la présentation (modèles) et la logique (dans ce cas les données) devraient être séparées. Que ferez-vous dans cette situation?
PS: les modèles génèrent des fichiers PDF et ne peuvent donc pas s'afficher en direct avec les modèles.
En supposant que nous parlons d'une partie de rapport général de l'application dans laquelle toutes les données disponibles à partir de l'application doivent être "déclarables": je garderais les critères de sélection séparés des modèles.
Laissez l'utilisateur d'abord sélectionner tout ce qu'il souhaite voir, puis proposez une action d'impression où il pourra sélectionner un modèle à utiliser. De cette façon, les modèles peuvent également être filtrés en fonction des données sélectionnées (inutile de présenter des modèles de facture lorsque l'application affiche des éléments de journal dans la grille de sélection).
Une alternative serait de commencer par sélectionner un modèle (et donc de limiter la sélection des données). Vos utilisateurs devront vous donner des conseils à ce sujet. Il peut être plus naturel pour eux de sélectionner un modèle en premier.
Dans les deux cas, j'aurais tendance à afficher les données sélectionnées en fonction des critères saisis. Par exemple, dans une grille ou une arborescence quelconque. De préférence "en direct" afin que l'utilisateur puisse voir immédiatement l'effet des critères qu'il saisit. Sinon, demandez-leur d'entrer certains critères, d'afficher des données, de les affiner (ajouter/supprimer/modifier) en revenant à la boîte de dialogue des critères jusqu'à ce qu'ils soient satisfaits de ce qu'ils ont sélectionné.
Mise à jour en réponse au commentaire
Assurez-vous donc d'avoir un modèle par défaut raisonnable. Encore mieux: sélectionnez un modèle le mieux adapté en fonction des données sélectionnées par l'utilisateur.
Cela ne veut pas dire que vous ne les avez pas :-), mais d'autres fonctionnalités qui peuvent aider les utilisateurs dans ces situations:
- Enregistrer la dernière sélection, les critères et le modèle utilisés
- Autorisez les utilisateurs à enregistrer les recherches sous un nom significatif et de préférence, organisez-les dans une sorte de structure de dossiers. De préférence avec une prise en charge complète du glisser-déposer afin qu'ils puissent déplacer les recherches enregistrées