Interfaz intuitiva para componer lógica booleana?

El principal problema que los usuarios no técnicos tienen con la lógica booleana es entender la diferencia entre AND y OR porque no siempre corresponde al lenguaje natural (por ejemplo, "muéstrame órdenes de Nueva York y Nueva York"). Jersey ”casi seguramente significa Ubicación = NY OR Ubicación = NJ). A menudo, los usuarios tienden a interpretar" o "como un OR exclusivo. Luego está la cuestión de perder la noción de paréntesis anidados.

Una solución que evita estos dos problemas es representar la lógica gráficamente con una plomería o metáfora eléctrica. Ha habido un par de líneas de trabajo con este enfoque:

Shneiderman, B (1991). Interfaces visuales de usuario para la exploración de información. Actas de la 54ª Reunión Anual de la Sociedad Americana de Ciencias de la Información, 28, 379-384.

Murray NS, Paton NW, Goble CA, Bryce J (2000) Kaleidoquery: un lenguaje visual basado en el flujo y su evaluación. Revista de Lenguajes Visuales y Computación, 11 (2), 151-189.

Los creadores de consultas son uno de los pocos lugares en los que tiene sentido tener modos básicos y avanzados separados. Probablemente encontrará que el 90% de las consultas de sus usuarios se ajustan solo a unos pocos patrones (por ejemplo, "Clientes cuyo nombre comienza con Xxxx", "Cuentas de las que soy responsable con facturas pendientes", "Pedidos realizados entre las fechas ayb "). Tiene sentido tenerlos como consultas enlatadas o semi enlatadas que se pueden seleccionar y especificar fácilmente mientras se coloca algo como Kaleidoquery en Avanzado para las consultas ad hoc más raras.

Este se probó bien con los usuarios técnicos y no técnicos y puede generar casi cualquier consulta de base de datos posible ...

Los beneficios son que está muy claro y un usuario puede arrastrar y soltar ( o eliminar ) cualquier expresión o grupo de expresiones en el árbol.

La desventaja es cuánto espacio consume.

Hay un complemento jquery para hacer esto, llamado QueryBuilder, que hace esto de una manera interesante: http://mistic100.github.io/jQuery-QueryBuilder/

Me gusta la forma Apple Las reglas del correo funcionan:

Aquí hay bastantes buenas ideas/referencias, especialmente para algunos enfoques existentes. A menudo, aunque no siempre, el enfoque de Apple es un buen lugar para comenzar, pero quizás en su caso no lo sea. Tengo la impresión (aunque en realidad no lo ha dicho) de que está trabajando con una gran cantidad de datos compuestos por muchos campos/variables.

Estoy de acuerdo en que tratar de encontrar una manera de simplificarlo para usuarios menos técnicos es una buena idea, siempre y cuando espere tener usuarios menos técnicos que utilicen el sistema. De lo contrario, desarrollar una interfaz menos complicada puede requerir mucho trabajo y poco beneficio. También me gusta la idea de un diagrama de Venn, sería interesante ver cómo se desarrolla.

Sin embargo, en términos de sugerencias reales sobre cómo simplificar esto, otro enfoque sería crear algún tipo de proceso de "Asistente" que guíe al usuario a través del proceso con una combinación de lenguaje natural y una apariencia familiar de "web". A continuación se muestra una maqueta de cómo podría funcionar esto, utilizando un ejemplo de una base de datos de vehículos de motor:

Lo anterior muestra cómo podría funcionar el Paso 1, brindando a los usuarios una serie de opciones que pueden seleccionar marcando la casilla correspondiente. Pueden seleccionar una o más casillas de verificación según sea necesario (¿o tal vez ninguna?). Si seleccionan una casilla de verificación para una opción que requiere más información, las palabras relevantes se vinculan. Al hacer clic en las palabras con hipervínculos, el usuario presentaría algo como el siguiente ejemplo:

