Interface intuitive pour composer la logique booléenne?
Je suis intéressé de savoir comment les gens ont, ou construiraient une interface qui simplifie la construction de conditions booléennes logiques? (Oui, c'est un générateur de requêtes de base de données) Dans mon esprit, une mauvaise interface les fait taper beaucoup de ET, PAS DANS, OR mots-clés, etc. Ou bien a un million de zones de liste déroulante.
Je me demande si quelqu'un a un bon exemple dont je pourrais tirer des idées? Ou quelques suggestions?
En ce moment, j'envisage un écran partagé avec une grille pour composer la requête et une toile pour afficher une représentation visuelle des ensembles de conditions et comment elles se chevauchent, etc. Comme un diagramme de Venn. Cela me pose toujours un problème avec la convivialité/intuitivité des contrôles sur la grille.
EDIT: Je suis très intéressé par les idées qui le simplifient pour les utilisateurs moins techniques. Cependant, les idées pour une version de l'interface utilisateur pour les utilisateurs avancés sont également très utiles.
Voir aussi iTunes 9 ou version ultérieure. Il ajoute la possibilité de faire des expressions "imbriquées" ET/OR, semblable à la façon dont un programmeur le ferait entre parenthèses:
Le principal problème que rencontrent les utilisateurs non techniques avec la logique booléenne est de comprendre la différence entre AND et OR car il ne correspond pas toujours au langage naturel (par exemple, "montrez-moi les commandes de New York et de New Jersey "signifie presque certainement Location = NY OR Location = NJ). Souvent, les utilisateurs ont tendance à interpréter" ou "comme un OU exclusif. Ensuite, il y a le problème de perdre la trace des parenthèses imbriquées.
Une solution qui évite ces deux problèmes est de représenter la logique graphiquement avec une métaphore de plomberie ou électrique. Deux axes de travail ont suivi cette approche:
Shneiderman, B (1991). Interfaces utilisateur visuelles pour l'exploration de l'information. Actes de la 54e réunion annuelle de l'American Society for Information Sciences, 28, 379-384.
Murray NS, Paton NW, Goble CA, Bryce J (2000) Kaleidoquery — un langage visuel basé sur les flux et son évaluation. Journal of Visual Languages & Computing, 11 (2), 151-189.
Les générateurs de requêtes sont l'un des rares endroits où il est logique d'avoir des modes de base et avancé séparés. Vous constaterez probablement que 90% des requêtes de vos utilisateurs ne correspondent qu'à quelques modèles (par exemple, "Clients dont le nom commence par Xxxx", "Comptes dont je suis responsable des factures en souffrance", "Commandes passées entre la date a et la date b) ”). Il est logique de les avoir en tant que requêtes prédéfinies ou semi-prédéfinies qui peuvent être sélectionnées et spécifiées facilement tout en plaçant quelque chose comme Kaleidoquery sous Avancé pour les requêtes ad hoc plus rares.
Celui-ci a bien testé avec les utilisateurs techniques et non techniques et peut générer à peu près n'importe quelle requête de base de données possible ...
Les avantages sont que c'est très clair et un utilisateur peut glisser-déposer ( ou supprimer ) toute expression ou groupe d'expressions dans l'arborescence.
L'inconvénient est la quantité d'espace qu'il consomme.
Il existe un plugin jquery pour ce faire, appelé QueryBuilder, qui le fait de manière intéressante: http://mistic100.github.io/jQuery-QueryBuilder/
J'aime la façon dont Apple les règles de Mail fonctionnent:
Il y a pas mal de bonnes idées/références ici, en particulier pour certaines approches existantes. Souvent, mais pas toujours, l'approche d'Apple est un bon point de départ - mais peut-être que ce n'est pas le cas dans votre cas. J'ai l'impression (bien que vous ne l'ayez pas déjà dit) que vous travaillez avec un très grand nombre de données comprenant de nombreux champs/variables.
Je suis d'accord qu'essayer de trouver un moyen de le simplifier pour les utilisateurs moins techniques est une bonne idée, tant que vous vous attendez à ce que moins d'utilisateurs techniques utilisent le système. Sinon, développer une interface moins compliquée peut demander beaucoup de travail pour peu de gain. J'aime aussi l'idée d'un diagramme de Venn - serait intéressant de voir comment cela se déroule.
Cependant, en termes de suggestions réelles sur la façon de simplifier cela, une autre approche serait de simplement créer une sorte de processus "Assistant" qui guide l'utilisateur à travers le processus avec une combinaison de langage naturel et une apparence et une sensation familières sur le Web. Voici une maquette de la façon dont cela pourrait fonctionner, à l'aide d'un exemple de base de données de véhicules automobiles:
Ce qui précède montre comment l'étape 1 pourrait fonctionner, offrant aux utilisateurs un certain nombre d'options qu'ils peuvent sélectionner en cochant la case appropriée. Ils peuvent sélectionner une ou plusieurs cases à cocher si nécessaire (ou peut-être pas ?!). S'ils sélectionnent une case à cocher pour une option qui nécessite plus d'informations, les mots pertinents sont liés par un lien hypertexte. Un clic sur les mots hyperliés présenterait à l'utilisateur quelque chose comme l'exemple ci-dessous:
Ainsi, l'exemple ci-dessus montre ce qu'un utilisateur peut voir s'il a sélectionné la case à cocher "Le véhicule est produit par des fabricants particuliers", puis a cliqué sur le texte du lien hypertexte pour sélectionner le ou les constructeurs qu'il souhaite inclure dans les résultats de la recherche. Bien sûr, votre approche peut différer selon qu'ils devraient voir un champ de texte libre, une liste déroulante d'options, etc.
Maintenant, pour faire face à toute "exception" aux critères de recherche, vous recréeriez essentiellement la première fenêtre, mais avec un libellé différent, comme:
Ainsi, après avoir sélectionné l'exception de carburant ci-dessus, l'utilisateur clique sur les mots hyperliens "carburant particulier" pour choisir l'exception comme ci-dessous:
Encore une fois, cela pourrait être une liste déroulante, des boutons radio, etc. selon ce qui convient le mieux à la condition. Ils suivraient également le même processus pour sélectionner le pays dans lequel ils ne souhaitaient pas que le véhicule soit fabriqué.
Bien sûr, je vois cette approche "Wizard" comme étant destinée aux utilisateurs moins techniques. Vous offririez également une option "Avancée" pour les utilisateurs à l'aise avec une approche plus compliquée qui peut être rationalisée par rapport à l'approche Wizard.
[~ # ~] addendum [~ # ~]
D'accord, cela m'a empêché de dormir la nuit dernière. En fait, je considère que cette approche Wizard est un assez bon chemin à parcourir, alors j'ai pensé qu'il valait la peine de revenir pour améliorer ma réponse car cela pourrait aider quelqu'un d'autre sinon vous.
J'ai mis à jour les images de maquette ci-dessus et je voulais développer votre idée d'utiliser un écran partagé.
À l'origine, je pensais qu'après la dernière étape, quelque chose comme votre idée de diagramme de Venn pourrait être utilisée pour indiquer visuellement ce que l'utilisateur avait choisi. Mais j'ai ensuite pensé à mon affirmation initiale selon laquelle il devrait également y avoir un moyen pour l'utilisateur de faire des allers-retours pour modifier ses critères. Alors maintenant, je pense qu'en utilisant votre écran partagé, vous pourriez atteindre les deux. Voici une nouvelle image pour illustrer ce que je pense:
Donc, ce qui précède est un exemple de ce qui pourrait apparaître dans la deuxième partie de votre écran partagé. Lorsque l'utilisateur sélectionne ses critères, celui-ci se met à jour pour indiquer quelles ont été ses sélections. Cette approche utilise également l'apparence et la convivialité du Web pour mettre en évidence leurs choix avec des hyperliens et, s'ils le souhaitaient, ils pourraient modifier leurs critères en cliquant sur les hyperliens de cet écran, plutôt que d'avoir à faire des allers-retours entre les écrans pour refaire leur pas. Bien sûr, s'ils voulaient sélectionner une nouvelle condition , ils devraient peut-être revenir à l'étape pertinente. Mais vous avez l'idée.
La seule autre chose que je voudrais mentionner est que sans connaître la complexité de vos données, vous devrez peut-être affiner cette approche Wizard. Ma base de données de véhicules simple n'a besoin que de deux étapes, mais compliquée on peut avoir besoin de plus d'étapes. Le point de cette approche n'est pas tellement dans le nombre d'étapes, mais dans le fait que le Wizard 'parle' aux gens à travers les étapes en utilisant le langage naturel comme autant que possible.
Quoi qu'il en soit, j'espère que cela, avec les autres réponses fournies, vous donnera matière à réflexion. Et peut-être quelques autres. C'est un bon sujet et je pense qu'il sera pertinent pour de nombreux utilisateurs.
Bonne chance!
Cela dépend du niveau de sophistication de vos utilisateurs. Nous avons quelque chose de similaire dans la version actuelle de l'interface qui a omis le regroupement et corrigé la conjonction entre les termes et OR. Chaque terme peut être annulé. La plupart des utilisateurs acceptent ce type d'interrogation et la plupart d'entre eux ne pourraient pas formuler correctement des requêtes plus avancées. Nous implémentons maintenant un processus en deux étapes dans lequel le résultat d'une requête peut être utilisé pour limiter la population dans une requête suivante (en laissant toujours de côté le regroupement explicite dans l'interface utilisateur).
L'interface utilisateur pour cela est une liste de base des contraintes qui peuvent être ajoutées, supprimées, activées et désactivées et annulées. Cela a été suffisant pour la plupart des requêtes que les utilisateurs souhaitent créer. Nous avions une conception pour une nouvelle version qui était basée sur un concept de flux de données (en s'inspirant fortement des vistrails, voir ci-dessous) mais qui n'a jamais été exécutée. Vistrails est un produit qui peut être utilisé pour créer des pipelines VTK. Si vous souhaitez suivre la route de nombreux éléments de l'interface utilisateur, le flux de données fonctionne pour formuler des requêtes, mais fonctionne également pour formuler le formatage de sortie.
Cherchez l'inspiration dans
- Yahoo Pipes
- Apple Finder
- Recherche Thunderbird
- Vistrails
Par opposition à la réutilisation des tableaux croisés dynamiques comme je l'ai précédemment répond , il s'agit d'une interface utilisateur expérimentale à laquelle j'ai pensé pour gérer le besoin répétitif d'écrire AND ou OR.
Il repose sur un élément, vous devez apprendre que ANDs sont horizontaux et ORs sont verticaux. Il parvient cependant à gérer une logique booléenne assez complexe.
Aperçu
Supposons que A, B, C, D et E sont des expressions booléennes.
Pour tester le concept, voici comment dessiner les deux côtés différents d'une équivalence booléenne standard:
(A and B) or C === (A or C) and (B or C)
Cela s'étend aux requêtes plus complexes:
((A and B and C) or D) and E
Interface utilisateur réelle
Pour ce tableau de données:
L'écran est divisé en deux:
- Un ensemble de filtres (effectivement
ANDrequêtes) - Une combinaison des filtres
Vous définissez les filtres (ceux-ci sont simplement saisis avec le journal conditionnel de base), puis faites-le glisser pour le "fusionner" avec la requête complète.
Après avoir fait glisser le nouvel ensemble de filtres, le côté gauche revient à une liste non filtrée et le côté droit affiche l'ensemble de données `` fusionné '':
Vous devriez alors pouvoir faire glisser et modifier les expressions sur le côté droit - mais cela demande beaucoup plus de travail.
Microsoft Access a fait une tentative raisonnable d'interface utilisateur de requête de base de données simple en produisant une version visuelle de "Requête par exemple"
Il a un langage plus naturel qui évite d'avoir besoin d'une interface utilisateur imbriquée , au détriment d'entrées de lignes parfois légèrement plus redondantes.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
C'est une vieille question, mais je pensais pouvoir contribuer au cas où quelqu'un serait intéressé. Bien que de nombreuses réponses intéressantes aient déjà été fournies, j'ai conçu pour notre application les éléments suivants:
Au départ, il n'y a que la première expression de groupe et une règle. Cliquer sur "Ajouter une condition" ajoute une nouvelle condition au-dessus, tandis que "Ajouter un groupe" ajoute un nouveau groupe juste en dessous; les groupes supplémentaires du groupe parent sont des frères et sœurs tandis que vous pouvez créer une imbrication infinie à l'aide du bouton "Ajouter un groupe" à partir d'un groupe imbriqué.
Sur les appareils mobiles, la pile de conditions, ainsi que le bouton d'action "supprimer" - qui change maintenant son texte en "Supprimer la condition".
Le design fonctionne bien, a l'air bien, est réactif et ne consomme pas trop d'espace non plus.
Bonus supplémentaire: au-dessus du groupe, une seule ligne indique l'état final produit, par exemple
[Date supérieure à XXX ET (Nom égal à Nick)]
edit: Afin de le rendre plus accessible aux personnes non techniques, je suivrais ce qui a été dit par d'autres dans ce fil - suivez le chemin d'Apple. Au lieu de ET/OU, j'utiliserais le contexte ALL/ANY +.
Si vos utilisateurs sont suffisamment avancés pour connaître la hiérarchie d'une requête, toute interface graphique que vous leur donnez doit être suffisamment fluide pour ne pas les gêner. Je pense qu'une interface basée sur le glisser-déposer d'éléments pour créer une hiérarchie implicite est idéale. Voici un exemple visuel annoté étendu de la façon dont un utilisateur peut construire la requête (A and B) or ((not C) or D):
Déposez A sur le panneau. + --- + | A | + --- + Supprimer "et" après A. + --------------- ---- + | + --- + + ----- + | | | A | et | ... | | | + --- + + ----- + | + ------------------- + Drop B sur "...". + ----------------- + | + --- + + --- + | | | A | et | B | | | + --- + + --- + | + ----------------- + Supprimer "ou" après "et". + -------------------------------- + | + ----------------- + | | | + --- + + --- + | + ----- + | | | | A | et | B | | ou | ... | | | | + --- + + --- + | + ----- + | | + ----------------- + | + ------------------------ -------- + Déposez C sur "...". + ---------------- -------------- + | + ----------------- + | | | + --- + + --- + | + --- + | | | | A | et | B | | ou | C | | | | + --- + + --- + | + --- + | | + ----------------- + | + ------------------------ ------ + Déposez "not" sur C. + -------------------- ------------------ + | + ----------------- + + ----------- + | | | + --- + + --- + | | + --- + | | | | | A | et | B | | ou | pas | C | | | | | + --- + + --- + | | + --- + | | | + ----------------- + + ----------- + | + ----------- --------------------------- + Drop "ou" après "pas C". + ---------------------------------------------- ------- + | + -------------------------- + | | + ----------------- + | + ----------- + | | | | + --- + + --- + | | | + --- + | + ----- + | | | | | A | et | B | | ou | | pas | C | | ou | ... | | | | | + --- + + --- + | | | + --- + | + ----- + | | | + ----------------- + | + ----------- + | | | + -------------------------- + | + --------------- -------------------------------------- + Drop D sur "...". + ------------------------------------ --------------- + | + ------------------------ + | | + ----------------- + | + ----------- + | | | | + --- + + --- + | | | + --- + | + --- + | | | | | A | et | B | | ou | | pas | C | | ou | D | | | | | + --- + + --- + | | | + --- + | + --- + | | | + ----------------- + | + ----------- + | | | + ------------------------ + | + ----------------- ---------------------------------- +
Les éléments de requête individuels (A, B, etc.) sont construits avant d'être déposés dans le panneau, à l'aide de zones de liste déroulante ou de tout élément nécessaire. De petites marges et des couleurs alternées pourraient rendre cela très lisible, ainsi que des règles d'affichage qui font, par exemple, une chaîne de ors afficher à un seul niveau:
+ ------------------------- + | + --- + + --- + + --- + | | | A | ou | B | ou | C | | | + --- + + --- + + --- + | + ------------------------- +
Naturellement, les éléments de requête peuvent être développés, réduits, réorganisés et modifiés après avoir été déposés dans le panneau de composition.
Je ne dis pas que c'est la façon la plus simple de construire un système à cet effet. En fait, du point de vue du développement, c'est probablement aussi difficile que possible. Mais c'est la chose la plus efficace et intuitive que je puisse imaginer, et de toute façon, il s'agit essentiellement d'un clone de l'interface utilisateur de la règle de messagerie Apple Mail, mais en mettant davantage l'accent sur la hiérarchie.
J'espère que cela se révèle utile dans votre recherche de ce qui est bien.
CognitoForms a la solution ET/OU la plus intuitive que j'ai rencontrée 
Voici une interface pour composer la logique booléenne.
Quelques réflexions
- L'interface commence simple
- Si cela se complique, c'est parce que l'utilisateur l'a construit pas à pas
- Pas de modification ni de glisser/déposer - il suffit de créer et de supprimer des branches
- Les conditions sont une simple liste déroulante dans cet exemple, mais pourraient être plus compliquées ou éventuellement annulées
Ambiguïté
En passant, je suis également préoccupé par l'ambiguïté des chemises "montrez-moi le rouge et le bleu", car l'utilisateur pourrait techniquement signifier "rouge ou bleu " chemises.
Je pense que si vous leur demandez de décrire la version singulière (une "chemise") alors le problème est quelque peu réduit. Par exemple, ils ne diraient pas "Montrez-moi une chemise rouge et bleue" s'ils signifient "rouge ou bleu".
Ajout d'un exemple de application de billetterie que nous avons développé.
Au lieu de regrouper "ET/OU", nous avons opté pour une liste déroulante "tout/tout/aucun" en haut. Exactement à cause de l'exemple mentionné ci-dessus: lorsque des personnes non techniques disent "donnez-moi des commandes de New York et du New Jersey", tit signifie en fait "OU logique".
Nous avons également décidé de ne pas regrouper plusieurs combinaisons complexes ET/OU, car les gens étaient confus. Nous leur proposons plutôt une "récursivité", proposant de "déclencher une autre règle" (en bas de la capture d'écran).
Je travaille sur une refonte d'une application web qui utilise Boolean et l'image ci-dessous montre comment cela se fait actuellement. L'utilisateur peut supprimer les crochets si nécessaire ou les rajouter. J'ai du mal à trouver une meilleure façon de le faire, donc je peux finir par garder cette partie que les utilisateurs semblent utiliser assez bien.
Mon interface utilisateur préférée pour l'élaboration de règles est serveur de scénario d'ATG . Regarde ça:
Pour créer des requêtes table unique relativement complexes, les tableaux croisés dynamiques sont très utiles.
Bon produit
- Vous pouvez obtenir
SUM,AVGetGROUPavec relativement peu de connaissances. - En divisant les champs entre colonnes et lignes, vous obtenez des requêtes
AND - Les totaux vous donnent des requêtes
OR - Vous pouvez correctement `` construire '' des requêtes - c'est-à-dire que vous pouvez rapidement voir un ensemble maître, puis ajouter des lignes/colonnes et ensuite ajouter des filtres qui vous indiquent quelles données sont disponibles pour filtrer
Mauvaises choses
- Je suppose que vous atteindrez des limites si vous essayez de combiner plusieurs tables/ensembles de données.
- Selon la profondeur d'imbrication de vos requêtes
AND/OR, vous pourriez avoir des problèmes
Mais au moins, vous n'avez pas une tonne de zones de liste déroulante, et les zones de liste déroulante que vous avez sont plus intuitives.
En voici une que j'ai faite plus tôt avec de belles statistiques de football fantastique pour aller avec.
Il est difficile de cerner exactement ce qui est intuitif pour quelque chose qui a été traditionnellement traité par les utilisateurs techniques (qui ne trouveront pas nécessairement des interfaces plus conviviales par rapport aux invites de commande). Il y a une raison particulière à cette efficacité, car les requêtes peuvent être spécifiées sans ambiguïté et exécutées dans une invite de ligne de commande. De plus, cela ne surprendra probablement personne que la conception d'interface traditionnelle se cassera probablement en ce qui concerne les requêtes plus complexes.
Néanmoins, je pense qu'il est probablement sûr de dire qu'en matière de logique booléenne, le thème le plus courant/familier doit être le diagramme de Venn. La question pourrait donc être de savoir comment prendre les déclarations précises des requêtes de base de données et les combiner avec la simplicité d'une interface de type diagramme de Venn?
Je pense que conceptuellement, une solution possible serait de combiner à la fois la disposition spatiale et les interactions des utilisateurs qui reflètent la nature des opérations qui sont effectuées. De cette façon, vous transmettrez le concept du diagramme de Venn aux utilisateurs tout en rendant les opérations suffisamment intuitives pour être comprises. Donc, cela prend effectivement ce que @bendytree et @sboye ont suggéré pour effectuer la saisie de données réelle, mais également pour produire le résultat de ces opérations sous la forme d'un diagramme de Venn afin que l'utilisateur puisse voir immédiatement s'il a effectué le bon type d'opération booléenne . Mais vous voudrez peut-être rendre l'entrée encore plus facile en implémentant un glisser-déposer pour les opérateurs booléens et les jeux de données/champs que vous souhaitez afficher, en s'inspirant de certains des diagrammes Venn interactifs que vous pouvez trouver dans les recherches Google.
S'il est mobile, disposez d'un bouton pour chaque opération qui le saisit simplement dans une zone de texte. Fournissez un lien pour aider sur l'algèbre booléenne et similaires. Ce serait à la fois simple et flexible.