Comment s'adapter et / ou avec des supports dans le système de filtrage de champ
Je construis un système de filtrage pour un rapport et j'essaie de trouver un moyen d'incorporer et/ou de logique lorsque les deux doivent être mélangés.
En substance, un filtre très simple pourrait être:
Select field 1 from table where field2="123" OR field3="123"
Dans ce scénario, j'utilise quelque chose comme ci-dessous et c'est très bien:
Cependant, les utilisateurs voudront parfois mélanger et et ou dans la même requête qui devient alors plus complexe du point de vue de l'interface utilisateur. Par exemple,
Select field 1 from table where (field2="123" OR field3="123") AND field 1="abc"
La simple utilisation de l'interface utilisateur d'origine ne fonctionne pas car elle ne permet pas à l'utilisateur de spécifier les bits entre parenthèses, je dois donc les autoriser à le faire - sans le faire, la requête se lit très différemment!
Mon exemple est assez simple mais bien sûr, les requêtes peuvent être beaucoup plus complexes que cela, vous pouvez donc avoir trois groupes de OR puis deux et par exemple dans lesquels vous devez savoir lequel OR ainsi que peut-être les ET à mettre entre parenthèses, etc.
Quelle serait la meilleure façon de permettre à l'utilisateur de le faire?
Blocs imbriqués dans une disposition verticale
Ce modèle a très bien testé avec nos utilisateurs. Il utilise un langage commun pour expliquer ce que vous recherchez et permet n'importe quel niveau de regroupement complexe où des blocs individuels peuvent être déplacés, modifiés de AND en OR, ou supprimés.
Ce niveau de clarté prend un peu d'espace mais pas trop pour la plupart des filtres simples.
Utilisateurs
Vous devez d'abord savoir qui sont les utilisateurs et si cette approche correspond à leurs besoins et compétences. Pour la plupart des utilisateurs professionnels et/ou la logique est difficile à comprendre et doit être évitée. Les techniciens ou commis en finance, comptabilité, ... sont habitués à une telle logique.
UI
En fonction des besoins, plusieurs implémentations sont envisageables:
Filtre simple : implicites et/ou définitions
Comme Google. Comme il semble que c'est trop simple pour vos besoins, je ne le mentionne que pour être complet.
Editeur de règles aux fonctionnalités réduites : explicites mais limitées et/ou définitions
Cela inclurait votre maquette. Toutes les fonctionnalités ne sont pas fournies, mais c'est le meilleur compromis entre les compétences de vos utilisateurs et ce qu'ils veulent.
Éditeur de règles complet : explicites et/ou définitions
Ici, vous pouvez faire tout ce que vous voulez, mais c'est complexe. Attendez-vous à des problèmes de convivialité et essayez toujours d'adapter votre solution à vos utilisateurs, comme la solution de DaveAlger.
Deux rivières ont écrit un excellent article à ce sujet http://tworivers.com/archives/697
Points les plus importants:
- Critères, fonctionnement, valeur
- Règles imbriquées
- Possibilité d'ajouter des règles partout
- Bons défauts
Encore une chose d'un autre x.se post :
- Utiliser les changements de couleur d'arrière-plan pour les blocs prévus
Saisie de texte : explicites et/ou définitions
Oui, pour certains utilisateurs comme les techniciens, la saisie de texte est le moyen le plus simple. Pourquoi la plupart des développeurs utilisent ce type pour créer des requêtes SQL? Néanmoins, les conseils et l'assistance sont toujours appréciés (saisie semi-automatique pour les mots clés/variables/...)
Tester
Les développeurs ont une vision complètement différente sur ce sujet. Je vous recommande vraiment de le tester, de le tester et de le tester à nouveau avec vos utilisateurs.
Est-ce seulement moi ou que l'option textuelle que vous avez utilisée est meilleure que n'importe laquelle des suggestions graphiques ci-dessus? À mon avis, cela est trop complexe pour être résolu uniquement par un arrangement graphique sophistiqué.
À ce stade, vous devez vous demander qui est votre utilisateur cible? Je suppose que cela est destiné à un utilisateur professionnel/expérimenté, pas à un utilisateur novice. Dans ce cas, vous pouvez vous attendre à ce que cet utilisateur formate une phrase de recherche écrite dans un langage assez simple.
Si vous décidez de le prendre, faites attention aux points suivants qui faciliteront la tâche de l'utilisateur:
- Vous n'avez pas besoin des guillemets pour "traduire" cette chaîne de recherche en code.
- Fournissez la saisie semi-automatique où vous le pouvez.
Donc, fondamentalement, cela devrait ressembler à ceci (deux options pour la saisie semi-automatique):
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Dans le cas d'utilisateurs non techsavvy, cela pourrait être un bon moyen:
Qu'en est-il de faire vos critères de recherche comme un langage commun. Tous les liens sont modifiables avec une liste déroulante ou similaire. Champs d'entrée pour les nombres ou le texte.
Mon entreprise a recherché et testé diverses représentations de requêtes depuis plus d'une décennie maintenant, et celle qui fonctionne le mieux avec nos utilisateurs est une représentation en forme d'entonnoir, où les conditions OR sont disposées horizontalement et les conditions AND verticalement. Les conditions ET fonctionnent comme des filtres dans une requête en ce qu'elles réduisent l'ensemble de résultats, nous les présentons donc de cette façon. Cela a abouti à une représentation visuelle de la requête intuitive même pour les utilisateurs non techniques, qui autrement pourraient avoir du mal avec distinction ET/OU et la signification des parenthèses.
Votre exemple de requête très simple ressemblerait à sa représentation la plus basique quelque chose comme ceci: 
Vous pouvez utiliser cette même disposition pour créer une requête. Vous pouvez en outre autoriser le regroupement de cases pour les requêtes plus complexes. Dans ce cas, les groupes agissent également comme des parenthèses. Nous avons développé une interface utilisateur glisser-déposer pour ajouter et réorganiser les conditions qui a très bien testé avec nos utilisateurs, et même étendu l'interface utilisateur pour ajouter une logique de style If/Then/Else, donc c'est assez flexible. Je laisserai les détails de conception hors de ce post, mais il existe de nombreuses façons de transformer cette représentation logique en une bonne interface utilisateur.
Beaucoup de bonnes réponses ici. J'en ajoute un de plus. Si vous connaissez l'interface Web de Microsoft TFS. C'est ainsi qu'ils proposent actuellement un filtrage basé sur ET/OU. Cela a également des sous-critères.
Cela ne permet qu'un seul niveau de cascade. Il y a également une raison valable à cela. L'ajout d'un plus grand nombre de niveaux est écrasant pour la logique de traitement, ce qui donne un résultat légèrement meilleur. Un filtre à deux niveaux fonctionne pour la plupart des cas.
ne autre approche
Dans notre application, nous avons suivi une approche à deux niveaux. Nous avons un niveau supérieur ET OR bouton radio de sélection. Sur la base de cette sélection, tous les éléments sont ANDed ou ORed ensemble. Nous avons fourni une option de sélection de deux ou plusieurs éléments, puis créez un sous-groupe (juste un nom que nous utilisons pour les critères un niveau plus bas). Ce sous-groupe généré déplace automatiquement les critères sélectionnés ensemble. Les met entre crochets et opérateur interne de AND à OR ou de OR à AND selon le cas). D'après les commentaires de nos clients, cela a bien fonctionné pour notre analyse de rentabilisation.
Malheureusement, je ne peux pas partager la capture d'écran de la même chose.
Deux modes peuvent être proposés à l'utilisateur: de base et avancé.
Le mode de base ne couvrira que l'option Tout/Tout pour joindre tous les filtres.
En mode avancé, l'utilisateur peut écrire une requête compliquée à l'aide de crochets.
Sinon, mettre toutes les options dans l'interface utilisateur donnée rendra les choses un peu compliquées, et peut-être que seuls quelques utilisateurs souhaitent utiliser cette fonctionnalité avancée.
Vous pouvez choisir des champs et prendre des valeurs pour chaque champ au lieu de fixer la séquence de champs.
La solution est dans l'interface. Ne faites pas interpréter un arbre d'entrées par les utilisateurs. L'interface doit aider l'utilisateur à comprendre sa tâche.
Laissez les utilisateurs se concentrer sur le filtre qu'ils créent. Utilisez les champs de formulaire, les sélecteurs, etc. uniquement comme entrées, pour n'afficher aucune information et supprimez-les une fois leur fonction terminée.
En divisant l'instruction en blocs logiques, vous pouvez utiliser le glisser-déposer pour éditer l'instruction et les blocs eux-mêmes peuvent être édités par rapport à forcer les utilisateurs à parcourir et modifier les entrées. L'interface peut facilement informer les utilisateurs lorsque leur filtre est correct, informer les utilisateurs des erreurs de logique et comment corriger les erreurs.
Voici une maquette d'une interface comme celle-ci. Les entrées peuvent être des menus déroulants, des sélecteurs, etc.
Modifié: ajouté plus de description à la maquette
L'utilisateur peut ajouter des composants à la déclaration, les faire glisser en position et l'application peut instantanément donner à l'utilisateur des commentaires sur tout.
Si vos critères sont pour la plupart simples, une approche de requête par exemple (QBE) peut être suffisante et plus simple pour l'utilisateur à apprendre, à construire et à déboguer, en particulier pour les utilisateurs familiers avec les feuilles de calcul.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
QBE peut évoluer vers des termes plus complexes.