Por lo tanto, el ejemplo anterior muestra lo que un usuario puede ver si seleccionó la casilla de verificación "El vehículo es producido por fabricantes particulares" y luego hizo clic en el texto con hipervínculo para seleccionar los fabricantes que desea incluir en los resultados de búsqueda. Por supuesto, su enfoque puede diferir dependiendo de si deberían ver un campo de texto libre, una lista desplegable de opciones, etc.

Ahora, para tratar cualquier "excepción" a los criterios de búsqueda, básicamente volvería a crear la primera ventana, pero con una redacción diferente, como:

Entonces, después de seleccionar la excepción de combustible anterior, el usuario hace clic en las palabras hipervinculadas "combustible particular" para elegir la excepción de la siguiente manera:

Una vez más, esto podría ser una lista desplegable, botones de radio, etc., dependiendo de lo que mejor se adapte a la condición. También pasarían por el mismo proceso para seleccionar el país en el que no querían que se fabricara el vehículo.

Por supuesto, veo este enfoque de "Asistente" para usuarios menos técnicos. También ofrecería una opción "Avanzada" para usuarios que se sientan cómodos con un enfoque más complicado que puede simplificarse en comparación con el enfoque Wizard.

[~ # ~] anexo [~ # ~]

Bien, esto me mantuvo despierto anoche. De hecho, veo este enfoque Wizard) como un buen camino a seguir, así que pensé que valía la pena volver a mejorar mi respuesta, ya que puede ayudar a alguien más si no a ti.

He actualizado las imágenes de la maqueta anterior y quería ampliar su idea de usar una pantalla dividida.

Originalmente pensé que después de completar el último paso, entonces algo como su idea del diagrama de Venn podría usarse para indicar visualmente lo que el usuario ha elegido. Pero luego pensé en mi afirmación original de que también debería haber una manera para que el usuario vaya y venga para modificar sus criterios. Así que ahora estoy pensando que usando tu pantalla dividida podrías lograr ambos. A continuación se muestra una nueva imagen para ilustrar lo que estoy pensando:

Entonces, lo anterior es un ejemplo de lo que podría aparecer en la segunda parte de su pantalla dividida. A medida que el usuario selecciona sus criterios, esto se actualiza para indicar cuáles han sido sus selecciones. Este enfoque también utiliza el aspecto web familiar de resaltar sus opciones con hipervínculos y, si quisieran, podrían cambiar sus criterios haciendo clic en los hipervínculos dentro de esta pantalla, en lugar de tener que ir y venir entre pantallas para rehacer su pasos. Por supuesto, si quisieran seleccionar una nueva condición , tal vez tendrían que volver al paso correspondiente. Pero se entiende la idea.

La única otra cosa que me gustaría mencionar es que sin conocer la complejidad de sus datos, es posible que necesite refinar este enfoque Wizard. Mi base de datos de vehículos simple solo necesita dos pasos, pero un proceso complicado uno puede necesitar más pasos. Sin embargo, el objetivo de este enfoque no está tanto en el número de pasos, sino en el hecho de que el Wizard 'habla' a las personas a través de los pasos usando lenguaje natural como tanto como sea posible.

De todos modos, espero que esto, junto con las otras respuestas proporcionadas, te dé algo de reflexión. Y tal vez algunos otros. Este es un buen tema y creo que será relevante para muchos usuarios.

¡Buena suerte!

Depende del nivel de sofisticación de sus usuarios. Tenemos algo similar en la versión actual de la interfaz, hemos omitido la agrupación y corregido la conjunción entre los términos a OR. Cada término puede ser negado. La mayoría de los usuarios están de acuerdo con ese tipo de consultas y la mayoría de ellos no podrían formular consultas más avanzadas correctamente. Ahora estamos implementando un proceso de dos pasos en el que el resultado de una consulta se puede utilizar para limitar la población en una consulta siguiente (sin incluir la agrupación explícita en la interfaz de usuario).

La interfaz de usuario para esto es una lista básica de restricciones que se pueden agregar, eliminar, activar, desactivar y negar. Esto ha sido suficiente para la mayoría de las consultas que los usuarios desean crear. Teníamos un diseño para una nueva versión que se basaba en un concepto de flujo de datos (inspirándose fuertemente en vistrails, ver más abajo) pero que nunca se ejecutó. Vistrails es un producto que se puede utilizar para crear tuberías VTK. Si desea seguir la ruta de muchas piezas de IU, el flujo de datos funciona para formular consultas, pero también funciona para formular el formato de salida.

Busca inspiración en

• Yahoo Pipes
• Buscador de manzanas
• Búsqueda de Thunderbird
• Vistrails

A diferencia de reutilizar tablas dinámicas como lo hice anteriormente respondido , esta es una interfaz de usuario experimental que pensé para manejar la necesidad repetitiva de escribir AND o OR.

Se basa en un elemento que debe aprender que ANDs son horizontales y ORs son verticales. Sin embargo, se las arregla para lidiar con una lógica booleana bastante compleja.

Visión general

Suponga que A, B, C, D y E son expresiones booleanas.

Para probar el concepto, aquí es cómo dibujaría los dos lados diferentes de una equivalencia booleana estándar:

(A and B) or C === (A or C) and (B or C)

Esto se extiende a consultas más complejas:

((A and B and C) or D) and E

IU real

Para esta tabla de datos:

La pantalla se divide en dos:

1. Un conjunto de filtros (efectivamente AND consultas)
2. Una combinación de los filtros.

Establece los filtros (estos simplemente se escriben con el registro condicional básico) y luego lo arrastra para 'fusionarlo' con la consulta completa.

Después de arrastrar el nuevo conjunto de filtros, el lado izquierdo vuelve a una lista sin filtrar y el lado derecho muestra el conjunto de datos 'combinado':

Entonces deberías poder arrastrar y editar las expresiones en el lado derecho, pero eso requiere mucho más trabajo.

Microsoft Access hizo un intento razonable de una simple interfaz de usuario de consulta de base de datos al producir una versión visual de "Consulta por ejemplo"

Tiene un lenguaje más natural que evita la necesidad de una interfaz de usuario anidada , a expensas de ocasionalmente entradas un poco más redundantes en las líneas.

^{descargar fuente bmml - Wireframes creados con Balsamiq Mockups}

Es una vieja pregunta, pero pensé que contribuiría en caso de que alguien esté interesado. Aunque ya se han proporcionado muchas respuestas interesantes, diseñé para nuestra aplicación lo siguiente:

Inicialmente hay solo la primera expresión de grupo y una regla. Al hacer clic en 'Agregar condición', se agrega una nueva condición encima, mientras que 'Agregar grupo' agrega un nuevo grupo directamente debajo de él; grupos adicionales del grupo principal son hermanos, mientras que puede crear anidamiento infinito usando el botón 'Agregar grupo' desde un grupo anidado.

En los dispositivos móviles, las condiciones se acumulan, junto con el botón de acción 'eliminar', que ahora cambia su texto a 'Eliminar condición'.

El diseño funciona bien, se ve bien, responde y no consume demasiado espacio tampoco.

Bonificación adicional: sobre el grupo, una sola línea muestra la condición final producida, por ejemplo

[Fecha mayor que XXX Y (Nombre igual a Nick)]

editar: para que sea más accesible para personas no técnicas, seguiría lo que otros dijeron en este hilo: seguir el camino de Apple. En lugar de AND/OR, usaría ALL/ANY + context.

Si sus usuarios son lo suficientemente avanzados como para conocer la jerarquía de una consulta, cualquier interfaz gráfica que les dé debe ser lo suficientemente fluida como para no interponerse en su camino. Creo que una interfaz basada en arrastrar y soltar elementos para crear una jerarquía implícita es ideal. Aquí hay un ejemplo visual anotado extendido de cómo un usuario puede construir la consulta (A and B) or ((not C) or D):

 Coloque A en el panel. 
 + --- + 
 | A | 
 + --- + 
 
 Drop "y" después de A. 
 + --------------- ---- + 
 | + --- + + ----- + | 
 | El | A | y | ... | | 
 | + --- + + ----- + | 
 + ------------------- + 
 
 Soltar B en "...". 
 + ----------------- + 
 | + --- + + --- + | 
 | El | A | y | B | | 
 | + --- + + --- + | 
 + ----------------- + 
 
 Suelte "o" después "y". 
 + -------------------------------- + 
 | + ----------------- + | 
 | El | + --- + + --- + | + ----- + | 
 | El | El | A | y | B | El | o | ... | | 
 | El | + --- + + --- + | + ----- + | 
 | + ----------------- + | 
 + ------------------------ -------- + 
 
 Suelta C en "...". 
 + ---------------- -------------- + 
 | + ----------------- + | 
 | El | + --- + + --- + | + --- + | 
 | El | El | A | y | B | El | o | C | | 
 | El | + --- + + --- + | + --- + | 
 | + ----------------- + | 
 + ------------------------ ------ + 
 
 Suelte "no" en C. 
 + -------------------- ------------------ + 
 | + ----------------- + + ----------- + | 
 | El | + --- + + --- + | El | + --- + | | 
 | El | El | A | y | B | El | o | no | C | El | | 
 | El | + --- + + --- + | El | + --- + | | 
 | + ----------------- + + ----------- + | 
 + ----------- --------------------------- + 
 
 Suelte "o" después de "no C". 
 + ---------------------------------------------- ------- + 
 | + -------------------------- + | 
 | + ----------------- + | + ----------- + | | 
 | El | + --- + + --- + | El | El | + --- + | + ----- + | | 
 | El | El | A | y | B | El | o | El | no | C | El | o | ... | El | | 
 | El | + --- + + --- + | El | El | + --- + | + ----- + | | 
 | + ----------------- + | + ----------- + | | 
 | + -------------------------- + | 
 + --------------- -------------------------------------- + 
 
 Soltar D en "...". 
 + ------------------------------------ --------------- + 
 | + ------------------------ + | 
 | + ----------------- + | + ----------- + | | 
 | El | + --- + + --- + | El | El | + --- + | + --- + | | 
 | El | El | A | y | B | El | o | El | no | C | El | o | D | El | | 
 | El | + --- + + --- + | El | El | + --- + | + --- + | | 
 | + ----------------- + | + ----------- + | | 
 | + ------------------------ + | 
 + ----------------- ---------------------------------- + 

Los elementos de consulta individuales (A, B, etc.) se construyen antes de colocarlos en el panel, utilizando cuadros combinados o cualquier elemento que sea necesario. Pequeños márgenes y colores alternos podrían hacer que esto sea muy legible, así como mostrar reglas que hacen, por ejemplo, una cadena de ors mostrada en un solo nivel:

 + ------------------------- + 
 | + --- + + --- + + --- + | 
 | El | A | o | B | o | C | | 
 | + --- + + --- + + --- + | 
 + ------------------------- + 

Naturalmente, los elementos de consulta se pueden expandir, contraer, reordenar y editar después de colocarlos en el panel de composición.

No digo que esta sea la forma más fácil de construir un sistema para este propósito. De hecho, desde el punto de vista del desarrollo, probablemente sea tan difícil como puede ser. Pero es la cosa más eficiente e intuitiva que se me ocurre, y de todos modos es básicamente un clon de la Apple UI de la regla de correo pero con más énfasis en la jerarquía.

Espero que esto sea útil en su búsqueda de lo que es correcto.

CognitoForms tiene la solución AND/OR más intuitiva que he encontrado

Aquí hay una interfaz para componer la lógica booleana.

Algunos pensamientos

• La interfaz comienza simple
• Si se complica, es porque el usuario lo construyó paso a paso.
• Sin edición o arrastrar/soltar: solo crea y elimina ramas
• Las condiciones son un simple menú desplegable en este ejemplo, pero podrían ser más complicadas o posiblemente negadas

Ambigüedad

Por otro lado, también me ha preocupado la ambigüedad de las camisas "muéstrame rojo y azul" ya que el usuario podría significar técnicamente "rojo o azul "camisas".

Creo que si les preguntas que describan la versión singular (una "camisa"), entonces el problema se reduce un poco. Por ejemplo, no dirían "Muéstrame una camisa roja y azul" si significan "rojo o azul".

Añadiendo un ejemplo de aplicación de tickets que desarrollamos.

En lugar de agrupar "Y/O" nos decidimos por un menú desplegable "todo/cualquiera/ninguno" en la parte superior. Exactamente por el ejemplo mencionado anteriormente: cuando las personas no técnicas dicen "dame órdenes de Nueva York y Nueva Jersey" tit en realidad significa "OR lógico".

También decidimos no agrupar múltiples combinaciones AND/OR complejas, ya que las personas se confundían. En su lugar, les ofrecemos una "recursión", ofreciendo "activar otra regla" (en la parte inferior de la captura de pantalla).

Estoy trabajando en un rediseño de una aplicación web que utiliza Boolean y la imagen a continuación muestra cómo se está haciendo actualmente. El usuario puede eliminar los corchetes donde sea necesario o agregarlos nuevamente. Estoy luchando por encontrar una mejor manera de hacerlo, por lo que podría terminar manteniendo esta parte que los usuarios parecen estar usando bastante bien.

Mi interfaz de usuario favorita para la creación de reglas es servidor de escenarios de ATG . Mira esto:

Para crear consultas relativamente complejas de una sola tabla , las tablas dinámicas son muy útiles.

Buen material

1. Puede obtener SUM, AVG y GROUP con relativamente poco conocimiento.
2. Al dividir los campos en columnas frente a filas, se obtienen AND consultas
3. Los totales le dan OR consultas
4. Puede 'generar' consultas correctamente, es decir, puede ver rápidamente un conjunto maestro, luego agregar filas/columnas y luego agregar filtros que le muestran qué datos están disponibles para filtrar

Cosas malas

1. Supongo que alcanzarás los límites si intentas combinar más de una tabla/conjunto de datos.
2. Dependiendo de cuán profundamente anidada desee sus consultas AND/OR, podría tener problemas

Pero al menos no tienes un montón de cuadros combinados, y los cuadros combinados que tienes son más intuitivos.

Aquí hay uno que hice anteriormente con algunas estadísticas encantadoras de fútbol de fantasía para acompañarlo.

Es difícil precisar exactamente qué es intuitivo para algo que tradicionalmente ha sido tratado por usuarios técnicos (que no necesariamente encontrará interfaces más amigables para el usuario en comparación con las indicaciones de comando). Hay una razón particular para esta eficiencia, ya que las consultas pueden especificarse y ejecutarse sin ambigüedades en una línea de comandos. Además, probablemente no sorprenderá a nadie que el diseño de interfaz tradicional probablemente se rompa cuando se trata de consultas más complejas.

Sin embargo, creo que es seguro decir que cuando se trata de lógica booleana, el tema más común/familiar tiene que ser el diagrama de Venn. Entonces, la pregunta podría ser cómo tomar las declaraciones precisas de las consultas de la base de datos y combinarlas con la simplicidad de un diagrama de Venn como interfaz.

Creo que conceptualmente una posible solución sería combinar el diseño espacial con las interacciones del usuario que reflejen la naturaleza de las operaciones que se realizan. De esta forma, transmitirá el concepto del diagrama de Venn a los usuarios y hará que las operaciones sean lo suficientemente "intuitivas" como para comprenderlas. Entonces, eso es tomar efectivamente lo que @bendytree y @sboye sugirieron para hacer la entrada de datos real, pero también generar el resultado de esas operaciones en forma de diagrama de Venn para que el usuario pueda ver de inmediato si han realizado el tipo correcto de operación booleana . Pero es posible que desee facilitar aún más la entrada implementando algo de arrastrar y soltar para los operadores booleanos y los conjuntos de datos/campos que desea mostrar, inspirándose en algunos de los diagramas interactivos de Venn que puede encontrar en las búsquedas de Google.

Si es móvil, tenga un botón para cada operación que simplemente lo ingrese en un cuadro de texto. Proporcione un enlace para ayudar con el álgebra booleana y similares. Eso sería a la vez fácil y flexible.